Zum Inhalt springen

MidWar [Midgard Kampfsimulator]


Mav3N

Empfohlene Beiträge

Geschrieben
Und wozu soll ich mich äußern?

 

Zum Beispiel darüber, ob du den Simulator auf die offizielle Seite aufnehmen möchtest und wie. Ich hab dir ja bereits gesagt, dass die FreeServer auf denen ich ihn gerade lager nicht gerade die beste Performance haben und somit eine Simulation seeehr lange dauern kann, bisweilen gar nicht geht. Bei dir dürfte das besser sein. Das ist einer der Gründe warum ich ihn auf der offiziellen Seite haben möchte.

 

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

 

Also zusammengefasst: Nenn mir (uns) mal bitte deine Bedingungen, damit er aufgenommen werden würde. Vllt. kann ich Einwände mit Hilfe anderer Programmierer hier entkräften.

 

Bamba

Geschrieben
Ich habe auf deinen Link geklickt. 3 Teams erstellt mit je einem Kämpfer:

Kampfinformationen:

�berlebende:

Name ID LP AP Schaden Team Angriffswert Verteidigungswert R�stung Status X Y B

Person_1 1 12 10 1W6 1 5 12 Lederr�stung Unbeeintr�chtigt 1 1 3

Person_2 2 12 10 1W6 2 5 12 Lederr�stung Unbeeintr�chtigt 9 9 4

Person_3 3 12 10 1W6 03 5 12 Lederr�stung Unbeeintr�chtigt 9 1 9

Runde: 1

Anzahl verschiedener Teams: 3

Person 1 sollte ein Oger ab drop down liste sein, wurde nicht übernommen.

"Person_1 mit der ID 1 geht 4 auf Feld 5,3, kann diese Runde aber nicht angreifen, da er diese Runde nicht gen�gend weit gehen konnte." macht keinen Sinn.

"Person_2 mit der ID 2 erzielt 24 und hat Person_1 mit der ID 1 getroffen. Person_1 mit der ID 1 erzielt 22, kann nicht abwehren, erh�lt 4 Schadenspunkte und verliert 0 LP und 4 AP."

Das ist ein schwerer Treffer, die Rüstung sollte LR sein also müssten 2 LP Schaden verrechnet werden.

da so natürlich niemand stirbt endet die Simulation irgendwann mit dem entsprechenden Fehler.

es grüsst

Sayah el Atir al Azif ibn Mullah

 

Hallo,

 

es gibt genau 2 Fehler wie es scheint bei deinen Werten und Eingaben. Ein Fehler hat mit dem A* Algorithmus zu tun, den ich gefunden und behoben habe - ich lade die Verbesserung bald hoch. Der andere Fehler (?) scheint sich um die Schadens und Lebenspunkte zu drehen. Das Problem ist, dass es mir nicht gelingt ihn mit deinen Eingaben nachzustellen und zu reproduzieren. Nenn mir daher bitte andere Konstellationen und die komplette Anzeige sowie alle eingegebenen Werte bei denen der Fehler auftritt. Sonst kann ich ihn nicht finden, sofern er existiert.

 

Bamba

Geschrieben
1. Die Eingaben für die X,Y und B Werte in insert.php werden noch nicht überprüft! Hierüber sind derzeit noch Attacken möglich (Ich glaube aber mal nicht, dass sich ein Midgard-Spieler dazu durchringt ;)) Bitte achtet darauf, dass ihr vernünftige Werte eingebt.
Wobei X und Y die Startposition angeben (X=0, Y=0 entspricht links oben) und B die Bewegungsweite ist. Ist es Absicht, dass man für die drei Werte maximal eine einstellige Zahl eingeben kann?

 

Und ganz besonders wichtig: Derzeit lasse ich einen Spieler seine kompletten Aktionen ausführen und erst dann den nächsten Spieler. Das muss ich noch ändern. Es soll am Ende so ablaufen, dass Spieler 1 einen Schritt geht, dann Spieler 2 einen Schritt seines Weges, etc.
D.h. du willst zunächst die sekundengenauen Regeln zur Abwicklung einer Kampfrunde umsetzen? Wäre es nicht sinnvoll, erstmal die 10-Sekunden Runde zu implementieren?

 

