Eintragsdetails ansehen
| ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
|---|---|---|---|---|---|
| 0000115 | Eressea | General | öffentlich | 2004-06-01 15:49 | 2004-06-27 11:28 |
| Reporter | ukuester | Bearbeitung durch | Enno | ||
| Priorität | normal | Schweregrad | kleinerer Fehler | Reproduzierbar | manchmal |
| Status | geschlossen | Lösung | erledigt | ||
| Zusammenfassung | 0000115: Hirntöter helfen ggf. Leuten | ||||
| Beschreibung | Hallo Enno, wir hatten uns schon drüber unterhalten. Hier ein schönes Beispiel aus Runde 382. Ich attackiere die Aquazonen und die Hirntöter helfen (sieht man schön an den "Attacke gegen"-Feldern).
Der Kampf wurde ausgelöst von Der Flammenorden (gLut). Heer 0: Der Flammenorden (gLut) Kämpft gegen: Heer 1(Aqu), Heer 2(Mon), Heer 3(-?-) Attacke gegen: Heer 1(Aqu)... in der 1 Kampflinie:
Heer 1: Aquazonen (aqua) Kämpft gegen: Heer 0(DF) Attacke gegen:... in der 3 Kampflinie:
Heer 2: Monster (0) Kämpft gegen: Heer 0(DF) Attacke gegen:... in der 1 Kampflinie:
Heer 3: Unbekannte Partei Kämpft gegen: Heer 0(DF) Attacke gegen:... in der 1 Kampflinie:
Einheiten vor der 1. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Einheiten vor der 2. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Einheiten vor der 3. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Einheiten vor der 4. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Einheiten vor der 5. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Einheiten vor der 6. Runde: Heer 0(DF): 1, Heer 1(Aqu): 0+0+1, Heer 2(Mon): 30, Heer 3(-?-): 50 Heer 0(DF): 0 Tote, 0 Geflohene, 1 Überlebende. Heer 1(Aqu): 0 Tote, 0 Geflohene, 1 Überlebende. Heer 2(Mon): 0 Tote, 0 Geflohene, 30 Überlebende. Heer 3(-?-): 0 Tote, 0 Geflohene, 50 Überlebende. | ||||
| Tags | Keine Tags zugeordnet. | ||||
| Partei | gLut | ||||
| Spiel | |||||
| Report | 382 | ||||
|
Ich weiß zwar nicht, ob das irgendwie relevant ist, aber ich habe das auch schon bei anderen Monstern beobachtet, dass die in Kämpfe eingreifen, die sie eigentlich gar nichts angehen. Ich dachte immer, das sei ein feature. |
|
|
Ja, ist es. Ich hatte Ulrich etwas falshes erzählt, im IRC. Di Sache ist so: Wenn eine Einheit attackiert wird, stellen sich alle diejenigen Einheiten vor sie, die Feinde der Feinde sind - Wenn also A gegen B kämpft, und B gegen die Monster, dann stellt sich die erste Reihe der Monster vor die zweite Reihe von A. Und Ulrich, das ist der grund, warum das bestimmen der eigenen Kampfreihe so komplex ist: Man muss halt wissen, wieviel die Feinde der Feinde jeweils in den Kampfreihen vor einem haben. Auch wenn ich pro Heer+Kampfstatus einen Zähler habe, so daß ich nicht jedesmal über alle Einheiten iterieren muss, dauert das trotzdem seine Zeit, da die Routine in einem Kampf wie dem von letzter Woche mehrere Milliarden mal aufgerufen wird. Ich habe an der Stelle dieses Wochenende allerdings nochmal ausgiebig optimiert. So merkt sich eine Einheit ab dieser Woche, auf wen sie letztes Mal eingeschlagen hat, und schaut zuerst, ob der noch lebt, und wenn ja, ob er noch erreichbar ist. Nur wenn das beides nicht der Fall ist, muss ich die Liste aller Einheiten in Reichweite erstellen (das ist der wirklich aufwendige Teil) und aus diesen eine neue aussuchen. |
|
|
Möchte gern noch einmal meinen Senf dazugeben :) |
|
|
Zu dem Kampf nochmal: Aber der einzige der Attackiert bin ich und ich hab ausschließlich auf Aquazonen-Attacke. Es gibt also nichts, was mich zum Feind der Monster macht. Dein A,B,Monster-Beispiel versteh ich schon, aber die Monster hätten eigentlich gar nicht im Kampf sein dürfen (es sei denn, das ist ein besonderes Feature), weil weder sie jemanden noch jemand sie attackiert hat. Der Fall liegt da ja etwas anders als in Deinem Beispiel. Zu der Performance: Ich will da keine Eulen nach Athen tragen oder über Dinge debattieren, von denen ich nix verstehe. Aber warum speicherst Du nicht einfach einmal welcher Kämpfer in welcher Kampfreihe steht, und - wichtig - die gegen welche feindlichen Kampfreihen kämpft und updatest das nur? Das ändert sich nur, wenn Einheiten fliehen oder sterben, weil dann ggf. aufgerückt wird. Im Falle unseres Kampfes also höchstens 180K mal (wobei das schon eine sehr grobe Abschätzung ist). Das heißt, Du müsstest die Prozedur doch höchstens einmal am Anfang und dann noch höchstens 180K-mal aufrufen, aber niemals ein paar Milliarden mal... (So und jetzt - versprochen - halt ich die Klappe zu diesem Thema). |
|
|
Der Grund, dass ich das nicht separat abspeichere, ist die Fehleranfälligkeit, insbesondere bei Zaubern. Da werden oft seltsame Dinge gemacht, und schon die paar momentan existierenen summierungen teilweise nicht richtig aktualisiert (das hat zu den Fehlern mit nicht aufrückenden Reihen geführt). Es ist eklig zu debuggen. Was den Kampf angeht: Warum die Monster da teilnehmen, ist mir wirklich schleierhaft, insofern werde ich den wohl doch nochmal debugggen. |
|
|
Ich habe gerade die Auswertung im Debugger getestet. Die Hirntöter greifen cqsk an, auch wenn das aus mir unerfindlichen Gründen nicht im Report steht. Ich schaue mal, warum. |
|
|
Verdammte Scheisse. Das liegt daran, dass die Monster auf die Aquazonen ein HELFE hatten. Das soll mir mal jemand erklären, wie es dazu gekommen ist... Und nicht nur die Aquazonen, eine ganze Reihen von Parteien betrifft das. Werde ich umgehend entfernen.
Wir helfen den Parteien Aquazonen (aqua) (Kämpfe, Bewache), Bulowas (mavo) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Urien Rakarth (bumm) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Die Roten Korsaren (roko) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Föderation freier Seestämme (ffss) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Cirque Nemesis (nmss) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Zirkaiden, Bezwinger der Wüste (zirk) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Zen Haikyu (zh) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Vereinigung von Tamyra (taha) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Xikkskh'krssk (tain) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Delenen (k0f) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Reich von Talquan (wwhx) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), OrcaMurai - Ordenskrieger des PadKu (orca) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), KanThai (thai) (Silber, Kämpfe, Gib, Bewache, Parteitarnung), Grafschaft Schwarzaar (saar) (Silber, Kämpfe, Gib, Bewache, Parteitarnung) und Kinder der Wölfe (u5hs) (Silber, Kämpfe, Gib, Bewache, Parteitarnung). |
|
|
Kann eigentlich nicht sein. cqks ist der Aquazone, den ich auch angegriffen habe. Da hätten ja sogar die Hirntöter und ich gemeinsam gegen den Aquazonen kämpfen müssen... |
|
|
Da muss noch ein Fehler sein. Ich hatte diese Woche (384) ein knappes halbes Dutzend Kämpfe, die bis zum letzten Detail wie der oben gepastete waren (beteiligte Parteien, Attacke-Felder etc.). Parteinummer ist nach wie vor gLut, eine beteiligte Einheit war z.B. gkwi. Das ist auch deshalb extrem lästig, weil ich nicht nur die Aquaspäher nicht wegbekomme, sondern gkwi z.B. das Äquivalent von 181 Lernwochen verloren hat gegen die Hirntöter, gegen die sie vermutlich fehlerhaft gekämpft hat und nun ein talentloser Dummy ist :-(. |
|
|
Ja, und ich weiss jetzt auch, wie es zu dem Problem kommen konnte. Im Code ist es gefixt, aber ich werde mal ein altes Backup ausbuddeln, um zu schauen, ob das Absicht war... |
|
|
Der Bug ist an allen mir erdenklichen Stellen gefixt, und sollte nicht mehr auftreten können. Einheiten, die an andere Parteien übergeben werden, vergessen alle ihre Befehle. |
|
| Änderungsdatum | Benutzername | Feld | Änderung |
|---|---|---|---|
| 2004-06-01 15:49 | ukuester | Neuer Eintrag | |
| 2004-06-01 15:49 | ukuester | Partei/Faction | => gLut |
| 2004-06-01 15:49 | ukuester | Runde/Turn | => 382 |
| 2004-06-02 16:53 | Schweiger | Notiz hinzugefügt: 0000250 | |
| 2004-06-03 09:38 | Enno | Status | neu => erledigt |
| 2004-06-03 09:38 | Enno | Lösung | offen => keine Änderung notwendig |
| 2004-06-03 09:38 | Enno | Bearbeitung durch | => Enno |
| 2004-06-03 09:38 | Enno | Notiz hinzugefügt: 0000251 | |
| 2004-06-03 12:33 | ukuester | Status | erledigt => Rückmeldung |
| 2004-06-03 12:33 | ukuester | Lösung | keine Änderung notwendig => wiedereröffnet |
| 2004-06-03 12:33 | ukuester | Notiz hinzugefügt: 0000253 | |
| 2004-06-03 12:43 | ukuester | Notiz hinzugefügt: 0000254 | |
| 2004-06-03 13:02 | Enno | Notiz hinzugefügt: 0000255 | |
| 2004-06-03 14:13 | Enno | Status | Rückmeldung => zugewiesen |
| 2004-06-03 23:40 | Enno | Notiz hinzugefügt: 0000256 | |
| 2004-06-04 00:09 | Enno | Status | zugewiesen => erledigt |
| 2004-06-04 00:09 | Enno | Lösung | wiedereröffnet => erledigt |
| 2004-06-04 00:09 | Enno | Notiz hinzugefügt: 0000257 | |
| 2004-06-04 00:10 | ukuester | Notiz hinzugefügt: 0000258 | |
| 2004-06-14 23:20 | ukuester | Status | erledigt => Rückmeldung |
| 2004-06-14 23:20 | ukuester | Lösung | erledigt => wiedereröffnet |
| 2004-06-14 23:20 | ukuester | Notiz hinzugefügt: 0000289 | |
| 2004-06-15 08:08 | Enno | Notiz hinzugefügt: 0000290 | |
| 2004-06-15 08:11 | Enno | Status | Rückmeldung => zugewiesen |
| 2004-06-18 07:57 | Enno | Status | zugewiesen => erledigt |
| 2004-06-18 07:57 | Enno | Lösung | wiedereröffnet => erledigt |
| 2004-06-18 07:57 | Enno | Notiz hinzugefügt: 0000300 | |
| 2004-06-27 11:28 | Enno | Status | erledigt => geschlossen |