search

CDarrow / DXX-Retro

A source port of Descent 1 and 2, focused on quality competitive play. Uncompromising commitment to original gameplay (except where the original sucked). Based on the Rebirth project.
Other
49 stars 16 forks source link

Homing missiles start tracking at a random time within 160ms in D1 and 133ms in D2. #80

Open roncli opened 7 years ago

roncli commented 7 years ago

Reported by Jediluke/Drakona:

Homing missiles are coded to only try to track players 8 times every second. These 8 times are fixed based on the amount of time that has passed since the game has begun for the client.

This means that when a homing missile is fired, it can start tracking another player immediately, or it can start tracking another player in 125ms, or anywhere in between. Worse, in net games, since the time the game has begun for the client will vary due to lag, joining at different times, etc., this time will be DIFFERENT for every player in the game.

Discussion required includes whether we would WANT to change this default behavior, and if so what would be the new behavior?

roncli commented 6 years ago

@CDarrow Am I reading the code correctly here? This actually appears to be 25 times per second (40ms)?

https://github.com/CDarrow/DXX-Retro/blob/50ec7ba6e058cc0d90ca332d12059de2700aa69b/d1/main/object.c#L124-L125

roncli commented 6 years ago

Also, it appears to be 30 times per second (33 1/3 ms) in D2.

https://github.com/CDarrow/DXX-Retro/blob/50ec7ba6e058cc0d90ca332d12059de2700aa69b/d2/main/game.h#L117

https://github.com/CDarrow/DXX-Retro/blob/50ec7ba6e058cc0d90ca332d12059de2700aa69b/d2/main/object.c#L2132

roncli commented 6 years ago

Yeah, homers track way more than 8 times per second. I don't think this is a valid issue.

CDarrow commented 6 years ago

You're misunderstanding the problem. Look at when homers start tracking after launch, not when they update while in flight.

On Jan 12, 2018 4:03 PM, "Ronald M. Clifford" notifications@github.com wrote:

Closed #80 https://github.com/CDarrow/DXX-Retro/issues/80.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CDarrow/DXX-Retro/issues/80#event-1422675332, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1XBffuBZi7hWSAb8aXm2o_ADIriafrks5tJ-RSgaJpZM4LwVtc .

roncli commented 6 years ago

Given a smooth 200 FPS, a setting of F1_0/25 for idealHomerFrameTime means that 25 times per second, or once every 8 frames, homerFrameCount will get incremented and doHomerFrame will be set to 1 for that frame. Both homerFrameCount and doHomerFrame are passed into Laser_do_weapon_sequence which uses the value of doHomerFrame to determine whether to call track_track_goal at all.

So this function is going to be called, ideally, every 40ms, not every 125ms. I do see how different clients will fire that within a different point within that 40ms window, but...

...oh dear, I didn't see this initially. Does THIS do what I THINK it does?

else if ((((tracker-Objects) ^ homerFrameCount) >>> % 4 <<< ) == 0)

If so, that's... oh god... 160ms... 😱

OK I think I see the problem.

roncli commented 6 years ago

And I may have a solution... move currentHomerFrameTime into object, tracking it per object instead of globally. It will take some refactoring work, but shouldn't be too hard.

CDarrow commented 6 years ago

You don't see it yet. Yes -- you see the delay I'm talking about. No, you shouldn't change how it works. That's tactical behavior that goes back to D1 and should be left alone. And you shouldn't change it per object, either. It's per missile intentionally. That's tactical behavior that goes back to D1 and which should be left alone.

The sole point of this issue is to communicate the value of the delay on the network somehow so that it is at least the same for both players. Right now the delay before tracking is calculated independently on both screens, leading to differences of opinion on when a missile starts to track.

I don't have time to work on this sort of thing! I thought you were going to stick to stuff that was zero physics impact.

-Drak

On Wed, Jan 17, 2018 at 1:31 AM, Ronald M. Clifford < notifications@github.com> wrote:

And I may have a solution... move currentHomerFrameTime into object, tracking it per object instead of globally. It will take some refactoring work, but shouldn't be too hard.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CDarrow/DXX-Retro/issues/80#issuecomment-358232899, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1XBe3_6xXL6Valk-AMibOlU4-6m9VOks5tLa_vgaJpZM4LwVtc .

