Beiträge von Tuxedo

Wenn das so stimmt wie du behauptest Bitnugger, dann überspringt das originale Script von Muecke bei mir aber nicht nur ein paar Millisekunden sondern über 900 ms. Und das halte ich für ausgeschlossen. Denn bei mir bleibt die Zehntelsekunde beim Start von Muecke's Script mehre Sekunden im selben Bereich stehen z.B. 5?? 5?? 5?? 4?? 6?? 5?? 3?? 5??. So oder ähnlich sieht das bei mir immer aus. Ohne TicksToTime habe ich den Effekt eben nicht. Dann kommt 1?? 2?? 3?? 4?? 5?? 6?? 7?? 8?? 9?? 0??, so wie man es eben erwarten würde.

Siehst du jetzt klarer? Wenn nicht brauchs du vielleicht eine Brille?

Und ja es geht sehr wohl ohne TicksToTime auf eine Zeit umzurechnen, man kann sich das Ergebnis von Timerdiff ja auch

selbst in Stunden Minuten Sekunden und Millisekunden zersägen. TickstoTime tut ja auch nix anders, nur eben nicht auf optimale Art.

Edit: Ich hätte jetzt ein Video-Sample mit ca 3,3MB wohin könnte ich das uploade, damit mans hier verlinken könnte?

In diesem Video sieht man den Effekt sehr gut.

Jetzt fühle ich mich langsam gezwungen 2 Beispiele zu zeigen die Version 1 arbeitet zwar mit 20 ms Aktualisierungsrate und nur bis zur Hundertstel Sekunde und sieht irgendwie runder und flüssiger irgendwie stimmiger aus(was aber auch bei 40ms der Fall wäre).

Die Version 2 arbeitet wieder mit 40ms Aktualisierungsrate und zeigt komplette Millisekunden an und sieht trotzdem stimmiger aus.

Hier sieht man trotzdem die Zehntelsekunden hochzählen, was bei der Ursprungsversion mit der _GetTime Funktion eben nicht so ist.

Muecke ich hoffe du verzeihst mir das neue Design, musst es ja nicht übernehmen(ich finds echt hübsch).

Sorry, ich habe schon daran gearbeitet als du noch die alte Version gepostet hattest. Wenn du es übernehmen willst,

musst du die neue Hilfe Funktion mit dem Tooltip wieder einpflanzen.

Meine geänderten Stellen habe ich mit "Tuxedo kommentiert und meistens die vorherige Zeile als Kopie drin gelassen.

So kannst du schnell wieder meine Veränderungen rausnehmen.

Jetzt vergleiche mal deine Version und meine 2 Beispiele(dann müsste dir der Unterschied auffallen,achte besonders auf die Zehntel Sekunden).

Achja und übrigens könntest du auch zum Anzeigen nur die Hundertstel Sekunden verwenden und trotzdem für die Endberechnung

die Millisekunden mit einbeziehen wenn das wichtig sein sollte.

Schönen SonnAbend noch

Tuxedo

Hätte fast die Anhänge vergessen

Nach zahlreichen Testdurchläufen bin ich mir ziemlich sicher, daß die merkwürde Anzeige der Millisekunden von der Funktion TicksToTime

verursacht wird. Ich dachte erst es liegt eventuell an den vielen schnellen Funktionsaufrufgen von _GetTime(), was aber nicht der Fall ist.

Ebenso die Vermutung von Bitnugger , daß es vom Aktualisierungsinterval (das 44ms Sleep) stammt hat sich bei mir nicht bestätigt.

Ich kann von 1 ms bis 100 ms durchgehen und habe nie das selbe merkwürdige Verhalten, nur bei zu kurzen Timings setzt die Anzeige der Millisekunden gelegentlich aus (wird schwarz) was aber bei einem Sleep von 1 bis 5 Millisekunden kein Wunder darstellt.

Ich hab es jetzt mit einer neu gebauten _GetTime Funktion versucht und die Zehntelsekunden laufen wunderbar weich durch,

