Error reading Mission State File zum 2ten

was diese Fehlermeldung bedeutet: die sav.lua Datei ist nicht lesbar

Bitte diese mal anhängen

Ich würde sagen TPF2 kann kein min = inf, laden. Zumindest mein luaTPF::Value hätte da wohl auch Probleme mit, wenn es es eine infinity float bekommt und es dann weiter in c++ verarbeiten muss. Wobei laut TPF2 Konsole, inf = nil ist. Wenn ich mich recht erinnere kann erst LUA 5.3 mit INF und co umgehen, keine Ahnung was LUA 5.2 rausgibt oder TPF2 da macht. (Auch keine Zeit das gerade zu testen)

Beispiel:

    line = {
                AIRCRAFT = {
                    Price = {
                        av = false,
                        max = 0,
                        min = inf,
                        num = 0,
                        sum = 0,
                    },

Da du scheinbar die Savegames durchnummerierst, könnte man ein vielleicht einen Diff zwischen dieser Datei und ein funktionierendes Savegame machen...

Ist eine funktionierende sav Datei eigentlich viel größer?

Kannst Du die "Qhulan - Cutash 247.sav.lua" zum Vergleich auch mal hier hochladen? Wenn es ein inhaltlicher Fehler ist können wir dann ein bisschen mitsuchen/vergleichen. Was hat Dir der Diff denn ausgegeben.

Zitat von eis_os

Ich würde sagen TPF2 kann kein min = inf, laden

"inf" ist kein Problem. Das wäre schon viel früher aufgefallen, so oft wie das vorkommt. Abgesehen davon dass es math.inf sein müsste und inf=nil ist.

Das Problem ist "-nan(ind)" (der Lua Wert für NaN) , ebenso "-inf"

Es geht ja hier um Advanced Statistics

data = {...
    town = {...
        TrafficRatings = {
                    av = -nan(ind),
                    max = 0.98568439483643,
                    min = 0.94183653593063,
                    num = 5,
                    sum = -nan(ind),
                },

ich hab mich natürlich bei der Entwicklung schon damit rumgeschlagen, als es das erste mal auftrat und ich natürlich erstmal keine Ahnung hatte wo das Problem ist. Ja ich habe 0/0 geteilt, passiert halt bei einem Durchschnitt, wenn n=0... Ich habe dann natürlich Vorkehrungen getroffen, dass das vermieden wird.

Sooo warum passiert das jetzt hier trotzdem.....

Bei einer Stadt ist das TrafficRating unerwarteterweise -nan(ind). Davon kann man nun wirklich nicht ausgehen. Vor allem, da das vorher nie aufgetreten ist.

Vorübergehender Fix: Die sav.lua löschen, wenn du keine Mod hast die da was wichtiges reinschreibt (wie zB Timetables; bei Adv.stats sind es nur die Einstellungen). Oder besser: die -nan(ind) einfach mit 0 ersetzen. Die Daten werden nicht gebraucht, sondern nächstes mal neu berechnet. Oder noch besser, mir fällt grad ein, ich hatte mal ein Button "Free data" gebaut, um eben die ganzen daten vom state zu löschen.

BITTE AN UG

Das Spiel muss endlich robuster werden. Es muss doch in euerm Interesse sein, dass gerade Fehler, die nicht sofort einer Mod zugewiesen werden können, besonders kritisch sind?

Nicht jeder Modder kann jetzt anfangen nochmal seinen state Inhalt zu überprüfen, ob da zufällig doch -nan(ind) drin steht, weil die api unerwartet diesen Wert ausgibt.

Vorschlag: Entweder kann -nan(ind) und -inf vom state file problemlos eingelesen werden oder es wird ein Fehler geworfen wenn state in save() diese problematischen Werte enthält (für userdata klappt das ja auch)

Ja, inf ist nil, nan ist halt auch nil, und ein Funktionsaufruf mit nil() wirft dann schon in LUA den Fehler. Du kannst das nur verhindern wenn du solche Wert niemals bei einem save event an UGs Code gibt. Eine andere Lösung fällt mir da nicht ein. Ok, ich hätte da ne Lösung die ich wohl noch in CommonAPI2 einbauen könnte... aber naja...


Das UG das fixt, unwahrscheinlich... (das ist ein Ansporn an Yoshi mich eines besseren zu belehren )

Ich hab das gefühlt, irgendwann bekomme ich eine Care Palette mit Plaster angeliefert...


Ein suchen und ersetzen von nan(ind) durch sagen wir mal 0 solle ein Savegame wieder lauffähig machen...

Völlig egal was da steht -0 macht keinen Syntax Fehler. Kannst auch schreiben sum = iljhashdfiuhasjhdbas

Ja Lua ist etwas eigen.

Also eigentlich ist es ja ein Problem im serializer