Ireyon
bei Xistics2RoadCafeItaly1 ist es byte 19 mit einem punkt, und da sind noch jede menge nullbytes dazwischen. ausserdem weiss ich nich wie ich dateien byte für byte auslesen kann..
ausserdem verwenden leider nicht alle objekte shared textures, also kann es passieren, dass gar kein ordner angelegt wird, weil das erste objekt keine nutzt. geht also nur wenn ich alle dateien auslese bis ein pfad gefunden wurde. das ist aber wahrscheinlich sehr langsam. hm...
errt
Das erste kann ich nicht bestätigen. Bei allen von mir überprüften .unique.ovls aus dem Xistics2RoadCafeItaly1 beginnt der Pfad bei Byte 15 mit dem \ und endet mit einem Null-Byte. Dass man alle Dateien auslesen muss, ist klar. Das dauert dann halt etwas. Zum Auslesen in Bytes: Ich weiß nicht, mit was du proggst, aber zumindest die Net-Sprachen kennen ConvertToByteArray oder wie der Befehl heißt.
EDIT: Habs nachgeschaut. In den Net-Sprachen geht es so:
ByteArray = My.Computer.FileSystem.ReadAllBytes(Datei)
Ireyon
nur schade, dass ich mit delphi5 arbeite und das zum glück noch keine .NET-Unterstützung hat
mit was für nem programm hast du die dateien denn überprüft? ich persöhnlich arbeite da mit winVI. vllt haben andere programme probleme mit den nullbytes?
und der pfad '..\shared\[...]' ist irgendwie logisch, weil der ordner meistens nicht da ist, wo das objekt sich befindet.
na ja mal guggen.
errt
Ich verwende HxD als Hexeditor zum überprüfen. Damit hab ich auch das Theme-Byte gefunden, über das der Category-Changer arbeitet. Also müsste es eigentlich gehen. Ansonsten musst du halt mal schauen, ich bin sicher, Delphi kann ebenfalls Dateien in Byte-Arrays einlesen. Zumindest ist der Category-Changer in seiner jetzigen Version auch ein Delphi-Programm. Allerdings glaub ich nicht delphi5.
Ireyon
delphi kann bytes grabben, hab jetzt auch endlich raus wie, allerdings werde ich alle bytes einzeln auslesen und überprüfen, und wenn es einen gewünschten wert hat, an einen string haengen. so viel zum auslesen.
btw: so wird jetzt der shared-name gefunden, jetzt muss ich ihn nur noch zerlegen, was aber kein problem darstellen dürfte, wiel ich dafür schon entsprechende funktionen habe.
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
|
fstp := false;
for i := 1 to 100 do
begin
fl.Read(a, 1);
if a = $2e then fstp := true;
if fstp then
begin
if (a >= $2d) and (a <= $7a) then
ls := ls + Char(a)
else
break;
end;
end; |
|
EDIT: Bitte testet doch mal die neue version und berichtet wieder über fehler
errt
Beim starten des Progs bekomm ich ne Zugriffsverletzung. Beim Installieren eines Sets sagt er 'Verzeichnis kann nicht erstellt werden' und bricht mit der Installation ab.
Mehr hab ich bis jetzt nicht gefunden
Ireyon
könnte mit der registry zusammenhängen, ich versuchs mal mit ner inidatei...
so, probiers jetzt nochmal
danke für den hinweis, ich bin so doof manchmal
errt
Kein Problem. Am leichtestens gehts mit Versuch und Irrtum^^ Das mit der ini-Datei ist halt nicht so 'schön'. Lässt sich das mit der Registry noch reparieren? Aber wenn nicht, ist es trotzdem gut geworden.
Ireyon
danke
ich persönlich arbeite lieber mit inifiles, weil sie schön textbasiert sind... und ich die fehler leichter finde.
bitte nochmal das aktuelle archiv nehmen, da ich inzwischen nochmal 20 bugs gefixt habe
errt
20 Bugs? Wo hast du die denn alle her?
Ireyon
können auch 30 sein... da waren noch einige drin und das mit der inifile scheint zumindest bei jobswoth nicht zu klappen...
errt
Habe jetzt 8 Sets damit installiert. 7 davon mit shared-Textures. Bei 5 hat er alles ordentlich gemacht. Bei shyguys Billboard Inserts und shyguys Water World 1 hat er aber die shared-Textures nicht erkannt und demnach nicht installiert. Außerdem stellt er den Pfad in der INI-Datei bei ca. 75% der Benutzungen wieder zurück auf Program Files und fragt dann wieder den Pfad ab. Und ein paarmal ist das Prog kommentarlost zugegangen.
Ireyon
So, das Update ist da, ich hoffe mal, dass es jetzt vollständig Shared Textures erkennt.
Und das iniproblem habe ich dank errt jetzt auch lösen können.
Und Leute, dioe ihre RCT3.exe aufgrund der installation von Soaked oder Wild schon gelöscht haben, können das Programm jetzta uch wieder nutzen.
errt
Ich helfe doch gerne bei so einem Projekt. Testen werde ichs nacher, und die Fehler wieder melden
Also das Installieren der Sets klappt jetzt soweit, die shared-Textures werden erkannt, der Ordner dafür angelegt. ABER die shared-Textures werden nicht in diesen Ordner kopiert und fehlen damit. Außerdem schmiert das Programm manchmal meldunglos ab.
Belgabor
Kannst Du unter Delphi irgendwie C++ Klassen aus bibliotheken linken? Dann könnte ich Dir glaube ich beträchtlich helfen =)
Ireyon
ich wüsste nicht, wie
btw: funktionierts denn jetzt wenigstens?^^
Belgabor
Ok, ich fürchte Du wirst früher oder später ein Problem kriegen. Die nächste Importerversion wird ovls anders schreiben als bisher.
Du musst anfangen, OVLs "richtig" zu lesen. Dafür sehe ich momentan zwei Möglichkeiten:
- Du steigst auf C++ um und verwendest die Klasse, die ich schon zum Grossteil geschrieben habe
- Ich erkläre Dir, wie ovls aufgebaut sind und Du interpretierst sie in Pascal
Ireyon
mal eben so auf C++ umsteigen geht nich. in kann es zwar ein bisschen, aber zu wenig, um so ein programm zu schreiben. Aber ich würde sagen: erstmal abwarten. allzuviel kann sich ja nicht ändern.
und was meinst du mit 'richtig' lesen?
errt
Naja, aktuell lesen wir in den OVLs mehr nach Zufall. Das funktioniert, weil der aktuelle Importer die OVLs immer nach einem bestimmten Schema erstellt. Jetzt wo wir aber wissen, wie die OVLs funktionieren, können wir sie 'richtig' aufbauen. Leider wird das dann dazu führen, dass die OVLs sich nichtmehr so einfach auslesen lassen.
Ireyon
wie funktionieren sie denn 'richtig'? dann könnte ich naemlich wirklich ne OVL-klasse zusammenschrauben. das aktuelle system suckt sowieso etwas.