dat had ik in het begin ook.
ik kwam er achter dat als je de lengte aanapst dat het dan niet meer werkt,
aangezien er in het begin geen ascii data staar maar wat anders dach tik nou dna meot daar wel wat info staan over de lengtes ofzo.
dus ff in een hex edtior geopend een uurtje of 1 2 trial and error en toen had ik het gevonden.
het werkt zo:
de eerste 8 bytes worden niet gebruikt.
byte 8 + byte 9*256 vormen de offset van string 1. (vanaf waar de tejst begint, byte 446)
byte 10 + byte 11*256 vormen de offset van string 2.
in het geval van tsk zijn de eerste 5 getallen bijv.
20
36
52
68
84
de tekst begint op byte 446
Nieuw spel beginnen
elke tekst eindigt een 0b00000000
die eind bit van teskt 1 stata dus op 446+20
de iend bit van tekst 2 staat dus op 446+36
de eind bit van tekst 3 staat dus op 446+52
enzovoorts.
als je dus een tekst langer maakt, meot je ook het corrosponderende getal aan het begin gaan aanpassen.
waar je ngo wel op meot letten is dat er heel veel byte paren zijn die FF FF zijn (255*255)
die kan je negeren.
waarschijnlijk zijn dat de restanten van text strings die ze eerst hadden (voor bijv de muur) die ze er later uitgehaald hebben en de lengte maar naar FF hebben gedaan om te zorgen dat niet alles in de war komt.