Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Sushi on April 08, 2009, 12:31:29 pm
-
Hi everyone,
I've been playing around with the current implementation of glide, trying to fix some of the (IMO) goofy things about it. The main thing that's bothered me is that the thrusting power of your ship is radically different between normal and glide mode. For example, in both the BTRL demo and The Babylon Project, sidethrusters have nearly zero acceleration when in glide mode. Also, the throttle control loses all proportionality in glide mode: it's always on, or always off.
So, here is what I have so far. I've modified the way that glide is handled so that it feels much more consistent between normal flight and glide mode. Also, the throttle is proportional again. Overall, glide feels much more natural (at least to me :)).
EDIT: Forgot to add ZIP! :p
SushiGlide v2 (http://students.cs.byu.edu/~sushi/fs2_open_3_6_10r_sushiglide2.zip)
The above ZIP contains both a patchfile with my current iteration of changes and a 3.6.10r build (based on rev. 5142) for your testing pleasure. It works decently as a drop-in replacement for the latest versions of the BTRL demo and TBP. At least, it works well enough to see how the flight model changes apply.
Please note that "$use newtonian damping" needs to be set to YES, otherwise forward/backward accel is nearly instantaneous. So, if you do use this with BTRL or TBP, make sure you set $use newtonian damping" to YES in the appropriate sections of ai_profile.tbl.
I'm interested to hear your feedback/thoughts/questions.
P.S. Would anyone be interested in a glide system that respects the maximum velocity values and includes ramping? For example, say your max velocity was 70 70 200 (like the Viper Mk7). In glide, from a full stop, you would only be able to accelerate sideways to a speed of 70 (with ramping). However, if you were already moving at 100 and turned sideways , you wouldn't lose that speed (you just wouldn't be able to use your sidethrusters to increase it further). I think I can do this. The best part about this is that it would allow for maximum similarity between normal flight and glide: the only real difference would be that in glide, your momentum would always be maintained. Flight characteristics would be otherwise near-identical. The only bad news is that this type of flight wouldn't really work for people who want to be able to accelerate forever in glide mode. In other words, regardless of glide cap, you would never be able to accelerate beyond maximum afterburner speed.
I will probably implement the above regardless, but I'm curious how much interest there is in spite of the "bad" news (which doesn't bother me at all). In fact, the only thing missing in order to do so is to be able to get the current ACTUAL velocity of the ship in local coordinates. I can probably figure out how to do it mathematically, but if there's an easier/existing way, I'd love to hear about it.
EDIT: Done! Exactly as described above. You can now check out Sushiglide v3 as well:
SushiGlide v3 (http://students.cs.byu.edu/~sushi/fs2_open_3_6_10r_sushiglide3.zip)
--
Update 4/9/09: SushiGlide v4
SushiGlide v4 (http://students.cs.byu.edu/~sushi/fs2_open_3_6_10r_sushiglide4.zip)
See my post below for more details
-
i m working on ship with glide enabled actually and yes i think it s interesting to respect the velocity values...
As i told in another "not so old" thread , do you think it s possible to add an option to have different Rotation Time value when you activate the glide?
somethink like $glide Rotation Time
I mean when you are in normal flight it's like you're flying in a cpu assisted mode, engaging glide would allow faster turn rate to give a substantial advantage on using glide, a bit like on racing game when you activate tcs (normal flight mode) or deactivate it (glide mode)
I don't know if i explained well myself :nervous:
-
So, you want glide mode to affect rotation speed too? I assume this would mean you could start a roll and gradually make it go faster and faster until you manually start slowing down... I see why that's an interesting idea. :) I suspect it would make the ships extremely difficult to fly though. The way ships rotate is not really what I'm focusing on at the moment, but I'll add your idea it to my "things to try at some point" list.
-
In the space flight simulator "Orbiter" (a freeware program to simulate real space flight within the solar system) they let your ship continue to spin faster and faster, but there is a control to "Kill rot", i.e. apply angular acceleration in the opposite direction.
What about something like that? (If you went with the idea)
-
Good news! I just finished SushiGlide v3, which includes the changes discussed in the second half of the first post. I put a link there as well.
So, overall, SushiGlide v3 has the following changes from the current standard glide:
1. The ship now accelerates at EXACTLY the same rate in both normal flight and glide flight. This is, IMO, the single most important difference. I accomplished this by using basically the same equations for both.
2. The ship cannot gain accelerate in a direction beyond the specified maximum velocity for that direction (although if it is already going as fast or faster in that direction, it will continue to do so).
3. It is no longer possible to accelerate and gain speed forever if the glide cap is disabled.
4. $use newtonian damping must now be set to YES.
This is where you, the dear SCP and HLP community, come in. Please try these tweaks out (especially the v3 one) and let me know what you think! If you like it, let me know. If you hate it, tell me nicely (and why). If you have suggestions, questions, or quibbles, please post them! And if enough people approve, let's get this merged into the main SCP branch.
-
good news!
i'll try that by this evening!
About the rotation that's not exactly what i would mean , the rotation behavior would remain the same but we would just be able to change it's x/y/ z rotation time when glide would be activated, that would give a good advantage for the glide users and avoid circle fighting ..
However something like orbiter is quite interesting too, it'll allow some very interesting manoever!
And for the kill rotation button you'll just have to disengage glide i guess!
-
I just finished SushiGlide v4 (see first post for links), which makes two minor (but significant) changes:
1. The flight direction now "centers" better when close to the glide cap. This is basically a bug fix to make the flight feel more natural when flying at high speed in glide.
2. There are now two glide caps: one for normal thrust and one for afterburner. By default, the normal glide cap is set to the maximum overclock speed and the afterburner glide cap is set to the maximum afterburner speed. The practical upshot is that you can no longer accelerate to afterburner speeds in glide mode by using only normal thrusters: you have to use your afterburner to do so, and will only be able to sustain that speed as long as the afterburner is on.
Why do this? First, it gives the afterburner a role in glide mode beyond increased acceleration. Second, it brings the flight physics between normal and glide flight into much better harmony. I think it's a change for the better. What do you think?
Also, it's obvious that I am having way too much fun with this. :D
-
This isn't supposed to replace the glide we have right now is it? If so you'll break at least one MOD with it.. Saga.
-
saga use glide for autopilot right?
-
No it uses glide for fighters. Wing Commander had gliding fighters. However, glide has special properties there which are violated in above description of the new version.
e.g. not being able to hold afterburner speed without keeping the AB activated.
Since that would not be in-universe consistent it would break the mod.
-
I see , maybe that could end like $glide type =
?
-
No it uses glide for fighters. Wing Commander had gliding fighters. However, glide has special properties there which are violated in above description of the new version.
e.g. not being able to hold afterburner speed without keeping the AB activated.
Since that would not be in-universe consistent it would break the mod.
Good point. I definitely don't want to break compatibility.
The good news is that if you want to be able to hold AB speed in Glide, you can still do so by setting "+max glide speed" in the ship tables to the same value as the max afterburner speed. So, I think WCS will still be OK. I'll have to reinstall the prologue and test it to make sure. :)
EDIT: If the behaviors are too incompatible, adding another flag to switch between them is always an option.
-
Meanwhile, there are two other issues I haven't figured out how to deal with yet. So, I'm throwing them out for discussion:
1. The "No glide cap" scenario: Because my changes add velocity ramping to Glide mode, they make the "no glide cap and accelerate forever" thing pretty much impossible. Well, it's probably still possible, but you'd have to be constantly turning, which is stupid.
We could always have a conditional branch that uses different physics (such as the existing system or SushiGlide v2) to still allow infinite accelerations. That would be trivial to do, I suppose.
I guess one relevant question is whether or not anyone uses the infinite acceleration thing?
2. Overclocking: Right now, the maximum (non-afterburner) glide cap is based on the maximum overclock speed of the ship. This causes some problems in ships where overclocking is enabled. First, it means that although a ship can't get to the glide cap speed by flying straight forward, it can by accelerating forward, turning, accelerating forward more, etc. This is, IMO, horribly counterintuitive. It also allows for awkward situations where the ship velocity vector never quite feels like it is where it should be (hard to explain, but happens a lot in SushiGlide v3).
One solution is to have a "dynamic" glide cap that changes based on the current maximum speed (including whatever overclock/underclock is happening). This would, IMO, be the ideal way to go.
Would something like this work for everyone?
- +max glide speed < 0 would disable glide capping, allowing for acceleration to infinity and beyond. This would use SushiGlide v2 (fixed acceleration rates, no ramping, no maximum speed for glide)
- +max glide speed > 0 would behave exactly as it does now.
- +max glide speed = 0 (or not specified) would use dynamic glide capping, where the glide cap adjusts with the current maximum speed (including overclock adjustments)
-
I finished another build that addresses the issues brought up in my last post, but I'm going to hold off on posting it for now until I can figure out the best way to set up defaults and table entries.
It adds the option to have "dynamic glide cap," where the same rules for max speed and overclocking by routing power to engines apply in glide mode as normal flight. It also makes it possible to turn speed ramping on or off for glide mode, and makes it possible once again to turn off the glide cap. With ramping off, you can also adjust the acceleration speeds for ships in glide mode in a more fine-grained way. In other words, users can enable/disable any of the extra glide features I've added, and have more control over existing features.
I don't know which of those fixes/features should be the defaults, though, and what the best arrangement of table entries would be. And all of that, of course, is assuming this stuff is even worthy of the main SCP trunk. :)
-
In the space flight simulator "Orbiter" (a freeware program to simulate real space flight within the solar system) they let your ship continue to spin faster and faster, but there is a control to "Kill rot", i.e. apply angular acceleration in the opposite direction.
What about something like that? (If you went with the idea)
play with the stabaug settings in space combat's ship editor if you want a good exaple of flight stabilization in a newtonian simulation. of course this makes your ship totally inefficient as far as fuel consumption goes. then the handeling becomes more freespacey. too bad space combat has suckey gameplay and ****ty weapons.
anyway its kinda nice to see somone working on (semi)newtonian features. so as standard procedure for me goes il toss up the same ideas i always toss up whenever physics is the topic.
optional conservation of angular momentum:
essentially keep angular momentum when glide is on. angular momentum would only change when torque is applied. optional limits would be in place for max roll, yaw, and pitch rates (separate of normal flight limits). possible inclusion of a kill rotation control, possible as either a toggle or single action key press.
optional proper usage of ship mass and moi matrix:
these would be an optional set of bools in the table. essentially "$usemoi: yes/no" and "$usemass: yes/no". if set to no it would essentially use the sushi glide model, where engine and thruster power is proportional to normal flight mode. if set to yes then the moi and/or mass values stored in the ship model are thrown into the equation. in case of usemoi that would be applied torque matrix * moi matrix, for usemass that would mean applied force vector / mass.
mission level foced usage of glide:
fred level toggle-ability of glide mode, either by sexp and/or mission flags. this should allow you to disable glide, force-enable glide (no normal flight), and disable/enable the players ability to change modes. for example you can have a mission that starts out nomal, then the gtva gives you "permission" to turn off your flight stabilizers to chase some pirates or something.
thruster based torque/linear force computation model:
instead of defining a ships performance with max rates and acceleration values. you instead define individual thrusters and engines with position, direction, and max force information. each thruster is bound to an input (like the graphic thruster glow system), and your ships applied torque and linear force are computed based on the power and direction of active thrusters and engines. play with the space combat ship editor to see what i mean.
-
Sushi I'd really like to introduce you to Tachyon, which had the best implementation for
slide, lats, rolls, etc... if you're interested please let me know by PM.
-
Am i wrong if i say that i feel the lateral thruster does not take any account of the ship's dampering actually? :confused:
-
The good news is that if you want to be able to hold AB speed in Glide, you can still do so by setting "+max glide speed" in the ship tables to the same value as the max afterburner speed. So, I think WCS will still be OK. I'll have to reinstall the prologue and test it to make sure. :)
Does this mean, that you would accelerate to max speed using afterburner or just by increasing throttle? If the latter applies:
EDIT: If the behaviors are too incompatible, adding another flag to switch between them is always an option.
Actually it would be the best possible solution. Glide function, as it is now, was written for Wing Commander Saga.
-
Am i wrong if i say that i feel the lateral thruster does not take any account of the ship's dampering actually? :confused:
It sort of does. The damping actually only applies in lateral directions UNLESS "$use newtonian dampening" is set to YES (in which case it applies for Z as well). This dampening basically affects how much the ship slides around when turning in normal flight. In glide mode, it has pretty much zero effect.
Does this mean, that you would accelerate to max speed using afterburner or just by increasing throttle?
My recent work has made either an option, with the "no afterburner required" thing being the default (as it is in 3.6.10). Actually, the iteration I'm working on now removes the separate afterburner glide cap and handles the whole problem differently.
I also noticed that if I run WCS with 3.6.10, glide behaves a bit differently because it is possible to accelerate while in glide mode. The build that comes with WCS Prologue doesn't allow ANY acceleration while in glide mode. Is that difference intentional? I kind of assumed it wasn't.
My next iteration of tweaks will actually make the "no accel for you!" option possible again for true WC3 authenticity. In other words, the new build will keep all the same default settings as 3.6.10, but will also add ships.tbl-based options for ensuring that accel can be totally turned off in glide mode as well. I think you WCS folks will appreciate that. :D
EDIT: Clarified effect on WCS
-
3.6.10 might have introduced a bug to the glide code in relation to this, there's been a lot of discussion in the RC2 release thread. I'd take a look there for details. There's also a Mantis report somewhere I think...
-
There is. And if the Glide function was originally intended for WCSaga, then the required for WCS behaviour can be tied in to the existing wcsaga flag that is already in the launcher, either in addition to or instead of yet another launcher flag.
-
No. It should be added to ai_profiles.tbl. This behaviour should not be disselectable.
-
There is. And if the Glide function was originally intended for WCSaga, then the required for WCS behaviour can be tied in to the existing wcsaga flag that is already in the launcher, either in addition to or instead of yet another launcher flag.
Absolutely not. Diaspora for one want to use the feature pretty much as it is now and we have no interest in using the same launcher flag we've been trying to obsolete for years to do so.
Having a launcher flag for game features is a very, very bad idea. What happens if you start a multiplayer game and some people have switched it off for instance?
-
True. I was actually more concerned about SP experience though. :)
-
Me too. But the multi example is pretty much a deathblow to the idea of using a launcher flag so why lead with anything else? :D
-
Why it wouldn't work like the $warpingtype?
i mean in the ship.tbl/tbm?
-
That's where both Diaspora and WCS are saying it should go. Or as an AI Profiles option so all ships inherit it.
-
I'd suggest ships.tbl.
I think that's the most flexible so a mod can use both glide versions on different ships.
Glide is set for ships already in that table, so one can simply add an option there for a different glide type.
So instead of a Glide YES/NO one would have GLIDE OFF, GLIDE TYPE 1 GLIDE TYPE 2 or something.
That would maybe require a table change for existing mods but that is acceptable I think.
-
Wouldn't even require a table change. Simply make a second entry $Glide Type: and map the older $Glide: YES and NO if present to the first two types. Existing mods would still have the old flag work while newer mods would have more options.
-
Hmm, one would have to make sure one overrides the other though, in case someone makes a mistake and uses both.
-
Yeah. And have the debug warn about the presence of both. :)
-
Cool!
Here is an excerpt from the README I'm writing to go with the next build release. Hopefully, this will work for people.
--Bug Fixes (universal)--
* Sidethrust is now about as powerful in glide mode as it is in normal flight. Previously, it was much weaker.
* Accelerations no longer suffer from the "inverse ramp" effect (where ships accelerate faster at higher speeds,
most noticable for sidethrust)
* The throttle control now works properly (proportionally) in glide mode. Before, 100% forward thrust was applied
for any non-zero throttle setting.
--New (optional) features--
* TODO: newtonian damping option
* Dynamic Glide Cap
In addition to having a fixed maximum glide speed or unlimited glide speed, there is now the option to have
a dynamic glide cap that adjusts with your engine settings and whether or not you use afterburner. In other words,
the maximum speed rules for the ship are the same for normal flight and glide mode: if you want to go faster, you
must either add power to engines or use your afterburner.
To facilitate this option, I added a new optional entry to the ships table (under $GLIDE):
+Dynamic Glide Cap
This option defaults to NO.
* Table-controlled acceleration constant
* Glide Speed Ramping
Both of these features are controled by another new ships.tbl entry (under $GLIDE):
+Glide Accel Mult
This option defaults to 0.66 (unless the WCS command-line flag is set, in which case it defaults to 0.0)
This gives modders more fine-grained control over how quickly ships accelerate in glide mode. Basically, this
specifies how quickly the ship accelerates in glide mode compared to the MAXIMUM acceleration in normal flight.
In other words, if this is set to 1.0, the ship in glide mode will accelerate at the fastest speed it ever does in
normal flight. If set to 0.0, ships can't accelerate at all in glide mode (like WCS). Modders can toy with this
value, but I've found that 0.66 is a "sane" value that feels more or less right in most places (and is pretty
consistent with existing mod behavior).
I've also enabled an (IMO) even cooler option: glide speed ramping. By setting +Glide Accel Mult to a value
less than zero, accelerations will ramp up to the target speed in glide mode in EXACTLY THE SAME WAY that
they do in normal flight! This allows for maximum consistency between normal flight and glide mode. For
example, flying BTRL's Viper mk7, it takes exactly as long to go from a dead stop to 200 in either mode.
Combining the Dynamic Glide Cap and Glide Speed Ramping, is, IMO, the best way to go. It allows for maximum
consistency between normal flight and glide mode while still allowing all of the fun extra manouvers that glide
gives you. This consistency not only makes the ships more fun and intuitive to fly, it makes it easier to balance
distances and combat when designing missions.
--Recommendations--
It is HIGHLY RECOMMENDED that you set the "$use newtonian damping" flag (in ai_profiles.tbl) to YES. I've
done so for the demos below. The new features were designed with this option in mind.
Also, the glide speed ramping was designed with the dynamic glide cap in mind. You can use the glide ramping
without the dynamic glide cap, but you may experience some wierd results (such as going faster when turning
than when going straight).
The idea is to make it so that everything is easily tweakable via ships table settings, but that the defaults are sane and minimally changed from the status quo.
Based on what I have right now, the WCS people wouldn't have to do anything special: the default glide cap is the maximum speed (including afterburner), and if the WCS features flag is set than the +Glide Accel Mult entry will default to 0 (which means no acceleration in glide mode).
Likewise for BTRL and TBP: The default behavior would be EXACTLY THE SAME AS IT IS NOW. Personally, I think the experience in both mods would be improved by using both of the "new" features (glide speed ramping and dynamic glide cap), but I'll leave that up to those mods to decide.
I'm also going to make it so that the newtonian dampening can be optionally set on a per-ship basis via ships.tbl flags. This would allow for more flexibility in (for example) mods like RealFlight that attempt to mod existing campaigns. We would be able to get the physics for gliding fighters working smoothly (since they would have the newtonian dampening) but not interfere with the mission timings since all of the transports, freighters, capships (etc) would still be using the old dampening (which wouldn't matter since they aren't gliding anyway).
As Havner pointed out in the RC2 Release thread, auto speed matching is currently broken in glide mode. I think the best solution for the time being is simply to turn that feature off in glide mode. There are other fun possibilities (like making it so that in glide mode, it tries to match velocity vectors instead of just speed) but those are a project for another day.
Regarding the throttle in glide mode: as previous versions had it implemented, any throttle setting at all meant 100% thrust. I fixed that so that the thrust is proportional to the throttle setting. This makes a lot of sense to me: it allows for more fine-grained control over your ship in glide mode. On the other hand, it breaks the "throttle speed = target speed" dynamic from normal flight. Turning the throttle off in glide mode or making it so that it still is based on the idea of "target speed" also makes sense. Should I add this as an AI Profiles option? I don't see any reason why this one should ever be per-ship.
My philosophy at the moment is "if there's more than one way that people might want it, make both ways possible." It means more ships and ai-profiles flags, but more options is a good thing, right? :D
So, expect SushiGlide v5 soon. :) And please, keep letting me know what needs to be done.
-
Like I already mentioned either here or in the RC2 thread: using a launcher flag is not an option.
To sum it up: default behaviour should remain as in 3.6.9. Quite a few mods make use of it, changing it will break their gameplay. I have no idea to which extent glide is used in btrl and tbp, I do know that upcomming Saga release relies heavily on it.
-
The only place I was talking about using a launcher flag was to set one default value differently if the WCS launcher flag was set, and that was only because I figured the flag was already used. Or are you planning to deprecate that flag and not use it anymore?
-
Diaspora and Beyond the Red Line already use glide as is and neither will want to have to turn on the WCS flag to have it work.
Furthermore you are correct that the flag is deprecated. Making it possible for Freespace players to turn on a flag and completely screw up the game has always been a bad idea. Similarly allowing WCS players to turn the flag off isn't a good one either.
-
Alright, scratch the WCS flag idea then.
In that case, what should the "default" behavior be? To satisfy both the Diaspora/BTRL/TBP and WCS models, somebody is going to have to change their mod tables. It's not possible to have both "no thrust in glide" and "thrust in glide" be defaults at the same time. :) It's simple enough to do: just set the +Glide Accel Mult flag to an appropriate value. But should that value default to 0 (like WCS/WC3) or should it default to 0.66 (more like current 3.6.10 RCs)?
-
Default should be 3.6.9 behavior as some released content already relies on it. Assuming that the actual bugs in that behavior are fixed though. If I recall there were a couple.
-
This is frustrating, I have been looking all over. And I can't figure out...
Can this be used with the FS2 campaign?
Or is it just your tweaks on BTRL and the other standalone that uses glide?
I don't understand at all.
Does the FS2 campaign need a complete overhaul in order to use glide and thrusters with the ships?
Maybe I have overlooked some key discussions about this, but I haven't found it.
I haven't played FS2 in so long, I just picked it up again and got all the new builds.
I really enjoyed BTRL for the new flight mechanics..... I wan't to play the FS2 campaign with the same.
Is that possible?
Do any of the FS2 ships have glide/thrusters with the OSP builds?
I guess thats my question.
Sorry for being a nub.
-
This might be what you are looking for. (http://www.freespacemods.net/download.php?view.519)
It's a mod that allows Glide on several, if not all, ships in FS2 (There's also a mod that does the same for the FSPort).
What do you mean by "OSP builds"?
-
I was referring to any of the "open source projects" that use the FS universe/ships
guess I meant SCP's
In any case, thank you. That was what I was looking for.
-
The executable, when used with retail data, does not change the default behavior of the ships from retail. You would need the retail data, this executable, and an additional mod that utilizes Glide. RealFlight is one that does so with just the retail ships, meaning you don't need a lot of extra data to play with it if you already have retail. If you had another mod already that used glide, you could probably switch this build for whatever you were already using to test out the changes. Or, you might need to make additional edits to the tables unless someone else does so first. So no, the builds don't enable glide for anything themselves, tables do when used with a compatible build.