wie es sich gehört. Bei den restlichen 2 Stellen kann ich es Mangels (meines Gehirn+Augen Speeds) nicht mehr beurteilen.

Ohne TicksToTime Funktion ist das Ergebnis auf jeden Fall besser.

SChönen Wochenbeginn wünscht

Tuxedo

Das Auffällige so genau zu beschreiben ist gar nicht so leicht, ein vergleichsvideo wär perfekt.

Die linke Stelle der millisekunden ist ja die Zehntelsekunde, und die würde man bei einer realen Stoppuhr schön fortlaufend raufzählen sehen, was bei

deiner Uhr aber nicht der Fall ist.

Dieses Verhalten habe ich aber nur bei Verwendung von _TicksToTime

Muss dich leider noch ein bisschen enttäuschen, verwendest du im Timerkern Funktionen mit dem Wort ticks im Funktionsnamen, ich vermute mal sehr, daß das der Fall ist.

Dann solltest du dir überlegen wie du dir selbst einen Zeitzählkern basteln kannst. Beim Testen deines Scripts ist mir das merkwürdige Verhalten der Millisekunden in der Zeitanzeige aufgefallen. Das dürfte von den ticks Funktionen stammen.

Ich habe die letzen Wochen einige Testläufe mit Timern und Stoppuhren hinter mir und dabei war öfters das Verhalten der Millisekunden beim Verwenden der ticks Funktionen auffällig. Ich hatte sogar Fälle da wurde der Timer mit der Zeit schneller.

Ausserdem wäre zu überdenken ob du für eine Stoppuhr die durch Menschenhand gesteuert wird nicht besser auf die Millisekundenanzeige verzichtest,

und nur auf Hundertstel genau anzeigst. Ich glaube nicht, daß du auf Menschen triffst die auf paar Millisekunden genau die Stoppuhr steuern können.

Aber eventuell gibt es welche die es auf 80 bis 120 Hundertstel schaffen. Ausserdem ist das Anzeigebild bei Hundertstel Sekunden wesentlich

runder und fließender. Dann sieht es beinahe einer Nixie-Uhr ähnlich.

Erstmal ein Lob an dich, hast du gut gemacht.

Aus dem Stadium "eines blutigen Anfängers" bist du aber wohl schon lange rausgewachsen. Die Uhr ohne Flackern hinzukriegen ist nicht so leicht

wie es scheinen mag. Es funktioniert gut, dein Code ist sehr gut lesbar.

Allerdings hättest du die jeweils aufeinanderfolgenden GUIsetState(@SW_SHOW) und GUIsetState(@SW_HIDE) überall bei den

Gui Deklarationen weglassen können.

Es reicht wenn du die GUI's erstellst, die Befehle für die Anzeige und wieder ausblenden rufst du ja eh später auf.

Ausserdem fände ich es hilfreich wenn du die Hilfe der Startseite jederzeit wieder ansehen könntest. Habe dir ein Bespiel dazu gemacht.

Falls du es verwenden willst musst nur oben bei den Hotkeyset Befehlen einen zB. mit F1 aufrufbaren Hotkey zu der Hilfefunktion einpflanzen:

HotKeySet("{F1}", "_Hilfe")

Func _Hilfe()
    Local Static $Status
    $Status = Not $Status
    If $Status = True Then
        GUISetState(@SW_SHOW, $ID_GUI_Start)
        Else
        GUISetState(@SW_HIDE, $ID_GUI_Start)
        EndIf
EndFunc

Und jetzt noch ein weiterer Tipp, die GUI fürs Formular kannst du doch mit dem Koda Formdesigner erstellen, aufrufbar im Editor Scite,

ich nehme mal einfach an du benutzt ihn. Den Koda Form Designer findst du im selben Menü wo auch das Script gestartet wird,

ist bei mir unter "Extras" und dort brauchst dann nur das Formular nach deinen Wünschen gestalten. Um die Daten ins Texfile deiner Wahl zu bekommen hast du dann mehrere Möglichkeiten. Die Formularfelder auslesen mit GuiCtrlRead und ins File schreiben.
Datei vorher mit Fileopen zum Beschreiben öffnen und und mit dem Handle per Filewrite oder FilewriteLine oder iniwrite schreiben.