Was mir noch aufgefallen: Es wäre schön, wenn man einstellen könnte, wie riskant ein Kämpfer kämpfen soll, d.h. ob er z.B. einen überstürzten Angriff macht oder nicht.

 

Screenshots für Fehler sind etwas schwierig, da man hier im Forum als normaler Nutzer keine Bilder anhängen kann. Vielleicht überlegst du dir noch einen Debug-Modus, der ein Text-Debuglog erzeug, das man dann hier posten kann.

 

CU

FLo

 

Das mit den Screenshots ist klar, deswegen bitte immer Eingaben und den gesamten Ausgaben Text bei Fehler mit Fehlerbeschreibung posten.

 

Deine Anregung, dass man einstellen kann, wie riskant ein Kämpfer kämpfen soll, ist bereits auf meiner Todo-Liste und wir demnächst umgesetzt. Ich werde übrigens erstmal die sekundengenauen Regeln umsetzen, und auf Basis dessen die 10-Sekunden Regel anbieten.

 

Ja, im moment ist es noch gewollt, dass man nur einstellige Werte (B kann zweistellige Werte annehmen) einstellen kann. Das hängt damit zusammen, dass nach der Umstellung intern einiges nicht mehr funktionierte und ich mehrstellige X und Y Eingaben derzeit noch nicht erlauben kann.

 

Bamba

Geschrieben

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

Wie effizient sind die von dir verwendeten Algorithmen? A* hat entweder O(N^2) oder O(N * log(N)), je nach Implementierung. Weitere? Ich bin mir auch nicht sicher, ob die Heuristik für bewegte Kontrollbereiche über eine Runde hinaus monoton ist, das will der Algorithmus aber.

 

Wie wertest Du die übergebenen Parameter aus? Ohne Code Review wird das wohl nix. ;)

Geschrieben

 

EDIT: Alle Fehler, die ihr findet bitte mit Screenshot hier posten!

 

Hallo - ich finde es schade, dass Rundumschläge, beidhändiger Kampf, Fechten, aber auch Pimpzauber wie Bärenwut offenbar nicht abzubilden sind.

 

Denn der echte Charme des Simulators liegt doch darin, ein Gefühl dafür zu kriegen, wann sich eine Spielerfigur noch einer Übermacht stellen kann und wann man besser die Beine in die Hand nehmen sollte.

 

Greetz Schneif

Geschrieben
Zum Beispiel darüber, ob du den Simulator auf die offizielle Seite aufnehmen möchtest und wie. Ich hab dir ja bereits gesagt, dass die FreeServer auf denen ich ihn gerade lager nicht gerade die beste Performance haben und somit eine Simulation seeehr lange dauern kann, bisweilen gar nicht geht. Bei dir dürfte das besser sein. Das ist einer der Gründe warum ich ihn auf der offiziellen Seite haben möchte.
Ich habe keine Ahnung vom Programmieren etc. D.h. es muss anders herum laufen. Du sagst mir, was Du gerne hättest und ich lasse schauen, ob sich das bei einem vertretbaren Aufwand realisieren lässt.
Geschrieben

Ich bin allerdings kein soo erfahrener PHP-Programmierer und kann nicht alle Vor- und Nachteile abwägen, deswegen wollte ich hier öffentlich darüber diskutieren, damit sich einige erfahrenere Programmierer (die es hier sehr wohl gibt) einschalten und ihren Senf dazugeben. Es geht dabei um Themen wie Sicherheit und Stabilität.

Wie effizient sind die von dir verwendeten Algorithmen? A* hat entweder O(N^2) oder O(N * log(N)), je nach Implementierung. Weitere? Ich bin mir auch nicht sicher, ob die Heuristik für bewegte Kontrollbereiche über eine Runde hinaus monoton ist, das will der Algorithmus aber.

 

Wie wertest Du die übergebenen Parameter aus? Ohne Code Review wird das wohl nix. ;)

 

Nun zur Komplexität des A* (der in meinem Script mit Abstand der am meisten Performance und Speicherfressende Algorithmus ist), kann ich nur sagen: Keine Ahnung! Ich hab mir den PseudoCode auf der Wikipediaseite angeguckt und einfach in PHP runtergescriptet. Den Code hast du in den vorherigen Beiträgen. Gut programmiert habe ich ihn nicht, aber er funktioniert mittlerweile. Alle meine Messungen lagen aber bei 10x10 Feldern immer unter 15ms. ;)

 

