Rebirth getting weird control types and changing HOG files
#21
How did you prepare the build area? It looks like the build script either didn't find git or that it was built in a directory that was not a git working copy. You would have a more precise version string, similar to the one I showed, if that were working.
(07-16-2019, 07:33 AM)OldSaltyGamer Wrote: 2. Rebuild for both machines (historically I just have typed in "scons" and let her build. If you want symbols I dare request what arguments to append to the command.)
It looks like you only rebuilt for gamelog-G, but not for gamelog-D.

For symbols, just ignore that for now.

I need both players to use this patch and for both logs to come from the same observed failure for the output to be useful.

I updated the patch I posted to provide slightly better output. Please revert to stock code, copy the patch from my post again, and apply that copy. It switches to hex output in net_udp.cpp to match the other output, and enables dumping single-byte arguments to do_checksum_calc.
Reply
#22
@Kp

Disregard issue. Upon deeper analysis and close inspection and observation of user actions leading up to and during the the symptoms previously reported, I have come to realize this is a user/hardware issue and in no way dxx-rebirths responsibility. 

I have now repeatedly and reliably reproduced and prevented the issue I reported.

Cause: during mutiplayer session, guest is using a third party PS3 controller connected via mini USB.
During death, players emotions overwhelm him and he jerks about with controller in hand, sometimes resulting in mini USB detaching from controller (sometimes only just enough to lose connection but not fall out completely). As a result, when attempting to reconnect gamepad, two things may happen...either independently or together; 1. One button signal gets hung causing ship to to behave as if button is being held (could be directional or projectile firing) and /or 2. No signals are recieved from controller at all. [Important to note that on my sons machine controller has to be on and connected before starting up game, or controller does not register.] 
Player exits and quits game, then restarts, and tries to rejoin game and recieved mismatched level error....
Interestingly enough, if player reboots computer and trys to rejoin game no mismatch error is thrown.

When using keyboard only controls, this never occurs. Players jerking about does not cause keyboard to become unattached. (Keyboard on flat surface, not in hand)

Solution: 
With twist ties or some other form of tie down I can attach to head of mini USB cable and wrap legs around controller thereby attaching the cable securely to controller. And by preventing the cable disconnect I do consistently and repeatedly prevent issue from reoccurring.
Tested for over 4 hours last night this solution works.

Only possible improvement I could see on behalf of dxx-rebirth is to keep a controller port open and listening on the channel, there by allowing a disconnect and reconnect. But I feel this is going to be hardware specific, and not readily addressable through the game code.

Thanks for your support and guidance Kp.
Let me know if you need me for test or study ever in the future. I'll be around on here - discord - and the git.

This project is amazing and I want to contribute where I can if I can. 
Reply
#23
(07-18-2019, 02:11 AM)Kp Wrote: How did you prepare the build area?  It looks like the build script either didn't find git or that it was built in a directory that was not a git working copy.  You would have a more precise version string, similar to the one I showed, if that were working.
(07-16-2019, 07:33 AM)OldSaltyGamer Wrote: 2. Rebuild for both machines (historically I just have typed in "scons" and let her build. If you want symbols I dare request what arguments to append to the command.)
It looks like you only rebuilt for gamelog-G, but not for gamelog-D.

For symbols, just ignore that for now.

I need both players to use this patch and for both logs to come from the same observed failure for the output to be useful.

I updated the patch I posted to provide slightly better output.  Please revert to stock code, copy the patch from my post again, and apply that copy.  It switches to hex output in net_udp.cpp to match the other output, and enables dumping single-byte arguments to do_checksum_calc.

(Unless I made an error in saving the edited source files on "gamelog-d" before I ran the build)
I built from src tar from the git following the links from the dxx-rebirth website.
Patch is applied for both builds on both machines.

I will re apply new patch and and load to both machines, and trigger issue to get you the logs if you still want them and wish to continue pursuing this.

I could build from git if you wish.
Reply
#24
My time zone is -5 cst. Not sure what yours might be. 

But considering you may not read my post before I get home today, I am going ahead and assuming you want the new patch information. So when I get home I will apply new patch and recreate the issue, and provide you with the logs.
In the event you do wish to continue investigating this you will not have to wait any extra time on me.
And if you decide to close the issue it is of no waste of my time for I am wanting to learn and this exercise is of good benefit to me anyhow.

I should have to logs ready 6 hours from this posting.

Enjoy your day sir.

The logs Are ready
theandroidcollective.org/dl/D2X-rebirth-Logs-07182019.zip
Reply
#25
I can see the controller disconnect causing weird input behavior, but it worries me that it can manifest in the spurious level mismatch message. Even if we say this is purely user error, I'd like to have the game handle the error more gracefully. I don't know how that would be though.

If you want to contribute, and you're comfortable working with C++ (in the C++14 dialect), pick an open issue on Github, pick a game bug that annoys you, or pick a missing feature you'd like to see implemented, and start work on it. If you need help or want guidance, ask. In particular, if you need to know where in the game code some particular bit of logic is implemented, ask and I will try to point you to it. Assuming compatible licensing, I'm happy to review and merge outside contributions.

I'll look at the logs soon.
Reply
#26
TL;DR: your logs pointed me to the bug. I have a fix. Full analysis below. Update to Always initialize station_idx on level start to fix the synchronization issue.

