Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Lukeskywalkie on August 07, 2008, 11:08:22 pm
-
I know there's a code freeze in effect, but...
One of the less immersive things about fs1 and 2 is the camera pull-out when you've jumped out. I know it's more of a style thing than a flaw, and it certainly signals the end of a mission with a certain amount of finality, but - especially with the 3d warp models, I think it'd be fun to stay in cockpit during jumpouts, to see what it looks like to have that welcoming vortex appear right in front of you, just before the mission ends - hell, it wouldn't even have to end when the ship was through - just when the nose touched the horizon.
is it possible to leave the camera at the HUD/cockpit view during jump-out, or is that hard-coded?
-
No, it's not possible. But you can simulate it by taking control of the player's ship with player-use-ai, flying through a vortex created with subspace-effect, and then calling end-mission.
-
Actually, you can just use player-use-ai and order the player ship to warp out. For some reason this won't make the camera pull out of the cockpit. It also doesn't play the 'powering up' sound, but that can be faked with play-sound-from-file.
You'd have to use end-mission as your ship touched the event horizon, though, because otherwise your view just goes straight through the vortex and out the other side.
-
Perhaps another question about players warping out. Is there any way to change the angle or rotation of the camera when it goes 3rd person?
-
Luke, you blooin Genius.
This little nugget has always been rattling around in my brain for the past 9 years...(ten+ if you count FS1)
I shoud have voiced this years ago...
PS Sith rule :nod:
Welcome aboard by the way..
-
It would be pretty cool to have a mission where you did go through the vortex first-person style, and then it immediately shifted to a jump corridor ala the last mission of Freespace 1. Actually, using that and enough control over the background, you could make a really long, continuous mission.
This will get a bit easier to do in the code when the warp camera code gets committed. However, it won't actually be possible with more work. The warp camera is now its own separate object, but it's fundamentally different from the multi-camera code in that it's updated every frame with a predetermined algorithm based on the object, rather than being updated only when it's needed with gradual position and rotation change data like the cutscene camera code.
I did think of one alternate idea of how to do this. The cutscene camera will override the warpout camera. So if you have use any of the set-camera-* SEXPs prior to the player warping out, it won't do the warpout view. So if you know where the eyepoints are, you can lock the cutscene camera to Alpha 1 (Or Red 1, etc) using set-camera-host. Then you could use set-camera-position to set the eyepoints. You'd also need to turn the HUD back on as the cutscene camera automatically turns it off. Haven't actually tried it, but the SEXP would look something like this:
when
-- player-starts-warpout (not an actual SEXP)
-- set-camera-host
---- "Alpha 1"
-- hud-disable
---- 0
-- set-camera-position
---- (eyepoint x)
---- (eyepoint y)
---- (eyepoint z)
If you had some scripting function to get the eyepoint you could use:
when
-- player-starts-warpout (not an actual SEXP)
-- set-camera-host
---- "Alpha 1"
-- hud-disable
---- 0
-- set-camera-position
---- script-eval-num
------ getEye("Alpha 1",1)
---- script-eval-num
------ getEye("Alpha 1",2)
---- script-eval-num
------ getEye("Alpha 1",3)
Where getEye is something like:
#Conditional Hooks
$Appliation: Freespace 2
$On Game Init: [
g_getEyeArray = {}
--These coordinates aren't right, just here for demo purposes
--Format: g_getEyeArray["Class name"] = {eyepoint x, eyepoint y, eyepoint z}
g_getEyeArray['GTF Ulysses'] = {0.0, 1.0, 2.0}
g_getEyeArray['GTF Hercules'] = {0.0, 3.0, 4.0}
--Add additional ships here
function getEye(shipName, axis)
--Get a handle to the ship we want
local ship = mn.Ships[shipName]
--If the ship is dead, return empty coordinate
if not ship:isValid() then
return 0.0
end
--Get what ship class the ship is
local className = ship.Class.Name
--If we don't have eyepoints for the class or a bad axis is given, return empty coordinate
if (g_getEyeArray[className] == nil) or (axis < 1) or (axis > 3) then
return 0.0
end
--Success! Return the eyepoint
return g_getEyeArray[className][axis]
end
]
Obviously you'd have to enter the eyepoints for your ship manually, which is a drag. At some point in the future, there should be an eyepoint function for models.
-
One long, continuous mission?
Children of Men: The Campaign!
-
Do you get checkpoints, so if you die you don't have to start again? Or have an option for those who like restarting things from scratch?
-
That depends on how good your FREDder is and how much time they spend on the mission. You can already do that, as well as have a list of options for where to start (Even without using scripting).
-
A "simulator" mission would be fun. Launch from a destroyer, jump to coordinates, fight, jump back to the destroyer, etc.
-
It would be pretty cool to have a mission where you did go through the vortex first-person style, and then it immediately shifted to a jump corridor ala the last mission of Freespace 1. Actually, using that and enough control over the background, you could make a really long, continuous mission.
I've actually tried this. I don't think it's possible at the moment without a set-subspace SEXP or something similar - set-skybox-model doesn't cut it for the subspace corridor.