[0.4.2] [Blood] Enemy state is reset on savegame load

[_mental_]

Makes me wonder why the compiler creates such different results compared to MSVC.

Thanks to bitfields, e.g. for MSVC sizeof(Blood::XSPRITE) is 80 bytes, for GCC it's 70.

[sinisterseed]

This still warrants investigation, if it happens so frequently on Linux. That's a clear sign that the code isn't doing what's to be expected. When it comes to pointer<->integer conversions one has to be careful - some compiler writers seem to treat such things as their playground for unsafe optimizations.

I'll hook up something here and let Manuel test it.

EDIT: done. It now prints some diagnostics when saving and loading. Let's hope this gives us a hint at what's happening here.

Never said it ain't worth investigating , especially since on Linux it happens constantly. Was just saying that troubleshooting AI glitches can be a pain sometimes, insofar as some originate from vanilla and not necessarily because of a feature that isn't working properly yet.

[Graf Zahl]

Makes me wonder why the compiler creates such different results compared to MSVC.

Thanks to bitfields, e.g. for MSVC sizeof(Blood::XSPRITE) is 80 bytes, for GCC it's 70.

The savegame code overall really needs to be redone. Even when writing binary data it cannot be done as blobs, it needs to write out all fields in a defined fashion so that such architectural differences do not affect the result. ZDoom never had such problems because even with its binary format, every single bit of data was written out separately in a machine independent form.
Of course this also means that bitfields are a no-go.

[Rachael]

Does Rachael use gcc or clang?

Clang 6.0, as included in Ubuntu's 18.04 repositories.

Code: Select all

clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I used it because at the time that I created the build tree, I was attempting to do the Linux port for Raze and Graf was already working on fixing the Mac OS version so it would compile, and I figured we'd get similar results by using similar compilers. (Mac uses Clang exclusively in Xcode, as far as I know)

I'll probably upgrade to Clang 9 at some point, but I have to remove something else from the system first.

[Manuel-K]

(…) if it happens so frequently on Linux.

I have a 100% bug trigger rate on Windows 8.1. On Linux my rate is a lot lower.


–––

So all in all I've triggered the bug if the engine was compiled by gcc, by clang and by msvc. I'll call that a huge success.

[Graf Zahl]

I'd still like to see what the debug output says which I added this morning.

[Manuel-K]

That's the output with the bug.

Edit: Shouldn't the printf inside the if of UnindexAIState after the assignment to state?

[Graf Zahl]

How precisely do you manage to get it?

[Manuel-K]

How precisely do you manage to get it?

The bug?

Hit a zombie with the pitchfork, wait until it's starting to get up again and save when it's almost standing.

[Graf Zahl]

I think I know what's going on. If you whack the zombie before it fully rises from the grave it never switches to its attacking AI - it stays in its rising-from-the-grave AI, and in that state cannot find any targets. That can be reproduced 100% even without savegames. Of course, if you save after knocking it down it will stay in that phase and aimlessly run around.

In other words: Totally unrelated to the savegame feature, it's a bug from the original game.

[Manuel-K]

That seems reasonable and I can confirm it on my end. It seems that I've been too fast during my previous tests.

I'm sorry for causing unnecessary confusion.

[Graf Zahl]

Don't worry. Finding the cause of that bug was worth it. Now I can investigate how to avoid it.

[Graf Zahl]

The cluelessly running around zombie should be fixed now.

[markanini]

This bug has been present since the DOS original. Amazing to see it fixed!