Andere Algorithmen habe ich nicht verwendet, ich habe mich an assoziative 2D Arrays gewöhnt, die ich immer und überall verwende. Diese verbrauchen denke ich auch eine ganze Menge Speicher in meiner fight.php, der Rest ist billiger Kinderkram if($actualChance + $Random >= 20) { ... } etc.

 

Dementsprechend wäre der A* das performancefressendste Konstrukt in meinem Code, gefolgt von sehr großen, häufig verwendeten 2D Arrays. Mehr nicht. (Beim Statistikkampf wird die Situation 100mal durchsimuliert und der Mittelwert genommen). Das wären im schlimmsten Fall 100 * 15ms (astar.php) + 100 * 2ms (fight.php). Ich denke aber daran das demnächst auf 1000 Durchläufe anzuheben. Außerdem werde ich demnächst alles Sekundengenau berechnen, was nochmal den Aufwand in der fight.php um den Faktor 10 anhebt. Im Endausbau sollte das ganze also 1000 * 15ms + 1000 * 20ms = 35 Sekunden für einen Statistikkampf verbrauchen. (Werte richten sich für 10x10 Felder und ca. 5 Kämpfer in 2 Teams). Bei größeren Feldern und mehr Kämpfern steigt das ganze exponential.

 

Bei allen Freehostern hast du ein execution time limit von meist unter 30 Sekunden. Also sehr, sehr wenig. Bei 100 Durchläufen ist das zwar noch machbar aber es wird knapp, wenn ich anfange sekundengenau zu simulieren. Das ganze Skript muss auf einen Server, der diese Beschränkung nicht hat (Elsa könnte das auf ihrem einstellen lassen denke ich) und der bessere Performance besitzt - ich mir die Performance nicht mit X Nutzern beim Freehoster teilen muss.

 

An Elsa: Ich möchte einfach die fight.php, astar.php und insert.php auf deinem Server hosten, nachdem ich nochmal die Sicherheit des Skriptes überarbeitet habe und hoffe dadurch die Beschränkungen der Freehoster zu übergehen.

 

Sicherheitstechnisch kann ich sagen, dass es ja alles von den Eingaben in der insert.php abhängt. Deswegen baue ich die Überprüfungen auch gerade Serverseitig und nicht Clientseitig auf. Derzeit ist es noch clientseitig. Diese könnte man nämlich umgehen, indem man sein eigenes JS Script anstelle von meinem platziert. Wenn die Eingaben abgesichert und überprüft sind, sehe ich kein Problem mehr. Sehr ihr erfahreneren Programmierer das ebenso?

 

Elsa kann nur 2 Probleme bekommen: Sicherheitstechnisch (s. oben) und Performancetechnisch. Es würden Spitzen auftreten, in denen die CPU des Servers stark belastet ist. Diese würden bis zu 10 Sekunden andauern. Daran kann man aber nichts ändern.

 

Jetzt bitte alle erfahrenen Progger äußern. :D

 

Bamba

Geschrieben

 

EDIT: Alle Fehler, die ihr findet bitte mit Screenshot hier posten!

 

Hallo - ich finde es schade, dass Rundumschläge, beidhändiger Kampf, Fechten, aber auch Pimpzauber wie Bärenwut offenbar nicht abzubilden sind.

 

Denn der echte Charme des Simulators liegt doch darin, ein Gefühl dafür zu kriegen, wann sich eine Spielerfigur noch einer Übermacht stellen kann und wann man besser die Beine in die Hand nehmen sollte.

 

Greetz Schneif

 

Das kommt doch alles noch. :lookaround:

 

Denk mal bitte nach: Für Rundumschläge und dergleichen, muss der Simulator doch mit Positionen rechnen, damit er simulieren kann, wer um einen rumsteht und ebenfalls getroffen wird... Das habe ich gerade erst hinzugefügt und bin noch am Fehler suchen ... Alle von dir aufgeführten Sachen werden noch kommen, allerdings benötige ich dafür viel, viel, sehr viel Zeit!

 

