[Lt.Cannonfodder]

I realise that this has been discussed briefly before but I didn't want to  bump the old thread.

Is there any change we could get a fix to the broken cutscene-sexps? After some testing I've noticed that at least both set-camera-facing and set-camera-rotation won't work. At all. From previous threads of the subject I've gathered that they have worked before, thought they have been pretty buggy.

So far I've only tested the sexps with goob's latest build.

[WMCoolmon]

IIRC I looked into this and wasn't sure why they weren't working. It doesn't make any sense; AFAIK that code hasn't been modified from the working version, and what people have described sounds like it's the equation again.

Edit: The original big thread: http://www.hard-light.net/forums/index.php/topic,30036.0.html

The function used to input the data to turn the camera (unused code removed):

Code: [Select]

void camera::set_rotation(matrix *in_orientation, float in_rotation_time, float in_rotation_acceleration_time)
{
if(in_rotation_time > 0.0f || in_rotation_acceleration_time > 0.0f)
{
//Safeties
if(in_rotation_acceleration_time <= 0.0f)
in_rotation_acceleration_time = 1.0f;
if(in_rotation_time <= 0.0f)
in_rotation_time = 3.0f;
if(in_rotation_acceleration_time*2.0f > in_rotation_time)
in_rotation_acceleration_time = in_rotation_time/2.0f;

//Get the angles in radians
angles curr_orientation, new_orientation;
vm_extract_angles_matrix(&curr_orientation, &orientation);
vm_extract_angles_matrix(&new_orientation, in_orientation);

//Find the distance
angles d;
d.p = new_orientation.p - curr_orientation.p;
d.b = new_orientation.b - curr_orientation.b;
d.h = new_orientation.h - curr_orientation.h;

//Set the desired orientation
if(desired_orientation == NULL)
desired_orientation = new matrix;

if(in_orientation != NULL)
*desired_orientation = *in_orientation;
else
vm_set_identity(desired_orientation);

//Calculate the maximum acceleration speed
rotation_acc_limit.xyz.z = fabsf(d.p / ((in_rotation_time * in_rotation_acceleration_time) - square(in_rotation_acceleration_time)));
rotation_acc_limit.xyz.x = fabsf(d.b / ((in_rotation_time * in_rotation_acceleration_time) - square(in_rotation_acceleration_time)));
rotation_acc_limit.xyz.y = fabsf(d.h / ((in_rotation_time * in_rotation_acceleration_time) - square(in_rotation_acceleration_time)));

//Calculate the maximum velocity
rotation_vel_limit.xyz.x = fabsf(rotation_acc_limit.xyz.x * in_rotation_acceleration_time);
rotation_vel_limit.xyz.y = fabsf(rotation_acc_limit.xyz.y * in_rotation_acceleration_time);
rotation_vel_limit.xyz.z = fabsf(rotation_acc_limit.xyz.z * in_rotation_acceleration_time);
}
else
{
if(in_orientation != NULL)
orientation = *in_orientation;
else
vm_set_identity(&orientation);

set_rotation_velocity(NULL);
}
}

Code to turn the camera once the data is set:

Code: [Select]

if(desired_orientation != NULL)
{
matrix ori_out;
vec3d vel_out;

vm_matrix_interpolate(desired_orientation, &orientation, &rotation_rate, in_frametime, &ori_out, &vel_out, &rotation_vel_limit, &rotation_acc_limit, 1);
orientation = ori_out;
rotation_rate = vel_out;

//TODO: Make this "if(*desired_orienation == orientation)"
if(vel_out.xyz.x == 0.0f && vel_out.xyz.y == 0.0f && vel_out.xyz.z == 0.0f)
{
delete desired_orientation;
desired_orientation = NULL;
}
}

Unfortunately I can't find anything wrong with either. And I can't find the person who gave me the right equation that worked.

[Ransom]

When I last tried it (a month or two ago), it seemed that the camera would twitch a bit then get reset back to the first set-camera-facing position if you tried moving it. Sometimes it would move correctly, but in the wrong direction (left instead of up, in this case) before getting reset.

I'd very much like to see these working too.

[karajorma]

I tried using the set camera rotation SEXP and it did absolutely nothing regardless of what parameters I gave it.

[WMCoolmon]

Well, everything seems to be in order from when the working code was uploaded.

[WMCoolmon]

OK, I've included a test mission with four sexp operations.

You start out in a Ulysees, nothing else in the mission.

Hit 1. The camera should move to position 0,0,0 facing straight ahead.

Hit 2. The camera should rotate to face the Ulysses.

