A bug and some requests

[Jake-NotTheMuss]

Hello, I have a bug to report and some requests.

In scripts/shared/audio_shared.csc in the function startSoundLoops(), there is an else block which encloses a devblock which encloses an if block. In the source, it looks like this:

else
{
  /#
    if( GetDvarint( "debug_audio" ) > 0 )
    {
      println( "*** Client : No looper sounds." );
    }	
  #/			
}

In the decompilation, it looks like this:

else
{
  /#
    println("");
  #/
  if(getdvarint("") > 0)
  {
  }
}

So the devblock and all the ops within it are listed before the if skeleton, and then the empty if block after

Most zm_*_amb.csc scripts have a function very similar to startSoundLoops() with this same problem, and the only other example of this that I found is in scripts/zm/zm_castle_weap_quest_upgrade.gsc, which can be seen in the images I attached.

Images showing these examples:

I also have some requests:

• listing includes by their actual table order rather than sorted alphabetically. When rewriting scripts from their decompiled representations, I want to match the script as accurately as I can, including the include order. I can check the FF dumps to see the include order for a particular script, but it would be more convenient if the order was listed in the decompiled script.

• Identify debug strings by adding enumerated placeholder names such as "Dev string 1", "Dev string 2", etc., where "Dev string n" is the nth debug string in the table, just as an example. Like with includes, this would make it more convenient to know which dev string I'm looking at rather than having to check the FF dumps. ( Also, another thing I often check is the length of a debug string, which you get from the FF dump based on offset differences in the table. Maybe in addition to enumerating them, you can put something like "Dev string 1 (length: 10 + 1)" where the string has 10 characters plus a null byte, for example, and then the last dev string would be "Dev string n ( last string, unknown length )" )

• Including code after unconditional returns ( or maybe this is a bug, but an example of this is in scripts/shared/_character_customization.csc in the function handle_forced_streaming(), which returns immediately but still has code after the return. Another example is in scripts/zm/_util.gsc in getOtherTeam(), where the function returns unconditionally and then has an assertmsg after.

Any of these changes would be a big help with what I use these scripts for.

[shiversoftdev]

I will fix the nested block issue (unfortunate because I knew this was a potential edge case but the fix is going to be awful).

I will remove the sort from the includes as well.

Emission of dev strings will be done by offset only; calculating length is undesirable if there are exceptions, IMO. If I output the offsets as hex strings, similar to hashes, in the format dev_01ab23cd, you should be able to do the calculation of length on your end if necessary.

Code not included after unconditional returns is due to how the decompiler determines where it should stop decompiling. I do a control flow-based parse where the function parses opcodes until it meets an end condition. It is unrealistic to expect this behavior to be changed because of the way files are emitted in memory. There is no guarantee of the bytes following a function, so it is possible to overrun a function that has bytes that resemble a valid opcode, thus breaking decompilation for that function. There is no size field emitted for functions, nor can you simply set overrun boundaries. This means that for the purposes of decompilation, I cannot parse past the end of the function's control flow for fear of inaccuracies in other places.

I will tack on the dev strings and nested block fixes when I get a chance.

[Jake-NotTheMuss]

Awesome

[Jake-NotTheMuss]

I have another small request: for OP_GetFloat, when the float is a whole number, the number is printed as a whole-number rounded integer in the decompiled output, which makes it unclear sometimes whether there was a GetByte or a GetFloat where the number is used. Can you make it so that GetFloat values always have a decimal point?