View Single Post
Old 28 February 2017, 11:39   #2
Registered User

Join Date: Feb 2017
Location: fastmem
Posts: 36
Originally Posted by demoniac View Post
Curious if anyone could figure out how to fix this bug?
Seems the cine bytecode is missing an 'update all' opcode during that sequence - it processes the text correctly and at the correct time, just doesn't display it.

I verified against two ipf sets (1163 and 1885) and the error is present in both. The cine bytecode is compressed on disk (and checksummed), so this is not a rip or crack artifact - it's an issue that has always been present as far as I can tell.


It's tricky to insert the correct opcode as the bytecode stream is quite tight - but there is room to do a shuffle without lengthening the stream

Original sequence:   ..., 'update_prims',   'string_id 0x3a', 'clear 0x04', ...
It should have been: ..., 'update_prims',   'string_id 0x3a', 'update_all', 'clear 0x04', ...
Shuffle fix is:      ..., 'string_id 0x3a', 'update_all',     'clear 0x04', ...
So a 4 byte in-place patch however, as mentioned above, the bytecode is compressed on disk (another custom dictionary packer, fml), so I'll have to reverse it and write a compressor... :s

In the meantime, if you want to see the cine as it was intended...

Freeze at the start of the sequence...

find the following:  00 18 00 3A 04 04
replace with:        18 00 3A 14 04 04

...and continue.
pants is offline  
Page generated in 0.04834 seconds with 9 queries