Bamba

Geschrieben

PHP ist für eine Simulation (die dann auch noch x Mal gemittelt werden soll) ziemlich ungünstig.

 

Wenn Du etwas haben möchtest, was online verteilt werden kann und keine Rücksicht auf eine bestimmte Plattform nimmt, dann programmiere es in Java. Jeder nutzt dann seinen eigenen Rechner und kann selber bestimmen, wann er Pause macht...

 

Noch mehr Performance würde natürlich C/C++ liefern, aber da gibt ein Programm für eine bestimmte Plattform.

 

Wenn A* so viel Zeit braucht, dann könnte auch eine Hashfunktion helfen. Damit würden bereits berechnete Pfade für ein bestimmtes Spielfeld nicht immer neu berechnet werden.

Geschrieben (bearbeitet)

Ich habe diese Fehler auch nicht mehr reproduzieren können... spricht man davon und voila:

System: Mac, 3 Personen 3 Teams, Bewegungsweite 3, Person 1&3 Oger aus dropdown liste (wird nicht übernommen) und es werden keine LP Schäden verrechnet. Selbe Einstellungen, PC, Vista, funktioniert.

Dafür hatte ich in einem anderen run folgendes Problem: 3 Kämpfer in 3 Teams Alles Standardkämpfer mit Bewegungsweite 3. Als die mittlere Person starb bekämpften sich die Ueberlebenden munter weiter, blieben aber auf ihren Positionen stehen und standen im Rösselsprung entfernt damit eigentlich ausserhalb der Reichweite eines Nahkampfangriffs.

Eines noch, zu deiner Berechung der Rechenzeiten: Man het eine Bewegungsweite von rund 20-30. Damit ist ein vernünftiggrosser Kampfplatz wohl auf einem Feld 100x100 anzusiedeln (den man in 3-5 Runden durquert) oder besser grösser, was wohl den Rechenaufwand deines Wegsuchealgorhytmus deutlich erhöht. Nicht?

es grüsst

Sayah el Atir al Azif ibn Mullah

Bearbeitet von sayah
Geschrieben

Alle meine Messungen lagen aber bei 10x10 Feldern immer unter 15ms. ;)

Nimm mal 100x100, das liegt näher an der Midgard-Realität. :D

 

Im Endausbau sollte das ganze also 1000 * 15ms + 1000 * 20ms = 35 Sekunden für einen Statistikkampf verbrauchen. (Werte richten sich für 10x10 Felder und ca. 5 Kämpfer in 2 Teams). Bei größeren Feldern und mehr Kämpfern steigt das ganze exponential.

Also O(N^2). Man lässt auch keine Anwendungen, die 35 s CPU-Zeit verbrauchen, als Webanwendung laufen. Wenn das jemand laufen lässt, der nicht genau weiß, was im Hintergrund abläuft, bricht er ab und drückt 'reload'...

 

Sicherheitstechnisch kann ich sagen, dass es ja alles von den Eingaben in der insert.php abhängt. Deswegen baue ich die Überprüfungen auch gerade Serverseitig und nicht Clientseitig auf.

Was man auf die Welt loslässt, das hat server side input sanitation. Sorry, ich denglische jetzt. Dein Programm sieht nur einen GET oder POST request, wer es aufruft, muss irgendwelche Eingabeseiten niemals gesehen haben. Das hat nichts mit Javascript oder nicht zu tun.

 

Verwende $_POST[] und $_GET[] für Parameter.

 

Verwende Methoden, um Datentypen festzuzimmern. Casts, Typumwandlungsmethoden in PHP,...traue keinem Input. ;)

 

So große Simulationen mit mehr als 10s Walltime haben als Webapp eigentlich nix verloren. :worried:

Geschrieben
PHP ist für eine Simulation (die dann auch noch x Mal gemittelt werden soll) ziemlich ungünstig.

 

Wenn Du etwas haben möchtest, was online verteilt werden kann und keine Rücksicht auf eine bestimmte Plattform nimmt, dann programmiere es in Java. Jeder nutzt dann seinen eigenen Rechner und kann selber bestimmen, wann er Pause macht...

 

