Ergebnis 1 bis 15 von 15

Thema: Picture Anzeigen - Error?

  1. #1

    Users Awaiting Email Confirmation

    Picture Anzeigen - Error?


    Diese Fehlermeldung kommt,wenn ich das Gegenstandsmenü aufrufen will.

  2. #2
    kann es sein, dass irgendwas mit dem picture nicht stimmt? Das es die datei gar nicht mehr gibt oder umbenannt wurde?

  3. #3
    Zitat Zitat
    gar nicht mehr gibt oder umbenannt wurde?
    In dem Fall wäre der Fehler "File not found" gewesen denke ich.

    Hat es denn eine ID die von der RPG_RT akzeptiert wird, also innerhalb des Limits ist?
    Unsinn, das ist auch ein anderer Fehler...

  4. #4

    Users Awaiting Email Confirmation

    öhm,ID 51-54.
    €dit:
    Ich hab jetzt den rm2k3 100 Pics Patch und es funktioniert O.o

    Geändert von Engel der Furcht (14.04.2010 um 21:58 Uhr)

  5. #5
    Anscheinend war das ein Fehler im Script vom rm2k3 selbst, weil da von "526 Line" steht.
    Den Fehler gibts ja öfter im rmxp oder vx, wenn man ein Script reinschiesst.
    Mit dem Patch wurde das normale Picture Script vom rm2k3 wahrscheinlich überschrieben.

  6. #6
    Zitat Zitat
    Ich hab jetzt den rm2k3 100 Pics Patch und es funktioniert O.o
    Dann waren es also doch IDs, nunja wie du wissen solltest kannst du ja
    keine höheren Werte nehmen als die RPG_RT vorschreibt.

    Zitat Zitat
    Anscheinend war das ein Fehler im Script vom rm2k3 selbst, weil da von "526 Line" steht.
    Halt ein Fehler im Quellcode, ist aber irre dass das Programm immernoch die
    Originalpfade samt Datei und Codeline vom Entwickler kennt.

    Zitat Zitat
    vom rm2k3 wahrscheinlich überschrieben.
    Die Picturezahl wird an einem bestimmten Byte verändert, das lässt sich bis
    126 hochstellen, danach gibt er auf und meldet einen anderen Fehler.

  7. #7
    Ich hatte den Fehler immer, wenn ich den PPP von Cherry eingesetzt hab und die RPG_RT.exe nich gepatched hatte <.<

    Also ist es einfach der Fehler, der auftritt, wenn man ID's aufruft, die die RPG_RT.exe gar nich zur Verfügung stellt, wie MagicMaker im Grunde schon gesagt hat =)

    PeAcE
    MorDen

  8. #8
    Kann es also sein, dass Engel der Furcht den PPP drin hatte, die Pictures aber normal per Command aufrufen wollte und deshalb der Fehler aufgetreten ist?
    Dann hat der 100 Picture-Patch den PPP irgendwie überschrieben, wäre möglich...

  9. #9

    Users Awaiting Email Confirmation

    ich frag mich,warum das nicht funtzte - der Maker konnte schon von anfang an 126 Pictures anzeigen ...

  10. #10
    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    ich frag mich,warum das nicht funtzte - der Maker konnte schon von anfang an 126 Pictures anzeigen ...
    Nein, der hat normalerweise nur 20 drauf. o_O
    Hast du vielleicht unbewusst den Patch von Cherry benutzt?^^

  11. #11
    Tut mir Leid, aber das ist der "Ungültige Picture-ID" Fehler. Du hast anscheinend doch
    keinen Patch drauf. Und nur weil du im Maker 126 Pictures einstellen kannst heißt das noch
    lange nicht, dass du auch 126 Pictures zur Verfügung hast. Ich benutz den PPP, ich hab
    mir die Anzeige auf 100000 hochgeschraubt für die Pointer-IDs. Ändert auch nix dran dass
    ich nicht mehr als meine 100 Pictures benutzen kann.

  12. #12

    Users Awaiting Email Confirmation

    Zitat Zitat von Nemica Beitrag anzeigen
    Tut mir Leid, aber das ist der "Ungültige Picture-ID" Fehler. Du hast anscheinend doch
    keinen Patch drauf. Und nur weil du im Maker 126 Pictures einstellen kannst heißt das noch
    lange nicht, dass du auch 126 Pictures zur Verfügung hast. Ich benutz den PPP, ich hab
    mir die Anzeige auf 100000 hochgeschraubt für die Pointer-IDs. Ändert auch nix dran dass
    ich nicht mehr als meine 100 Pictures benutzen kann.
    mir ist schon klar,dass man eine extra RPG_RT.exe braucht.

  13. #13
    Zitat Zitat
    Dann hat der 100 Picture-Patch den PPP irgendwie überschrieben, wäre möglich...
    Der PPP ersetzt Picture-IDs doch nur mit Variablenwerten, bzw Version 2 auch die Namen.

    Zitat Zitat
    Nein, der hat normalerweise nur 20 drauf. o_O
    Die RPG_RT kennt 20 bzw 40 bzw 50 aber von der reservierten Speichermenge her
    lässt es sich auf 126 hochdrehen. Alle Werte darüber, ausser über eine weitgehende
    Manipulation wie 9999-Pics im HP2, führt zum sofortigen Absturz beim Starten.

  14. #14
    Zitat Zitat von MagicMaker Beitrag anzeigen
    Die RPG_RT kennt 20 bzw 40 bzw 50 aber von der reservierten Speichermenge her
    lässt es sich auf 126 hochdrehen. Alle Werte darüber, ausser über eine weitgehende
    Manipulation wie 9999-Pics im HP2, führt zum sofortigen Absturz beim Starten.
    Ich rede aber von normalerweise und nichts anderes.

  15. #15
    Zitat Zitat von MagicMaker Beitrag anzeigen
    Halt ein Fehler im Quellcode, ist aber irre dass das Programm immernoch die
    Originalpfade samt Datei und Codeline vom Entwickler kennt.
    Naja, das kommt daher, dass die da, um zu verhindern, dass im Speicher was überschrieben wird, wenn zu hohe Picture IDs verwendet werden, die ungefähr sowas drin haben:

    Code:
    assert(id <= 20)
    Das sollte normalerweise in einem fertigen Programm nicht stehen, es dient nämlich eher dazu, so einen Fehler abzufangen und dem Programmierer zu berichten, welches "assert" in seinem Code das ausgelöst hat, damit der herausfinden kann, warum diese "Schutzbedingung" (id <= 20) nicht erfüllt war. Dazu wird Zeilennummer und Dateipfad in die EXE reingeschrieben.

    Da da aber eben der Fall 0 zugelassen wird (0 ist ja <= 20), kommt, wenn man per PicPointerPatch und eine Variable mit Wert 0 versucht, ein Picture #0 anzuzeigen, eine hässliche Access Violation (bzw. ???????????????, bei japanischen Fehlermeldungen).

    Zitat Zitat von MagicMaker Beitrag anzeigen
    Die Picturezahl wird an einem bestimmten Byte verändert, das lässt sich bis
    126 hochstellen, danach gibt er auf und meldet einen anderen Fehler.
    Naja, es sind mehrere Bytes, nämlich lauter Stopbedingungen in Schleifen (und eben dieses assert), und dass es bis 126 geht, liegt daran, dass der Indexwert ZUERST um 1 erhöht wird und DANN verglichen. Wenn du also 20 Pictures hast, wird da mit 21 verglichen und im false-Fall die Schleife verlassen*. Da der Vergleich aber vorzeichenbehaftet stattfindet und nur ein Byte verglichen wird (kein DWord), kann ich als höchsten Wert nur 127 (also 126 Pictures) einstellen, weil der Bereich eines vorzeichenbehafteten Bytes von -128 bis +127 reicht. Für höhere Zahlen braucht man dann mehr als ein Byte, dazu muss aber auch der Befehl, der für den Vergleich zuständig ist, umgeschrieben werden, sodass er ein DWord (32 Bit) abfragt, und nicht ein Byte (8 Bit). Da ein DWord aber 4 Bytes Platz braucht, und natürlich nur 1 Byte Platz ist, muss ich dafür eigenen Code schreiben und in einen unbenutzten Platz in der EXE auslagern, und dann bei den Vergleichen jeweils dorthin springen. Das kann - im Gegensatz zum Suchen und Ändern dieser einzelnen Bytes vorhin - nicht automatisch vom Programm erledigt werden, weil das nicht so intelligent ist wie ich^^ Also muss ich das für jede Version extra machen, und das hab ich nur für RM2k v1.07. Das ist der Grund, wieso man im Hyper Patcher 2 nur für diese Version 9999 Pics einstellen kann und für die anderen nur 126. Und warum 9999? Wegen des PicPointerPatches, der ja ab 10000 in Aktion tritt, und ich nicht Verwirrung stiften wollte. Theoretisch könnte man 2 Milliarden Pictures einstellen, was aber dann nie in den Arbeitsspeicher passen würde.

    *: Die Schleifen kann man sich ungefähr so vorstellen: Im Quellcode steht wahrscheinlich etwa dies:
    Code:
    for(int i = 1; i < 20; i++) {
        // Pictures initialisieren oder was auch immer
    }
    Das ist in Assembler im Endeffekt äquivalent zu:
    Code:
    int i = 1;
    while(true) {
        // Pictures initialisieren oder was auch immer
        i++;
        if(!(i < 21)) { break; }
    }
    Ja, ich weiß, dass der Maker in Delphi geschrieben ist, aber C verstehen wahrscheinlich mehr Leute.


    mfG Cherry

    Geändert von Cherry (15.04.2010 um 20:07 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •