Beiträge von Andy

Mars, anbei habe ich Hindernisse eingefügt, allerdings steigt dann ab und zu die Func __Area_GetRichtung() mit Rekursionsoverflow aus...

//EDIT
ahhh, habe mir das mal genauer angeschaut, du errechnest nicht von jedem freien Feld den Abstand sondern gehst davon aus, dass der Weg Hindernisfrei ist
Wieso du dir aber dermassen die Finger brichst weiss ich nicht
Starte am Start
Springe auf jedes freie Nachbarfeld und notiere dort den Abstand zum bereits berechneten Feld (plus dessen Wert) , dieses ist der "Wert" des neuen Feldes
Fülle so das gesamte Spielfeld aus
Gehe vom Ziel aus immer auf das nächste Feld mit dem kleinsten Wert, bis du bei Start bist

Texos, du hast den Algorithmus nicht verstanden...Wenn das Feld einen bestimmten Wert hat , dann musst du nicht in einem weiteren Array oder Index diesen Wert nochmal speichern.
Wenn ein Feld bspw den Wert 1000 hat, dann wird dort nie "hingelaufen", weil alle anderen angrenzenden Felder einen kleineren Wert haben.

Hi,
beim A*-Algo musst du einfach nur das "diagonale" Gehen weglassen^^

Letztendlich läuft es darauf hinaus, jedes Feld des Spielfelds vom Start ausgehend zu bewerten und diese Werte zu addieren. Am Ziel angekommen geht man dann rückwärts auf dem "kürzesten" Weg, d.h. immer zum Feld mit dem kleinsten Wert. Das Prinzip ist sehr einfach.
Bei einem TD mit mehreren Creeps würde ich es so machen, dass zusätzlich zum Wert des Feldes auch noch das "Gewicht" des Creeps mit addiert wird. Dann würde ein von einem Creep besetztes Feld nur im absoluten Notfall mehrfach besetzt werden, trotzdem wäre aber ein Stau vermeidbar bzw, ggf wäre ein längerer Weg einem Stau vorzuziehen.

Bei deinem Beispiel sieht der Weg länger aus als er ist, da nicht der "gerade" Weg zum Ziel genommen wird^^.
Das war auch bei meinem A* Algo so, das konnte ich aber über die Bewertung der Diagonalen einstellen.
Da bei dir nur Waagrecht und Senkrecht gegangen werden kann, solltest du das Feld, das auf der "Luftlinie" zum Ziel liegt, bei gleichem Wert vorziehen....So läuft die Figur auch "diagonal" über das Spielfeld, statt bspw. ganz nach unten und dann ganz nach rechts zu laufen. Der eigentliche Weg ist zwar genauso lang, aber es sieht einfach doof aus^^

Zitat

Wenn man sein Programm wirklich sichern will muss man eben auf eine richtige Programmiersprache umsteigen (z.B. Assembly).

Sobald man an die ausführbare Datei herankommt ist es völlig unerheblich mit welchen Mitteln gesichert oder verschlüsselt wurde!
Dann ist es nur eine Frage des Aufwandes und der Hartnäckigkeit, ein Programm zu knacken.

Hi,
das würde zutreffen, wenn bspw. nur ein Passwort verwendet wird. Dann kann man es natürlich "hartkodiert" direkt im Script verwenden. Was aber alles nichts nützt, denn wenn dekompiliert wird ist es völlig schnurz, ob das Passwort im Klartext oder gehashed oder sonstwie verschlüsselt im Script steht.
Der Hash oder die Verschlüsselung machen nur dann Sinn, wenn sie "außerhalb" des Scriptes stehen, bspw. in der Registry oder in einer Datei (*.ini)
Verschlüsselte Passwörter in externe Dateien (Registry oder *.ini) schreiben ist imho suboptimal. Ist die Passwortdatei beschädigt oder nicht im Zugriff, gibt es Stress!
Die EXE ist immer im Zugriff, man braucht nur eine Datei und kann beliebig viele und große Passwörter anhängen.

Hi,
in letzter Zeit wurden einige Anfragen gestellt bzgl. der Speicherung von Passwörtern bei kompilierten Scripten. Der Sinn sei mal dahingestellt...