Noch mehr Performance würde natürlich C/C++ liefern, aber da gibt ein Programm für eine bestimmte Plattform.

 

Wenn A* so viel Zeit braucht, dann könnte auch eine Hashfunktion helfen. Damit würden bereits berechnete Pfade für ein bestimmtes Spielfeld nicht immer neu berechnet werden.

 

Hallo,

 

PHP ist nunmal die einzige, die ich wirklich gut genug kann, um soetwas zu erstellen. ;) Außerdem mag ich Java nicht. Mir ist gerade aufgefallen, dass ich ja mit Zend dem ganzen noch einen ordentlichen Performanceboost geben kann - ich glaube das werde ich tun. Mal sehen wie es dann steht. Hashfunktion? Geht nicht! Jedes Ziel ist beweglich und ändert sich fast jede Runde... Bereits berechnete Pfade fallen sofort wieder weg. ;) Lass mich mal A* in zend auslagern, dann dürfte das ganze ein wenig schneller laufen.

 

Bamba

 

@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Geschrieben

PHP ist nunmal die einzige, die ich wirklich gut genug kann, um soetwas zu erstellen. ;)

Wenn man einen Hammer hat, sieht jedes Problem wie ein Nagel aus... :sigh:

 

Außerdem mag ich Java nicht.
Was sehr interessant ist, weil PHP seit Version 5 da viel übernommen hat. :lol:

 

Mir ist gerade aufgefallen, dass ich ja mit Zend dem ganzen noch einen ordentlichen Performanceboost geben kann - ich glaube das werde ich tun.

Nimm lieber HipHop - das haben die Facebook-Leute entwickelt und hält sie am Laufen. ;)

 

@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. :disturbed: Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Geschrieben
@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. :disturbed: Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Was passiert eigentlich, wenn zwei oder noch mehr Leute gleichzeitig etwas machen wollen? ;)

 

Bei jedem Aufruf erst einmal 30s Rechenzeit zu verbraten ist keine gute Idee für einen Server, der auch noch andere Aufgaben erfüllen soll.

 

Solwac

Geschrieben

So, V2.0.1 ist fertig (Fehlerbehebungen, neues Design, verbessertes Output, Forschrittsanzeige).

 

Ich hab die beiden Fehler bei der Wegberechnung, die sayah genannt hat korrigiert. Den Fehler, dass keine LP abgezogen werden, finde ich nicht und kann ich nicht rekonstruieren. Vllt. ist er jetzt weg? Ich weiß es nicht - bitte einfach weiter beobachten. Außerdem hab ich den Fehler mit den JavaScript Dropdownlisten (diese Dinger wo man einen Orc oder einen Oger übernehmen kann) behoben - sie müssten jetzt endlich wieder funktionieren. Das neue Design ist aus einem Oblivionfanpackage - man darf es überall verwenden. Wie obw schon sagte sind "Fortschrittsanzeigen bei Webanwendungen ... sportlich". Aber ich hab's trotzdem geschafft. So weiß man wenigstens wie lange der noch ca. braucht. ;) Was das verbesserte Output angeht, hab ich mal die Ausgabemeldungen ein wenig überarbeitet - müsste jetzt verständlicher sein.

 

Was ich noch nicht geschafft habe, aber als nächstes kommt ist endlich eine Serverseitige Überprüfung der Eingaben (und damit auch eine Überprüfung der X,Y und B Eingaben, die immer noch nicht überprüft werden), sowie die Möglichkeit, dass man einstellen kann wie Groß das Feld sein soll.

 

Wir haben nach wie vor das Problem, dass alles über einen Freeserver läuft, bei dem die Maximum Execution time extrem niedrig liegt. Der Berechnungsaufwand ist einfach zu hoch. Das führt dazu, dass man derzeit keine wirklich großen Kämpfe berechnen kann - es wird zu früh abgebrochen ... Daher hatte ich mich ja an Elsa gewandt. UPDATE: Mir fällt gerade auf, dass der Fortschrittsbalken auf dem Freeserver nicht läuft, was an HipHop bei Lima liegen dürfte. Irgendeiner der Programmierer hier eine Ahnung was man da machen könnte?

 

Hm gut, ich hab jetzt glaube ich alles erwähnt.

 

