Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on January 18, 2005, 07:12:22 pm
-
When I get some free time again, I'm thinking of adding some SEXPs:
set-camera-position - Sets camera position, like set-ship-pos(ition)
set-camera-facing - Sets camera facing, like set-ship-facing(?)
reset-camera - Resets view to whatever it was before
For simplicity's sake, these would lock the camera in position, unless the player tried to get out of the view or a camera SEXP was called.
Of course, here's where the problem comes in - I figure for the player's sake, esc should probably skip the cutscene. With the above method, the cutscene would continue anyways; the camera would just jump back to the previous view.
Also, the player's ship would continue to be flyable(Although, the mission designer could get- and set- the ship position/facing with the ship-invulnerable SEXP to keep the player from being too much of an arse ;).)
So, using SEXPs, how would people like to see cutscenes be setup and take into account things like the player hitting escape? (Should cutscene-skipping support be left up to the mission designer, through use of is-key-pressed?)
Oh, and for black bars, either a fourth argument for the set-camera SEXPs or a black-bars-on and black-bars-off system.
-
You. are. the. man.:yes:
-
Ugh. No, no, no, no, no. You can already do all that with the player ship - set-ship-position, set-ship-facing, etc. Play Shrouding the Light and see how Blaise Russel did his cutscenes. This is completely unnecessary and would only duplicate what we already have.
-
Unless you actually want to keep the player model in shot...
-
Yeah. And the black bars for the movieesque would be good too.
Ihope that that might be utilizeable for an autopilot flyby for WCS...
-
It'd be easier to FRED. You do something like:
set-ship-invulnerable
player-ship-use-ai
set-camera-position
And you've got your cutscene.
It should also work in multiplayer.
You don't have to worry about the player switching to different views (say, external views of his own ship) while the cutscene is playing.
You don't have to worry about the ship having a "show ship" flag (Which would be another SEXP to add, like toggle-hud)
It's the right way to do it and makes more sense when you're looking at the SEXPs.
And like vyper said, it means that you could see your own ship.
Finally, set-camera-position could be used for things other than cutscenes. Let's say you wanted to implement a remote-camera system; using is-key-pressed and set-camera-position you could switch to a remote camera point, write some text using a custom hud gauge and hud-set-text, and the player ship would still be flying - no need to try and make it look like the player stayed in the same place the whole time.
Edit: also, if shadows ever get reimplemented, you wouldn't have to worry about the 'camera' casting shadows.
-
How would this conflict with the cockpit code (visible ship models, actually)
-
Would it be possible for a lock-camera-on-object sexp, so the camera would follow a ship as it passed by? Or perhaps pan-camera, with arguments of left, right, up, down, degrees of pan and duration of the pan. Something like
When
-true
-pan-camera
--left
---20
--up
---90
--5
so the arguments are
--direction left/right
---degrees of left/right pan
--direction up/down
---degrees of up/down pan
--duration of pan in seconds.
Obviously the FREDer can opt to leave one of the directions blank it its only a 2D pan. We might also benefit from a translate-camera SEXP, to simulate zooms & such. It would need co-ordinates for the destination location, the amount of time the translation should take, and perhaps even an option to acclerate and decelerate on either end of the translation, so its not quite so jerky.
Feasable?
-
The sexps - for moving the camera would be incredibly usefull for other uses: force changing a ship's orientation, without the snappyness of set-ship-facing.
So we could force rotate a capship so it's port or starboard where it's weapons are (Orion) facing the NMEE.
As for the whole camera thing: is it possible to build a ship's that's only a view source? If yes we have a camera.
This kind of ship should also suffer from no tbl. restriction's - so any speed any rotation ratio and damp ration should be possible.
So I see 3 possible refinements for cutscenes and general FRED:
-Force gradual change in orientation
-Invisible Ship support
-Know-no-limit sexp for ships allowing to reset table values
The last will also make the overpowered engines possible. With that instead a case-by-case table tweak with a separate entry we could pick any given ship and simulte damage or power-redistribution or out of ordinary operation by changing the table values.
-
What about a camera ship? A *.pof file with an invisible texture it would also have unrestricted movement in the ships.tbl. All you would have to do then is place a camera ship in the mission or how many camera's you want.
You could also have a sexp called reset-player-view then specify the camera object. That way you still would have your player ship visible in the cutscene. IMHO
-
Originally posted by Falcon
What about a camera ship? A *.pof file with an invisible texture it would also have unrestricted movement in the ships.tbl. All you would have to do then is place a camera ship in the mission or how many camera's you want.
You could also have a sexp called reset-player-view then specify the camera object. That way you still would have your player ship visible in the cutscene. IMHO
Uhmm...that's not very different from what I suggested though it may not have transleted too well. *Sip*
-
Having a Pan feature would be incredibly usefull indeed. Almost _every_ other function is possible (yes, I've actually tested it!) with current SexPs except for that one.
-
...or force rotate a capship (not pitch or yaw but roll)?
-
Originally posted by Flaser
Uhmm...that's not very different from what I suggested though it may not have transleted too well. *Sip*
Actually its because I overlooked your post. :p
oooops......
-
set-cutscene-bars and unset-cutscene-bars implemented.
They take one argument - the number of milliseconds to add/remove the black bars (Done like homeworld).
I couldn't compile FRED, though.
-
what do those do?
-
Make it look like you're watching a widescreen movie :p
-
ok. thanks :)
-
Originally posted by WMCoolmon
set-cutscene-bars and unset-cutscene-bars implemented.
They take one argument - the number of milliseconds to add/remove
Hmm. Why have the milliseconds at all? Why not just turn them on and then a little while later turn them off?
-
I'm guessing here but if the FREDder has to handle the use of the ESC key then he'll want the game to snap back to normal when it's pressed.
-
So just do
when
--is-key-pressed
----ESC
--unset-cutscene-bars
--[clean-up-cutscene-stuff]
ESC is a reserved key, though, so it should be tied to something else. Maybe 'Q'.
-
I think you missed the point Goober. What I meant is that when the mission is supposed to start a cinematic scene it would be nice if the black bars slowly slide in and out of view like in homeworld (which from his post appears to be how WMC has implemented it) but when the user wants to skip out of a cutscene the black bars should dissappear instantly rather than slowly retracting.
Oh and you can't use Q either. That's the equalise shields button :D
-
I don't think you understand. If the key is going to be tied to the key-pressed sexp, it has to be one of the keys recognized by the game. ESC doesn't work because it shows the "Quit Mission" screen. I thought of Spacebar, but that fires missiles. Q for Quit (or perhaps S for Skip) are the least-invasive of any of the key-pressed keys that could be plausibly used. (Unless you want to say "To skip this cutscene, press '1'".)
-
New stuff:
fade-out
-- milliseconds to fade out
-- color to fade out to(Implemented but not working properly, may need lowlevel function editing)
fade-in
-- milliseconds to fade in
-
Originally posted by Goober5000
I don't think you understand. If the key is going to be tied to the key-pressed sexp, it has to be one of the keys recognized by the game. ESC doesn't work because it shows the "Quit Mission" screen. I thought of Spacebar, but that fires missiles. Q for Quit (or perhaps S for Skip) are the least-invasive of any of the key-pressed keys that could be plausibly used. (Unless you want to say "To skip this cutscene, press '1'".)
Ah. Fair enough. I suppose Q isn't bad. 1 would be a bad choice cause a lot of people use that for other things. Can't think of too many times when a player wouldn't want to equalise his shields straight after a cutscene :)
-
Planned camera stuff (Partially implemented):
set-camera-position
-- x point
-- y point
-- z point
set-camera-facing
-- x point
-- y point
-- z point
set-camera-rotation
-- x degrees
-- y degrees
-- z degrees
set-camera-facing-object
-- object name
(Not implemented)
setting-text
-- text
-- lines from bottom of screen
This would draw out text for giving a setting or time 1 letter at a time, as is done in many movies (I think it's done in Apollo 13)
Edit: Goob, are SEXPs calculated before game_render_frame_setup? That's where (ideally) the camera movement code would go. If not, where are they called from in game_frame?
-
Originally posted by WMCoolmon
set-camera-rotation
-- x degrees
-- y degrees
-- z degrees
Would this basically constitute a pan? Do you plan on adding a time factor so you can adjust the pan rate? If this is pan, why to you have x, y, & z? A vector only requires 2 variables. Am I wrong on my assumption that this is a pan function?
-
No; I'm not quite sure how I'll do pans yet, but that would be a change on the y axis. Hopefully I'll be able to peg an optional variable onto the end of the set-camera-* sexps, which will be the time it takes to complete whatever you asked it to do.
So, to do a pan 45 degrees to the left, you'd say something like:
set-camera-rotation
-- 0
-- 45
-- 0
-- 5000
With the two 0s being replaced by the current camera x and z rotations.
Another possibility would be change-camera-rotation, which would rotate the camera from its current position by however many degrees you specify (relative rather than absolute, in other words).
-
Originally posted by Trivial Psychic
Would this basically constitute a pan? Do you plan on adding a time factor so you can adjust the pan rate? If this is pan, why to you have x, y, & z? A vector only requires 2 variables. Am I wrong on my assumption that this is a pan function?
A two dimensional vector takes 2 arguments - 3D takes 3.
Though if you used polar cordinates then you'd need a radius, an azimuth and iclination angle. If we make all vectors a "unit" long than you can get away with only 2 angles.
-
i think a good idea for a pan is to have the cam_x, cam_y, and cam_z values stored as variables in fred, then use an every-time sexp to move it:
everytime
=
1
set-camera-pos
modify_variable
+
etc.
tweak dx,dy,dz as necessary
-
Originally posted by WMCoolmon
Edit: Goob, are SEXPs calculated before game_render_frame_setup? That's where (ideally) the camera movement code would go. If not, where are they called from in game_frame?
Yep. Immediately before, practically. Here's the game_frame excerpt:
[b]game_simulation_frame(); [/b]
// if not actually in a game play state, then return. This condition could only be true in
// a multiplayer game.
if (!actually_playing ) {
Assert( Game_mode & GM_MULTIPLAYER );
return;
}
}
if (!Pre_player_entry) {
if (! (Game_mode & GM_STANDALONE_SERVER)) {
clear_time1 = timer_get_fixed_seconds();
// clear the screen to black
gr_reset_clip();
if ( (Game_detail_flags & DETAIL_FLAG_CLEAR) ) {
gr_clear();
}
clear_time2 = timer_get_fixed_seconds();
render3_time1 = timer_get_fixed_seconds();
[b]game_render_frame_setup(&eye_pos, &eye_orient);[/b]
game_render_frame( &eye_pos, &eye_orient );The sexp stuff (among other things) is handled in game_simulation_frame().
-
Awesome. :D Thanks Goob.
Now implemented, the stuff I said in the first post. No gradual movement SEXPs yet, unfortunately.
http://www.hard-light.net/forums/index.php/topic,29763.msg607952.html#msg607952
-
What about subtitles? Are they possible there?
-
show-subtitle
-- subtitle text
-- image/animation to display to left of text (optional; default is none)
-- fade in time (optional; default is 0)
-- text redness (optional; default is 255)
-- text greenness (optional; default is 255)
-- text blueness (optional; default is 255)
-- text alpha (optional; default is 255)
-- x position (optional; default is centered)
-- y position (optional; default is at the bottom of the screen)
clear-subtitle
-- fade out time (optional; default is 0)
Would that be good?
-
Better than I've ever hoped:D
-
*goes off to implement it*
-
this sounds great for Willy_principal's "Battle of Beta Aquilae" demo.
now, make a new D3D version of FRED2 3.6.5 and i could have some fun with it. :D