Das Fileclose beim Beenden nicht vergessen.

Viel Erfolg beim fertigstellen wünscht Tuxedo

Beitrag wegen möglicher Redundanzen gelöscht

Eine Abfrage wirst aber immer machen müssen, wenn du die Taste nicht abfragst, dann musst du eben das Fenster abfragen.

Du willst ja, daß dein Programm irgendwie auf den Tastendruck(oder Buzzer) reagiert und eine bestimmte Aktion ausführen soll.

Oder du hast ein Event registriert, dann wird eben auf dieses Event reagiert.

Hier bekommst ein kleins Beispiel wofür die Status-Variablen wichtig sind.

Mit F5 wird die Funktion gestartet.

Mit ESC kannst du die Funktion abbrechen und landest in der Hauptschleife, Script wird nicht beendet

Mit F2 wird das Script beendet.

Ich denke die Funktion der Variable $Status sollte daraus ersichtlich sein, du kannst durchaus auch mehrere solcher Varaiblen einsetzen.

Natürlich mit jeweils anderen für dich passenden Namen.

;Ein kleines Beispiel

HotKeySet("{F2}", "F_Ende")
HotKeySet("{ESC}", "F_Ende")
HotKeySet("{F5}", "F_Timer")
Global $Status = False

While 1
    Tooltip("Script ist im Standy-Modus", Default, Default, "Titel", 1, 1)
    Sleep(100)
WEnd


Func F_Timer()
    $Status = True
    Tooltip("")
    While $Status = True
        For $i = 1 To 100000
            Tooltip("Timer " & $i, Default, Default, "Titel", 1, 1)
            Sleep(10)
            If Not $Status = True Then ExitLoop
        Next
        ; Und hier noch weitere Rechenschritte
        $Status = False
    WEnd
Tooltip("")
EndFunc


Func F_Ende()
    $HotK = @HotKeyPressed
    If $HotK = "{ESC}" Then $Status = False
    If $HotK = "{F2}" Then Exit
EndFunc

Es funktinoniert folgendermassen:

Durch den Start per F5 wird der $Status auf True gesetzt, dann startet weil $Status = True die While Schleife in der Timer-Funktion,

dann läuft die For Next Schleife durch. Und durch die Abfrage von $Status kann auch die For Next Schleife durch Abbruch per Beenden Funktion mit ESC

unterbrochen werden, weil in der Beenden Funktion abgefragt wird mit welchem Hotkey die Beenden-Funktion aufgerufen wurde.

Dadurch wird die For Next Schleife per ExitLoop verlassen und landet dann in der While Schleife der Timer Funktion, die dann ebenfalls

verlassen wird weil eben While $Status = True nicht mehr stimmt und danach wird die Funktion verlassen und das Script landet wieder in

der Hauptschleife. Jetzt kann die Funktion wieder neu gestartet werden oder man beendet es mit F2.

So wird die Funktion sauber verlassen ohne immer neue Instanzen davon im Speicher anzusammeln.

Viel Spass damit

Edit:

Das mit den Hotkeys und den Infos zu Bildern und Sounds in die Ini zu schreiben ist denke ich gut so. Ich würde es vermutlich anders machen,

aber ich bin auch kein Berufsprogrammierer und schreibe so wie es mir am Besten passt(und nicht wie es am Besten wäre...)

Und beim Formular wird dir die Funktion _ArrayToString vermutlich weiterhelfen. Dafür musst die die Formulardaten allerdings

in einem 2D Array erfassen. Dafür würdest du wenn du das oben abgebildete Forumlar verwendest 10 Spalten und was weiß ich

z.B. 100 Zeilen brauchen. Wenn die Hundert Spieler gespeichert wurden, schreibst du das ganze Array dann mit _ArrayToString in eine Textdatei (Formular.csv). Dann das Array wieder leeren und wieder weitermachen bis die Hundert wieder voll sind.