Bitte Fehler suchen ;)

Bamba

 

P.S: Die Subdomain http://www.midwar.de.vu von nic.de.vu hat gerade mal wieder Probleme (ja auch ein Freeservice...) daher solltet ihr über die richtige Adresse http://midwar.lima-city.de/ gehen.

Geschrieben
@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. :disturbed: Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Was passiert eigentlich, wenn zwei oder noch mehr Leute gleichzeitig etwas machen wollen? ;)

 

Bei jedem Aufruf erst einmal 30s Rechenzeit zu verbraten ist keine gute Idee für einen Server, der auch noch andere Aufgaben erfüllen soll.

 

Solwac

 

Das 2 Personen etwas gleichzeitig machen wird nie der Fall sein. Du weißt doch beim Programmieren gibt es keine Gleichzeitigkeit - nur eine Liste von Anweisungen, die abgearbeitet wird. ;)

Geschrieben
@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. :disturbed: Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Was passiert eigentlich, wenn zwei oder noch mehr Leute gleichzeitig etwas machen wollen? ;)

 

Bei jedem Aufruf erst einmal 30s Rechenzeit zu verbraten ist keine gute Idee für einen Server, der auch noch andere Aufgaben erfüllen soll.

 

Solwac

 

Das 2 Personen etwas gleichzeitig machen wird nie der Fall sein. Du weißt doch beim Programmieren gibt es keine Gleichzeitigkeit - nur eine Liste von Anweisungen, die abgearbeitet wird. ;)

Warum sollte nicht einer das Programm starten wollen, während der Server schon für Dich rechnet? ;)

 

Solwac

Geschrieben
So, V2.0.1 ist fertig (Fehlerbehebungen, neues Design, verbessertes Output, Forschrittsanzeige).

 

Ich hab die beiden Fehler bei der Wegberechnung, die sayah genannt hat korrigiert. Den Fehler, dass keine LP abgezogen werden, finde ich nicht und kann ich nicht rekonstruieren. Vllt. ist er jetzt weg? Ich weiß es nicht - bitte einfach weiter beobachten. Außerdem hab ich den Fehler mit den JavaScript Dropdownlisten (diese Dinger wo man einen Orc oder einen Oger übernehmen kann) behoben - sie müssten jetzt endlich wieder funktionieren.

Also folgende Beobachtung: Kampf 3 Kämpfer in 3 Teams, Kämpfer 1 Oger per dropdown Liste, B=3 Startposition 0/0 5/5 und 9/9

Mac mit Mac OS X 10.5.6 und Firefox/3.5.7: Dropdown liste funktioniert nicht, es werden keine LP Verluste verrechnet.

PC Windows Vista, Firefox 3.6: dropdown liste funktioniert, LP Schäden werden verrechnet.

Für mich heisst das, das Problem liegt in der Kombination von Mac und deiner Software. Vielleicht ist es spezifisch für meinen Mac, vielleicht sind alle (mit einer speziellen Konfiguration?) betroffen.

Problem bei der Bewegun: hast du die Kontrollbereiche schon umgesetzt? Bei der Simulation beim Mac, stehen sich nach der 1. Runde Kämpfer 1&2 in Nahkampfreichweite gegenüber (Kämpfer 2 greift an) trotzdem bewegt sich Kämpfer 1 in der nächsten Runde ungehindert auf Kämpfer 3 zu.

es grüsst

Sayah el Atir al Azif ibn Mullah

Geschrieben
@ obw: Nun das die User dann abbrechen kommt in der nächsten Version auch "weg": Ich füge einfach eine Fortschrittsanzeige hinzu. Dann werden sie sich an ein paar Sekunden warten halt gewöhnen müssen. :P Ja, ich arbeite gerade mal wieder an den Inputüberprüfungen ... ^^

Fortschrittsanzeigen bei Webanwendungen sind... sportlich. :disturbed: Sofern sie über eine einfache Textausgabe ("10%...20%..." inklusive flush()) hinausgehen.

Was passiert eigentlich, wenn zwei oder noch mehr Leute gleichzeitig etwas machen wollen? ;)

 

Bei jedem Aufruf erst einmal 30s Rechenzeit zu verbraten ist keine gute Idee für einen Server, der auch noch andere Aufgaben erfüllen soll.

 

