Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Black Wolf on February 08, 2005, 12:17:32 pm
-
What would be the difficulty in modifying this to apply to waypoints as well?
-
*Checks*
virtually none, unless you wanted some sort of gradual transition.
-
Could the camera code be used for moving ships as well...
....or forcing ships to do off-table feats (set engines to overdrive, mad-immelman that sorta thigns)?
-
is there any way to get that to work with the subspace jump effect so you can make an intra system jump while in mission with it? so the ship will jump from its current position to its new position.
-
Yes to the camera code thing, although the camera code only fully supports rotation. Although you'd be limited in SEXPs to moving it towards certain ships or towards a specific position, you'd have to set the rotation manually. Although it'd be done to manually set the ship position, so it'd circumvent the collision detection code for that ship (It'd fly through ships).
Fixing anything besides the first thing would probably take enough work to warrant just adding the thing in itself. The upside would be that if you could override max ship speed on a per-ship instead of per-class basis you could add SEXPs pretty easily to do it too. I think.
With the camera code, you could pretty easily do a poor-man's subspcae jump effect (assuming we have a make-wormhole SEXP of some sort); set the camera to the player's position and make the warp wormhole, fade out, fade in to show the player ship flying away from the wormhole. (setting ship/camera position appropriately while things are completely black)
-
Originally posted by WMCoolmon
*Checks*
virtually none, unless you wanted some sort of gradual transition.
Nope - I can do any gradual transitions I'll need with every-time and variables.
-
I asked for this a while ago - suffice to say it's the best possible way to script dynamic capship battles because you have such fine grain control over where you want things to go.
-
Originally posted by Black Wolf
Nope - I can do any gradual transitions I'll need with every-time and variables.
IMHO a hardcoded sexp for gradual movement would be better, since anything going through and from the sexp system is bound to be slower and waste resources.
-
Originally posted by Flaser
IMHO a hardcoded sexp for gradual movement would be better, since anything going through and from the sexp system is bound to be slower and waste resources.
But a hardcoded system would be at best difficult as WM Coolmon suggested, as opposed to the apparently very simple system if it's not hard coded and we achieve the same results through sexping. Why go for a difficult option when a simple one presents itself? It's not like this is a massively high priority request after all - if it gets too difficult or complicated, it'll probably not be done.
Besides - what's the point of gradual waypoint movement? I only said it was possible with sexping because WMC brought it up - I can't think of a single situation where you'd need the kind of split second perfect movement for an object you can't even see.
-
It's possible, but there might be a complication if the code needs to calculate new paths.
Barring any complications, it could be done in less than 30 minutes.
-
You might want to contact Kazan about the autopilot he did for us, it sounds mostly similar to what's described here.(Basically, you have some waypoints, and when you press a certain button, time compression kicks in and your ship automatically flies to the selected waypoint/mission area)
-
That has nothing to do with this.
-
Was referring to WMC's poor man's warp point idea, with some "show subspace effect" sexp or something this could work.
Should have quoted that.
-
Originally posted by Goober5000
It's possible, but there might be a complication if the code needs to calculate new paths.
Barring any complications, it could be done in less than 30 minutes.
That's true, I didn't think of that. Unfortunately, I don't remember seeing the vm_matrix_interpolate in the path finding part of the code.
However, I don't think it would be a problem as long as the waypoint wasn't changed while a ship was in transit to it.
Edit: Oh, and the jump point stuff, if you were clever you could probably do it with the SEXPs and a finished version of the camera code, as well as a SEXP to activate the special clipping that occurs when the ship enters the wormhole. (It might be interesting to map that to a SEXP regardless.)
Anyway, I'm going to be quiet now, until I can actually implement this stuff. :p
-
http://fs2source.warpcore.org/exes/latest/C02092005x.zip
Includes latest CVS (taylor's latest builds) along with high-res fixes (Lockon thingy works now), the camera code (of course).
The SEXP is set-object-position, and is completely untested. It should work with anything though (including wings...if it actually works, changing the position of a wing should be fun to watch. :D)
-
Erm... thanks, but typically new sexps need a new FRED :p
I'll see what I can do with notepad.
-
Originally posted by WMCoolmon
The SEXP is set-object-position, and is completely untested. It should work with anything though (including wings...if it actually works, changing the position of a wing should be fun to watch. :D)
Er... did you modify set-ship-position or did you add a new sexp?
You should probably rename and change this to set-waypoint-position, since set-ship-position is already implemented and tested.
-
I added it as "set-object-position", and it takes an argument of SHIP_WING_POINT plus x, y, and z values.
I lazed out for the team option, It'll just grab the first ship it finds if it's given a team for the value. I may or may not fix that, since I doubt people will have much use for specifying a team.
Edit: Fixing it was easier than I thought, it'll do the same thing if a team is specified as if a wing is specified in my next build. :D
-
...but I had already added set-ship-position. Did you use the code I had, or did you create new code?
There shouldn't be a duplicate sexp. The two sexps should be merged somehow.
-
I used get_object_position's code, mostly. :p
Anyway, if you wanted to, you could just have set-ship-position call the set-object-position SEXP - it'd cause a lil' bit of slowdown though.
-
Actually, with so many campaigns in development (and released) that use set-ship-position, the best solution would be to change your sexp to set-waypoint-position and just drop the wings entirely. People can set individual ships if they really want to.
-
:wtf:
Just because it can do the same thing doesn't mean it HAS to. If having redundant SEXPs is so bad, we could always make set-ship-position deprecated by removing it from the list of SEXPs that can be added in FRED.
-
Originally posted by WMCoolmon
Just because it can do the same thing doesn't mean it HAS to.
Huh? It sounds like you're arguing my point here. Just because set-waypoint-position can, with little modification move ships as well as waypoints, doesn't mean we should incorporate set-ship-position's behavior.If having redundant SEXPs is so bad, we could always make set-ship-position deprecated by removing it from the list of SEXPs that can be added in FRED.
Except the SCP doesn't deprecate anything. We're fully backwards compatible. So removing it from the sexp list doesn't make any sense, because it will still always be supported.
-
I already wrote the code, added the features, everything. I could split it up into separate functions - set-waypoint-position, set-team-position, set-wing-position - but it'll just needlessly clutter up the SEXP list with extra SEXPs. I suppose I could also pop up an error message telling people to use set-ship-position instead of just doing it with set-object-position, but - why? :wtf: We've already got get-object-position SEXPs, it makes sense to have set-object-position SEXPs as well.
Except the SCP doesn't deprecate anything. We're fully backwards compatible. So removing it from the sexp list doesn't make any sense, because it will still always be supported.
But apparently it's absolutely unacceptable to have two fully supported SEXPs that can do the same thing. set-object-position does the same thing as set-ship-position and more, so it doesn't make much sense to keep set-ship-position in favor of set-object-position. I'd say just leave them both in - set-ship-position is slightly faster for setting ships and already used.
-
Set-wing-position isn't needed. Set-team-position makes no sense.
Bah. I'll check it out this weekend.