die länge eines wait[0.0sec] ?

[Blackadder]

bisher dachte ich die gleichung 6*wait[0.0sec] = wait[0.1sec] hätte eine universelle gültigkeit. ein gelehrter kam einst zu diesem ergebnis und schilderte sein experiment zur ermittlung der dauer des nichts folgendermassen:

Erstmal für alle die, die es nicht wissen: Wenn man mit der Funktion "Wait" einen Wert von 0,0 tangibt, ist das sehr wohl eine warte Zeit... eine SEHR Kurze..
Man hat mir zwar gesagt, dass die Länge dieser Wartezeit von der Leistung des Rechners abhängt, allerdings hab ich es sehr ausgiebig getestet, auch mit umständen, wo das gesamte Spiel geruckelt hat. Ich habe zwei parallele Events nach einer Warte-Zeit einen Ton-Abspielen lassen (natürlich zwei verschiedene)
Das eine hat nach 0,1 Sekunden Wartezeit den Ton abgespielt... das andere nach 6x 0,0 Sek Wartezeit... Und egal, wie viele Parallel-Events ich hinzugefügt habe, selbst als das Spiel schon stark geruckelt hat:
Die Töne kamen IMMER gleichzeitig...
Daraus folge ich mal:


Ein Wait mit 0,1 Sekunden ist = 6 Waits mit 0,0 Sekunden

nun habe ich das auf eine andere weise getestet und bin zu einem anderen resultat gekommen...

man nehme zwei events, das erste sieht so aus:


wait [1.0 sec]
change switch 0001 [ON/OFF TRIGGER]
das zweite:

wait [0.0 sec]
change variable 0001 [+ 1]
if (variable 0001 >= 60)
{
change variable 0001 [SET 0]
change switch 0002 [ON/OFF TRIGGER]
}

die switches aktivieren jeweils ein anderes event, beide leer und mit einer grafik.
eigentlich müssten doch beide events nun (annähernd) gleichzeitig erscheinen und wieder verschwinden, tun sie jedoch nicht.
die erklärung wie ich auf 60 gekommen bin:
6 * w0.0 = w0.1
10 * w0.1 = w1.0

daraus leite ich ab ;
w0.0 * 6 * 10 = w1.0
w0.0 * 60 = w1.0


wenn ich die fork-bedingung auf 30 setzte, klappt es beinahe gleichzeitig.
das zweite event hat zwar eine fork, aber ich kann nicht glauben, dass diese den eventablauf dermassen abbremst...

oder hab ich da einen logikfehler in meinem versuch übersehen?


nachtrag:
oke... hab jetzt beim zweiten event einfach 60 wait0.0 reingehauen... es IST gleichzeitig. -_-'
ich werde nie wieder forks benutzen. :hehe:nton:


BTW & OT @ MODS:
ihr könnt meinen "Wie man die Farbtiefe bei Bildern verändert"-thread langsam aber sicher von da oben abpinnen. mittlerweile eher überflüssig.

[NicQtin]

oke... hab jetzt beim zweiten event einfach 60 wait0.0 reingehauen... es IST gleichzeitig. -_-'
ich werde nie wieder forks benutzen.

Es lag nicht an den Forks. Der Grund dafür war einfach, dass ein Parallel-Process für einen Durchlauf auch ein wait von 0.0 braucht. Die Abweichung ensteht dadurch, dass dein zweiter PP 60x durchgelaufen ist. (Es sollte also eine Abweichnung von einer Sekunde gewesen sein)

[Blackadder]

Es lag nicht an den Forks. Der Grund dafür war einfach, dass ein Parallel-Process für einen Durchlauf auch ein wait von 0.0 braucht. Die Abweichung ensteht dadurch, dass dein zweiter PP 60x durchgelaufen ist. (Es sollte also eine Abweichnung von einer Sekunde gewesen sein)

omfg... ich hab im zweiten event das w0.0 rausgenommen, es hat also nur noch die anweisungen drinnen und.. es ist fast gleichzeitig! ergo hast du recht.
und wieder was dazugelernt. danke.:bogart:

[NicQtin]

Noch ein kurzer Nachtrag:


wenn ich die fork-bedingung auf 30 setzte, klappt es beinahe gleichzeitig.

Deshalb klappt es ja dann auch beinahe gleichzeitig. Denn dann hast Du:

30 x das wait 0.0
und
30 x das wait des PP

ergibt 60 x wait 0.0 = wait 1.0

Das es dann nur annähernd gleichzeitig ist, dass liegt an den Forks.

[übelster Held]

mit labels gibt es kein warten mehr, am ende des pp-events
(weil das ende ja nie erreicht wird.^^ )



label 1
wait [1.0 sec]
change switch 0001 [ON/OFF TRIGGER]
goto label 1


das zweite:


label 1
wait [0.0 sec]
change variable 0001 [+ 1]
if (variable 0001 >= 60)
{
change variable 0001 [SET 0]
change switch 0002 [ON/OFF TRIGGER]
}
goto label 1