Solwac

 

Das 2 Personen etwas gleichzeitig machen wird nie der Fall sein. Du weißt doch beim Programmieren gibt es keine Gleichzeitigkeit - nur eine Liste von Anweisungen, die abgearbeitet wird. ;)

Warum sollte nicht einer das Programm starten wollen, während der Server schon für Dich rechnet? ;)

 

Solwac

 

Ach jetzt verstehe ich was du meinst. :D Nun dann haben wir halt einen überlasteten Server. :lookaround:

 

Daran kann ich leider auch nichts ändern... ;)

Geschrieben
So, V2.0.1 ist fertig (Fehlerbehebungen, neues Design, verbessertes Output, Forschrittsanzeige).

 

Ich hab die beiden Fehler bei der Wegberechnung, die sayah genannt hat korrigiert. Den Fehler, dass keine LP abgezogen werden, finde ich nicht und kann ich nicht rekonstruieren. Vllt. ist er jetzt weg? Ich weiß es nicht - bitte einfach weiter beobachten. Außerdem hab ich den Fehler mit den JavaScript Dropdownlisten (diese Dinger wo man einen Orc oder einen Oger übernehmen kann) behoben - sie müssten jetzt endlich wieder funktionieren.

Also folgende Beobachtung: Kampf 3 Kämpfer in 3 Teams, Kämpfer 1 Oger per dropdown Liste, B=3 Startposition 0/0 5/5 und 9/9

Mac mit Mac OS X 10.5.6 und Firefox/3.5.7: Dropdown liste funktioniert nicht, es werden keine LP Verluste verrechnet.

PC Windows Vista, Firefox 3.6: dropdown liste funktioniert, LP Schäden werden verrechnet.

Für mich heisst das, das Problem liegt in der Kombination von Mac und deiner Software. Vielleicht ist es spezifisch für meinen Mac, vielleicht sind alle (mit einer speziellen Konfiguration?) betroffen.

Problem bei der Bewegun: hast du die Kontrollbereiche schon umgesetzt? Bei der Simulation beim Mac, stehen sich nach der 1. Runde Kämpfer 1&2 in Nahkampfreichweite gegenüber (Kämpfer 2 greift an) trotzdem bewegt sich Kämpfer 1 in der nächsten Runde ungehindert auf Kämpfer 3 zu.

es grüsst

Sayah el Atir al Azif ibn Mullah

 

Dann ist auch klar, warum ich das nicht reproduzieren konnte: Ich hab keinen Mac... :D Das sich Kämpfer 1 in der nächsten Runde auf Kämpfer 3 zubewegt, liegt daran, dass derzeit der Kämpfer, der in der nächsten Runde angegriffen werden soll, immer noch per Zufall ausgesucht wird. Also wurde da gerade eine 3 mit meinem Würfel gewürfelt und - schwupps - rennt Kämpfer 1 auf Kämpfer 3 zu. Kontrollbereiche sind noch nicht umgesetzt - kommt noch... Es dauert eben... ^^

 

Ich weiß leider nicht was ich wegen dem Mac da jetzt machen soll. Vllt komme ich irgendwie mal an einen Mac um das zu testen dann sehe ich weiter.

Geschrieben

Vielleicht liegt es nicht am Mac selbst, sondern an der Version von Firefox oder der Version der Software die die Werte ausliesst oder...

Was mich erstaunt: Das alles macht Sinn, würde das Programm von meinem Rechner ausgeführt, was aber, wenn ich dich richtig verstanden habe, nicht der Fall ist, womit meine Erklärung der Mac sei schuld zwar naheliegend, aber halt doch nicht wirklich logisch ist. :confused:

Uebrigens, ich denke es ist sinnvoll, dass du die Rechenarbeit vom Server nimmst und auf den Computer des Benutzers verlegst. Sonst findest du nie jemanden, der dir die Nutzung seines Servers erlaubt. Vorausgesetzt natürlich, das ist nicht sowieso schon der Fall.

es grüsst

Sayah el Atir al Azif ibn Mullah

Geschrieben
Vielleicht liegt es nicht am Mac selbst, sondern an der Version von Firefox oder der Version der Software die die Werte ausliesst oder...