Das Array könnte in deinem Fall wie folgt aussehen $Array[100,10] Die Daten aus der ersten Zeile kannst du wie folgt

ansprechen $Array[0][0] bis $Array[0][9], Zeile 2 ist dann $Array[1][0] bis $Array[1][9]

Das "D-Array kannst du dir am Leichtesten wie eine Excel Tabelle vorstellen.

Irgendein User hier ein mal ein gutes Tutorial über Arrays erstellt(ist aber ein Kopfweh-Thema), könnte BugFix gewesen sein.

Darüber findest du ausreichend Informationen in der Hilfe

Man mir raucht der Kopf (Schei.. Arrays)

Bei diesem gewünschten Ablauf würde es sich anbieten, folgende Struktur zu verwenden:

1. Eine Hauptschleife While-Wend oder Do Until die alles steuert

2. Eine Funktion mit eigener GUI und Schleife für den StartBildschirm

3. Eine Funktion für den laufenden Timer mit eigener GUI und Schleife

4. Eine Funktion für die Ergebnis Anzeige mit eigener GUI und Schleife

5. Eine Funktion mit GUI und Schleife für die Dateneingabe.

6: Eine Funktion zum Beenden

Wenn du alles in eigene Funktionen verpackst ist es leichter die verschiedenen Sounds und Bilder einzufügen.

Und nicht auf notwendige Status-Variablen vergessen, damit du jederzeit die Funktionen sauber beenden kannst(ohne MemoryLeaks

die durch mehrfache Funktionsaufrufe entstehen ohne die Funktionen vorher zu beenden).

Allerdings bin ich mir durch deinen Schritt 4 nicht mehr sicher, daß eine Ini Datei dafür wirklich geeignet ist, ja nach dem wieviele Mitspieler

hier auftreten können, wäre es eventuell besser gleich in eine csv Datei zu schreiben(in Tabellenform).

Das könnte man dann später in Excel weiterverarzten. Dafür gäbe es auch eine Excel-UDF die anscheinend gerne verwendet wird.

Ich werde aus deinem Code nicht so ganz schlau, sieht für mich aus als ob du 10 Dinge gleichzeitig machen wolltest.

Fange vielleicht erstmal mit der Stoppuhr an und versuche die perfekt zum laufen zu bringen, so wie du sie brauchst.

Die Grafik und den ganzen anderen Klimbim kannst du danach auch noch einfügen.

Für die Stoppuhr hätte ich dir ein paar Beispiele zur Inspiration(die Beispiele stammen von verschiedenen Usern).

Nach ein bissschen rumexperimentieren damit ,hat sich für mich als wichtig herausgestellt die Uhr aus verschiedenen Blöcken

zusammenzustellen, dann kannst du auch nur Teile davon aktualisieren statt den ganzen String auf einen Rutsch, das würde dem Flackern

vorbeugen wenn du Hundertsel oder sogar Tausendstel Sekunden anzeigen willst. Aber ich denke Hundertstel sollten auch genügen.

Wenn die Stoppuhr dann läuft kannst du die anderen Dinge einbauen wie ein Hintergrundbild und später dann die Konfiguration per ini hinzufügen

und den Sound zum Schluss noch oben drauf.

Aber irgendwie ist mir nicht wirklich klar was dir da genau im Kopf herumgeistert, wie das zum Schluss aussehen und funktionieren soll.

Gibt es da irgend eine Vorlage nach der du vorgehen willst(wenn ja,wäre ein Bild oder Video davon sicher hilfreich)?

Hätte fast den Anhang vergessen:

zu Benachrichtigung: Eventuell sind deine Profileinstellungen nicht korrekt oder wurden durch ein Update resettet.

Das Forum ist im Moment immer noch im Update-Wahn, kann passieren, daß immer wieder etwas nicht funktioniert oder wieder funktioniert.

Ich kann diesem Update-Wahn auch nichts abgewinnen.

Ich denke dieser Buzzer kann in der Systemsteuerung oder per Software so eingerichtet werden, daß bei Betätigung ein bestimmter Tastencode gesendet wird,

