Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on October 09, 2005, 02:50:23 am
-
In CVS now are some new SEXPs. None of these are tested, of course. :D There's no FRED under Linux.
set-object-speed-(x, y or z)
Overrides the current object's velocity (Should I rename to set-object-vel-*? hmm...) Note that it instantly changes the ship's speed; so the speed will likely continually decrease if you set it higher than how fast the ship wants to go.
EDIT: This should also theoretically work with waypoints, too... :drevil: And if a wing is specified, then all ships in that wing will have the effect applied to them.
Possible uses: Hyperspace effect? :D
ship-create
This is a SEXP that basically does some error checking on the variables and then calls the internal ship_create function. It lets you create a ship or ships without specifying it in FRED. But I am not sure if you'll actually be able to use other SEXPs on these ships since they won't exist at mission start.
Possible uses: Escape pods. With the any-ship and string arguments, you could autogenerate them for whatever ship classes without having to create each and every one in FRED.
Of course this is a somewhat dangerous SEXP since you may not know exactly how many ships will be made with it in every case in a mission. Use with care. :nod:
mission-set-nebula
Takes a true/false argument to determine whether the nebula is enabled or not.
Right now, I think FRED2 will only let you set the poofs if you turn on the nebula initially. However I've overriden that in the parsing code so that the variables will be loaded anywho if they exist.
If you start out in a nebula you will not be able to use the background nebula; and it looks like skyboxes will be replaced in non-HTL mode.
It will take a little more memory since both nebula and normal stuff has to be loaded, but it shouldn't be anything significant.
I haven't tested this beyond making sure that non-nebula and nebula missions seem to still work properly.
-
w00tage!
Some questions:
For the nebula sexp - does that mean that I can turn on a nebula in-mission after certain mission events or does it simply mean that I can determine at the start of a mission whether it has a nebula or not, depending on the outcome of the previous mission?
As for the set-ship-speed sexp: will it allow us control of ships as they exit subspace? That's really hte effect i'm looking for, IIRC. Something that will allow us to set the exit speed/vel for subspace. However, its use in cutscenes would definately be good :yes: :drevil:
-
Always happy to see new SEXPs :yes:
What happens if you create a new ship with the same name as an existing ship? I'll have to see if you can refer to these ships using a string variable rather than by selecting the ship from the list in FRED. Since variables are only checked during runtime it might let you. :)
-
Well, it means you can turn it on and off just like you might turn glowmaps on and off. So you might be able to use a campaign-persistent variable to toggle the nebula by switching it on/off depending on the status of that variable.
I don't think set-ship-speed will work when a ship is warping in, since those functions manually set physics values as well.
However it wasn't too hard to add in a manual override to ships.tbl :D Testing that now.
-
Done and in CVS. Values "$Warpin speed:" and "$Warpout speed:" are located just after "$Slide decel" and before the shockwave/explosion stuff.
I've added the values into the lab as well so you can fool around with them on the fly.
Or you can use a modular table: :thepimp:
#Ship classes
$Name: GTD Orion
+nocreate
$Warpin speed: 10
#End
If somebody wants this on a per-ship basis, it'll be pretty straightfoward to implement. The critical function is shipfx_calculate_warp_time()
Originally posted by karajorma
Always happy to see new SEXPs :yes:
What happens if you create a new ship with the same name as an existing ship? I'll have to see if you can refer to these ships using a string variable rather than by selecting the ship from the list in FRED. Since variables are only checked during runtime it might let you. :)
The SEXP returns NAN if the ship couldn't be created (Most likely a bad ship class was given), 1 if the named ship already exists regardless of class (In which case it'll do nothing), or 2 if a new ship was created.
-
These are some rather useful new sexps. :yes:
One question though, can ship-create create ships in wings?
-
Originally posted by WMCoolmon
mission-set-nebula
Takes a true/false argument to determine whether the nebula is enabled or not.
Hooray!
-
Originally posted by WMCoolmon
Done and in CVS. Values "$Warpin speed:" and "$Warpout speed:" are located just after "$Slide decel" and before the shockwave/explosion stuff.
I've added the values into the lab as well so you can fool around with them on the fly.
Or you can use a modular table: :thepimp:
#Ship classes
$Name: GTD Orion
+nocreate
$Warpin speed: 10
#End
If somebody wants this on a per-ship basis, it'll be pretty straightfoward to implement. The critical function is shipfx_calculate_warp_time()
[/B]
:wakka:
HORRAY!!
You've got a date with TBP!
-
Wow... WMCoolmon is on a roll. :eek2:
Don't stop announcing cool features!
BTW, this would work for Star Trek 'warps' too, right?
We got a warp-'flash' too. Just use an invisible map for the model...
:)
-
Originally posted by WMCoolmon
set-object-speed-(x, y or z)
Overrides the current object's velocity (Should I rename to set-object-vel-*? hmm...) Note that it instantly changes the ship's speed; so the speed will likely continually decrease if you set it higher than how fast the ship wants to go.
Now that I think of it any chance of having the corresponding accessor SEXPs too? I can think of a lot more uses for this if I have the corresponding Get-Speed SEXPs :D
-
Originally posted by WMCoolmon There's no FRED under Linux.
Actually, you can use taylor's 2005-06-30 Fred2Open build almost perfectly under wine.
More recent builds do not display ship coordinates on mouse over in my tests, and require OpenAl to be installed, and some dll's that my wine install does not have by default.
But it does work, and it's what i've been using. :)
-
Originally posted by karajorma
Now that I think of it any chance of having the corresponding accessor SEXPs too? I can think of a lot more uses for this if I have the corresponding Get-Speed SEXPs :D
Yeah, should be mostly copy-paste work.
-
Originally posted by DaBrain
Wow... WMCoolmon is on a roll. :eek2:
Don't stop announcing cool features!
BTW, this would work for Star Trek 'warps' too, right?
We got a warp-'flash' too. Just use an invisible map for the model...
:)
Well, you couldn't do the whole flash thing, but you could make it go really fast warping in. Imagine an Orion warping out...that's the sort of thing you'd have, except a lot faster.
-
?
We got the flash thing already.
(http://img342.imageshack.us/img342/2237/warp9fk.gif)
The only thing missing is the geometry deforming.
(which isn't really important imho)
-
OK. I finally tried the warpin/warpout speed thing, and it's not doing what I expect it to.
I would expect that setting them to someting like 300 for a fighter, would mean that a fighter would depart at and arrive at a speed of 300, rather than the 50 you'd have by default, and then decelerate from there. What IS happening is the figure seems to control how long the warp effect is remaining. The lower the figure, the longer the warp lasts.
Now, either A), I miss-interpreted what this feature is for, or B), the change to the actual warping speed hasn't been done in the code. The second possibility might explain the effect I described. If I set it at 300, the warp last for the duration it calculates that a ship at 300 m/s would require to warp out. A ship at 3 m/s would require that the warp effect last for quite some time for the ship to war out at, so it stays there.
-
I tried it for the Orion...fighters may use a different codepath to calculate the exact speed. Makes sense since it's pretty much always 50 m/s for fighters, but varies for capships depending on length. The code I changed was for the latter.
I see you've got it mantised :yes:
-
Could it be made to apply for fighters and bombers as well?
-
Has anyone tried the ship-create SEXP out yet? I wanted to make one new Hercules. Here's my code
$Formula: ( when
( and
( has-time-elapsed 3 )
( = 2 ( ship-create
"Ship 2"
"GTF Hercules"
0
0
0 ) )
)
( do-nothing )
)
+Name: Create Ship
+Repeat Count: 1
+Interval: 1
+Team: 0
Here's the result :eek: :confused:
-
:lol: They're breeding! :lol:
This would be a good effect for a Halo mod. :)
-
my god! The flood has infected them!!
[Donut]
Run for your lives!!!!1111
[/Donut]
-
Originally posted by Goober5000
:lol: They're breeding! :lol:
To be honest I think they were. As you can see from the picture there were at least 200 of them present when I took the picture and I think they were probably still spawning at 0,0,0 when I quit.
-
I think the problem is actually with your sexp:
when
--and
----has-time-elapsed
------3
----=
------2
------ship-create
--------Ship 2
--------GTF Hercules
--------0
--------0
--------0
--do-nothingWhy did you do it that way? :confused:
-
ship-create
ship-create
Creates a new ship
Returns NAN if ship couldn't be created;
Returns 1 if the ship already existed;
Returns 2 if the ship was created
Takes 5 to 8 arguments...
1: Name of new ship
2: Class of new ship
3: X position
4: Y position
5: Z position
6: Pitch (optional)
7: Bank (optional)
8: Heading (optional)
It was the only way I could get it to work. (the time elapsed stuff was just there so I could see the ship get created).
From what I can see, like special-check even though this does have action operator uses you still have to use it in the conditional part of the event. If I'm wrong feel free to tell me so but the fact that it returns a value seems to indicate that I've got it in the right place (Together with the fact that it complained about a mismatch when I accidentally replaced do-nothing with it.)
Also it still doesn't explain why I got 200 of the ships. It's a non-repeating event. I should have only got one as far as I can see.
-
HOW did you do it that way? The grouping's so FUBARed that I can't make heads or tails of how it's evaluating. The important problem regardless is that Ship-create is being used as part of the test evaluation rather than the action, so it will fire once each time the SEXP is evaluated at least until the event becomes true (if it becomes true, I don't know if ship-create will ever equal 2 for equality purposes). Thus the growth. If you want to use the return value, set it to a variable.
EDIT: You should probably put something in the event that will notify you of its completion (a message maybe) instead of do-nothing. Then you'll see why it's doing that.
-
I think you're right about why it's creating the ships (Cause it's evaluating the SEXP and creating a new ship each time it does so) but the fact is that after it's created the first one it should be unable to create any more hercs because the name is already taken.
That seems to point to the SEXP being broken somehow regardless of how hamfisttedly I used it. Besides I still don't see how I'm supposed to use it if not in the conditional part of the event. It has a return value see. If you look at the docs only SEXPs used in the conditional part have those. The action operators aren't supposed to return anything.
As for a message.I'm predicting I'll only see it once. :) I'll go test it now.
-
Bah. WMC's thinking too much in the C paradigm. :p
The only way that sexp will possibly work, as-is, is if you dowhen
--[condition]
--set-variable
----[return-value-variable]
----ship-create
------[...]and then evaluate the variable.
The conditional is evaluated every frame. Action stuff should not go in the conditional part of the sexp for this reason. (Come to think of it, that might be an interesting way to repeat events as a substitute for "every-time" that doesn't flush the sexp tree.)
Because of the prohibition on return values, the de facto paradigm for writing sexps is to have the sexp do everything correctly or else fail. It's the mission designer's responsibility to ensure that the failure condition cannot take place.
-
That's pretty much what I thought.
Special-check is the only SEXP that does things this way and it's an obvious hack anyway.
That said I ran the mission again and this time counted. I had ships named GTF Hercules 2 - 245 and no sign of one called Ship 2 as I'd requested in the SEXP in the first place :D
As I said before there's something else wrong with the SEXP.
I'll try it the way you suggest though :)
EDIT: I tested it and the ship was still called GTF Hercules 2. Am I doing something wrong or is it definitly the SEXP? Here's the code
$Formula: ( when
( has-time-elapsed 3 )
( send-message
"#Command"
"High"
"Test Message"
)
( modify-variable @JustForShow[0] ( ship-create
"Ship 2"
"GTF Hercules"
0
0
0 ) )
)
+Name: Create Ship
+Repeat Count: 1
+Interval: 1
+Team: 0
-
Actually it was a problem with the function. When given a ship name, it didn't actually use it. Looks like it was only called from FRED originally. (Fixed in CVS)
I can easily remove the return values if that'll make it evaluate properly. I don't get why it's evaluating every second or though...is that necessary or very hard to fix?
-
Can we get a 'mission-set-subspace' ?
-
Evaluating consistently is necessary for conditions, and your sexp is being treated as a condition. It needs to be treated as an action. This is easy to fix; simply change the sexp value to OPR_NULL and the function type to void.
Though you might want to modify the function so that if the ship with the specified name already exists, it uses the incremental "GTF Hercules 1" method.
-
Originally posted by Trivial Psychic
OK. I finally tried the warpin/warpout speed thing, and it's not doing what I expect it to.
I would expect that setting them to someting like 300 for a fighter, would mean that a fighter would depart at and arrive at a speed of 300, rather than the 50 you'd have by default, and then decelerate from there. What IS happening is the figure seems to control how long the warp effect is remaining. The lower the figure, the longer the warp lasts.
Now, either A), I miss-interpreted what this feature is for, or B), the change to the actual warping speed hasn't been done in the code. The second possibility might explain the effect I described. If I set it at 300, the warp last for the duration it calculates that a ship at 300 m/s would require to warp out. A ship at 3 m/s would require that the warp effect last for quite some time for the ship to war out at, so it stays there.
Can you determine if it's only b/c of class, or if it has something to do with length?
Also, is the speed of the ships that it isn't working properly for affected at all by the variable?
-
Originally posted by WMCoolmon
I don't get why it's evaluating every second or though...is that necessary or very hard to fix?
It wasn't evaulating every second. It was evaulating every frame.
By the time I'd turned around there were 200 of the buggers already. :D
What confuses me is why it stopped at 245. :)
-
Simple, the game presumably reached a limit and couldn't create any new ships. Thus the existance of a failure code.
-
I guessed it was a limit but 245 just seemed like an odd number :)
-
It's apparently not always 245. The screenshot you posted has GTF Hercules 263 targeted ;)
Presumably there's loss of ships from colissions too, if you're generating one per frame at the same point.
-
Actually I never saw any of the blow up :)
What I saw instead was a shoal of Hercs all swiming in the same direction :D
-
ROFL! Guess that shows how predictable the AI is.
But what's exploding in the earlier pic?
EDIT: And are those Hercs missing engine glows intentionally? Or is that a bug?
-
Now do that with one of the larger ship classes. :drevil:
-
Ah. I was running a test to see if ships created with the ship-create SEXP could be affected by other sexps. The idea was to have two ships. One I placed in FRED normally as a control and one created with SEXP and then self destruct the pair 20 seconds into the mission and see which ones blew up :)
I like using explosions as part of the testing procedure. It's so much more satisfying than any other SEXP and the events get logged quite nicely in the events screen so you can just press F4 and see exactly when everything blew up :)
Looks like I took the pic just as the control got destroyed. Which reminds me I need to rerun the experiment with the new CVS build redmenace just posted to see if they can be affected by SEXPs :)
As for the engine glows. Probably just a reappearance of the ongoing thruster bug.
-
I just thought of something potentially important for the create-ship SEXP. How is the IFF handled? What's in the table?
-
you know I always intended to implement as 'spawn list' were you have one or more ships that get spawned when a ship dies (and the position relitive to that ship's center).
don't supose you'd be willing to give that a go seeing as you are fresh on the relivent code
(it would also be cool if spawning of weapons would be posable on death)
-
Originally posted by Bobboau
you know I always intended to implement as 'spawn list' were you have one or more ships that get spawned when a ship dies (and the position relitive to that ship's center).
don't supose you'd be willing to give that a go seeing as you are fresh on the relivent code
(it would also be cool if spawning of weapons would be posable on death)
No, that's not needed. It can be done with the current sexps: when a ship is about to die, create W number of ships at X, Y, and Z relative to the ship's center. Much more customizable that way. :)
What would be useful, though, is a create-weapon sexp, just like create-ship. :D
-
not if you wanted to make a ship class that relies on spawning ships, if you made a shivan ship that was realy easy to kill but once you killed it it spawned five smaller ships, that were faster and tougher, there are things that it would work vastly superior as a ship property than sExp. and if you wanted one of those smaller ships to it'self spawn three other ships, the sExp system wouldn't work because the ship wouldn't be in game, and it would be totaly imposable in waves as well for the same reason.
-
Originally posted by Goober5000
What would be useful, though, is a create-weapon sexp, just like create-ship. :D
Yeah, I was thinking of some fire-weapon/create-weapon SEXPs for cutscene type things.
-
Originally posted by Goober5000
Because of the prohibition on return values, the de facto paradigm for writing sexps is to have the sexp do everything correctly or else fail. It's the mission designer's responsibility to ensure that the failure condition cannot take place.
Great slimy tentacles! And we want to adhere rigidly to the SEXP system exactly WHY?
-
Probably because of the exact confusion that lead to this discussion in the first place. If an action SEXP has a return value, non-coder types may interpret that is meaning the SEXP should be used in conditional evaluations. Which it should not, if it actually affects any change in the mission.
-
Er, no, that wasn't confusion. The SEXP worked exactly as I expected it to, and Kara used it exactly as I had intended it to be used. The problem lay in the system itself...it seems to evaluate SEXPs that return any kind of value every frame regardless of where they're placed.
The way it's set up is inefficient though. You'd need a minimum of three SEXP calls to duplicate the intendented functionality of the original. (One ship-exists call before it, one after it). Otherwise you could just set a variable equal to the ship-create call and check its value.
Granted it's pretty unlikely that the SEXP call will fail, unless you're near the ships limit.
-
Hmmm. I meant to post after posting the thread on General Freespace.
I've just checked and you can use SEXPs with ships spawned using ship-create perfectly well. I created a ship and then blew it up a few seconds later in a different event simply by using the when-argument SEXP so that I could supply the ships name as the < argument >.
String variables should no doubt work just as well :)
And WMCoolmon is correct. I didn't get the use of the SEXP wrong. Apart from the hack that Goober suggested there aren't any ways of simply using the SEXP from the action operator part of the event. :)
Problem at the moment is that if you put the ship-create SEXP in the conditional part of the event everything works fine until the newly created ship is destroyed. At which point its exact double pops up! I think we're going to have to hack the SEXP in like Goober suggested while it remains a conditional cause I do like the idea of being able to respawn ships that are already dead :D
-
Well, sorry... WMC made it an action event earlier today.
And in a fit of OCD, I went and added its create-weapon counterpart. :p
// Goober5000
{ OP_WEAPON_CREATE, "weapon-create\r\n"
"\tCreates a new weapon\r\n"
"\tTakes 5 to 10 arguments...\r\n"
"\t 1: Name of parent ship (or < none > for no parent)\r\n"
"\t 2: Class of new weapon\r\n"
"\t 3: X position\r\n"
"\t 4: Y position\r\n"
"\t 5: Z position\r\n"
"\t 6: Pitch (optional)\r\n"
"\t 7: Bank (optional)\r\n"
"\t 8: Heading (optional)\r\n"
"\t 9: Targeted ship (optional)\r\n"
"\t10: Targeted subsystem (optional)\r\n"
},
-
I can work around that. every-time ship-destroyed -ship-create should work just as well :)
-
Oooh...
Have a look at this. :D
http://fs2source.warpcore.org/temp/warpdrive.zip
-
Very cool :) It really does look like you're travelling at warp speed :)
BTW I noticed that the mission started out as my Bosch singing 6 bottles of beer on the wall mission :lol:
-
Er... yeah. :nervous: :D
-
Originally posted by StratComm
Probably because of the exact confusion that lead to this discussion in the first place. If an action SEXP has a return value, non-coder types may interpret that is meaning the SEXP should be used in conditional evaluations. Which it should not, if it actually affects any change in the mission.
You've just made a case against side-effects. That makes me feel dirty. Its times like this I thank the FSM that I am not a fredder.
-
I noticed a weird problem regarding warpout speeds. They're different for the player than for AI controlled ships. I was flying a Whitestar wing, (without using the special warpin/out table entries) and I ordered my wingmen to warpout one by one. When they did, they acellerated to about 150 m/s, but when I jumped, I dropped down to about 42 m/s. There appears to be a warpout speed restriction when it comes to the player's ship. Any chance this could be limiting my previous tests with the table entries? Any chance that this restruction could get lifted (ONLY in cases where table-defined warpin/out entries are present, to preserve backward compatability)?
-
Moved on from the 12-October CVS build to try my BoE stuff with Ship-Create and it appears as though when WMCoolmon changed the SEXP into an action operator he rolled the bug back into it.
The 14th-October build seems to be making up the number for the ship regardless of what I tell it to call the ship.
-
No, Goober 'bulletproofed' it. :doubt: I'll let him take this one since I'm not sure what he was trying to accomplish with that code...
if ((ship_name == NULL) || (ship_name_lookup(ship_name) < 0) || (ship_find_exited_ship_by_name(ship_name) < 0)) {
sprintf(shipp->ship_name, NOX("%s %d"), Ship_info[ship_type].name, n);
} else {
strcpy(shipp->ship_name, ship_name);
}
Translated into English:
"If a ship name isn't provided, or the ship doesn't exist, or the ship isn't logged as having departed, make up a ship name based on the class. Otherwise, use the name provided."
When I fixed I had it as "If a name isn't provided, make up a ship name. Otherwise, use the name provided."
-
That's odd. Cause I am providing the ships name (Via a when-argument list) and it's still causing bugs. You can find the mission I was using on this (http://www.hard-light.net/forums/index.php/topic,35794.0.html) thread (it's the modified Bearbaiting one).
-
No, the problem is very simple...
In order to use the name provided, the ship must already be in the mission, but also have already departed. I think those two things are mutually exclusive.
-
I see. Wasn't looking closely enough :)
That said I think Goober changed it when he made it possible to use none as a ship name. If that't the only edit he made then the bug predates his changes cause I'm using the 14th October build and those changes were made on the 16th.
I'll wait for Goober's comments and/or a new CVS build before commenting any further though :)
EDIT : Just tried the 16th October CVS build and the bug is present there.
-
Oh crap. Sorry. I added that to prevent collisions between ship names but I did it completely backwards. Fixed.
I seem to be doing a lot of bum commits lately. :nervous:
-
Every time i try to run the warp build you just posted, it gives errors about weapons.tbl then causes an application error in itself and crashes.
-
Just use any CVS build after the 14th and it should be in there anyway.
-
ZOMG NEW FEATURE WTF
"$Player warpout speed:" after "$Warpout speed:", will set the warpout speed of the player when he needs to warp out.
Note that there is code in Freespace 2 that won't let the player warp out if the speed is faster than the ship's speed witha ll power to engines.
If this causes problems for anybody let me know and I will take it out, barring rejections and a good reason to keep it in.
-
COOL! Gotta test this out with my Whitestar as soon as a new build comes up!
-
Now all we need is a FLASH (from the warp drives going "POOF" just before warp) and a BANG (the bright white warp point) for the Star Trek ships...
-
Originally posted by Gregster2k
Now all we need is a FLASH (from the warp drives going "POOF" just before warp) and a BANG (the bright white warp point) for the Star Trek ships...
and a /really/ rapid decelleration when dropping out of warp, could also be useful when coming out of hyperspace for the B5 effects.
-
Well, there is a way to simulate this. WMC's recent addition of the set-object-speed-x/y/z, you can give the player's ship a high speed to drop down from.
when-
-true
-set-object-speed-z (that's forward right)
--Alpha 1
--300
It'll decelerate from there.
-
Originally posted by Trivial Psychic
COOL! Gotta test this out with my Whitestar as soon as a new build comes up!
Speaking of which...
-
Originally posted by WMCoolmon
ZOMG NEW FEATURE WTF
"$Player warpout speed:" after "$Warpout speed:", will set the warpout speed of the player when he needs to warp out.
Note that there is code in Freespace 2 that won't let the player warp out if the speed is faster than the ship's speed witha ll power to engines.
If this causes problems for anybody let me know and I will take it out, barring rejections and a good reason to keep it in.
I can confirm the restriction. I set the player warpout speed and warpout/in speeds to 300 on my whitestar, but the top speed is somewhere in the 150 range, so I got the message when I tried to warpout, that listed speed exceeds the maximum speed of the craft, and that warpout would be aborted. I request that this limitation be removed.
-
Why the hell does that limitation exist anyway? Is there a reason?
-
Limitation removed in CVS
-
Originally posted by WMCoolmon
Limitation removed in CVS
It may be a good idea to still allow the limitation unless the player_warpout_speed option is set, just in case there is something which assumes the check exists. I can't really think of a reason why that would be but it's an easy enough check to add and then we won't have to worry about unbreaking something later.
-
That would be acceptable for my purposes.
-
More trouble than it's worth, IMHO, and it's more likely to fix problems with someone accidentally breaking the warp by setting ship speed too low.
Up til SCP, there would be no way to end the mission if the player couldn't jump out. So any mission after SCP is suspect, but even then I can't see much of a reason to restrict the player's warpout that way instead of using the disallow-warp (or whatever) SEXPs.
I did comment the code out with the date, rather than remove it entirely, since I can't just test it...but I think it'd be better to get rid of it completely, since it's such a little-known restriction that could totally confuse someone FREDding or modding as to why the player couldn't warp out.
basically if you're disabling warp it's probably due to some plot thing, rather than the ship class, and even in that case you can do it with SEXPs in the future.
-
set-object-speed-(x, y or z)
Overrides the current object's velocity (Should I rename to set-object-vel-*? hmm...) Note that it instantly changes the ship's speed; so the speed will likely continually decrease if you set it higher than how fast the ship wants to go.
EDIT: This should also theoretically work with waypoints, too... :drevil: And if a wing is specified, then all ships in that wing will have the effect applied to them.
Possible uses: Hyperspace effect? :D
OK, either I'm miss-interpreting how this is to take place, or its not working properly... or perhaps a bit of both.
First, is the x,y,z figure used relative to the craft, or to the game space? I'm using set-object-speed-z, similar to the method I mentioned a few posts up, but it ends up sending the crafts sideways. Maybe the XYZ directions are miss-aligned, like they are for rotational directions in PCS1.
Second, is the speed supposed to bleed-off after use? Even several minutes after use, ships are still dancing around a several hundred M/s.
What am I doing wrong?
-
Does the rotation of the ship in the world have any affect as to which way the ship goes?
-
I think its relative to the world. I used set-object-speed to simulate gravity for the BSG mod's combat landings. Even when I came in upside down I still landed on the deck.
Though I've only used the set-object-speed-y, so x and z might be mixed up or something.
-
Alrighty then. It seems that the "dancing around" effect I was getting, was because I was using an "every-time-argument" conditional for the activating sexp. I wish there was a "once-per-argument" conditional. Anyway, the result was that each ship was continuously getting a lateral speed boost. Next, it seems that these are world-relative xyz directions, which make it awkward if you want an object to move down a non-standard vector. Also, the speed bleeds off quite quickly, even for a 300 m/s boost. Finally, in the sexp's current state, it will refuse to move a ship down its own z-axis. What that means is that if I have a ship facing precicely 90 degrees to the right relative to the environment, and I use a set-object-speed-x, since that corresponds to the Z-axis of the ship, it will refuse to move it. I would definitely consider this a bug.
What I'd like to see is another set of sexps, to manipulate a ship's speed, but based of its own relative axis, rather than relative to the world. Also, a couple of figures included to manipulate both the time it takes for the object to decelerate from said speed down to a stop or to whatever its max speed is, or the amount of time it takes to acellerate to the speed.
The the current set-object-speed-x/y/z would become set-object-speed-world-x/y/z, while the new one would be set-object-speed-relative-x/y/z. The sexps arguments would look like this:
set-object-speed-relative-z
-Alpha 1
-300 (the speed to set it to)
-0 (the time it takes to accel to this speed, seconds)
-0 (the time it takes to decel from this speed, seconds)
For a ship warping-in, set accel time to "0", and decel time to "3", and it'll take 3 seconds after this sexp is fired, for the ship to reach its table-defined speed, or "0" depending. For a ship warping-out, the reverse is used. Setting them both to "0" will result in the default behaviour. Now, lets say you want a ship to employ a "ramming-speed" ability that exceeds its top speed. You'd make the speed, as whatever you'd like this ramming-speed to be, set the accel speed to however long you'd like it to take to reach ramming-speed, but since a ship should remain at its ramming-speed, you wouldn't want it to decelerate, so you'd set the decel speed to "-1". To disengage ramming-speed, have another instance of this sexp, but set to "0" accel and then a positive figure for the decel. I can't see any instances where having a "-1" accel would get you anything.
-
I wish there was a "once-per-argument" conditional.
Try invalidate-argument when you're done with each one.
-
set-object-relative-x would be easy.
Doing it with acceleration and stuff like you're saying would be a bit harder, but would be flexible later on.
Basically you'd have to create (Well, probably I'd have to create) a forced-movement system using the camera code algorithms. Probably as simple as adding a variable to objects, creating another Camera array, iterating that through every frame and overriding an object's movement so long as the forced movement hasn't been done yet.
Throw in a SEXP to add the object to the list and set the object's variable and that'd give you mostly what you're asking.
That'd be the simplest method, but it wouldn't give you exactly what you're asking. Instead you'd get a set-object-position function in the style of a set-camera-position function. (Or since that's not implemented yet, set-ship-rotation/set-camera-rotation)
Right now the SEXP just changes the current speed. gradual movement would require changes to either the object's phyiscs info, or overriding the object's phyiscs info. Either way you'd need a separate set of arrays and checks per frame.
-
I may be able to get some manually-controlled accel/decel by using a single every-time or repeating event per ship and setting a variable for each that gets it set lower and lower, or higher and higher each instance of the event. Of course, this won't work until that bug about models refusing to be being moved down their x-axis is fixed.