Checksum failure on 64 bit builds causes script load failure about descent3 HOT 7 CLOSED

Eventually the scripting system is going to be replaced with a WebAssembly based one

FWIW, that isn't set in stone yet though it's currently the top choice it appears.

from descent3.

Checksum is calculated based on size of various structures and objects. Some of them has members with long or ulong type with 8 bytes long instead 4 on 32 bit, so on 64 bit we have different size and different checksum. Need to carefully examine Osiris structures involved to checksum calculation and replace (u)long to (u)int32_t from cstdint.

from descent3.

Checksum is calculated based on size of various structures and objects. Some of them has members with long or ulong type with 8 bytes long instead 4 on 32 bit, so on 64 bit we have different size and different checksum. Need to carefully examine Osiris structures involved to checksum calculation and replace (u)long to (u)int32_t from cstdint.

I think the bigger problem is going to be pointers. AFAIK there isn't a way to get 32 bit pointers on aarch64 so we'll always be adding 4 bytes there.

from descent3.

Checksum is calculated based on size of various structures and objects. Some of them has members with long or ulong type with 8 bytes long instead 4 on 32 bit, so on 64 bit we have different size and different checksum. Need to carefully examine Osiris structures involved to checksum calculation and replace (u)long to (u)int32_t from cstdint.

I think the bigger problem is going to be pointers. AFAIK there isn't a way to get 32 bit pointers on aarch64 so we'll always be adding 4 bytes there.

Yeah, this too.

from descent3.

Here are my thoughts:
For all platforms use the d3-linux.hog concept that way we effectively can move away from BOA checksum system entirely.

Then update how the level scripts hog filename is generated based on the build environment:

Microsoft Windows Visual C++: d3scripts-win32.hog or d3scripts-win64.hog
Platforms using GCC/Clang: d3scripts-<triple target>.hog
Mac with Xcode: d3scripts-<whatever xcode decides to use for target names>.hog

from descent3.

Checksums here is way to determine that nothing changed on ABI level of Osiris subsystem. On updating scripting system without checksums we cannot say that certain script in hog file can actually executed.

from descent3.

I get that, but going forward we only need to manage a spec version since rather then depending on struct sizes, it is just a hacky solution to being with and not worth to maintain between various platforms. Eventually the scripting system is going to be replaced with a WebAssembly based one, and with that, the modules just need conform to some versioned spec check as well.

I believe the compiled script stuff was something closed off to the public? I can see for internal development, where you have multiple teams working on things parallel, and some kind of verification was needed in place. Today, no one is working on the official assets as they are still closed sourced and not going to change until that legal stance changes. Lets not forget all of the official level scripts are now part of the main source, so there isn't a need to verify things that live right in the same source repo. If someone does make a major change to the scripting system, it their responsibility to make sure all the level scripts all work too.

from descent3.