Am einfachsten ist es, die Passwörter direkt in der EXE-Datei zu speichern aber wo dort?
Man könnte auf die Idee kommen, ein Passwort im PE-Header der EXE zu speichern, aber einige Virenscanner überprüfen diesen Bereich und warnen mit Vorhandensein von bspw. "Dropper.Gen" (jaja, im DOS-Stub wurde "früher" auch gerne mal rumgeschrieben und sog. Dropper eingefügt, was aber absolut garnichts mit einem Virus o.ä. zu tun hat)
Dann könnte man weitere ungenutzte Bereiche innerhalb der EXE-Datei beschreiben, aber dazu müsste man einigen nicht unerheblichen Aufwand betreiben (in Assembler ist alles sooo viel einfacher 8 ) !
Am allereinfachsten ist es, man hängt das Passwort einfach an die EXE an

Es macht Sinn, das Passwort zu "hashen", erstens ist es dann unleserlich, zweitens auch halbwegs "sicher", da es nirgendwo im Klartext steht!

Wie fragt man das Passwort in der gestarteten EXE-Datei ab?

Also zuerst das zu schützende Script zu einer EXE kompilieren.
Dann das 1. Script aufrufen und damit dann das einzugebende Passwort an die EXE anhängen.
EXE aufrufen und Passwort eingeben.

Wer mag, kann das Passwort auch in der *.AU3-Datei einfügen
Einfach als Kommentar in die letzte Scriptzeile schreiben, dann funktioniert auch die Au3-Version

Zitat

Das hängt nur von den eigenen Fähigkeiten ab. Ich garantiere dir, dass ich eine GUI mit diversen Elementen ohne Koda mindestens genauso schnell, aber sauberer erstelle als irgendwer mit Koda.

Was nichts anderes heisst, als dass Koda wesentlich verbessert gehört!
Den Ansatz finde ich nicht schlecht, und ich bin überzeugt, dass auch die "Pro´s" Koda nutzen würden, wenn es einen Vorteil hätte!
Im Visual Studio schreibt sich niemand (ernsthaft) seine GUI selbst, der dort enthaltene Editor ist viel zu gut, um die Zeit mit "in der Hilfe suchend nach den passenden Befehlen"-rumgehopse zu verschwenden!
Ich jedenfalls wäre ohne die Hilfe ganz schön aufgeschmissen, gerade eine GUI mit mehreren (nicht ständig benutzten) Elementen klicke ich mir gerne in Koda zusammen, um dann "nachher" den Code zu bearbeiten und anzupassen!

Zitat

Das bedeutet demnach, dass deine Funktion nicht richtig arbeitet.

So ist es, kommentiert man das "Errorhandlling", also die ersten 5 Zeilen in der Funktion aus, funktioniert sie...im 64-Bit-Zahlenraum.

Zitat

Ob Andy es herausgefordert hat ?

Hat er!!!!

hmmm, dann wird das Script aber HÄSSLICH!

Hi,
da MUSS ich doch meinen Senf dazugeben^^

Zitat

Da wohl niemand daran gedacht hat für diesen Fall Errorhandling einzubauen, um das ganze wirklich idiotensicher zu machen, beschwert sich AutoIt halt über das Array das keins ist.

Ein Hoch auf die Programmierkunst!
Genau wegen dieser "Fehler" werden für die einfachsten (Win-API)-Funktionen Errorhandlings eingebaut, und zwar dermassen viele, dass bei den meisten Funktionen das Errorhandling bei weitem das Maß überschreitet bzw. die Ausführungsgeschwindigkeit extrem verlangsamt!
Wenn ein simpler "Sin()" in C++ bis zu 5x länger dauert wie der Inline-ASM-Code (Aufgrund des Errorhandlings ! ) dann kann man sich ansatzweise Vorstellen wie viel schneller u.a. GDI wäre, wenn man auf die "Fehler"-Abfragen weitgehend verzichten könnte....
Erschwerend kommt noch dazu, dass die "Programmierer" nicht mal in der Lage sind, die "Fehler" auszuwerten, s. u.a. diesen Thread

Genau aus diesem Grund weigere ich mich mittlerweile, sog. UDF´s zu publizieren!
Die "Anwender" dieser Funktionen gehen selbstverständlich davon aus, dass es weder nötig ist, Funktionsbeschreibungen zu lesen, noch auf die Syntax oder die Datentypen zu achten....
Um alle diese "Fehler" (wohlgemerkt nicht die der Funktion, sondern der ignoranten oder faulen Anwender) abzufangen, muss man einen simplen 20-Zeiler auf 100 Zeilen "bloaten".
Wie hier im Thread gezeigt, hilft auch das nicht, wenn die Errormessages nicht in einer Messagebox angezeigt werden. Simples SetError() ist somit völlig überflüssig
Ein Hoch auf die Programmierkunst!

