Rebirth getting weird control types and changing HOG files
(This is in the 4/14 XP build)

Sometimes I will get an error "Unknown control type 5 in object 0". I don't even know what this means.
The weirder part is that every single attempt to play afterward will report a file mismatch until I recopy the files.

EDIT: After looking at the code, apparently the object is "slewing" (whatever that is) in the first error, which isn't checked for if 'RELEASE' is defined. I should note that the error never occurs on my (the host's) end.
First, please do not use the 4/14 build. It is very old. Use the latest commit from whichever branch you choose to track.

Second, I cannot reproduce the problem with the information available.

When you say you need to recopy files, which files are you copying and from where? Nothing should corrupt game data files. Save games might be corrupted if you saved after the in-memory data was corrupted.

The only place an error message like that appears is in an error path:
            Error("Unknown control type %d in object %hu, sig/type/id = %i/%i/%i",obj->control_type, static_cast<objnum_t>(obj), obj->signature.get(), obj->type, obj->id);
Object 0 is the object used for the ship of the host. When RELEASE is unset, slewing is handled. Slew is an alternate movement mode, which may be useful in development because it does not follow the rules used by normal flight. It should never occur during regular play. That error path has been there for a very long time, so the problem must be that now there is a way to enter slew state.
The copied files are the HOG files from one machine to the other.

Also I've historically had problems compiling, hence using the latest XP build I could find.
The hog files should never be modified by running the game. Could you summarize what it changes in them?
I don't know. I just get mismatch errors.

How does Rebirth check for the correct HOG version?
There is no one correct version. Rebirth supports HOGs from each of the official released versions (shareware, OEM, retail), and can limp along with unknown ones that are close enough to the default HOG version (retail game data).

Please explain what you hope to achieve in this thread. As it stands:
  • I do not understand what fails for you that requires a recopy. I need an exact error message about the mismatch. I would appreciate exact steps to reproduce. I would also appreciate an exact description of what it is you do afterward to clean up. Where do you get clean HOG files? In what ways do the good and bad HOG files differ? Who has the bad HOG files? Is that person doing anything that could modify the HOG files?
  • I am not convinced this is even a problem that can be fixed by a code change. I can add a hack to avoid the crash, but by the time you enter the state that causes the crash, you already have a currently unknown amount of memory corruption. If I don't know the extent of the corruption, I can't hack around it.
  • Even if a code fix were possible, the newest nightly is from April; I do not post compiled builds; and you do not prepare your own builds. So how would a code fix do you any good once I write and post it? You would need to make your own build, or find someone who will build it and post it for you. (AFP: any chance you could do this?)
If I had to guess from the information available, I would say that some other event is corrupting game data files, and everything reported is fallout from using corrupted inputs. Whether that external corruption is failing hardware, buggy system software, or a user playing with a buggy tool, I don't know.
By correct version I meant how it knows how if the clients' mission HOGs that are being used in the coop game are different enough to warn about a mismatch. I'm trying to see if I can identify what got changed.

EDIT: We tried again today, and everything worked fine (though we started on the level that caused issues). This suggests (given that this isn't the first time the issue has come up) that some memory associated with the file is being corrupted somewhere, which could also explain the slewing state. Given that the error occurs on level transition I'm wondering if something uses a bad pointer that contains something other than the expected level data.
I was just able to verify on a different level that the "checksum mismatch" was cleared by both people restarting Rebirth. However both people must do it - only the person with the error restarting doesn't fix anything.
The game checksums select segment data and sends the checksum. The full calculation is in netmisc_calc_checksum in similar/main/gameseq.cpp.

It would be a bit surprising that a wild write could manage to set a valid value, but it's possible. The levels aren't kept loaded when you're not playing them, so an early wild write shouldn't be able to corrupt a later level. The corruption would need to happen after the level loads, but before you can play it.

Can you provide a memory dump when the game reports the slew error?
How do I get to the memory dump?


Forum Jump:

Users browsing this thread: 4 Guest(s)