Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: zookeeper on August 31, 2009, 10:15:50 am
-
I've been making a hyperspace jump effect for FotG for a while now, and there's a couple of things that apparently can't really be solved by scripting:
1. Since $Warpout type: Hyperspace is used for SW-like warp effects where the ship just accelerates rapidly into the distance, ships that are warping out shouldn't be required to decelerate during the cancellable "engaging warp drive" part (right before the warp effect itself) in order to engage the warp. Instead, the ship should keep its original velocity during that phase until the warp begins.
2. The amount of time the "engaging warp drive" part takes should either be fixed (3 seconds sounds nice; I'm not sure what the default minimum is) or possible to specify or override in the ships table.
Of course, I'm assuming here that $Warpout type: Hyperspace isn't currently used in other mods/TCs or that they wouldn't mind such a change either. If it's used elsewhere and the current behaviour is liked, then of course any changes should be optional.
EDIT: A couple more:
3. When initiating a warp, the game checks whether there are any obstacles in front of you. However, this distance is really, really short for a hyperspace warp, meaning that in most cases you're free to jump away right through obstacles. Thus for $Warpout type: Hyperspace the collision check distance should rather be as long as possible.
4. It'd be very nice if it was possible to customize the time for the acceleration, instead of having the ship always assume full jump velocity in a split second. $Warpout Speed could be used for specifying how many seconds it takes for the ship to accelerate from its previous velocity to the full jump velocity, since apparently that property isn't currently used for anything when $Warpout type: Hyperspace. Although of course $Warpout Speed could be used for setting the actual final velocity and some new key for setting the acceleration time, too.
-
Here what I've done to simulate a pseudo hyperspace jump with the default Warping out from 3.6.9 or 3.6.10.
In my ships.tbl, I put this:
$Forward accel: 2.0
$Forward decel: 0.2
$Slide accel: 0.0
$Slide decel: 0.0
$Warpin speed: 15500
$Warpout speed: 35500
IIRC, the ship won't slow down when engaging Warping-out.
-
Hmm, so if i look through the script section of the wiki i can theoretically make my own warp effect?
-
Hmm, so if i look through the script section of the wiki i can theoretically make my own warp effect?
Well, basically yes, you can probably make all the effects themselves via scripting.
The problems I had when I tried to take that approach was that I didn't find clean ways of making the ships actually exit the mission or the mission to end nicely. Also it of course became such a complicated mess when you had to handle not just the player's ship warping out but also all other ships as well that I just figured that in this specific case it'd be pretty backwards to implement all of that in scripting when there's a feature which is apparently intended to handle at least a part of it.
-
No way to remove from radara and change alpha?
-
Points 1, 3 and 4 should now be addressed in trunk. (http://www.hard-light.net/wiki/index.php?title=Ships.tbl&diff=37109&oldid=37070)
1. $Warpout speed now denotes the minimum velocity required for a warp (so if your speed is below that when engaging hyperdrive, you'll accelerate, but if it's above then you won't decelerate).
3. The collision check distance for the hyperspace warp type is now 100000 instead of 200.
4. You can control the acceleration/deceleration curve at the beginning/end of the warpout/warpin effect with $Warpin Decel Exp and $Warpout Accel Exp.
Also, when a ship arrives from hyperspace, it will now immediately resume the initial velocity set for it in FRED after the warpin has finished and even the use of $Warpin Decel Exp will not cause the ship to be decelerated below that initial velocity during the effect.
-
While we're on the subject of warping, I was asking for a slight change to the effect for TBP for quite some time... trivial as I assume it may be to implement. I wanted a way for fighters and capital ships to warp out together, matching the same speed, but having only one big warp effect. The only change I would like to see is a checkbox in the event editor (and perhaps a corresponding sexp toggle) to disable the rendering of the warp vortex on an individual ship basis, but retain the acceleration and deceleration associated with it. Simply clicking the existing no-vortex box causes the ship to appear or disappear when arriving or departing.
-
That's not exactly trivial. You would need to implement some sort of Warp Group function for all the ships to share one warpout animation. Disabling the animation on a given ship would be simple enough, but then the parent ship's animation may not be big enough to enclose all its children. And there's no guarantee the children would be facing the same direction as, or be at the appropriate relative coordinates to, the parent.
-
It would be easy enough to control their positioning and orientation for arrivals. As for departure, I believe that there are sexps to manipulate an object's orientation. One needs to give fighters orders to approach the cap-ship and stay near it, then face the same way (use a waypoint or something), then trigger the departure cue. Am I correct on these statements?
-
That's correct, but it's more complicated than it sounds. Facing the right direction isn't particularly easy if it's not facing directly at some object or along one of the three axes.
The other problem is that ships have different warpout speeds. In order to get the ships to all disappear at the same spot, you'd have to place them at carefully calculated points forwards or backwards along the main ship.
I would say the Warp Group option is the way to go.
-
There are other issues too. What happens if the ships get a warp out order but the ship which is controlling the formation of the warp hole is dead or disabled? It would not be a simple change at all.
-
I have a few changes myself:
1. Make it so that the game treats the ship as "arriving" when it actually stops moving, not when it appears out at super far away. This will eliminate issues such as wings arriving from a ship's arrival being spawned at super long distances, and more importantly fix a crash that results when ships warping in have initial orders set to waypoints, waypoints-once, and ai-chase which occurs because there is an invalid pathfinding matrix as the ship's location is undefined/changing too fast. (I had a callstack identified as this by #scp, so yes it happens.)
2. Make ships not collide until they have "arrived" and stopped moving to prevent "hyperspace accidents", especially with the "near ship" and "in front of ship" triggers which can't really be used. I have had several people document ships failing to arrive/spontaneously exploding on arrival due to such collisions, which are not consistent and vary from processor to processor based on floating point math. This will also fix the bug where such a collision results in the game sounds cutting out.
I am making a mod that uses hyperspace as a warpin type, and these things occasionally end up semi-randomly breaking missions. The second one especially, since I can either have fixed arrival points (which can be abused), or the random factor of ships dying on arrival and game sounds cutting out.
In fact, I would classify these as bugs, but some people insist they don't exist, even though I've presented call stacks from FSO crashing with both, with handwaves telling me "oh, just don't set initial orders, assign them via sexp after they arrive" and "er, no, no hyperspace collisions"...
-
That's correct, but it's more complicated than it sounds. Facing the right direction isn't particularly easy if it's not facing directly at some object or along one of the three axes.
Shouldn't the previously-mentioned used of waypoints do the trick? For arrival grid placement, place all ships in close proximity, then place a waypoint at extreme distance in the direction you want them to point, use the point-towards option in object editor, then remove the waypoint. For departures, have the cap-ship turn towards a waypoint again at extreme distance, have fighters approach then cap-ship then turn in the same direction. Use a variable or argument event to confirm when all fighters are in formation, but discount any that might have been destroyed, then initiate warp for all.
While we're on the subject, I've always thought that it would be useful to define an object's orientation via hand-keyed figures the way you can input co-ordinates, rather than trying to adjust them freehand or via the waypoint-point-to method.
The other problem is that ships have different warpout speeds. In order to get the ships to all disappear at the same spot, you'd have to place them at carefully calculated points forwards or backwards along the main ship.
I believe that there are table options to control warping accel/decel rates and warping speeds. You'd only need to make sure that these figures are the same for all ships.
I would say the Warp Group option is the way to go.
I could probably see such a system being somewhat more user-friendly, but I suspect that it would require so much new code as to take quite a long time to implement. My suggestion on the other hand would be completely backwards compatible with existing missions, but one could make the table adjustments for warping speeds etc as a mod of the main TBP and include adjusted ship placements for any missions that are updated to this new system. Also, as I said earlier, I suspect that finding a way to simply disable the vortex rendering while preserving speed+accel./decel. is much less difficult to implement.
There are other issues too. What happens if the ships get a warp out order but the ship which is controlling the formation of the warp hole is dead or disabled? It would not be a simple change at all.
I would suspect that the answer is quite obvious... design your missions so that either A), your target cap-ship can't be disabled with ship-subsyst-guardian-threshold, B), you get auto-fail (or die) if you lose your cap-ship, or C), include contingencies for alternate departure methods available to the player (other cap-ships or jumpgates), should your prime ship be destroyed. It all comes down to how you handle your mission. In fact, the mission would need to be designed for contingencies like this anyway for story purposes, I'm just trying to simulate the visual aspects of B5 warping in regards to group warping and their speeds.
Now, I know that I'm not an active member of TBP anymore, and I don't know if anyone on the current Zathrus team would directly want or use this, I'm just saying that it could be made to work, and that I suspect it's the least troublesome to implement. But if it is done, then the existing team may decide to make use of it.
Thank you.
-
I think you'd be better off telling the coders what you want and letting us decide the easiest way to implement it. :p
-
Fair enough.
-
2. The amount of time the "engaging warp drive" part takes should either be fixed (3 seconds sounds nice; I'm not sure what the default minimum is) or possible to specify or override in the ships table.
Could you also look into this? For all kinds of warpouts, table controlled (if possible).
Right now, it's a bit inflexible, especially if you want capship missions.
-
2. The amount of time the "engaging warp drive" part takes should either be fixed (3 seconds sounds nice; I'm not sure what the default minimum is) or possible to specify or override in the ships table.
Could you also look into this? For all kinds of warpouts, table controlled (if possible).
Right now, it's a bit inflexible, especially if you want capship missions.
Yeah, I probably will at some point.
-
For entering subspace, the amount of time it takes to start the jump sequence is the time it takes to adjust speed to 40 +/- 2 m/s.
-
Hrmmm, this may take more profiling to pin down, but it seems the WE_Hyperspace code is now taking up quite a bit of CPU time.
Circa 4% of cycles during a mission.
-
Hrmmm, this may take more profiling to pin down, but it seems the WE_Hyperspace code is now taking up quite a bit of CPU time.
Circa 4% of cycles during a mission.
What the... :eek2: Is that only during a hyperspace effect? I can't see how those changes could affect anything unless the hyperspace warp type is actually in use.
-
I have a few changes myself:
1. Make it so that the game treats the ship as "arriving" when it actually stops moving, not when it appears out at super far away. This will eliminate issues such as wings arriving from a ship's arrival being spawned at super long distances, and more importantly fix a crash that results when ships warping in have initial orders set to waypoints, waypoints-once, and ai-chase which occurs because there is an invalid pathfinding matrix as the ship's location is undefined/changing too fast. (I had a callstack identified as this by #scp, so yes it happens.)
2. Make ships not collide until they have "arrived" and stopped moving to prevent "hyperspace accidents", especially with the "near ship" and "in front of ship" triggers which can't really be used. I have had several people document ships failing to arrive/spontaneously exploding on arrival due to such collisions, which are not consistent and vary from processor to processor based on floating point math. This will also fix the bug where such a collision results in the game sounds cutting out.
I am making a mod that uses hyperspace as a warpin type, and these things occasionally end up semi-randomly breaking missions. The second one especially, since I can either have fixed arrival points (which can be abused), or the random factor of ships dying on arrival and game sounds cutting out.
In fact, I would classify these as bugs, but some people insist they don't exist, even though I've presented call stacks from FSO crashing with both, with handwaves telling me "oh, just don't set initial orders, assign them via sexp after they arrive" and "er, no, no hyperspace collisions"...
Please? D:
-
Sure, I'll take a look at those sometime soon'ish.
-
This super-simple patch should pretty much fix those issues:
Index: shipfx.cpp
===================================================================
--- shipfx.cpp (revision 7929)
+++ shipfx.cpp (working copy)
@@ -4222,7 +4222,7 @@
if(direction == WD_WARP_IN)
{
- shipp->flags |= SF_ARRIVING_STAGE_2;
+ shipp->flags |= SF_ARRIVING_STAGE_1;
objp->phys_info.flags |= PF_WARP_IN;
objp->phys_info.vel.xyz.z = (scale_factor / sip->warpin_time)*1000.0f;
objp->flags &= ~OF_PHYSICS;
@@ -4258,6 +4258,7 @@
vm_vec_scale( &vel, initial_velocity );
objp->phys_info.vel = vel;
objp->phys_info.desired_vel = vel;
+ shipp->flags |= SF_ARRIVING_STAGE_2;
}
objp->flags |= OF_PHYSICS;
this->warpEnd();
@@ -4287,4 +4288,4 @@
vm_vec_scale_add(&objp->pos, &pos_final, &objp->orient.vec.fvec, scale);
}
return 1;
-}
+}
\ No newline at end of file
-
Oooh that sounds cool.
...time to add another patch to my ever-growing-list of bug-fixes-not-in-trunk >.>
-
Not having any hyperspace-capable ships, I don't have the ability to test this, but it looks like it'll work. Committed in 7936.