roncli commented 6 years ago

Your reply highlights the very reason for the discussion here: We have an issue that not only has an unclear problem, but an unclear solution. This discussion is my attempt to clarify it. I reported this issue initially because you mentioned it to me, there wasn't already one in the issues list, and I didn't want it to get lost.

I'm aware of your situation, and I respect that. It's the reason I want to be vigilant and thorough about these issues, so that when you do have time, it's productive time. Take care of life outside Descent, and then reply when you have time.

To be clear, here's the plan, which hasn't changed since we discussed it.

I plan on completing observer mode, with all discussed and agreed to features and for all game modes in D1 and D2, by 1.4X7. (The encryption discussion on #13 is outstanding, and won't be included at this time.)

After that, CTFC is next to be implemented. Who will do that or when remains to be discussed, although @nightwish75 may very well have already done the necessary work for that.

After that, there is literally nothing discussed. No bugs, no features, no physics adjustments, nothing. Until something else gets discussed, we have just a long list of issues that needs direction.

This is not going to stop someone that has invested a lot of time and effort from understanding what the issues are. I've played around with quite a number of these issues in my own time in an attempt to understand them. The "off-by-one pixel" on the energy display. Fusion shake FPS. D2 smart blob speed. Some I've made attempts at fixing. Some I've actually been successful with. None I've ported back to this project. I am fully on board with respecting the community's wishes, and don't ever intend to change anything without the proper checks and balances. But I am still going to strive to understand the issues.

Clearly, I don't understand what this particular issue is. Nor do I don't understand what your idea for fixing it may be if not wanting to change original D1 mechanics is a concern (which is a whole discussion of its own). The good news is open issues can be closed, closed issues can be opened, and everything can be discussed when we have time. Nothing should be getting hurt here.

CDarrow commented 6 years ago

Haha! Sorry to be grumpy with you. Sounds good. Thanks!

On Wed, Jan 17, 2018 at 5:51 PM, Ronald M. Clifford < notifications@github.com> wrote:

Your reply highlights the very reason for the discussion here: We have an issue that not only has an unclear problem, but an unclear solution. This discussion is my attempt to clarify it. I reported this issue initially because you mentioned it to me, there wasn't already one in the issues list, and I didn't want it to get lost.

I'm aware of your situation, and I respect that. It's the reason I want to be vigilant and thorough about these issues, so that when you do have time, it's productive time. Take care of life outside Descent, and then reply when you have time.

To be clear, here's the plan, which hasn't changed since we discussed it.

I plan on completing observer mode, with all discussed and agreed to features and for all game modes in D1 and D2, by 1.4X7. (The encryption discussion on #13 https://github.com/CDarrow/DXX-Retro/issues/13 is outstanding, and won't be included at this time.)

After that, CTFC is next to be implemented. Who will do that or when remains to be discussed, although @nightwish75 https://github.com/nightwish75 may very well have already done the necessary work for that.

After that, there is literally nothing discussed. No bugs, no features, no physics adjustments, nothing. Until something else gets discussed, we have just a long list of issues that needs direction.

This is not going to stop someone that has invested a lot of time and effort from understanding what the issues are. I've played around with quite a number of these issues in my own time in an attempt to understand them. The "off-by-one pixel" on the energy display. Fusion shake FPS. D2 smart blob speed. Some I've made attempts at fixing. Some I've actually been successful with. None I've ported back to this project. I am fully on board with respecting the community's wishes, and don't ever intend to change anything without the proper checks and balances. But I am still going to strive to understand the issues.

Clearly, I don't understand what this particular issue is. Nor do I don't understand what your idea for fixing it may be if not wanting to change original D1 mechanics is a concern (which is a whole discussion of its own). The good news is open issues can be closed, closed issues can be opened, and everything can be discussed when we have time. Nothing should be getting hurt here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CDarrow/DXX-Retro/issues/80#issuecomment-358500542, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1XBRfADA6HUkfJX80H6e3F-wU-HXSDks5tLpWZgaJpZM4LwVtc .