Doodle Jump gesucht

  • Vor sehr langer Zeit haben zwei oder mehr Personen, ein Spiel Namens Doodle Jump in Autoit nachprogrammiert.

    Klägliche Reste davon hab ich auf verschiedenen Seiten aufgetrieben. Dennoch versuche ich seit Wochen das Ding

    korrekt zum Laufen zu bringen, aber bei dieser Projectgrösse habe ich keinen Durchblick mehr.

    Ich habe Versionen die Laufen eine Zeit lang und stürzen dann einfach mit einem Arrayfehler ab. Fehler für mich nicht nachvollziehbar.

    Oder ich krieg eine Version zum Laufen, da kommen aber keine Gegner(Monster und mehr) und die weissen Platten sind unsichtbar

    uind die Feuerplatten sind auch fehlerhaft und vieles andere mehr. Es ist einfach nervtötend.

    Da ich damals vor ca. 8 Jahren noch nicht mit Autoit beschäftigt war, hatte ich keine Chance auf einen passenden Download.

    Ich denke und ich hoffe Ubuntu und YxYx haben nix dagegen, falls jemand aus dem Forum eine korrekt funktionierende Version 8.1 von DoodleJump

    herumliegen hat und sie mir hier zur Verfügung stellt. Wenn möglich mit Sourcecode und benötigtem Resourcen-Ordner.

    Die Resourcen haben sich nämlich öfters verändert deshalb wäre es gut wenn alles in einem Paket vorhanden wäre.

    Schönen Sonntag an alle Foristen

    Tuxedo


    ps: Warum kann ich eigentlich mit meinem Firefox 56 hier keine Beiträge mehr erstellen oder beantworten??;(:thumbdown:


    Da sich doch einige Leute wider Erwarten für den auf Autoit 3.3.14.2 fehlerfrei laufenden Doodle Jump Sourcecode interessieren,

    möchte ich es denjenigen einfacher machen die nur das Ergebnis testen wollen und am DrumHerum nicht interessiert sind:

    Den endgültigen Download findet ihr im Beitrag #11

    Einmal editiert, zuletzt von Tuxedo (8. Oktober 2018 um 15:05)

  • Habs gerade getestet, das dürfte eine von den Varianten sein die ich schon in der Mache hatte und damit hatte ich auch die besten Ergebnnisse.

    Die EXE-Version läuft korrekt, aber sobald ich sie als Sourcecode verwenden will, hagelt es viele Fehler.

    Soviel Erfahrung mit Autoit habe ich auch noch nicht, aber es scheint mir so, als ob die Probleme durch die Unterschiede der GDIPlus von

    damals und heute verursacht werden. Da krieg ich irgendwie etwas lauffähiges heraus, aber eben nicht die korrekte Version.

    DA sind immer noch viele Dinge die nicht oder nicht richtig funktionieren.

    Wie müsste ich da am Besten rangehen. Im Res-Ordner gibts ja eine GDIPlus.dll, aber ich hab keine Ahnung ob die auch verwendet wird.

    Sicher ist aber, daß durch den gdi include die neu gdiplus UDF verwendet wird.

    Muss ich da jetzt unbedingt eine alte Autoit Version auftreiben, oder habe ich andere Möglichkeiten das korrekt zum Laufen zu bringen.

    Achja trotzdem Danke für die Links.

  • Muss ich da jetzt unbedingt eine alte Autoit Version auftreiben, oder habe ich andere Möglichkeiten das korrekt zum Laufen zu bringen.

    Das sind nur Kleinigkeiten die du ändern musst:

    1. $ghGDIPdll zu $__g_hGDIPdll umbenennen
    2. Z. 2146 ein Leerzeichen vor dem Then einfügen
    3. _GDIPlus_GraphicsRotateTransform löschen
    4. _GDIPlus_GraphicsResetTransform löschen
    5. _GDIPlus_GraphicsTranslateTransform löschen
    6. _GDIPlus_Startupdll löschen und den Funktionsaufruf zu _GDIPlus_Startup() ändern

    und schon läufts bei mir (3.3.14.2).

  • 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?

    2 Mal editiert, zuletzt von Tuxedo (7. Oktober 2018 um 11:36)

  • 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?

    Wenn du SciTE4AutoIt3 als Editor für deine Scripte benutzt, kannst du mit Strg + F5 das Tool "Au3Check" ausführen lassen, welches dir diese Arbeit abnimmt. Mit F4 springst du zum nächsten Fehler, mit Shift + F4 zum vorherigen. Mit einem Doppelklick im Output-Pannel von SciTE (der untere Bereich) auf eine (rote) Fehlerzeile, springt der Editor an diese Stelle im Script. Damit hast du dann schon die halbe Miete...

    SciTE4AutoIt3.png

  • 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.

  • Ich weiß nicht wie lange das her ist, aber früher war Hex($a) implizit ein Hex(Int($a)). Daher tauchen in manchen alten Skripten unnsinnige Werte bei gewissen Rechnungen auf die Hex() benutzen. Da muss man dann ein Hex(Int()) draus machen. (Hab mir den Quellcode hier nicht angesehen, vllt taucht das garnicht auf, könnte aber z.B. irgendwo bei Koordinatenberechnungen verwendet worden sein, sodass die Gegner nicht mehr auftauchen, weil sie irgendwo außerhalb des Bildschirms sind). Der Vollständigkeit halber aber mal erwähnt.

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

    Die beiden Files (*.dll) brauchst du nicht mehr, weil du die Funktion _GDIPlus_Startupdll() (in dieser wurden sie geladen) gelöscht und durch _GDIPlus_Startup() ersetzt hast.

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

    Hehe... ja, viel Spaß dabei... utopisch ist wohl schon das richtige Wort. ;)

  • 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.

  • 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

  • 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.

    ja klar, man kann sich von hinten durch den Ellenbogen vorne durchs Knie schießen, wenn man die Ferse treffen will... oder man zielt direkt auf die Ferse... sprich, man macht es so, wie alpines es bereits gezeigt hat und braucht dann auch deine Source-Files nicht. 8o

    den 64-bit Download könnt ihr euch schenken

    Ja, denn die Files sind alle identisch mit den 32-Bit.

  • 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.

  • 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.

    Das ist auch durchaus verständlich ich habe die 3.3.14.2 am laufen und das Skript wurde sonst wann compiled.

    Bei jeder großen Versionänderung gibt es viele Script-Breaking Changes, es ist überhaupt ein Wunder, dass das Programm ansatzweise das macht, was es soll.

  • 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

  • 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.

    Wenn du das im englischen Forum loslässt dann wirst du mehrmals dafür gesteinigt werden, wir haben leider keinen Zugang zum Sourcecode.

    Es gibt viele, wirklich viele Sachen die ich in AutoIt gerne ändern würde aber nicht kann.

    Dein Frust wird hier natürlich verstanden, aber es wird sich dadurch nichts bessern.

    Teilweise ist das auch verständlich, Script-Breaking Changes gehören einfach dazu, man kann nicht 20 Jahre in die Zukunft schauen und dafür vorprogrammieren.

    An einem bestimmten Punkt befindet man sich einfach in einer Sackgasse und muss den bisherigen Zweig komplett wegschmeißen oder sich irgendeine wackelige Konstruktion zurechtfriemeln und wie du schon erwähntest offenbar nur letzteres.

    Zu deinem Firefox Beispiel: Ich war schon bei FireFox 3 irritiert warum die 4 überhaupt rausgebracht hatten, der lief nämlich noch richtig toll und jetzt hauen sie jede Woche eine neue Version raus.

    Chrome ist mittlerweile bei Version 69.... und es kann mir niemand erzählen, dass in der Zeit so viele Webtechnologien dazugekommen sind ein Major-Update durchzuführen, vielleicht interpretieren sie auch Versionsnummern einfach anders.

    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.

    Das ist aber nicht ausschließlich darauf zurückzuführen, Win32 Controls kommen allmählich ziemlich in die Jahre und für die neuen Controls gibt es glaube ich sowas wie AutoIt Window Info noch nicht.

    AutoIt ist einfach nach Win7/8 nicht mehr so einsatzfähig wie (so wie es gedacht war!!) in 98/XP/7. Aber man kann nach wie vor tolle Programme basteln.

  • Ja das ist hier etwas zu einer Grundsatzdiskussion geworden. Ich finde es auch schrecklich, dass sehr viele alte Skripte einfach nicht mehr lauffähig sind. Aber das davor die meisten Softwarefirmen sicher sind ist ein Irrtum, die kapseln ihre Sachen nur ab und haben anständig definierte Schnittstellen. Könnte wetten dass 80% aller dlls die man so verwendet mit den aktuellen Softwareversionen nicht mehr kompilierbar sind. Deshalb sind die Programme heutzutage oft auch so unnötig groß, weil sie teilweise nur einen Bruchteil von irgendwelchem abgekapselten Code brauchen und dafür die ganze Kiste mitnehmen müssen.

  • Teilweise ist das auch verständlich, Script-Breaking Changes gehören einfach dazu, man kann nicht 20 Jahre in die Zukunft schauen und dafür vorprogrammieren.

    Das sehe ich nicht so. Eine Programmiersprache ist in aller erster Instanz erst mal eine Summe von Befehlen, aka FUNKTIONEN.

    Und das was diese Funktion macht, bestimme ich als Programmiersprachenersteller. Ich bestimme aber auch, wie diese Funktion heißt.

    Ergo habe ich bei einer Entwicklung die Möglichkeit, eine (gewollte) Verbesserung innerhalb des Funktionscodes so durchzuführen, dass die Ergebnisse der Funktion mit der der Vorversion übereinstimmen.

    Wenn ich an der Funktion die von dir beschriebenen "Script-Breaking Changes" durchführe, schiesse ich mir als Ersteller einer Programmiersprache permanent ins Knie!

    Beispiel Funktion(), da könnte ich haufenweise Änderungen und "Script-Breaking Changes" dranhängen, ich könnte aber auch Funktion1(), Funktion2(), FunktionXX(), FunktionYY() uswusf erstellen, mit individuellen, "weiterentwickelten" Eigenschaften. Wer bin ich denn als Programmiersprachenersteller, einem "Programmierer" vorschreiben zu wollen, was er letztendlich zu tun und zu lassen hat?!

    Was mache ich denn als Programmierer, wenn der Programmiersprachenersteller GENAU DIE Funktion, deren Ergebnis ich GENAU SO haben wollte, einfach ändert?!

    Mein Programm so umschreiben, "..dass es wieder passt.."?!

    Ich habe neulich einen tollen Beitrag im Blog von Agner Fog gelesen. Dort beschreibt er, wie die Prozessorhersteller mit jeder Generation "tausende" neue Befehle aus ihrem Silizium quetschen, und die Krux, mit jedem "neuen" Prozessor die uralten Abhängigkeiten (aka "Abwärtskompatibilitäten") mitschleppen zu müssen.

    Natürlich schreitet die Entwicklung voran, aber lieber Agner Fog, die Handvoll 40 Jahre alten x86-Befehle sind definitiv NICHT das Problem in einem neuen Prozessor!

    Es ist die SOFTWARE, die diese 40 Jahre alten Prozessorbefehle zu 99% heute noch nutzt! Und Compiler, die mir als User zwar "neue" Befehle anbieten, aber als "Intrinsics"? Was soll denn DER Schei***? Esoterische Programmiersprachen werden erfunden, damit letztendlich Maschinensprachebefehle eingegeben werden müssen?

    Wo ist denn der Compiler, der keinen der alten, "obsolet" gewordenen Prozessorbefehle mehr nutzt?

    Wenn nicht der Prozessorhersteller, wer denn bitteschön sonst kann einen "neuen" Compiler zum passenden innovativen, "neuen" Prozessor mit all den tollen neuen Features zur Verfügung stellen?

    Ich bin überzeugt, aus technischer Sicht bestünde da absolut kein Problem. Ich vermute nur sehr stark, die wirtschaftlichen Gründe entscheiden, sprich man muss den immer fleissig zahlenden Kunden möglichst langfristig in einer Abhängkeit halten! Jedwege revolutionäre Änderung würde einen bisher vom Produkt abhängigen Kunden sofort nach (ggf sogar "besseren") Alternativen Ausschau halten lassen! (ähhhm, Parallelen zu AutoIt?!)

    In dem Moment in dem bspw. ein Prozessorhersteller einen innovativen "neuen" Prozessor incl. Programmierumgebung vorstellt, ziehen ALLE anderen Anbieter SOFORT nach, denn die sind ja auch nicht blöd und haben solch ein System längst auch in der Schublade.

    Damit würden aber ALLE Karten im Markt neu gemischt, und DAS tut sich keiner der global Player an!

    Solange man Milliarden damit verdient, auf neuester Hardware uralte Software laufen zu lassen, ändert sich auch nichts!

    Und damit schließt sich aber auch der Kreis zum Anfang meines Posts!

    In meinem allerneuesten Prozessor kann ich immer noch 8-Bit-Befehle ausführen, wenn ich das will! Und die liefern GENAU das gleiche Ergebnis wie vor 40 Jahren!

    Natürlich kann ich auch AVX512 Befehle ausführen, aber diese sind, und genau DAS war so beabsichtigt, eine Erweiterung des Befehlssatzes, und kein Ersatz!

    Wieso macht man das nicht genau so bei einer Programmiersprache?

    Was wäre an AutoIt schlechter geworden, wenn ich heute mit der neuesten Version mein 10 Jahre altes Script kompilieren (sic) könnte?

    Oder wäre AutoIt eventuell sogar dadurch "besser" als andere, "modernere" Sprachen?

    An einem bestimmten Punkt befindet man sich einfach in einer Sackgasse

    ...in die man sich genau durch dieses Vorgehen selbst reingeritten hat...

    und muss den bisherigen Zweig komplett wegschmeißen oder sich irgendeine wackelige Konstruktion zurechtfriemeln

    ...unter der wir alle, die mit "alten" Scripten zu tun haben, leiden müssen!

    Win32 Controls kommen allmählich ziemlich in die Jahre und für die neuen Controls gibt es glaube ich sowas wie AutoIt Window Info noch nicht.

    Auch damit kämpfe ich fast jeden Tag, mittlerweile ist es schon problematisch, ein "Fenster" in den "Vordergrund" zu holen. Das ist aber nicht das Problem von AutoIt, sondern von WIN10. Ich habe jetzt wirklich vor, in der Firma einen Rechner auf Win7 "downzusizen" und die seit vielen Jahren problemlos laufenden Scripte LOKAL (nicht im RDP) in Verbindung mit Drittherstellersoftware laufen zu lassen.

  • Hey Andy

    Das sehe ich nicht so. Eine Programmiersprache ist in aller erster Instanz erst mal eine Summe von Befehlen, aka FUNKTIONEN.

    Und das was diese Funktion macht, bestimme ich als Programmiersprachenersteller. Ich bestimme aber auch, wie diese Funktion heißt.

    Ergo habe ich bei einer Entwicklung die Möglichkeit, eine (gewollte) Verbesserung innerhalb des Funktionscodes so durchzuführen, dass die Ergebnisse der Funktion mit der der Vorversion übereinstimmen.

    Ich denke das kann man bei einer Sprache die Vererbung, Überschreibung, usw. kennt so sagen. Aber AutoIt war einfach anders angelegt. Du musst nicht immer alles includen, sondern kannst für vieles direkt loslegen. Wenn man da alle Varianten nebeneinander ermöglichen wollte, würden bald die abenteuerlichsten Funktionsnamen-Varianten entstehen. Das wäre auch nicht sinnvoll.

    Auch damit kämpfe ich fast jeden Tag, mittlerweile ist es schon problematisch, ein "Fenster" in den "Vordergrund" zu holen. Das ist aber nicht das Problem von AutoIt, sondern von WIN10

    Das ist kein "Problem" von Windows 10. Vielmehr ist es doch so, dass AutoIt für Win32 Controls entwickelt wurde und seit langer Zeit keine Weiterentwicklung stattfindet, während Microsoft auf der anderen Seite Windows weiterentwickelt.

    Grüße autoiter

  • Wenn ich an der Funktion die von dir beschriebenen "Script-Breaking Changes" durchführe, schiesse ich mir als Ersteller einer Programmiersprache permanent ins Knie!


    Beispiel Funktion(), da könnte ich haufenweise Änderungen und "Script-Breaking Changes" dranhängen, ich könnte aber auch Funktion1(), Funktion2(), FunktionXX(), FunktionYY() uswusf erstellen, mit individuellen, "weiterentwickelten" Eigenschaften. Wer bin ich denn als Programmiersprachenersteller, einem "Programmierer" vorschreiben zu wollen, was er letztendlich zu tun und zu lassen hat?!

    Was mache ich denn als Programmierer, wenn der Programmiersprachenersteller GENAU DIE Funktion, deren Ergebnis ich GENAU SO haben wollte, einfach ändert?!

    Nein, mir persönlich ging es darum, dass man einfach mit der Zeit dazu lernt und an einem Punkt ankommt wo man einige Sachen einfach ändern sollte, da man sie nicht vorausplanen konnte.

    Und das nicht permanent mit jeder Version sondern auf einen Schlag und dann ist erstmal Ruhe, dann muss auch nicht permanent was geändert werden sondern nur einmal.

    Abwärtskompatibilität ist natürlich immer eine feine Sache aber irgendwann vermengt sich das ganze und man muss sich halt fragen, ob es sich lohnt 40 Jahre alten Programmcode mitzuschleifen den man durch effizientere Implementationen ersetzen könnte. Auch wenn man die neue Implementation nehmen kann und die alte drinlässt, es bläht sich doch nur alles auf.

    In AutoIt würde ich z.B. GUISetState ändern, weil mir das zu inkonsequent ist die Flags vor der GUI zu setzen (auch wenn AutoIt für eine GUI gedacht war) und das ist nur die Spitze des Eisberges.

    Würde man immer Funktion1 Funktion2 Funktion3 nehmen, so macht man das ganze, meiner Meinung nach, nur schlimmer weil man nur Symptome bekämpft aber nicht das Problem.

    Inwiefern man nun die ursprüngliche Funktion ändert oder neue hinzufügt ist sicherlich von Fall zu Fall unterschiedlich, ich denke da sind wir uns beide einig.

    Aber, dass eine Sprache konsequent ihre Parameter benennen sollte (sowie ihre Reihenfolge) und die selben Typen in ähnlichen Funktionen erwartet sollte doch wohl auf der Hand liegen.

    Das ist es was mir bei AutoIt solche Kopfschmerzen bereitet.