Ergebnis 1 bis 20 von 23

Thema: [DynRPG-Plugin][RM2k3] MessageExtender | BETA

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Tja, es kann aber mehr als ein Skript laufen! Ein PP reicht aus und deine Lösung funktioniert nicht mehr sondern corrupted das andere Event indem irgendwelche Stringparameter überschrieben werden oder, wenn du Pech hast, auf Zeile -1 oder so zugegriffen wird und das Spiel crasht.
    Darum meine Idee, auch wenn sie hacky ist - aber damit sind die Sachen wirklich konkret an eine ScriptLine gebunden!

    EDIT: return false verhindert nur dass die aktuelle Skriptzeile ausgeführt wird, das ist sinnvoll wenn man einen Eventbefehl ersetzen will durch eigenen Code. Sag mal, warum verwendest du am Ende "i = -1" statt "break" um einen Loop zu beenden? Davon abgesehen ist der Source nicht schlecht, da gibts weitaus schlimmeres. Im Falle DynRPG ist es immer erfreulich wenn Source da ist, weil es eh an Beispielen fehlt.

    EDIT2: eventId ist aber nicht verlässlich im Moment, genauso wie pageId... Und selbst wenn das schon gefixt wäre: Du vergisst dass dasselbe Event 2x laufen kann, nämlich wenn es durch zwei verschiedene PPs gecallt wird (oder 1x durch ein PP gecallt wird und 1x ohne ein PP läuft). Und Callstack ist noch nicht implementiert.

    Geändert von Cherry (17.06.2013 um 23:35 Uhr)

  2. #2
    Zitat Zitat von Cherry Beitrag anzeigen
    Tja, es kann aber mehr als ein Skript laufen! Ein PP reicht aus und deine Lösung funktioniert nicht mehr sondern corrupted das andere Event indem irgendwelche Stringparameter überschrieben werden oder, wenn du Pech hast, auf Zeile -1 oder so zugegriffen wird und das Spiel crasht.
    Darum meine Idee, auch wenn sie hacky ist - aber damit sind die Sachen wirklich konkret an eine ScriptLine gebunden!

    EDIT: return false verhindert nur dass die aktuelle Skriptzeile ausgeführt wird, das ist sinnvoll wenn man einen Eventbefehl ersetzen will durch eigenen Code. Sag mal, warum verwendest du am Ende "i = -1" statt "break" um einen Loop zu beenden? Davon abgesehen ist der Source nicht schlecht, da gibts weitaus schlimmeres. Im Falle DynRPG ist es immer erfreulich wenn Source da ist, weil es eh an Beispielen fehlt.
    Das ist mir auch gerade aufgefallen xD Und du meintest ja irgendwann mal, dass sich EventId usw nicht zuverlässig abfragen lassen - zumindest hab ich das irgendwann mal gelesen. Wie gesagt, das wäre sonst vielleicht auch noch ne Idee, zumindest für Map-Events - bei CE's gibt's ja keine eindeutige Identifizierung, außer vielleicht die DatabaseID.

    Wahrscheinlich wäre deine Lösung aber momentan wirklich das effektivste.

    Ich habe ehrlich gesagt keine Ahnung warum ich das gemacht habe xD Wahrscheinlich war ich nicht ganz da oder so

    PeAcE
    MorDen

  3. #3
    So, nachdem Cherry und ich auf 'ne gute Lösung für das Problem mit PP's usw. kamen, hab ich das Ganze jetzt mal soweit fertig gemacht. Ich hab's mit 6 PP's getestet und es funktioniert.

    Leider gibt es aber einen Fall, bei dem das Ganze nicht funktioniert, bzw. wo es zu Fehlern kommen kann. Nämlich dann, wenn zwei PP's gleichzeitig eine Message anzeigen wollen und dies unmittelbar nacheinander geschiet - also ohne, dass eine Eventzeile dazwischen ausgeführt wird. Aber ich denke, dass kann man verhindern und das wird auch nicht allzu oft vorkommen ^^''

    Hab den ersten Post aktualisiert. Für Interessierte gibt's dort auch den Source - den hab ich mal ein wenig kommentiert.

    PeAcE
    MorDen

  4. #4
    Zitat Zitat
    Code:
                    if( id > 0 && id <= RPG::map->events.count() )
                        return RPG::map->events[id]->getName();
                    break;
    Keine gute Idee. Angenommen eine Map hat die Events 1, 2, 5 und 9. RPG::map->events.count() ist dann 4. \e[5] und \e[9] werden also fehlschlagen. Besser: if(RPG::map->events[id]) bzw. RPG::Event *event = RPG::map->events[id] und dann if(event) return event->getName()

    Technisch betrachtet trifft das auch auf Actors und andere NamedCatalogPtr-Typen zu (count() sollte da nur für das Iterieren über alle, mit ->list[i], verwendet werden), aber bei denen sind eigentlich immer die IDs mit 1 beginnend ohne Lücken vorhanden.

  5. #5
    Zitat Zitat von Cherry Beitrag anzeigen
    Keine gute Idee. Angenommen eine Map hat die Events 1, 2, 5 und 9. RPG::map->events.count() ist dann 4. \e[5] und \e[9] werden also fehlschlagen. Besser: if(RPG::map->events[id]) bzw. RPG::Event *event = RPG::map->events[id] und dann if(event) return event->getName()
    Hab's schon korrigiert, aber noch nicht updated -> Wollte nicht kurz danach schon wieder nen Update schmeißen. Merke aber gerade, dass das wirklich nicht so trivial ist, wie ich dachte. Lade das korrigierte denn heute Abend auf jeden Fall hoch (wegen der Events-Sache).

    In der nächsten Version will ich dann noch deine Idee mit dem Padding umsetzen, Cherry. Und meinst du, es wäre performancetechnisch groß problematisch, wenn ich zwei Pointer speichern würde (in einem [2]-Array) und dann jeweils beide überprüfen lasse? So würde die Sache mit den PP's zumindest bei zwei parallelen Events aus der Welt geschafft sein, oder nicht? Denn ich denke nicht, dass jemand mehr als zwei PP's hat, die gleichzeitig eine Message anzeigen wollen.

    PeAcE
    MorDen

  6. #6
    Sollte keinen großen Unterschied machen.

  7. #7
    Sofern du nicht ein Array von 10k Größe (oder vector, oder list, oder was weiß ich) mit einem Bubble Sort oder so etwas in der Art bearbeiten möchtest, wird keiner Performance mäßig merken, das du was speicherst und überprüfst. C++ != maker, in C++ kann man viel mehr, viel besser und viel schneller checken Also lieber zu viel prüfen, als zu wenig, weil an die Grenze wirst du so schnell nicht stoßen, und wenn es Probleme gibt, ist meistens eine andere Stelle daran Schuld und nicht der Check an sich.

    mfg

  8. #8
    So, hab's mal updated.

    Funktioniert jetzt auch, wenn zwei Event's gleichzeitig eine Message anzeigen wollen ohne Probleme. Mehr - denke ich - sollten aufeinmal nicht auftreten.
    Und Cherry's Eventproblematik ist auch behoben.

    Viel Spaß^^ In der Hoffnung, dass das auch jemand gebrauchen kann

    PeAcE
    MorDen

  9. #9
    Sorry für die schreckliche google Übersetzung. Ich liebe dieses Plugin, aber ich fand ein riesiges Problem mit ihm. In vielen Orten (meine Steal System zum Beispiel) Ich versuche, dies zu tun:

    Code:
    "Stole \i[\v[23]]!
    um das Element mit der ID 23 angezeigt. vielleicht 30-50% der Zeit funktioniert es gut, aber für die anderen 50-70% der Zeit, zeigt diese:

    Code:
    Stole [23]!
    Ich habe dann entweder zurück zum Hauptmenü und legen Sie eine neue Datei oder das Programm beenden, um vielleicht die Chance bekommen, es funktioniert wieder. Ich schaute auf den Quellcode, aber es ist alles über onComment getan, also bin ich nicht sicher, was das Problem sein könnte. Parsing problem?

    Geändert von PepsiOtaku (03.09.2013 um 15:56 Uhr)

  10. #10
    Probier mal zwei Sachen aus:
    • Teste die Funktion in dem du eine MessageBox auf einer normalen Map aufrufst
    • Teste die Funktion in dem du den MessageBox Befehl im Kampfsystem aufrufst ( den aus Liste von Befehlen im Kampfsystem )
    • Jetzt schreibe dir ein CommonEvent in dem die MessageBox enthalten ist und rufe dieses CE im Kampfsystem auf.



    Wichtig: Erstelle jeweils die MessageBox per Klick, kein Copy&Paste von Sonstwo.

    Ansonsten: Schreib die Inhalte der MessageBox nochmal neu. Manchmal gibts so Zeichenkombinationen wie ^` die unsichtbar irgendwo in Zeichenketten drin sind, sieht man nicht, stören aber Compiler und Interpreter.

  11. #11
    Zitat Zitat von PepsiOtaku Beitrag anzeigen
    Sorry für die schreckliche google Übersetzung. Ich liebe dieses Plugin, aber ich fand ein riesiges Problem mit ihm. In vielen Orten (meine Steal System zum Beispiel) Ich versuche, dies zu tun:

    Code:
    "Stole \i[\v[23]]!
    um das Element mit der ID 23 angezeigt. vielleicht 30-50% der Zeit funktioniert es gut, aber für die anderen 50-70% der Zeit, zeigt diese:

    Code:
    Stole [23]!
    Ich habe dann entweder zurück zum Hauptmenü und legen Sie eine neue Datei oder das Programm beenden, um vielleicht die Chance bekommen, es funktioniert wieder. Ich schaute auf den Quellcode, aber es ist alles über onComment getan, also bin ich nicht sicher, was das Problem sein könnte. Parsing problem?
    You don't have to use Google Translator, I do think people understand English quite well here.
    That problem sounds interesting, I doubt that it has anything to do with writing "[23]" instead of "[0023]", right? ;0
    Btw - I love your plugins. Especially the menu ones, that's some of the best stuff I've seen with DynRPG! Q_Q

  12. #12
    @Corti: Yes, I tried all of those scenarios. Those steal commands are pulled from common events.

    @goldenroy: I'll try using leading zeros and see if that makes a difference, although I'm a little skeptical. Thanks for the compliment! I've actually got a couple more plugins on the way. The biggest one being auto-switches. I wrote a little blurb about them here: http://rpgmaker.net/forums/topics/13...940#post490940

    Edit: Still no luck after trying leading zeros. :/

    Geändert von PepsiOtaku (04.09.2013 um 00:14 Uhr)

  13. #13
    @PepsiOtaku
    Did you get the same result, when you output these messages vie an event on map and not via a common event? I will try to reproduce this problem in the next week. I also wanted to extend this plugin so that you can use padding like Cherry mentioned some posts before, but I didn't found time last months. But now I should have more time for delevoping some DynRPG-Stuff.

    PeAcE
    MorDen

Berechtigungen

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