RBSong Writer/Reader null-termination oddity

[maxton]

Strings and symbols in RBSongs and DTBs are stored as what some call "pascal strings" - that is, first the length of the string is written as an unsigned int, then the string itself is written. This is in contrast to "C strings" which do not have the length, but rather are terminated with a single null byte after the string.

However, this is not entirely true, evidently: sometimes, strings in RBSongs are both length-prefixed AND null-terminated! Through trial and error I devised some code that seems to work for reading these strings and skipping the null-terminator when needed (https://github.com/maxton/LibForge/blob/master/LibForge/LibForge/RBSong/RBSongReader.cs#L164) but the code is basically "guessing" if the next byte is a null terminator or not.

I think the only way to sort this out is to find the RBSong reading routines (possibly the writing ones, in case they are in the game binary and not just the editor) in either RBVR's or RB4's binary and see what the actual logic behind this is. What a pain!

[maxton]

Debug symbols are awesome! I think I can find the routines now thanks to cross referencing some stuff with what I assume to be unintentional debug symbols left in an HmxAudioPlugin library

[maxton]

This is "fixed" for now in a duct-tape sort of way but I'll leave the issue open as I still don't know the real issue is.

[maxton]

This is fixed in c4feb31, it was never a null terminator but actually all ResourcePath types start with a single additional byte that's usually 0. They just happened to follow symbols and other resourcepaths so they looked like null terminators.