und diesen kannst du dann im Script auswerten(evtl per Hotkey und sonst per _IsPressed) oder wenn du es kompliziert magst geht sowas sicher auch per DLL Calls oder per WinApi.

Ich weiss es nicht genau, aber ich glaube eine Uhr in gross und Fullscreen (oder fast) hat entweder Oscar oder UEZ mal ein Script im Forum veröffentlicht.

Wenn ich es finde poste ich einen Link dorthin.

Die Konfig-Datei kannst du mit iniread und iniwrite oder auch mit fileread oder filereadline bedienen, wobei die ersten beiden am geeignetsten wären, denke ich.

Das sollte dir erstmal über die Runden helfen.

Es grüsst Tuxedo

Habe den Button gerade angesehen und denke nicht, daß dieser Button dafür geeignet ist. Die Beschreibung wie immer bei Amazon nichtssagend.

Aber laut etlichen Kommentaren wird der Button nur deshalb mit USB angestopst um die soundfiles darauf zu laden.

Deshalb denke den wirst du für dein Vorhaben nicht verwenden können.

Alles andere sollte sehr gut mit Autoit realisierbar sein.

Brauchst dir nur noch einen wenn möglich konigurierbaren Button aussuchen, dann kannst du loslegen mit programmieren oder eben wieder fragen.

So etwas wie hier sollte gehen, evtl gibts ja auch noch etwas günstigeres in der art

https://www.amazon.de/USB-PushButton…e/dp/B00IXIM6BC

Edit: fast vergessen, du kannst ja auch einfach die Maus dafür hernehmen.

Hallo Mikki wenn du wirklich vor hast eine Arbeitszeiterfassung zu machen, dann mach doch mal einen Suchlauf bei der

Suchmaschine deines geringsten Misstrauens und du wirst feststellen, daß sowas so gut wie immer mit Excel realisiert wird.

Ich hatte früher auch mal sowas gebaut in Excel. Da wurden Plus und Minus Stunden besonders markiert und auch Feiertage waren einfach

zu realisieren. Und vor allem bist du mit Excel wesentlich flexibler als mit Autoit. Kleine Änderungen erfordern in Excel ein paar Sekunden

oder höchstens Minuten wo du hier in Autoit unter Umständen das halbe Script umschreiben darfst. Und im Rechnen ist Autoit auch keine Granate,

das konnte in den Neunziger Jahren jeder bessere Taschenrechner um Welten besser als Autoit.

Also wie gesagt Arbeitszeiten oder Stunden erfassen ist in Excel wesentlich flexibler und leichter machbar. Nur ein Tipp von mir.

Korrektur meines Beitrags.

Ich habe 3 verschiedene Befehle zur Überprüfung des Online-Status verwendet, und zwar den Befehl von fakeraol und

zwei weitere aus den WinApi Befehlen.

Das Ergebnis dabei war bei allen drei Befehlen folgendes, egal ob ich Online-Verbindung hatte oder nicht der Status war immer derselbe.

Keine Veränderung wenn ich den Router vom Netz genommen habe.

Nur meine On-Off Simulation funktionierte wie erwartet.

Die Befehle verhalten sich wie Placebo's, sie tun nix ausser Rechenzeit und Speicher zu verschwenden.

1: $IsCon = DllCall($hDLL, 'long', 'IsInternetConnected')

2: _WinAPI_IsNetworkAlive

3: _WinAPI_IsInternetConnected

Bei allen drei Befehlen keine Statusveränderung.

Ich entschuldige mich jetzt schon mal für die langatmige und heftige Antwort, aber es ist einfach die Wahrheit !!

Genau das ist ja so eine Unsitte heutzutage, in meinen Augen würde ein intelligenter Programmierer

eine Programmiersprache so entwickeln, daß sie jederzeit erweiterbar wäre, aber auf keinen Fall etwas an

bestehenden Befehlen und deren Parametern durch Verschlimmbesserung geschieht, was heute aber laufend vorkommt.

Sowas ist einfach ein inakzeptabler Unsinn, bestehende Befehle kaputt zu verbessern, sodass alter Quellcode plötzlich