Hi,
schön, dass du den Threadtitel geändert hast^^ jetzt hagelt es Hilfen, jede Wette

Zitat

Achso ok, und noch was, kann sein das WinWaitActive nicht tut? Weil wenn ich WinWaitActive("Titel") eingebe und starte passiert nichts, gebe ich statt dessen sleep(...) ein dann funktioniert der darauffolgende Befehl

Ja, ein Sleep() ist nie verkehrt! Ich wähle je nach Fenstertyp und Anwendung bis zu 2 Sekunden!!!
Das Problem an Windows ist, dass es völlig Eventbasiert ist! So kann es sein, dass zwar die Information "Fenster aktiv" abgefeuert wurde, aber diese Information noch nicht in den entsprechenden Listen enthalten ist (oder das Fenster ist bei weitem noch nicht so weit...).
Wenn du dann "zu früh" den Befehl "Drück den Button" gibst....dann hat Windows sich mal wieder selbst überholt, das ist an der Tagesordnung!
Also entweder Wartezeiten einplanen (mit Sleep() geht das am einfachsten) oder mehrfach und ggf. mit verschiedenen Funktionen Ereignisse abfragen (kritisch s. o.)

Hi,
der Controlclick-Befehl funktioniert einwandfrei...
Definitiv liegt es nicht am ControlClick(), sondern an dem, der diesen Befehl nicht richtig anwendet!

Zitat

Kann mit jemand sagen was ich falsch gemacht habe?

Wie jetzt, also gehst du doch davon aus, dass DU den Fehler verursachst?! Wieso schreibst du das dann nicht so in die Überschrift zum Thread anstatt den Programmierern von AutoIt "die Schuld" zuzuschieben?

Schau dir mal die Parameter genauer an, und nimm den "Advanced Class" als Parameter

ControlClick("Piriform CCleaner", "", "CLASS:Button; INSTANCE:2")

dann noch (siehe Hilfe) den Button (links/rechts) und die Anzahl der Klicks uswusf

Hi,

Zitat

Ist doch etwas seltsam oder. Ist das Prog, das ich steuern will vielleicht einfach scheiße geschrieben, dass die Controls nicht sauber abgebaut werden oder sowas?

Willkommen in der Windows-Welt!
Die meisten von M$ oder deren Programmiersprachen erstellten Programme kümmern sich einen SCHEISS! um die von M$ "vorgegebenen" Windows-Konventionen! Da werden in den Fenstern irgendwelche esoterischen (teilw. Browser ! ) - Plugins verwendet um Listen, Tabellen und deren Controls zu verwenden um jeden Zugriff auf den Inhalt wirkungsvoll zu verhindern, "Tastatursteuerung" (bspw. Tab führt ins nächste Edit/Feld/Menüpunkt/Button) wird völlig ignoriert und schlussendlich findet man heraus, dass es "eindeutige Handles" garnicht gibt (s. quote) !
Und das wird alles nicht besser, sondern in letzter Zeit schlimmer...den "neuen" tollen Programmiersprachen sei Dank...
Ich habe wohl oder übel in letzter Zeit dienstlich wieder häufiger auf "PushTheButton" (sic) zurückgreifen müssen, weil eine Automatisierung auf anderem Weg garnicht möglich ist/war

Hi,
habe mir im letzten Jahr einen Samsung NP305E7A-S01DE geschossen für 450€ incl Win7-64.
17´´ mattes Display, Quadcore A6-3450 mit integrierter Grafik Radeon 6520G und zusätzlichem Grafikchip Radeon 7400M, zufriedenstellender Tastatur, im Standardbetrieb lautloser Lüfter und per Mausklick (ich hasse Touchpads) anpassbarerem Takt (400MHz bis 2.7Ghz) und somit Laufzeit bis zu 5.5h.
Der Prozessor ist für alle bisherigen Aufgaben völlig ausreichend, bei Grafikanwendungen werden die beiden Grafikchips im Verbund geschaltet und erlauben auch das eine oder andere Gerendere/Gezocke...
Ich würde das Gerät nicht mehr eintauschen wollen.
Für jemanden, der auf die Grafikanwendungen(fast) völlig verzichten kann, wäre einer der neuen Intel-Chips sicher interessant, allerdings ist das Preis/Leistungsverhältnis bei AMD bei weitem besser...
Für vergleichbare Rechenleistung/Ausstattung/Display ist bei Intel der übliche "Marktführer"-Aufschlag von 100-150€ fällig!

