[Sushi]

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!
SushiGlide v2

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

--

Update 4/9/09: SushiGlide v4
SushiGlide v4

See my post below for more details

[Reprobator]

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 

[Sushi]

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.

[Aardwolf]

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)

[Sushi]

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.

[Reprobator]

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!

[Sushi]

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.

[KeldorKatarn]

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.

[Reprobator]

saga use glide for autopilot  right?

[KeldorKatarn]

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.

[Reprobator]

I see , maybe that could end like $glide type =

?

[Sushi]

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.

[Sushi]

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)

[Sushi]

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.

[Nuke]

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.

[JGZinv]

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.

[Reprobator]

Am i wrong if i say that i  feel the lateral thruster does not take any account of the ship's dampering actually? 

[Tolwyn]

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.

[Sushi]

Am i wrong if i say that i  feel the lateral thruster does not take any account of the ship's dampering actually? 

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.

EDIT: Clarified effect on WCS

[chief1983]

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...