nicht mehr fehlerfrei ausgeführt wird.

Oder glaubt hier jemand im Ernst, Apple oder Microsoft würden heute noch exisitieren wenn die vor 30 Jahren solche Arbeit

abgeliefert hätten, daß alle oder die meisten alten Programme nach jedem zweiten MacOS oder Dos oder Win Update nur noch

mit Fehlermeldungen abgestürzt wären.

Spätestens nach 10 Jahren solchen Unsinns wären beide Konzerne in der Vergessenheit versunken wo sie

verdienterweise auch hingehört hätten.

Aber heute sind die ganzen Konsumenten und Anwender schon so verblödet, daß man ihnen jeden Schrott

andrehen kann ohne, daß irgendwer auf die Idee käme aufzumucken und zu reklamieren.

Und jetzt kommt mir nicht mit es kostet dich ja nix ist ja Freeware: Fakt ist schlechte Arbeit ist und bleibt schlechte Arbeit,

egal ob ise kostenlos ist oder nicht.

Aber ich schätze viele User hier haben die Konsequenzen eh schon gezogen, wenn man sich ansieht

was hier und im englischen Forum oder in Wambo's altem Forum so los war zwischen 2005 und 2012.

Da war einiges los und es gab hervorragende Programmierer die sehr schöne Programme entwickelt und an alle

weitergegeben haben. Aber heute ist ja im Vergleich dazu schon beinahe Totalstillstand eingetreten.

Oder noch ein Beispiel schlechter Arbeit ist der Firefox, am liebsten würde ich noch mit einer 23er oder 24er Version arbeiten,

aber ich war vor kurzem genötigt auf die neue Schei..Version umzusteigen, weil deepl.com plötzlich nicht mehr wollte mit meiner

56er Version oder hier im Forum konnte ich keine Beiträge mehr erstellen oder auf andere Beiträge antworten.

Und jetzt hab ich einen Schrottbrowser am Laufen der plötzlich für nix 6 bis 8 Prozesse startet und für ein paar lausige Tabs

gleich mal 1GB Speicher und mehr belegt wo mit Sicherheit 200 MB auch reichen würden.

Und wenn noch ein paar Videotabs (einer davon aktiv) dazukommen geht unter Umständen die Prozessorlast auf 100%

hoch und der Speicherbedarf geht noch weiter hoch auf 3-4 GB, was soll der Mist.

Berufsprogrammierer sollte man heute erstmal 2 Jahre lang mit Assemblerprogrammierung quälen,

damit sie lernen können wie man resourcenschonend programmiert.

MfG Tuxedo

Bitnugger ich muss dich leider entäuschen, warum spielst du nicht mal mit beiden Varianten also der von alpines und meiner.

Dann wird dir auch auffallen, daß meine Variante das tut was sie tun soll und die von alpines macht einige Dinge eben nicht wie es gehört.

Sprch spiel zuerst mit der EXE die im Chip-Download steckt, dort kannst du sehen wie es sein sollte.

Danach wirst du sehen, daß minstesens 2 Dinge anders laufen. Es kommen keine Monster und beim Sprung auf die Weissen Platten fällst du beim Zweiten mal einfach durch, richtig wäre , daß die Platten bei erster Berührung verschwinden.

Und die Feuerplatten sind erstmal gelblich-orange und verfärben sich bei Aktivierung nach Rot und explodieren dann. Auch das ist bei der Variante von alpines nicht der Fall.

Nicht Äpfel mit Birnen vermischen.

Du siehst meine Variante hat also durchaus ihre Berechtigung.

Nach unzähligen Spielen von Doodle Jump würde ich sagen es läuft perfekt.

Von der Anpassung der Grösse werde ich aber Abstand nehmen(vielleicht krieg ich später wieder mal Lust drauf), das ist wirklich utopisch

das irgendwann fehlerfrei zum Laufen zu kriegen.

Das Szenario hatten die damaligen Programmierer wohl nicht vorgesehen.

Wer "Doodle Jump für PC" mit heutigen Autoit-Versionen als AU3 spielen will kann sich erstmal das Original-Game von folgender Seite downloaden

