-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
According to my website, ins_14 in STD gains a third argument in UFO, which holds the layer.
STD_BY_OPCODE.set('12', {
...STD_BY_OPCODE.get('11'),
14: {ref: 'std:sprite-3arg'}, // signature change!
18: {ref: 'std:up-time'},
});
Yet, trustd's core mapfiles have been decompiling this using a signature of SS without issue:
$ for x in ~/thcrap/decomp/bleh12/*.std; do TRUTH_MAP_PATH= target/release/trustd d --game 12 $x | grep ins_14; done
warning: /home/exp/thcrap/decomp/bleh12/stage02.std: object at index 2: object has non-sequential id (expected 2, got 1)
ins_14(0, 4);
ins_14(1, 5);
ins_14(2, 6);
ins_14(3, 7);
warning: /home/exp/thcrap/decomp/bleh12/stage07.std: object at index 2: object has non-sequential id (expected 2, got 1)
truth would warn if there were leftover bytes in the instruction, so clearly SS is correct. Where did SSS come from? Is this what it changes to in th14 maybe?
Metadata
Metadata
Assignees
Labels
No labels