One of the logs cuts off a bit early, probably due to that game instance dying from the level mismatch exception. Fortunately, the error is much farther up, so I don't need the bits that were lost. After controlling for timestamps and machine-specific logs, this appears to be the first mismatch (first two lines of context, then the mismatch):
gamelog-d-gitbeta.txt:308780:
18:25:19.626735 similar/main/gameseq.cpp:941: netmisc_calc_checksum: seg[6]: sum1=00000084 sum2=00072940
18:25:19.626788 similar/main/gameseq.cpp:943: do_checksum_calc: b=0x7ffdbf10411a len=2 sum1=00000084 sum2=00072940 [00000098]
18:25:19.626841 similar/main/gameseq.cpp:950: do_checksum_calc: b=0x5633eeea58a2 len=1 sum1=0000001d sum2=0007297a [00000001]
18:25:19.626895 similar/main/gameseq.cpp:951: netmisc_calc_checksum: seg[6]: sum1=0000001e sum2=00072998
gamelog-g-gitbeta.txt:163614:
18:31:07.232295 similar/main/gameseq.cpp:941: netmisc_calc_checksum: seg[6]: sum1=00000084 sum2=00072940
18:31:07.232308 similar/main/gameseq.cpp:943: do_checksum_calc: b=0x7ffe7d7089ea len=2 sum1=00000084 sum2=00072940 [00000098]
18:31:07.232322 similar/main/gameseq.cpp:950: do_checksum_calc: b=0x55bdcb41a8a2 len=1 sum1=0000001d sum2=0007297a [00000000]
18:31:07.232335 similar/main/gameseq.cpp:951: netmisc_calc_checksum: seg[6]: sum1=0000001d sum2=00072997
The mismatch in b= is fine. That says that the two systems did not assign the same virtual memory address to the field in question, which is normal. The game would be almost completely broken if it cared about that. The mismatch in value (last field) is not fine, and explains why the next lines start to deviate. Looking at the code, the line numbers don't quite align (which is weird), but it's close enough that I can figure out from context. Based on line numbers, this would be similar/main/gameseq.cpp, line 933 in the unmodified source:
Code:
        do_checksum_calc(&i.station_idx, 1, &sum1, &sum2);
This is convenient, since station_idx is rarely modified. There are 8 places it could be modified, but we can exclude several of them right away. We are looking for places that could assign an integer 0 (gamelog-g) or 1 (gamelog-d). I cannot go further with the logs, but this was enough to start some interactive debugging. I hosted a game, under control of gdb, and inspected it to see what value I got when I played that level. I found 0, which is surprising. That's the value from gamelog-g, which is the guest, but I was hosting. I restarted, with a watchpoint on that address. It was never written. That was weird, but also very suspicious. If it isn't written, it will retain whatever value it had before, which may not be synchronized between the players, in which case mixing it into the synchronization checksum is wrong. I then hosted on level 2, not level 3, and observed the value get set to 1, matching gamelog-d. From this, I believe the bug is that you cannot reliably have a player join a game on a level other than the level where the host began the campaign. I cannot explain why reinstalling is required, but I never thought that made sense anyway. I think the real workaround is that the host needs to exit Descent completely, then restart it. I think loading a saved game is fine, which will hopefully be an acceptable workaround for people who play builds without this fix. For users with the patch mentioned at the start of this post, no workaround should be necessary.
Reply
#27
[strike]For the life of me I wished I'd saved the log.
But I kinda resigned myself to acceptance of the controller disconnect/level mismatch error to be user error and moved on.
But here I am days later thinking about a log error I saw.
It was something along the lines of....
Mismatch level set:64 wall:4 does not exist.[/strike]

Just saw post #26 when post refreshed the page.

You amaze me at how well you know all this information. You sir are amazing.

My family and I are testing the new guide bot experiment in MP
4 players
Reply
#28
Unfortunately, I can't do anything with the struck-out part. Mismatch is only used in one of the helper scripts, and is never used in the game's source code. level set appears in two comments, but never in a string that would have been printed to your screen or to the log. does not exist appears in one place as a string, with the message access to guarded object that does not exist. If you got that string, that's definitely a bug.

Please do report back on how the guidebot goes. You're the first person I know of to use it (excluding myself using it in test games, where I was just checking that it wasn't obviously broken).
Reply
#29
(07-24-2019, 01:41 AM)Kp Wrote: Unfortunately, I can't do anything with the struck-out part.  Mismatch is only used in one of the helper scripts, and is never used in the game's source code.  level set appears in two comments, but never in a string that would have been printed to your screen or to the log.  does not exist appears in one place as a string, with the message access to guarded object that does not exist.  If you got that string, that's definitely a bug.

Please do report back on how the guidebot goes.  You're the first person I know of to use it (excluding myself using it in test games, where I was just checking that it wasn't obviously broken).

No Need to do anything about the struck out part, hence it being struck out. 
When i posted it, my page refreshed and I noticed you had commented prior. So i struck it out as a way to say never mind but leave the info there in case it reared its ugly head again.
But that wont happen any way.
I made an updated build per your instructions. and tested for a few hours. First with out the guidebot. It took a while but tried to reproduce the ERROR mismatched level files, repeatedly..
Controller detachment, death, abort game and rejoin game, exit game and restart game, in many combinations as stand alone actions and combo actions.
*Death results in re-spawn. No issues present. 
*Controller detachment still resulting in loss of control even after reattached. only closing D2x-rebirth and restarting gives controller response back. But can rejoin MPG with out issue.
**Error is no longer present, affected player is always able to rejoin game in progress with out issue. 

MPG with guide bot threw a couple of [bug] lines. 
gonna open a issue on the git for that one.

http://theandroidcollective.org/dl/Gamel...23-SOG.zip
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)