Doodle Jump für PC (32 bit) , den 64-bit Download könnt ihr euch schenken (da ist nix 64 bitiges dran, zumindest im Moment)

Dann irgendwohin nach Wunsch entpacken und danach die 3 Dateien aus meinem Archiv "DoodleJump8.1_Source.zip"

auch in diesen Ordner entpacken und Game Starten.

Und nochmal einen großen Dank an @Ubuntu und yxyx und ihre Helfer für dieses schöne Spiel.

MfG Tuxedo

Danke an Mars für den Tipp, das werde ich mal nachprüfen, ich hab noch ein paar ältere Autoit-Games bei denen nach einer gewissen Spielzeit

ein Absturz kommt wegen eines Fehlers in einem Array. Eventuell hilft mir dein Tipp dort weiter.

Ein fremdes mehrdimensionales Array das man nicht selbst entworfen hat ist für mich sehr schwer durchschaubar um dort den Fehler zu finden.

Da muss ich erstmal rausfinden was genau der Wert im Array für eine Bedeutung hat und woher diese Werte kommen.

Es könnte irgendein Überlauf sein oder das betreffende Array ist zu einer bestimmten Zeit aus unerfindlichen Gründen kein Array obwohl eines erwartet wird.

Das sind für mich die schlimmsten Fehler. Und abfangen kann ich da auch nix, weil Tooltip hilft mir dann nicht weil das Proggie ja abschmiert und

Messagebox fällt auch weg, weil dann das Game nicht mehr spielbar ist bei tausenden Messageboxen.

Und Bitnugger du hast mich falsch verstanden, ich hab bei der neuen Variante nicht mehr die Tipps von alpines befolgt, sondern stattdessen

nichts mehr im Script gelöscht oder geändert ausser den beiden GDIPlus Files aus einer alten Autoit-Version ins Scriptverzeichnis kopiert und den Include geändert.

Danach habe ich noch eine Zeile stillgelegt die den Fehler mit den nicht erscheinenden Monstern verursacht hat.

Ja ich verwende SciTe4Autoit, aber diese Details kannte ich noch nicht. Danke für den Tipp, ich wollte es mit einem Debugger erledigen der sonst gute Dienste

vollbringt, der hat sich diesmal aber ziemlich böse aufgehängt.

Aber inzwischen, habe ich die Probleme gut im Griff und habe ein fehlerfrei laufendes Script.

Es läuft jetzt mit der neuen Autoitversion und zwei alten GDIPlus Files ohne grosse sonstige Änderungen.

Keine Abstürze oder sonstige Fehler bis jetzt.

Wenn ichs jetzt noch hinkriege das Game-Fenster doppelt so groß zu kriegen(bei diesem Script evtl utopisch) dann wäre ich zufrieden.

Danke Alpines, werd das mal testen gehen, dann gibts Rückmeldung wie üblich.

Kann aber noch etwas dauern, hab noch was anderes vor.

Edit: Habs grade probiert, es läuft schon mal wenn auch noch nicht so wie es sich die Programmierer gedacht hatten.

Achte mal auf die weissen und die Feuerplattformen. Die weissen kannst du beim Spiel mit der EXE nur einmal anspringen dann verschwinden sie und die Feuerplattformen sollten zuerst gelb sein und werden dann per Timer umgefärbt sobald der Doodle auf deren Höhe springt und explodieren dann nach Zeitablauf.

Wer weiss was da noch so alles falsch läuft, Monster kommen bei mir z.B. auch keine, das Fehlen der Monster passiert allerdings auch bei der EXE-Version.

Oder kommen die erst wenn man 50.000 schafft oder muss man die erst freischalten.

Naja immerhin bin ich jetzt schon weitergekommen, eventuell kriege ich ja doch noch eine fehlerfreie Version hin.

Wie schafft ihr das eigentlich so schnell solche Fehler in einem so riesigen unübersichtlichen Script zu finden, habt ihr Euch einen Bot

dafür gebastelt oder wie macht ihr das?