Applied Special Relativity: Achieving Full Stop takes *way* too long

[ryllae]

Achieving full stop takes way too long in nearly every ship - especially in ships with large mass, such as a Freighter. You ship will sit on "0.0m/s" for several minutes before the server thinks you're fully stopped (as measured by whether or not you can eject.

I don't know how it worked back then or on live, but I would think this behavior is not accurate, and if anything, unfun.

Not actually stopped? Einstein would disagree:

[zhyrohaad]

My movement code is based on client. I've had to tweak it to match what client shows, and have not found a way to tell client an object has changed movement outside of (the clients) coded parameters. This is the main problem with turns and orbits.

[zhyrohaad]

The other thing I found when messing with this is all ships move for much longer then I had originally thought. Eject is a good test for movement, as I have it coded to not allow eject/board while moving. The reason for this is I have not been able to consistently apply pilot skills and effects to a moving ship correctly.

[THUNDERGROOVE]

Regarding the skill application stuff. Do you mean getting it to stick on the client side?

On Tue, Aug 27, 2019, 7:41 AM Allan notifications@github.com wrote:

The other thing I found when messing with this is all ships move for much longer then I had originally thought. Eject is a good test for movement, as I have it coded to not allow eject/board while moving. The reason for this is I have not been able to consistently apply pilot skills and effects to a moving ship correctly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zhyrohaad/AlasiyaEvE/issues/38?email_source=notifications&email_token=AANEANSBUQOCOKYPXK54MLTQGU4JJA5CNFSM4IP6H5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5H7EGQ#issuecomment-525333018, or mute the thread https://github.com/notifications/unsubscribe-auth/AANEANXK4MDEG2OZPQTKIPLQGU4JJANCNFSM4IP6H5CQ .

[zhyrohaad]

no, on server side.
getting ship to update with new pilot skills while moving is tricky. too many variables right now. i may revisit it later.

and honestly, ejecting from a moving ship is worse... removing skills, updating ship to and then getting client to show ship slow to a stop has proven impossible so far. server does fine with it....i've tracked ship stopping after eject (hard coded to stop) and it worked great. convincing client that the ship is stopping hasnt happened yet.

[ryllae]

My movement code is based on client.

Hmm, I'm a bit dubious, but there's something quite off here. Undock, push stop. Measure how much time it takes to reach full stop (when you can eject):

Kestral: 32s, and I'm right where I should be to reboard the ship. That seems about right.

Charon: 4m45s (!) And over one minute is spent at "0.0" while it's busy rounding down to one iota. Orca: 6m12s (!!) wat. And after I eject I'm about ~100m from the ship, but I'm told I'm not within 500m to reboard, even though I'm right next to it on the overview, and "approach" says I'm where I should be. I still contend there's something awry.

[ryllae]

RE: https://github.com/zhyrohaad/AlasiyaEvE/issues/39 ships decel at same rate no matter what. it's part of eve physics.

I've been boarding from a Hawk, traveling at about 300m/s when I jump into a stationary Hulk. The hawk on the client usually stops about 500m away. Doing a .update afterward shows the server thinks your Hawk is 800m away. Either the client had a problem recording when you ejected, or the server isn't slowing down ships fast enough?

An easy way to test this further would be to ENABLE bailing from ships while they're moving, and record the differences in where the client and server think the ship end up?

[zhyrohaad]

ive tried that. thats the reason i have it disabled.... when bailing from ship, we have to reset ship to 'base' values because of your skills. this involves determining current speed as a fraction of the ship's new max speed.
i have not had a chance to integrate that type of code and checks into current movement code, which is already a bit complicated. the downside is this check would have to play nice with all the other movement variables, and i havent been able to consistently get this set right.

my point is this.....enabling would screw up server's ship movement variables, which would give erroneous readings to ship stopping, ergo, that test on this server code would be moot.

[zhyrohaad]

however, kinda makes me wonder if we can disable effects to get a baseline and go from there.

[zhyrohaad]

changed the check for eject/board instead of waiting for full stop, im allowing ejecting from ships as long as your current speed is < 20 m/s. not sure what kinda havoc this will play with positioning/desync, but we'll see. ;)

try it and lemme know your thoughts.

[ryllae]

As to #39, I think you're fine, but I still think ships decelerate too slowly.

I've had several occasions where I warped an Orca onto a hulk. On one screen I see the Orca slowing to a halt, and on the other, I bump the orca and keep going for ages. Yeah, it could be a .syncloc issue, and I didn't play in Crucible to confirm this, but I can't image that takes 30s to reach top speed should take 6+ minutes to stop. Craziness.

[zhyrohaad]

been thinking about this. it does make sense, in this aspect..... to reach desired speed, the ships thrusters are activated, so the ship is being 'pushed', so to speak. for decel (either partial or full), there is no 'reverse power' to stop the ship, therefore the ship is having to coast, which will rely on 'space friction' to slow down. this is same as ship in water. because of this, velocity changes will take longer, and vary according to mass of object. so, on the 6+ minutes to stop....yeah, big ships will take a while, but the last lil bit is minuscule.

[zhyrohaad]

Have we come to any conclusions on this?