Präzise Spielzeitmessung

[IndependentArt]

dieses skript misst bei einer tatsächlichen spielzeit von 5 min eine spielzeit von 4:45 min.
liegt das daran, dass es die befehle danach noch verwursten muss? sollte man lieber ausschließlich die variable erhöhen und den rest in nem anderen event machen?

[Corti]

Für Gesamtzeit gibt es den Time-played Wert, für präzise Dinge gibts den Timer.

[IndependentArt]

Monment. willst du sagen, der maker misst schon und man muss es nur irgendwo abfragen? aber warum ist es dann nicht "präzise"?

[MagicMaker]

Hast du berücksichtigt, dass so ein Event während Mapübergängen nicht korrekt funktioniert?

Da du eine Wartezeit von einer Sekunde nimmst, kann es passieren, dass du mitten in diesem Warteprozess
mal die Map wechselst und sie dann von vorne startet, sich also drauf rechnet.

Hier ein Beispiel, das deutlich weniger Fehlerquote aufweisen müsste:

Code:

<> Framecounter + 1
<> If Framecounter == 60
 <> Sekunden + 1
 <> Framecounter = 0
:: END
<> If Sekunden == 60
 <> Minuten + 1
 <> Sekunden = 0
:: END
<> Wait 0
<>

Für Gesamtzeit gibt es den Time-played Wert

...

Kann ich irgendwie nirgendwo sehen.

[Kazesui]

...

Ich nehme an dass dies ein parallel prozess Event ist. Am ende einer pp events gibts ein 0.0 wait (1 frame), was bedeutest dass du den variabel nicht pro sekunde +1 macht, sondern pro 1.0167 sekunden. Mit zeit gibts daraus ein ziemlich falsches ergebnis. Richtiger wäre

Code:

wait 0.9
wait 0.0
wait 0.0
wait 0.0
wait 0.0
wait 0.0

Dann kommst du wieder auf eine Sekunde, ausser Eventuell bei Map wechseln.

folglich

Code:

<> Framecounter + 1
<> If Framecounter == 60
 <> Sekunden + 1
 <> Framecounter = 0
:: END
<> If Sekunden == 60
 <> Minuten + 1
 <> Sekunden = 0
:: END
<> Wait 0
<>

unter die selbe annahme dass es hier um ein PP Event handeln, muss der wait 0.0 am ende raus wenn der die frames zählen soll (oder den Framecounter 2 zulegen statt 1).

[IndependentArt]

Hast du berücksichtigt, dass so ein Event während Mapübergängen nicht korrekt funktioniert?

...

auch ein common event? ich hab btw. aber bei der messung die map nicht gewechselt.


okay, ich werd mal beide varianten ausprobieren.

Dann kommst du wieder auf eine Sekunde, ausser Eventuell bei Map wechseln.

folglich

Code:

<> Framecounter + 1
<> If Framecounter == 60
 <> Sekunden + 1
 <> Framecounter = 0
:: END
<> If Sekunden == 60
 <> Minuten + 1
 <> Sekunden = 0
:: END
<> Wait 0
<>

unter die selbe annahme dass es hier um ein PP Event handeln, muss der wait 0.0 am ende raus wenn der die frames zählen soll (oder den Framecounter 2 zulegen statt 1).

...

ohne das wait würde es ja laggen.

heißt das dann, ein wait von 0.0 dauert 1 frame...?

[Kazesui]

0.0 wait dauert 1 frame, ja
und nein, es ist nicht gegeben dass es ohne dem 0.0 wait laggen wird (da es ja schon eins am ende jede pp event sowieso gibt). Das hängt eher von wie viel Code durchgeführt werden muss bevor es einen "pause" gibt.
Wenn dir das aus irgendeinem Grund trotzdem angst einjagst kannst du aber wie gesagt einfach "Framecounter + 2" stattdessen machen, und dem wait 0.0 behalten.

[IndependentArt]

die methode funktioniert sehr präzise, hatte keine abweichung, ohne teleport.

mit teleport dann leider ca. 1 sekunde pro teleport.

[G-Brothers]

Am ende einer pp events gibts ein 0.0 wait (1 frame), was bedeutest dass du den variabel nicht pro sekunde +1 macht, sondern pro 1.0167 sekunden.

...

Das kann man folglich dann mit einem Loop/Jump to Label umgehen, oder?

[Kazesui]

Das kann man folglich dann mit einem Loop/Jump to Label umgehen, oder?

...

ja

[Engel der Furcht]

die methode funktioniert sehr präzise, hatte keine abweichung, ohne teleport.

mit teleport dann leider ca. 1 sekunde pro teleport.

...

kann man das ganze nicht per switch lösen, indem du das PP einen Switch zuweist und diesen dann vor jedem Teleport auf OFF setzt und danach wieder auf ON setzt?
Vllt hab ich auch einfach deine Fragestellung nich verstanden...

[IndependentArt]

naja, es wird eine sekunde geklaut. aber wenn ich es mir so überlege: wen juckts? die eine sekunde, wo man teleportiert wird, kann man eh nicht spielen.

dann werd ichs womöglich einfach so lassen, es sei denn corti enthüllt noch was über den geheimnisvollen "time played wert".

[Corti]

Haha, bei letzterem hab ich mich geirrt. Da muss ich was verwechselt haben. Ich war mir irrtümlicherweise sicher, dass es bei Variable = ...z.b. Timer1 Seconds/Number of Fights etc. noch sowas gegeben hätte, aber nunja. Tut mich sorry Hoffnungen geweckt zu haben.

[elvissteinjr]

Aber eigentlich wird doch die Spielzeit im Savegame hinterlegt. Immerhin kann Cherrys HowLongDidIPlay die Spielzeit von einem beliebigen Maker Savegame anzeigen.

Ändert natürlich nichts daran, dass man vom Spiel aus keinen Zugriff auf den Wert hat. Interessant ist's aber dennoch.

[Cherry]

Ja, dieser Wert lässt sich nur als Zusatzfeature vom No-ATB-Patch (glaube ich) auslesen. Diese Spielzeit ist aber auch nicht perfekt, weil da afaik auch Bildschirmübergänge und gewisse Situationen im Kampf nicht funktionieren.

DynRPG ist da schon besser, erstens zählt der interne Zähler im Kampf korrekt (das ist in DynRPG gepatcht) und man könnte außerdem noch präziser werden indem man händisch die Zeitpunkte misst, etc.

[TwoFace]

Das Skript von Kazesui hab ich für Colors of Damnation (Survival Mode) als Zeitzähler verwendet und war damit sehr zufrieden. Die 5 Minuten Spielzeit (die ich auch habe!) lässt sich damit relativ genau messen. Wie es allerdings aussieht, wenn es dir auf einzelne Zehntelsekunden ankommen sollte, weiß ich leider nicht. Auffälligkeiten gab es bei mir allerdings keine, was positiv zu werten ist.