Learning how to decompile .o files

[Cjk10000]

One problem that people are probably running into is that with new zdoom functions getting added, older decompilers (like ListACS) that work for the new zdoom features don't work anymore, or pretty much break if one unknown function comes along.

I compiled something in a new format and seemed to have misplaced the source somehow. Ideally I'd like to get it back by decompiling-- luckily in my case it was just a few lines of ACS code... but if it was much larger I'd have been out of luck.

I can't find anywhere on documentation for reading the bytecode itself. I checked the Hexen specs to see if I could get a headstart, but it just tells you stuff that a programmer already knows/can infer easily. Ideally the plan was to find a file like the Unofficial Doom Specs file which tells you in detail the purpose of the bytes and how to extrapolate usable data from them.
Is there anyway to find documentation on how to read the compiled bytecode? I read somewhere that Randy pretty much redid ACS so I assume the newer ACS may potentially be completely different from Hexen scripts.

[Nash]

It's unfortunate that you lost your source but it's better to have backups handy. Even sending the source to your own e-mail address is better than absolutely no backups...

[Blzut3]

Is there anyway to find documentation on how to read the compiled bytecode? I read somewhere that Randy pretty much redid ACS so I assume the newer ACS may potentially be completely different from Hexen scripts.

Here you go.

[Cjk10000]

Is there anyway to find documentation on how to read the compiled bytecode? I read somewhere that Randy pretty much redid ACS so I assume the newer ACS may potentially be completely different from Hexen scripts.

Here you go.

That is awesome! Thanks

If you don't mind me ninja'ing a question in here:
How does zdoom handle multiple scripts with respect to stacks? Does it have a separate stack for every script run? Always wondered how it also determines which ones to run...etc
So far I've read over the entire manual, that's pretty much the last part I'm trying to figure out (besides getting the blocks like if/while/switch to be read correctly)

[Blzut3]

How does zdoom handle multiple scripts with respect to stacks? Does it have a separate stack for every script run? Always wondered how it also determines which ones to run...etc

While scripts should be seen as executing simultaneously with no particular order (much like threads) they are technically executed in some undefined order one by one until either a terminate or delay instruction is reached. The stack pointer is zeroed between scripts, but in theory it should always be 0 after the execution of such instruction.

[Gez]

The order is not undefined actually, since it has been subjected to a hidden compatibility option to run vanilla Hexen map in the reverse order of what ZDoom does. Or I'm being confused.

[Blzut3]

The order is not undefined actually, since it has been subjected to a hidden compatibility option to run vanilla Hexen map in the reverse order of what ZDoom does. Or I'm being confused.

The order in which the scripts execute are undefined. That compatibility option changes the preference when loading multiple scripts with the same number IIRC.

[Worst]

That compatibility option changes the preference when loading multiple scripts with the same number IIRC.

How would you load multiple scripts with the same number in vanilla hexen? There is no library support, so in order for that to happen, you'd need two scripts with the same number, within the same behaviour lump.. at which point I think ACC would have yelled at anyone trying that.

There is a compability check that reverses the order in which scripts executed during the same tic are run.
http://www.zdoom.org/Changelog/1565/files

[Blzut3]

How would you load multiple scripts with the same number in vanilla hexen? There is no library support, so in order for that to happen, you'd need two scripts with the same number, within the same behaviour lump.. at which point I think ACC would have yelled at anyone trying that.

If you use "think" and "ACC" in the same sentence you're probably wrong. viewtopic.php?f=7&t=25065&p=480643

There is a compability check that reverses the order in which scripts executed during the same tic are run.
http://www.zdoom.org/Changelog/1565/files

I see. Regardless though, it isn't safe to assume any order if you want maximum compatibility between VMs. (Yes there is another port non-ZDoom based getting support for ZDoom's ACS.) Since it's not a safe assumption it can be said to be undefined.

[Graf Zahl]

It may be undefined but any port implementing ACS should be aware of this - or it may get problems with some maps.

[Cjk10000]

(Yes there is another port non-ZDoom based getting support for ZDoom's ACS.)

Cool, which one is that?

[Blzut3]

Cool, which one is that?

Eternity Engine