Hit 3. The camera should rotate back to its starting position.

Hit 4. The view will return to in-cockpit.

Now, on any recent released build, on "2" the camera will reset to its original position once its done. I'm guessing it hasn't been working for anyone else because they confused the ms value with seconds, so the camera jerked to the destination position, then jerked back to the original position. This is a bug, and I just uploaded a fix to CVS.

You can hit 3 while 2 is still working. It's not really working that well right now, because the calculations don't take into account the time to change velocity; they assume a starting velocity of 0.

Note that the set-camera-facing-object SEXP will only face the position of the object when called, so if you move after pressing 2, the camera will not follow you.

Finally, the camera should still move regardless of whether its active or not. So if you hit 2, then wait a couple seconds and hit 1, you should catch the camera partway through its movement. It's setup this way so you can have multiple cameras at once (although the SEXP system is only set up to handle one.)

[karajorma]

Ah. Now I see the way it's supposed to work

The bug in set camera facing meant I didn't see any change so I simply stuck things in an every-time SEXP and got a slight improvement

I think I know what I'm doing a bit better now so I'll have to play about with these. The stuff I had when I was doing it wrong looked cool already so I'm thinking that this will be a definate addition to my missions for SoR

I'm still confused about show-subtitle though. The help in FRED looks like this.

   Shows a subtitle  Takes 4 to 12 arguments...
   1:   X position (negative value to be from right of screen)
   2:   Y position (negative value to be from bottom of screen)
   3:   Time to be displayed, not including fadein/out
   4:   Text to display   5:   Image name
   6:   Fade in time
   7:   Center horizontally?
   8:   Center vertically?   9:   Width
   10:   Text red component (0-255)
   11:   Text green component (0-255)
   12:   Text blue component (0-255)

Yet when you add the SEXP it looks like this

Show-subtitle
-0
-0
-< Any String >
-0

As you can see the parameters don't match up. When I added more parameters it looks like 3 is set to string instead of int. Is that just a bug?

Edit : While I'm here what does the image option do anyway?

[WMCoolmon]

show-subtitle
    show-subtitle
    Shows a subtitle Takes 4 to 12 arguments...
    1: X position (negative value to be from right of screen)
    2: Y position (negative value to be from bottom of screen)
    3: Text to display 4: Time to be displayed, not including fadein/out
    (optional)
    5: Image name
    6: Fade in time
    7: Center horizontally?
    8: Center vertically? 9: Width
    10: Text red component (0-255)
    11: Text green component (0-255)
    12: Text blue component (0-255)

Just the description was incorrect.

"Image" should display a 2D image at the position, my thinking was that you could use this to display, say, homeworld style subtitles. You can also do that with the custom gauge system, but it seemed to fit with subtitles as well.

[karajorma]

Leave it blank if you don't want to use one I assume.

[SadisticSid]

OK, your test mission works without a hitch, but things still aren't working properly in my missions.

First off, I wanted to use waypoints to act as markers for the camera, so I could use their x, y and z co-ordinates as either the camera position or camera facing (therefore not having to enter them manually if I wanted to change them slightly). This doesn't work for waypoints using the get-object-x/y/z sexps.

Anyway, I tried using manual co-ordinates for the camera position and tried to make it face a cruiser in my mission using either manual co-ordinates or the set-camera-facing-object sexp. This works perfectly when I don't supply a turn time, but as soon as I do, it aims at completely the wrong point every time.

If you've time, have a look at it yourself - I'm using fs2_open_G-20050728.exe. BTW, the fade-in/fade-out sexps don't seem to work at all either.

EDIT: Is there any chance you can put in a move time and accell/decell time for the set-camera-position sexp in the same way as  set-rotation? That'd give us the ability to make some really good cutscene effects like a 'driveby' on a warship.

[Axem]

Regarding images subtitles, where do they need to be placed, and what image formats are supported?

[karajorma]

Gave your mission a try Sadistic Sid and you're correct. Something odd is going on but I'm  not having the same problems you are.

When I select and play the mission the camera fades in correctly giving me a shot of the planet/moon combo you probably wanted it to open on. It then pans the camera to the left until the sun is partially in shot.

When I click restart however it fades in looking at empty space and pans the camera to the left, past the sun to look at empty space again.

I have no idea why it's doing that. I can't see anything in the mission that could cause that behaviour either.



I'll take a look at the get-object-x problem in a bit. I see no reason why that shouldn't work unless get-object-x etc don't actually work for waypoints in the first place. It may be that this is a symptom of the other strangeness going on in this particular mission.

[karajorma]

