Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on March 29, 2015, 11:47:11 pm
-
Hey folks. I think I've got a lead on a major issue with glide behavior.
It's possible to cap a ship's maximum glide speed at its maximum cruise speed, rather than its maximum afterburner speed. This is to prevent exploitative tactics in which you can lock a ship in permanent afterburner by gliding while at AB speed. We can't just let everyone slide around in the danger zone all the time.
Unfortunately, there's a pretty simple exploit to get around this. If you engage glide after releasing the afterburner key, but before you decelerate below your maximum cruise speed, you'll stay at your current (afterburnery) velocity. This is a really easy highway to the danger zone. It seems like the glide speed cap only realizes you're afterburning while you have the afterburn key pressed!
This is bad and degenerate for a lot of missions. Can anyone repro this behavior, and if so, can we find a fix?
-
This is technically a feature request (http://scp.indiegames.us/mantis/view.php?id=2918). I can bump it up my to-do list if you need this sooner rather than later.
-
I think it's important to have. It breaks a couple of existing missions.
-
So that's what's going on! I just assumed there was some bug with the Custos-X that would sometimes cut my speed back to max after doing the burner-glide thing. Looks like the bug is the other way around :P
-
I always thought this was intended behaviour, I actually rely on any glide capable ship being able to do this!!! :D
-
I always thought this was intended behaviour, I actually rely on any glide capable ship being able to do this!!! :D
It is the intended behavior, as mentioned on the Mantis issue; since it's counter-intuitive to many, however, it makes sense to introduce the alternative via a game_settings.tbl flag.
I'll try to find some time to work on this soonish.
-
I always thought this was intended behaviour, I actually rely on any glide capable ship being able to do this!!! :D
I don't see any logical reason why you shouldn't be able to glide at afterburner speed either, so it's definitely a feature.
-
>logic
>fs2 speed caps
-
Would this be best to implement as a per-ship switch or a per-mission switch or a per-mod switch or all of the above? Like should you be able to override a per-mod switch to allow a certain mission or certain class of ship to do this? It might be able to be a feature; not sure what techno-jargon would have to be resorted to to explain it, but it would be fun if done correctly, I would think. (Perhaps to incentivize using a ship with other drawbacks, or to introduce a player to the advantage of certain piloting styles or somesuch.)
-
We already have a good way of dealing with this implemented, the problem is that it's just not working properly.
-
Ah, I see. The fix is glitched?
-
I always thought this was intended behaviour, I actually rely on any glide capable ship being able to do this!!! :D
I don't see any logical reason why you shouldn't be able to glide at afterburner speed either, so it's definitely a feature.
Would this be best to implement as a per-ship switch or a per-mission switch or a per-mod switch or all of the above? Like should you be able to override a per-mod switch to allow a certain mission or certain class of ship to do this? It might be able to be a feature; not sure what techno-jargon would have to be resorted to to explain it, but it would be fun if done correctly, I would think. (Perhaps to incentivize using a ship with other drawbacks, or to introduce a player to the advantage of certain piloting styles or somesuch.)
I see there's some confusion here. This is not a feature and it's definitely a bug. First, let me do what I should've and be explicit about the name of the feature that's broken:
$Glide: YES
+Dynamic Glide Cap: NO
+Max Glide Speed: 40
This ship has glide. It does not use a dynamic glide cap. It has Max Glide Speed defined, which is the maximum speed it's allowed to travel when gliding.
Why, Karajorma might rightly ask, does this feature exist? What logical reason is there for a ship to have its glide speed restricted to its max cruise speed (or lower)?
The answer is gameplay. Imagine you're flying a frigate or a big gunship. The player might want to strafe alongside a target, bearing their weapons on it. Or they might want to go really fast to evade incoming missiles or get somewhere. But we don't want to let them do both at once: this is a degenerate tactic for our mission, since it's clearly optimal to glide everywhere at AB speeds, take all power out of engines, and put it in guns/shields.
If your ship has equipment or abilities relevant to AB recharge, this is even worse. They're now extraneous, since you don't need to worry about AB recharge except when you're changing directions.
So we add '+Max Glide Speed'. But Max Glide Speed is a lie. It should actually be named 'Max Glide Speed If You Press Glide While Holding Down Afterburner, Otherwise Don't Worry About It.' With quick fingers the player can ignore Max Glide Speed.
This is a broken feature. One way or another, please fix it!
-
Ah, I see your point now, it's that specific table setting (which we didn't use in Diaspora) that is broken rather than the way gliding is handled in general.
-
I see there's some confusion here. This is not a feature and it's definitely a bug.
[...]
This is a broken feature.
As I said on the Mantis issue, this is most certainly "working as intended", even though it's counter-intuitive and leads to degenerate gameplay. If you look at the part of the code responsible for glide caps (both dynamic and absolute), you see this comment:
// Only do the glide cap if we have one and are actively thrusting in some direction.
This code (and the associated checks) were added in r8628 by Sushi on March 27, 2012, with the following commit message: "Gliding bugfix: only 'decay' glide speed when actually thrusting."
So as much as this behavior may annoy you, it was most certainly intentional. Now, it shouldn't be hard to add in the alternative behavior (I was going to use a game_settings.tbl flag, but now I'm wondering if people would prefer the ability to change this behavior on a per-ship basis), but it's still adding a new feature rather than fixing an existing one.
-
Ask Sushi what up with that, I guess? If it's not important behavior to preserve that simplifies things greatly.
-
Now, it shouldn't be hard to add in the alternative behavior (I was going to use a game_settings.tbl flag, but now I'm wondering if people would prefer the ability to change this behavior on a per-ship basis), but it's still adding a new feature rather than fixing an existing one.
I'd like to be able to define this on a per-ship basis.
-
If somebody does end up making it so that the ship speed decays to below the glide cap, would they be so kind to make it so that said behavior is optional?
FringeSpace wants to be able to hold their top speed while gliding, as this is the same behavior as in Tachyon. Novalogic balanced this behavior by making the energy reservoirs charge comparatively slow, and energy transfers were lossy (I think around least 15% energy loss)
-
I'm not sure I follow, z64555. Can't you just leave your Max Glide Speed high, or undefined? How would this change affect you at all?
I'm not sure I get the desire for a glitchy Max Glide Speed at all. Can someone help me understand why you want the following behavior?
- Ship cannot glide above normal cruise speed if glide is engaged while afterburning
- Ship can glide above normal cruise speed if glide is engaged after afterburning, but before decelerating
- Ship cannot accelerate above normal cruise speed if afterburners are fired while gliding
- If gliding above normal cruise speed, decelerate to cruise speed if you try to accelerate
Why would anyone want this weirdly specific, roundabout edge case? Why not just...increase your Max Glide Speed, or don't set it at all? Why let a player glide at high speed with a keyboard trick, but forbid them from gliding at high speed if they use the normal, intuitive controls?
-
Yeah, I'm with GB on this. The behaviour you want is already available; making the Max Glide Speed behave as advertised instead of the way it works now is certainly desirable.
-
Well, if nobody wants to keep the current behavior, then the "fix" is as simple as reverting r8628.
-
We should reach out to Sushi to see if there's something we didn't think of.
-
I'm not sure I follow, z64555. Can't you just leave your Max Glide Speed high, or undefined? How would this change affect you at all?
Eh, I guess it doesn't really affect us after all, sorry. Brain has been three wheeling this morning. :banghead:
-
No worries! I didn't do a good job of pointing at the precise problem in the first post.
-
Yeah, that's what threw me too. But as soon as I looked at the Diaspora tables I realised that this didn't affect Diaspora in any way since we never set a max gliding speed.
-
Yeah, that's what threw me too. But as soon as I looked at the Diaspora tables I realised that this didn't affect Diaspora in any way since we never set a max gliding speed.
Not setting a max gliding speed doesn't actually mean you don't have one set; FSO automatically sets it to the fastest speed the ship can go (taking overclocking/afterburner into account). However, this does mean that Diaspora should, theoretically, be unaffected by reverting r8628. I'm currently compiling a test build to see if it works as expected.
EDIT: So it turns out Diaspora explicitly sets a dynamic glide cap, which means it is affected.
-
Hello there! I just happened to stumble across this thread before anyone tracked me down...
It's been long enough that I don't remember all the details, and I don't have the source code checked out so I can't see exactly what was in the commit in question (or later follow-up tweaks). I do remember writing reference here (which you should all read):
http://www.hard-light.net/wiki/index.php/Ships.tbl#.24Glide:
So, some history, as best as I can remember it. I stumbled across BTRL, and was driven up the wall by the fact that you could exceed speed limits in glide by flying forwards and turning. I found myself getting ahold of the source code to fix this, and got pulled into FSOpen dev in the process.
Later, I ended up refining this for Diaspora (and for my own use in TBP) with the "dynamic glide cap" approach, trying to make it so that the basic ship flight envelope was the same in both glide enabled and disabled modes. Turning on dynamic glide cap supersedes the "max glide speed" completely, and IIRC has some fairly different logic to avoid having to interact with the weird behavior that you can get when you DONT use the dynamic cap. Diaspora *definitely* uses the dynamic glide cap.
I do seem to recall that the behavior where you can maintain your current speed in glide, even if it's over the cap, was desired or relied on by someone (TBP / Zathras, maybe?). Including the part where applying thrust would break you out of that magic state and slow you down.
This does seem like something that should be fixed. If someone wants to be able to maintain AB speed in glide, they can just set the max glide speed == max AB speed. If you want the max glide speed LESS than max AB speed, then I think it should behave the way Battuta is asking.
Assuming that nobody is currently using a max glide speed < max AB speed and depending on the current behavior, I think it can be treated as a bugfix without needing to add another table flag.
As already mentioned, I can't see what was in r8628, so I can't comment on whether or not it's safe to revert as-is.
Unfortunately I won't be able to help out with actually implementing a fix, my current employer is very lame about participation in own-time game dev projects. And frankly I don't have the spare time and energy anyway.
Some alternate ideas for Battuta that wouldn't require a code change (these may or may not be helpful, just brain-dumping):
* Use dynamic glide cap so the player ship can't maintain a high glide speed without keeping energy in engines?
* Use +Glide Accel Mult: 0 to prevent ANY thrusting during glide, as an alternative "tradeoff" for using it?
-
Quick follow-up, I took a look at the linked mantis issue:
given that the code intentionally (both by the code and the comments) doesn't decay velocity when the ship isn't actively thrusting.
This sounds familiar, and I think it's the heart of the problem. The speed decay only gets applied when the ship is trying to apply thrust, so if you're just drifting you won't slow down. I don't remember whether this is also the case when using "dynamic glide cap" or not... I *think* the dynamic cap will still decay your speed even without thruster input. If I'm right about that, fixing this should just be a matter of syncing some of the code between the branches for dynamic and non-dynamic.
If not, then this will affect Diaspora as well and perhaps means we need a +decay_glide_speed_without_thrust flag or something.
-
Dynamic glide cap doesn't cause a different code branch to be followed; all it does is change which speed is decayed to (as long as some thrusting is happening).
Given that Diaspora doesn't actually have ETS controls and the Viper's overclock speed is identical to its max speed, the dynamic glide cap is equivalent to setting the glide cap to the Viper's top speed, except without having to type the number manually. Playing Diaspora with a build with r8628 reverted, if you afterburn and then glide, your speed will slowly decay until it reaches your normal top speed. Without reverting r8628 (e.g. current trunk, or any of the executables ever bundled with Diaspora), you can instead drift at afterburner speeds indefinitely.
As for what r8628 actually did: link (http://www.cliftongordon.com/websvn/diff.php?repname=fs2open&path=%2Ftrunk%2Ffs2_open%2Fcode%2Fphysics%2Fphysics.cpp&rev=8628).
-
Dynamic glide cap overrides and shuts off max glide speed, right?
-
Dynamic glide cap overrides and shuts off max glide speed, right?
It should, yes.
As for what r8628 actually did: link (http://www.cliftongordon.com/websvn/diff.php?repname=fs2open&path=%2Ftrunk%2Ffs2_open%2Fcode%2Fphysics%2Fphysics.cpp&rev=8628).
Hmm. I don't remember the reason for doing that one at all! :) I can't even remember if that was from someone else's request or if I thought it made sense for some reason.
It does look straightforward to revert (or to hide behind a flag), no idea who that would break though. (It would obviously affect Diaspora, but I don't *think* in any significant way).
Kicking myself for not including a Mantis link in the code, or at least a better explanatory comment.
-
Kicking myself for not including a Mantis link in the code, or at least a better explanatory comment.
QFT, fellow SCPers. Always take the time to write a good, clear message, and reference a ticket whenever possible. :yes:
-
i would very much love to see this fixed, it has bugged me in the past :/ i just never realized it was a actual bug
-
I think it's important to have. It breaks a couple of existing missions.
It makes Act 3 so much easier :D
-
I'll be sad to see it go on the Ainsarii, gliding in at 180m/s makes the opening of HFH much more manageable.