Bei M$ kann man den 64-Bit-Compiler auch in das kostenlose Visual Studio einbinden
http://msdn.microsoft.com/en-us/library/…s(v=vs.90).aspx

misterspeed,
sehr schön erklärt und auch fein aufbereitet!
Das auseinanderfrickeln von derart komplizierten Protokollen ist schon eine Heidenarbeit für sich, bei unbekannten Protokollen bzw. Formaten kommt noch das Testen und Reingeneering dazu , das tu ich mir aber heutzutage nur noch bei einfachen Sachen an^^

Allerdings beobachte ich den Thread seit dessen Erstellung
Der TE hat ein Problem, welches er nicht mal ansatzweise äussert. Es ist immer noch nicht klar, wieso und weshalb überhaupt WAS gemacht werden soll....
Und wenn ich dann lese

Zitat

Leider gibt es in dem RFC keine eindeutige Syntax, so wie "DHCPDISCOVER [param1] [param2]" oder so.
Nur gaannnzz viel Text
Kann man so etwas in der Art irgendwo finden?

ist mir schon klar, dass wieder mal "der Arm aus der Sonne gelegt" werden soll.
Die RFC zum Thema listen definitiv alles auf, was an Informationen benötigt wird. Wieso findest DU die Informationen in dem "gaaaanzzz viel Text", der TE aber nicht? Wieso kannst du Scripte zur Verdeutlichung erstellen, der TE aber nicht?

Wieder mal ein schönes Beispiel dafür, dass die c&p-Generation nicht in der Lage ist, aus Bergen von Informationen (RFC, Wiki, google) das Gesuchte rauszuziehen

Hi,

Zitat

Üblicherweise ist entweder dein Programm mit allen DLLs 64 bit oder alles ist 32 bit.

kann man so stehen lassen^^

Allerdings gibt es noch eine weitere Möglichkeit, eine Dlll gleichzeitig für 32+64Bit zu verwenden!
Die Funktionen in der Dll werden dann nicht direkt angesprungen, sondern über eine Art "Wrapper". Dieser erkennt Anhand des Aufrufs und der Konventionen, ob ein 32-Bit- oder 64-Bit-Call vorliegt und springt dann die eigentliche Funktion mit den "richtigen" Parametern an.
Imho aber überflüssig, da es wohl nur bei SEHR speziellen Funktionen einen Vorteil von 64- zu 32-Bit-Funktionen gibt.
2 Dll´s, eine als dll32 und die andere als dll64 compiliert und damit hat es sich idR....

Einfach, Usability 100% !

AspirinJunkie,

Zitat

Das Ergebnis wird hier lediglich gerundet.

Na, dass weiss ich doch!!
Daher auch mein Statement:

Zitat

Die Frage bleibt aber, ob der Prozessor richtig rechnet oder das Ergebnis "richtig" dargestellt wird

was ehrlich gesagt aber völlig unerheblich ist, denn das was "dort steht" ist per definitionem erstmal richtig (s. BILD-Zeitung).
Es bleibt anderen überlassen, die Darstellung zu interpretieren bzw. "richtiges" von "falschem" zu unterscheiden!
Würde das Consolewrite() die von dir genannte printf()-Funktion nutzen, wäre der "Fehler" im Startpost niemals aufgefallen, er hätte aber weiterhin bestanden!!! Oder doch nicht?

Denn wie James in seinem Beispiel gezeigt hat, macht diese Diskussion nur dann Sinn, wenn die Anzahl der relevanten Nachkommastellen im Vorfeld festgelegt wird.
Wenn ich mit

For $i = 2 to 3.5 Step 0.025

definitiv 3 Nachkommastellen festlege, dann MUSS! in der nächsten Zeile

$i=round($i,3)

oder eine Entsprechung auftauchen, alles andere führt zu verfälschten Ergebnissen!

Die Frage stellt sich nun, warum der Compiler/Interpreter das nicht weiss