Speaking of weird behaviour where did my wingman go? If I was playing Transcend I could understand but in my campaign there is no reason for a ship to just suddenly vanish. (He's still there when the cutscene ends so obviously the game is simply deciding not to render him). I'm using the fov SEXP so it might be related to that.

[taylor]

Originally posted by karajorma
Speaking of weird behaviour where did my wingman go? If I was playing Transcend I could understand but in my campaign there is no reason for a ship to just suddenly vanish. (He's still there when the cutscene ends so obviously the game is simply deciding not to render him). I'm using the fov SEXP so it might be related to that.

Not sure exactly what you are referring to but if it's the left most ship that vanishes just before the edge of the screen, and you are using OGL, then it's an OGL thing.  Something to do with the viewport setup when the cutscene bars are there but I've never actually tried to fix it.  It happens a lot on the death view as well.  The background and weapons fire will work fine but 2d lines and models get a bit weird.  Fixing that is pretty back burner at the moment, has been for most of the year in fact.  One day it will get fixed but it won't be today, or tomorrow, or the next day, or any day next week, or...

[karajorma]

Ah. I'll try it on D3D and see if the same thing happens

As long as it's fixed sometime before I release SoR I'm not hugely worried at the moment

[SadisticSid]

Originally posted by karajorma
Gave your mission a try Sadistic Sid and you're correct. Something odd is going on but I'm  not having the same problems you are.

When I select and play the mission the camera fades in correctly giving me a shot of the planet/moon combo you probably wanted it to open on. It then pans the camera to the left until the sun is partially in shot.

When I click restart however it fades in looking at empty space and pans the camera to the left, past the sun to look at empty space again.

I have no idea why it's doing that. I can't see anything in the mission that could cause that behaviour either.

I'll take a look at the get-object-x problem in a bit. I see no reason why that shouldn't work unless get-object-x etc don't actually work for waypoints in the first place. It may be that this is a symptom of the other strangeness going on in this particular mission.

I assume you mean the camera pans to the right to show the sun the first time the mission is played, but does it eventually point at the Mentu in or near the centre of the screen? That's what I wanted to happen.

The restart bug seems like some data isn't being reset in that particular function, since it doesn't occur when you exit and re-load the mission.

Any ideas why the fade-in isn't working on my system? I've tried running with D3D and OpenGL with all the high-memory usage graphics options on and all options off without effect.

[karajorma]

I have no idea why fade-in didn't work for you. Maybe it doesn't like having two fade SEXPs in the same Event. What happens if you trim out the Fade in and make it take 3 seconds to fade-out?

In neither case did I see the Mentu but it may simply be that the camera is positioned too far away (I made that mistake a couple if times and saw exactly what you saw. I nice starfield and no ships).

I'm going to be playing about with the cutscene SEXPs a bit more so I'll let you know if I figure out the cause cause right now I'm as stumped as you are.

[karajorma]

BTW about the disappearing Perseus. It disappears on D3D too (in fact the video was on D3D. I forgot that I'd changed to D3D mode to play TBP the night before).

So since it's D3D and OGL I guess it's something else.

[SadisticSid]

Originally posted by karajorma
I have no idea why fade-in didn't work for you. Maybe it doesn't like having two fade SEXPs in the same Event. What happens if you trim out the Fade in and make it take 3 seconds to fade-out?

In neither case did I see the Mentu but it may simply be that the camera is positioned too far away (I made that mistake a couple if times and saw exactly what you saw. I nice starfield and no ships).

I'm going to be playing about with the cutscene SEXPs a bit more so I'll let you know if I figure out the cause cause right now I'm as stumped as you are.

I put a fade-out sexp in before the fade-in one just to check if you needed something to 'fade in from'. I tried fade-out over time as you suggested and it doesn't work either on mine. I'm running Catalyst 5.3s on a Radeon 9800 Pro if that's any help, although the fact that they don't work in either D3D or OGL would indicate that drivers aren't the problem.

The Mentu is centred perfectly when you don't supply any extra parameters to the set-camera-facing-object sexp, i.e. an instant scene change. Give any numbers to it though and it aims somewhere else. If you watch the camera motion carefully you might see that the camera starts rotating in an arc towards the target, but then seems to aim along a flat plane about half way through the rotation. Perhaps this is why it ends up looking at the wrong point - since WMCoolmon's test mission has the camera and the Ulysees on the same flat plane, this might be why it succeeds there and fails in my mission.

[karajorma]

You're right about the get-object-x SEXPs not working BTW. It's not just something weird about that mission cause I just tested it in one of mine and had exactly the same thing happen.