Falls Loops im Maker nicht aus irgendwelchen Gründen unperformant sind ist das ganz großer Schwachsinn.
...
Es ist mir jetzt zu mühselig in den Untiefen des Quartiers nach einem Performancetest zu suchen, den ich mal vor Jahren gesehen habe, aber soweit ich mich erinnere wurde das mal gestestet und in Sachen Performance Jump>loop.
Dazu kommt die Sache mit dem Bug.
Zitat von Tako
Sprunganweisungen sollte man so selten wie möglich verwenden, besonders, wenn es korrekte Alternativen gibt. Sie werden nicht ohne Grund als schädlich angesehen.
...
In Sprachen, die vollwertige, sicherere und fehlerfreie Alternativen zur Auswahl haben: 100% Zustimmung.
Zitat von Tako
Was wollen wir in diesem Fall machen? Eine Schleife. Also verwenden wir auch eine Schleife, alles andere wäre pants-on-head-retarded.
...
Makerschleifen sind scheisse. while(true) { if(X) break; } mit möglichen Fehlern wenn man das Abbruchkriterium nicht ans Fußende packt. Wenn ich mir überlege wie ich etwas umsetze dann denke ich in for,while,doWhile~ nicht in while(true)break, was sich mit Labels imo eleganter umsetzen lässt.
Der Break springt immer automatisch zum nächsten Schleifenende, das im Code ist,
ohne darauf zu achten, dass dieses eine Verschachtelungstiefe weiter oben sein muss,
wie aber schon gesagt lässt sich das problemlos verhindern:
Wer ganz komisch drauf ist, kann den Bug auch zu einem sehr skurrilen Vorteil nutzen:
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Ich bin tatsächlich nicht besonders gut darin, ein Script logisch aufzubauen. Es läuft oft eher nach der Art Try and Error. Loops hab ich bisher nie großartig benutzt, verstand auch den Sinn nicht, wiederholt sich zB ein PP Event automatisch. Und Labels sind halt schön flexibel anzusteuern.
Ich hab jetz mal den Timer reingehaun in meinen Zeitmesser, scheint zu funktionieren. Hab aber trotzdem noch ein 0.0 wait drin, damit immer die Minuten und Stunden richtig abgerechnet werden.
Jetzt versuche ich mich gerade darin, die Zustandsanzeige damit zu verbinden. Das waren bisher 3 PPs, für jeden Chara einer(der Verschleiß an PPs schockiert mich grad selbst). Das ist bisher so geregelt, dass wenn irgendjemand von einem Zustand betroffen ist, alle 3 PPs laufen(entweder war ich da faul oder es hatte wirklich einen triftigen Grund).
Der Code der Events sieht so aus:
Auf diese Weise werden hübsch die Zustände der Charas nacheinander durchgeschalten. Da nicht jeder Chara notwendiger Weise von den gleichen Zuständen betroffen ist, sah ich da auch die 3 Events gerechtfertigt.
Sehe ich grad auch immernoch, da mir nicht so recht einfallen will, wie ich das in das Zeitevent hineinquetschen kann, ohne das sich die Waits verändern.
Das Zeitevent sieht grad so aus:
Ja, und das ist nun der Punkt, wo ich in dem Skript des Zeitevents etwas mit der gleichen Funktionalität der anderen PPs schreiben müsste.
Whoa.
Der 2k ist so scheiße?
Entwickelt ihr nicht den ganzen Tag Patches und DynRPG Plugins mit mehr Codezeilen, als der eigentliche Maker hat? Könnt ihr das nicht fixen?
Ich meine WHOA
Aber klar, dann hast du natürlich recht.
Der 2k kann nichtmal Schleifen oh Gott help
Zitat:
Code:
if: zustand 1 on:
variable zustandsanzeige chara 1: set 1
wait 1.0
if: zustand 2 on:
variable zustandsanzeige chara 1: set 2
wait 1.0
usw.
Warum brauchst du dort ein Wait?Das bringt den Code doch unnötig zum stottern? Ausserdem würde ich diesen Paralellen Code anders aufbauen, da beim zutreffen der Bedingung, der Code bei jedem durchlauf also mehrere
Dutzend mal in der Sekunde neu zugewiesen wird.Das spielt nur keine Rolle wenn ein Schalter für ein anderes Common Event aktiviert wird. Wobei man dann überlegen sollte ob man es nicht anders Eventen kann, weil bei diesem Aufbau und eine Set Moveroute Befehl würde das Spiel anfangen zu laggen, weil der Moveroute Befehl es absolut nicht mag jeden Frame
neu zugewiesen zu werden fürs selbe Ziel.
Beispiel anhand eines simplen Schnell laufen Systems:
Conditional Branch: A.Taste Gedrückt
Wenn Ja: Conditional Branch: Schalter[Rennen] Aus Wenn Ja: Set Move Route Player Speed 5 Turn Schalter[Rennen]An
Wenn Nein: Nichts
Else Case von der ATaste= Conditional Branch Schalter [Rennen]An Wenn Ja Set Move Route Player Speed 3 Turn Schalter[Rennen]Aus
Else:Nichts oder erst gar keinen Else einstellen.
Die zusätzliche Schalterabfrage verhindert, das Code der teilweise Rechenintensiver ist als eine Bedingung neuausgeführt wird obwohl es nicht nötig ist.
Im Beispiel rennt der Spiele sollange Schnell bis er die A Taste los lässt.Der code der ihn aber schnell laufen lässt , bzw langsam, wird nur einmalig zugewiesen
Ich bin kein Experte,also korigiert mich falls ich mal falsch liege, sind aber meine Erfahrungswerte bisher.
Edit: Ups bin etwas vom eigentlichen Code abgewichen^^
Damit der Zustand 1 Sekunde lang angezeigt wird. Ich vergaß zu erwähnen, dass sich das ganze auf Events auf der KS Map bezieht, die dann je nach Stand der Variable eben umschalten.
Ich verstehe ungefähr, was du meinst. Ich wüsste nur nicht so recht, wie ich das auf mein Problem anwenden könnte.
Wie kommst du darauf? Seite 3, rechte Spalte, 8ter Befehl von unten.
@Schleifen
In einer vernünftigen Hochsprache ist so eine Pragmatik wünschenswert. Aber doch bitte nicht in so einer Umgebung wie der 200x Serie des Makers.
Oh entschuldige. Ich hätte dir auch etwas sinnvolles zu deinem Ursprungsproblem hinterlassen sollen.
Ich hole es mal nach:
Zitat
Ich hatte schon länger den Gedanken, das Zeit-mess-Event, dass bei mir ja eh mitläuft, noch für andere Zwecke zu benutzen, wenn ich eben für irgendwas einen PP brauche, der was anzeigen soll. Natürlich darf ich das Wait dabei nicht verändern.
Aber mal rein theoretisch: Wenn ich verschiedene Befehle da reinhaue die keine Zeit brauchen, zB das ein Balken im Kampf blinkt o.ä., geht das irgendwann zu Lasten der Genauigkeit der Messung? Oder ist dem Maker egal, wieviel da noch durchläuft?
...
Erstmal braucht jeder Befehl Zeit um abgearbeitet zu werden. Das heißt jeder Befehl den du zusätzlich in dein PP reinsetzt, wird die Zeitmessung beeinflussen.
Wenn du das verhindert möchtest, solltest du ein zweites PP erstellen wo du nicht zeitkritische Operationen ablaufen lässt.
Eine andere Alternative um das Problem ganz zu umgehen, ist es gar nicht erst mit PPs zu arbeiten wo es nicht sein muss. Die Aktualisierung einer Werte Anzeige (HP, MP, etc.) muss nicht zwangsläufig im Hintergrund ständig aktualisiert werden.
Oft weißt du genau wann sich zum Beispiel der HP Stand des Spielers verändert. Es macht hier Sinn nach jedem Schaden dem man dem Spieler zufügt ein CE aufzurufen. Dieses kann dann den Schaden von den HP abziehen und die HP Leiste aktualisieren.
Im Endeffekt solltest du dir aber nicht übermäßig Gedanken über zu viele PPs machen. Der Großteil der Rechner dürfte heutzutage mehr als Leistungsstark genug dafür sein. Da kommt es auf eine kleine Anzahl mehr auch nicht an.
Zitat von Tako
Zitieren
CherryShare