Was mich erstaunt: Das alles macht Sinn, würde das Programm von meinem Rechner ausgeführt, was aber, wenn ich dich richtig verstanden habe, nicht der Fall ist, womit meine Erklärung der Mac sei schuld zwar naheliegend, aber halt doch nicht wirklich logisch ist. :confused:

Uebrigens, ich denke es ist sinnvoll, dass du die Rechenarbeit vom Server nimmst und auf den Computer des Benutzers verlegst. Sonst findest du nie jemanden, der dir die Nutzung seines Servers erlaubt. Vorausgesetzt natürlich, das ist nicht sowieso schon der Fall.

es grüsst

Sayah el Atir al Azif ibn Mullah

 

Das Problem ist, dass ich nur PHP gut genug kann, um darin den Kampfsimulator zu programmieren - und PHP ist eine Sprache für das Internet. Sie wird nur auf einem Server ausgeführt womit die Rechenleistung immer vom Server gestellt werden muss - klar könnte ich alles in JS auf den PC des Benutzers auslagern, aber das ist viel zu aufwendig und dämlich... Es bleibt also dabei, dass ich den dort auf dem Server lassen muss - altenativ kann ich den PHP Quellcode verteilen, dann muss man sich schnell XAMPP installieren und schon kann man den Code auf seinem PC ausführen.

Geschrieben (bearbeitet)

ich habe nun 2 Oger Gr 4 und 5 Orcs Gr 1 in Team 1 gegen 9 Menschen Gr 1, 5 Zwerge Gr. 1, 2 Elfen Gr1, einen Bären Gr5 und einen Wolf Gr2 kämpfen lassen.

In Runde 2 erhielt ich folgenden Fehler: Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 72 bytes) in /home/webpages/lima-city/midwar/html/V2.0.1/astar.php on line 235

Dazu habe ich noch das Problem, dass Oger 1 in der ersten Runde einen Gegner angreift, obwohl keiner in Reichweite steht. In der zweiten Runde läuft Oger 1 wie er sollte, die anderen Figuren verhalten sich (soweit ich sehe) normal. Ebenfalls wird für einige Figuren ein Zielfeld 10/1 berechnet, was (wenn ich es richtig verstanden habe) ausserhalb der erlaubten Werte ist... nicht?

es grüsst

Sayah el Atir al Azif ibn Mullah

ps. vielleicht musst du dir halt doch eine Programmiersprache beibringen die etwas besser rechnet.

Bearbeitet von sayah
Geschrieben
ich habe nun 2 Oger Gr 4 und 5 Orcs Gr 1 in Team 1 gegen 9 Menschen Gr 1, 5 Zwerge Gr. 1, 2 Elfen Gr1, einen Bären Gr5 und einen Wolf Gr2 kämpfen lassen.

In Runde 2 erhielt ich folgenden Fehler: Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 72 bytes) in /home/webpages/lima-city/midwar/html/V2.0.1/astar.php on line 235

Dazu habe ich noch das Problem, dass Oger 1 in der ersten Runde einen Gegner angreift, obwohl keiner in Reichweite steht. In der zweiten Runde läuft Oger 1 wie er sollte, die anderen Figuren verhalten sich (soweit ich sehe) normal. Ebenfalls wird für einige Figuren ein Zielfeld 10/1 berechnet, was (wenn ich es richtig verstanden habe) ausserhalb der erlaubten Werte ist... nicht?

es grüsst

Sayah el Atir al Azif ibn Mullah

 

schicke mir bitte per PN den ganzen ausgegebenen Text. Also lass den MidWar alles simulieren, drücke bei Windows STRG + a und kopiere mir alles in die PN, dann kann ich weitergucken.

 

Der Fehler mit der Allowed memory size heißt einfach, dass mein A* Algorithmus gerade mal wieder zuviel Speicher verbraucht, ich vermute daher, dass im Algorithmus Einträge immer noch nicht richtig gelöscht werden - derart exorbitante Werte sind jenseits von Gut, Böse und verständlich für so ein kleines Feld, irgendwo sind also leider immer noch Fehler. Wie mir scheint habe ich noch viel zutun. ;)

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...