Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2591 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-06-11 20:11 2019-06-11 20:11
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.20.0  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.21  
Partei: q4ik
Spiel: E2
Report: 1126
Zusammenfassung: Passworte von neuen Spielern stimmen nicht
Beschreibung:

Das Passwort im Report der neuen Spieler entspricht nicht dem, das in der Datenbank steht.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Ich habe das eben manuell repariert, aber vor dem nächsten Schwung neuer Spieler sollte das ordentlich gemacht werden.

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2590 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2019-06-09 17:26 2019-06-09 17:26
Reporter: K Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: turt
Spiel: E2
Report: 1126
Zusammenfassung: regelmäßige Unterhaltskosten von Tunnel, Damm und ggf. Karawanserei entfernen
Beschreibung:

Diese Gebäude sind primär dazu da den Bau von Straßen in unwirtlichen Regionen zu ermöglichen.
Bei aktuellem Regelstand ist es nur wärend des Straßenbaus nötig diese Gebäude zu besetzen und zu bezahlen.

Danach und damit für 99% ihr Existenz stehen sie leer und werden nicht bezahlt. Die Unterhaltskosten sind unnötiges Mikromanagement ohne Mehrwert.
Ich schlage vor die Unterhaltskosten zu streichen, ggf die Baukosten dafür anzuheben. Dies wäre zumindest übersichtlicher als die aktuelle Regelung mit Unterhaltskosten.

Die aktuelle Regelung ist schlimmstenfalls eine Falle für unerfahre Spieler die entweder die Kosten unnötig weiter zahlen oder davon grundsätzlich abgehalten werden diese Gebäude zu errichten.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Die Karawanserei hat noch eine Zusatzfunktion (erhöhtes Handelsvolumen), ob diese die Kosten rechtfertig kann man streiten.

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2587 [Eressea] Reportformat Trivial immer 2019-06-02 14:14 2019-06-02 14:50
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.20.0  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 1125
Zusammenfassung: Helfestati im NR ohne klare Trennung zur letzten Region
Beschreibung:

Die Helfestati hast du ans ende des NR verschoben, dort haben sie jedoch kleine klare Trennung zu letzten Region erhalten. So ne gestrichelte Linie würde sich da ganz gut machen:

Feuerwandgondel I (zbq7), Boot, (14/34), 32% beschädigt, Westküste; h9u9.

* Bauer (5ot5), 1 Nebelmeermensch, kämpft nicht, Talente: Schiffbau 4,
  Segeln 4, Unterhaltung 9, Wahrnehmung 3, hat: 325 Silber, "UNTERHALTE".

                           Aktueller Status

Wir helfen viele viele kleine Goblins. (sybr) (ALLES),
blablabal bal
bla ...

                         Liste aller Adressen
  • Der Phönix (7): dingd@dongs.de; Ceterum censeo U.F.O. delendam esse.
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2586 [Eressea] NACH/ROUTE schwerer Fehler nicht getestet 2019-05-19 11:33 2019-05-26 10:08
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.19.7  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.21  
Partei: quar
Spiel: E2
Report: 1123
Zusammenfassung: FOLGE EINHEIT umgeht Reichweitenbeschränkung
Beschreibung:

Hallo,

diese Runde (1123) hatten wir einen entscheidenden Kampf in der Region (d8oqd). Aus dem vorherigen Verhalten unseres Gegners haben wir geschlossen, dass er versuchen würde, nach dem Kampf aus der Region zu ziehen, also haben wir FOLGE EINHEIT auf eine seiner Einheiten gesetzt.

Beide Seiten haben die Region bewacht.

Der vorhergesagte Fall ist tatsächlich eingetreten und die verfolgte Einheit ist zu Pferd zwei Regionen weit gezogen. Unsere Armee ist hinterhergezogen, obwohl sie nicht zu Pferd mobil war. Die meisten konnten nicht einmal reiten und der Rest war bewusst zu Pferd überladen und nur zu Fuß mobil. Einige sind in der Zwischenregion wegen feindlicher Bewachung aufgehalten worden, was aber hier keine Rolle spielt. Ich vermute, dass FOLGE EINHEIT irgendwie die Reichweitenbeschränkung umgeht.

Ich muss zugeben, dass wir dadurch jetzt einen strategischen Vorteil haben. Aber da wir den Kampf mit 1861 zu 8 Toten klar für uns entscheiden konnten und die Flucht unseres Gegners eher eine halsbrecherische Flucht nach vorn ist, als eine ausgefuchste strategische Bewegung, glaube ich nicht, dass es mittelfristig einen Unterschied machen würde.

Beispieleinheit ohne Reiten-Talent: 5rtk
Beispieleinheit mit Reiten aber nur zu Fuß mobil: h3y7
Startregion der Bewegung (in der auch der Kampf stattgefunden hat): d8oqd
Zwischenregion: qzdp9n
Zielregion: 6zwi55

Beste Grüße,
Xeno

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008465)
Xolgrim   
2019-05-19 13:29   

@xenomorph Ich traue mich ja kaum zu fragen, aber wenn so grundlegende Dinge kaputt erscheinen, dann sind andere Fehler meist ersteinmal dei naheliegenderen. Eine Straße zwischen den Regionen gab es nicht?
Eine Zaubermeldung ist nirgends zu sehen? Magischer Pfad sorgt dafür, dass Regionen einige WOchen lang wie mit Straße zu bereisen sind, die Regionsmeldung sagt irgendetwas von trockenen Wegen und Brücken oder so in der Richtung, ist lange her.

(0008466)
xenomorph   
2019-05-19 13:57   

Natürlich kannst du fragen!
Es gibt keine Straßen und keine Meldungen, dass ein Magischer Pfad auf den Regionen liegt.

Wir selbst hatten in der Vorrude des Kampfes einen Magischen Pfad auf der Anfangs- und Endregion der beschriebenen Bewegung, aber nicht auf der Zwischenregion. Außerdem haben wir den Pfad nur auf Stufe 1 gezaubert. Er sollte also zum Zeitpunkt unserer Bewegung also nicht mehr aktiv gewesen sein.

(0008467)
Xolgrim   
2019-05-19 14:30   

Der Pfad verzaubert nicht nur eine Region, sondern eine Region und die 6 Regionen drum herum. Und wenn der Pro Stufe zwei Wochen hält, passt hier alles, ggf. erscheint die Zaubermeldung nur in den Regionen auf die er gezaubert worden ist und nicht in denen auf die er noch wirkt?
Mit der Info gehe ich noch mehr davon aus, dass Folge nicht das Problem ist und ihr Euch unwissentlich den Erfolg selber beschwert habt.

(0008468)
xenomorph   
2019-05-19 14:42   

Aha, ok. Ich dachte immer dass der Pfad pro Region Straßen in alle Richtungen macht, und daher auf jede Region der Bewegung einzeln gezaubert werden muss; und außerdem nur eine Woche pro Stufe andauert.

Wenn der Magische Pfad wirklich so funktioniert, wie du sagst, dann wäre in der Tat alles normal gelaufen. Aber es gab vergangene Runde (1122) in den Nachbarregionen keine Meldungen über den Zaubereffekt, nur in den Regionen, die direkt verzaubert wurden.

(0008469)
Xolgrim   
2019-05-19 16:03   

Mit der Zauberdauer bin ich mir nicht sicher, ist schon lange her. Dass der auf 7 Felder geht ist aber ganz sicher. Das wäre dann ggf. eher ein Anzeigefehler, weil man in den verzauberten Regionen drum herum nicht erkennen kann, dass ein Zauber auf ihnen liegt.

(0008474)
Enno   
2019-05-25 14:10   

Ich vermute stark, dass hier kein Fehler vorliegt. Der Zauber scheint mir die wahrscheinlichste Erklärung. Aber angucken kann ich es mir natürlich trotzdem mal, zur Sicherheit.

(0008475)
xenomorph   
2019-05-26 10:08   

Also ich habe das diese Woche an einer anderen Stelle noch mal ausprobiert. FOLGE EINHEIT hat so zu funktioniert, wie es soll: Die verfolgte Einheit ist zwei Regionen weit geritten, der Verfolger (der nicht reiten konnte), ist nur eine Region weit gefolgt und hat eine Meldung bekommen, dass er der Einheit nicht weiter folgen kann.

Es muss also tatsächlich am Zauber gelegen haben. Dann sollte man vielleicht beim Magischen Pfad dafür sorgen, dass auch in allen betroffenen Regionen eine Meldung erscheint?


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2581 [Eressea] General kleinerer Fehler nicht getestet 2019-04-27 21:21 2019-05-19 17:52
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.19.4  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.21  
Partei: 0
Spiel: E2
Report: 1120
Zusammenfassung: Fehlermeldungen im Backup
Beschreibung:

Wenn die Spieldaten auf dav.box.net geschoben werden, kriege ich gelegentlich eine Fehlermeldung:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre_DAV_Exception_Forbidden</s:exception>
  <s:message>Permission denied to overwrite node</s:message>
</d:error>

Da sollte mal untersucht werden, was das sein kann, ob es wirklich fehlschlägt, oder ob man da ein Retry machen muss.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008472)
Enno   
2019-05-19 17:17   

Nachdem es jetzt überhaupt nicht mehr geht, habe ich einen Bugreport beim box.com Suport gemacht.

https://community.box.com/t5/custom/page/page-id/BoxViewTicketDetail?ticket_id=1912179

Bis dahin muss ich wohl manuelles Backup machen, oder einen anderen Client finden? cadaver vielleicht?

(0008473)
Enno   
2019-05-19 17:52   

Argh!

https://community.box.com/t5/Archived-Box-Product-News/Deprecation-WebDAV-Support/ba-p/55684


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2483 [Eressea] Featurewunsch Unschönheit immer 2018-09-03 17:11 2019-05-19 17:12
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.19.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.21  
Partei: ate3
Spiel: E2
Report: 1090
Zusammenfassung: Erste Einheit hat KÄMPFE AGGRESSIV
Beschreibung:

Hallo,

die Starteinheit neuer Parteien steht auf KÄMPFE AGGESSIV. Da TEMP-Einheiten den Status der Muttereinheit erben, steht schnell die ganze Partei auf aggressiv, es sei denn man verhindert es aktiv in der ersten Runde.
Wäre KÄMPFE NICHT vielleicht ein besseres Default?

Grüße,
-Xeno

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008048)
Solthar   
2018-09-04 23:24   

Warum? In welchen Situationen wären alle Einheiten auf KÄMPFE NICHT besser als alle auf KÄMPFE AGGRESSIV und warum sind diese wichtiger?

(0008049)
Xolgrim   
2018-09-05 22:35   

Ich denke auch, jemand der die Kampfstati seiner Einheiten nicht anpasst, hat immer ein Problem, egal welchen default Status man den Einheiten verpasst. Kosmetisch fänd ich jetzt VORNE netter als AGGRESSIV aber dafür muss man jetzt nicht zwingend was ändern.

(0008050)
xenomorph   
2018-09-06 10:24   

Ich denke, dass irgendwann die meisten Einheiten eher auf KÄMPFE NICHT stehen werden, als auf AGGRESSIV. Außerdem finde ich es intuitiv einleuchtender, wenn ich meine Kämpfer aktiv in Kampfbereitschaft versetzen muss, statt dass irgendwann meine ganze Partei eine wilde Horde ist, die ich Zaum halten muss, mit Ausnahme der Kämpfer ;)

Aber ja, man muss sich um die Kampfstati kümern. Das hier ist letzten Endes nur eine Nebensächlichkeit, die mir aufgefallen ist. Momentan ist eines eine zusätzliche Sache, an die man in der ersten Runde denken muss.

(0008052)
Enno   
2018-09-08 10:31   

Wenn überhaupt, ist FLIEHE der beste Default für unbewaffnete Einheiten ohne Training.

(0008083)
xenomorph   
2018-09-10 23:04   

Ja, das stimmt natürlich.

(0008085)
Solthar   
2018-09-11 09:42   

Mit KÄMPFE FLIEHE sind vielleicht die Schäden bei Fehlbedienung weniger schlimm. Zumal Magellan meckert, wenn man mit Einheiten mit diesem Status bewachen oder attackieren will ...
Wenn man angegriffen wird, sind beide Fälle (alles auf AGGRESSIV oder alles auf FLIEHE) je nachdem ähnlich schlimm.

(0008463)
Enno   
2019-05-18 16:15   

Ich bin für FLIEHE als Default.

(0008471)
Enno   
2019-05-19 17:12   

Da ich vermutlich in zwei Wochen neue Parteien aussetze, ziehe ich das mal noch in das kommende Release hinein.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2584 [Eressea] ZAUBER kleinerer Fehler immer 2019-05-18 11:16 2019-05-19 10:16
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.7  
    Zielversion: 3.19.7  
Partei: turt
Spiel: E2
Report: 1122
Zusammenfassung: Vertraute regenerieren keine Aura
Beschreibung:

Die Vertrauten die eigene Zauber und Aura haben regenerieren keine Aura mehr.

Schritte zur Reproduktion:

Einheit: dtnx

Zusätzliche Informationen:

Dies ist schon mindestens seit AW 1109 (Anzeigebug der Vertrautenaura).

Angehängte Dateien:
Notiz
(0008459)
Enno   
2019-05-18 11:37   

Meine auch nicht: ek57 und wr6p

(0008460)
Enno   
2019-05-18 12:42   

Ich glaube, die Funktion benutzt is_mage, was explizit magic == M_GRAY ignoriert.

(0008461)
Enno   
2019-05-18 13:20   

Fix gemacht, sieht gut aus in meinem Report:

Spitzmaulnashorn (ek57) in Sidnin (0,2) regeneriert 3 Aura.
Breitmaulnashorn (wr6p) in Shagrin (-1,1) regeneriert 4 Aura.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2517 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-11-15 21:18 2019-05-19 10:15
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.8  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: ufo
Spiel: E2
Report: 1098
Zusammenfassung: Vertraute ohne eigene Zauber überarbeiten
Beschreibung:

Der Vertraute "Der Zonk" hat versucht, Viehheilung zu zaubern. Das hätte er mit der Aura seines Magiers Spintax (spin) machen sollen, der massenhaft Aura hatte, trotzdem gab es eine Fehlermeldung:

Der Zonk (zonk) in Betud (0,1): 'ZAUBERE Stufe 1 Viehheilung' - Für diesen Zauber fehlen noch 1 Aura.
Spintax The Green (spin) in Betud (0,1): 'LERNE Magie' - Die Lernkosten können nicht bezahlt werden.

Trotzdem der Zonk gezaubert hätte, hat Spintax außerdem noch versucht, einen langen Befehl auszuführen.

Ich möchte bei dieser Gelegenheit gerne an den "unbeliebten" Vertrauten (z.B. Luchs) ändern, dass sie den Magier an langen Befehlen hindern, und die Zauber des Magiers verteuern. Einziger Unterschied zum Zaubern "eigener" Sprüche sollte sein, dass die Materialien und Aura vom Zauberer abgezogen werden, nicht vom Vertrauten.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008212)
Enno   
2018-11-15 21:22   

Das sollte jetzt wie gewünscht funktioineren. Muss unbedingt angekündigt werden, und Anleitung angepasst.

(0008213)
Enno   
2018-11-15 21:23   

Ehe ich das für erledigt erkläre, sollte ich evtl. nochmal den Report 1098 testen.

(0008214)
Enno   
2018-11-15 21:37   

Mist. Fehler ist nicht behoben :-(

Der Zonk (zonk) in Betud (0,1): 'ZAUBERE Stufe 1 Viehheilung' - Für diesen Zauber fehlen noch 1 Aura.

(0008216)
Enno   
2018-11-16 16:39   

Das Problem ist in cancast, dort wird beim Vertrauten nach Materialien gesucht.

(0008217)
Enno   
2018-11-16 16:41   

Das passiert, weil der Luchs selber den Zauber Viehheilung hat, das also kein Magierzauber ist.

(0008218)
Enno   
2018-11-17 18:53   

Das Problem ist offenbar, dass der Vertraute ein Magiegebiet (GwyrrD) hat, und deshalb die Zauber der Partei besitzt.

(0008219)
Enno   
2018-11-17 19:16   

Es passiert in study_cmd!

Wenn der Vertraute Magie lernt, wird ein at_mage mit dem Magiegebiet der Partei erzeugt, obwohl es dort nicht gebraucht wird.
mage = create_mage(u, u->faction->magiegebiet);

Es wird allerdings weiter oben getestet, dass die maximale Anzahl Magier nicht überschritten wird, d.h. es hätte schlimmer sein können.

(0008220)
Enno   
2018-11-17 19:18   

Der Fehler tritt in diesem konkreten Fall im Report 1086 das erste Mal auf.

(0008221)
Enno   
2018-11-17 21:30   

Erfolg: Der Zonk (zonk) verdient in Betud (0,1) 50 Silber durch Zauberei.

(0008224)
Enno   
2018-11-17 22:41   

Das ist eine ziemlich große Änderung geworden, hat sicher noch Fehler. Mal gucken, wo es morgen crasht.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2451 [Eressea] ZAUBER kleinerer Fehler immer 2018-06-23 15:36 2019-05-19 10:15
Reporter: Pyanfar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: gnom
Spiel: E3
Report: 463
Zusammenfassung: zauberliste bei Vertrauten fehlerhaft
Beschreibung:

Meine Vertrauten, die über eigene Aura und Zauber verfügen, bekommen diese eigenen Zauber nicht angezeigt, sondern nur die Liste der Zauber, die der dazugehörige Magier beherrscht. Also meinem verständnis nach die Zauber, die ich über den Vertrautem, wie bei jedem Vertrauten, als "Fernzauber" zaubern kann.
Beispiel: wqpa

Soweit ich das sehe, erstreckt sich das über alle Magiegebiete und Spezialvertrauten-typen, soweit ich das aus den Auswertungen unserer Allianzmitglieder sehen kann.
Beispiel: cnit

Bei E4 dasselbe Problem (dort Einheit o212).

Schritte zur Reproduktion:

@zeige alles zauber gelöscht (einmal bei Vertrautem, einmal bei einem Magier), immer noch dieselbe Angabe.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008209)
Enno   
2018-11-14 20:22   

Ich plane, mir zum naechsten Release die Vertrauten mal genau anzugucken, ob man da was tun kann.

(0008230)
Enno   
2018-11-22 20:41   

Ist nicht von der Änderung in Bug 2517 betroffen, hat immer noch keine Zauber (und har Cerddor, wie seine Partei). Erwartet: kein Magiegebiet, und maximal drei eigene Zauber (Furcht, Schlaf, Flucht). Muss ich wohl weiter suchen.

(0008231)
Enno   
2018-11-22 20:46   

Im Datenfile steht schon Cerddor, das ist falsch, und der Vertraute hat keine eigenen Zauber. Das war also wahrscheinlich nicht der erste Report, in dem das passiert ist.

(0008232)
Enno   
2018-11-22 20:56   

Notiz: Der Zauberer ist "Solarika, Erforscherin stellarer Energien, 1338238", und der Vertraute erscheint im Report 438 zum ersten Mal.

(0008233)
Enno   
2018-11-22 21:20   

Offenbar wird in der Woche der Erstellung die Zauberliste nicht angelegt (unit_add_spell wird nie aufgerufen). Warum?

(0008234)
Enno   
2018-11-22 21:30   

Aha! equip_unit ist kaputt, das benutzt ipairs(spells), aber spells ist ein dict (name -> level), es muss also pairs(spells) heissen. Deshalb hat der Kerl keine Zauber. Er hat zwar Magie 1 als Skill, aber deshalb hat er noch immerkein at_mage, das wird dann in unit_add_spell erzeugt, und mit dem Magiegebiet der Partei erzeugt, was auch falsch ist.

Den Code kann ich reparieren, aber wie ich die existierenden Vertrauten alle repariert kriege, weiss ich noch nicht.

(0008235)
Enno   
2018-11-22 21:45   

Fehler im Code ist erledigt. Nach einer Neu-AW von Report 438 steht dort jetzt:

* Vertrauter von Solarika, Erforscherin stellarer Energien (soLa) (68dy),
  Hauptcharaktere (gnom), 1 Singdrache, flieht, Talente: Magie 2 (+2).
  Aura 0/4, Zauber: Grauen der Schlacht.

* Vertrauter von Lumalkin (Luma) (vfva), Hauptcharaktere (gnom), 1 Luchs,
  flieht, Talente: Magie 1 (+1).

Bei Luchsen ist es normal, dass die keine Aura oder eigene Zauber haben, bei Singdrachen nicht. Also alles genau wie erwartet. "Nur" noch eine Reparaturfunktion schreiben.

(0008236)
Enno   
2018-11-22 22:12   

Neuasuwertung Woche 463, mit einmailger Vertrauten-Reparatur:

* Drachine (wqpa), Hauptcharaktere (gnom), 1 Singdrache, flieht, Talente:
  Magie X, Ausdauer X, Waffenloser Kampf X. Aura 55/66, Zauber: Schlaf,
  Gesang der Angst, Grauen der Schlacht, "LERNE Ausdauer".

* Laborkatze (fmr9), Hauptcharaktere (gnom), 1 Luchs, flieht, Talente:
  Magie 6, Ausdauer 8, Waffenloser Kampf 2, "LERNE Ausdauer".

Drache hat seine Zauber bekommen, sieht gut aus. Luchs hat weder Ausdauer noch eigene Zauber, da ist auch so gewollt.

(0008237)
Enno   
2018-11-22 22:13   

Ich habe jetzt auch mehr Vertrauen in meinen ersten Bugfix, danke dafür.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2582 [Eressea] MACHE Trivial immer 2019-05-15 08:58 2019-05-18 16:09
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.19.6  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 1122
Zusammenfassung: Inhaltlich falsche Fehlermeldung bei Laenabbau in nicht bezahltem Bergwerk
Beschreibung:

Erzzwerg (yyv1) kann den Unterhalt von Black Hole (jzjc) nicht bezahlen.
Erzzwerg (yyv1) in Xxx (xx,xx): 'MACHE Laen' - Die Einheit steht nicht im benötigten Gebäude, Bergwerk.

Die Einheit steht in einem Bergwerk, hat den Unterhalt jedoch nicht bezahlen können. Daher ist die Fehlermeldung vom Text her nicht ganz korrekt. Ob das nun geändert werden muss, sei dahin gestellt.

Passend wäre beispielsweise
"'MACHE Laen' - Laen kann nur in funktionstüchtigen Bergwerken abgebaut werden."

Diese Fehlermeldung kann nur Laen und Adamantium betreffen, da alle anderen Rohstoffe auch ohne Gebäude abgebaut werden können.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008462)
Enno   
2019-05-18 16:09   

Alternativ: "'MACHE Laen' - Die Einheit steht in keinem funktionierenden Bergwerk.". Dann brauche ich den Namen des Rohstoffes nicht in der Nachricht, und grammatisch ist das der Singular des Gebäudes, das ist einfacher.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2543 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-01-06 12:41 2019-05-18 13:40
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.18.3  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.21  
Partei: enno
Spiel: E2
Report: 1106
Zusammenfassung: Lohn für Arbeit verscheiden in CR und NR / Zugvorlage
Beschreibung:

In der Region Onema steht eine Zitadelle, meine Partei sind Elfen (nicht Orks), erwarteter Arbeitslohn ist also 16.

Zugvorlage sagt 15:

REGION -4,-35 ; Onema
; ECheck Lohn 15

Report sagt 15:

Lohn für Arbeit: 15 Silber

CR sagt 16:

REGION -4 -35
1252510329;id
"Onema";Name
"Ebene";Terrain
16;Lohn
Schritte zur Reproduktion:

In der Region steht die Einheit onem. Sie arbeitet nicht, ich kann also nicht sagen, welcher Wert wirklich gilt.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008312)
Enno   
2019-01-06 13:06   

Das eine ist der Lohn für Bauern (16), das andere für Spieler (15, oder 13, wenn man Ork ist).
Das ist natürlich verwirrend, dass da nicht in beiden Reporten der selbe Wert steht.

(0008313)
Enno   
2019-01-06 14:44   

Oh, schlimmer, wenn in der Region Lohn für BAuern erhöht wird, dann kann der sogar 17 sein.
Dann steht im CR 17, im NR 15, und in der Vorlage auch 15.

(0008315)
Enno   
2019-01-07 23:02   

Gelernt: Segen der Erde wirkt nicht auf Einkommen durch ARBEITE, nur auf die Bauern.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2583 [Eressea] Featurewunsch Feature-Wunsch nicht getestet 2019-05-17 15:05 2019-05-17 16:19
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 1
Zusammenfassung: Katapulte durch 'Panzerbrechend' aufwerten
Beschreibung:

Wir hatten neulich eine Debatte im Discord über die guten alten Zeiten in denen Katapulte noch für mehr als Dekoration gut waren und unkomplizierter im gebrauch waren, da keine Rohstoffe verschossen wurden.

Der Lösungsvorschlag dazu war Katapultgeschosse Panzerbrechend zu machen wie Armbrüste (RS des Zieles halbiert).
Das macht sie nicht mehr zu der Massenvernichtungswaffe die sie früher einmal waren, gibt ihnen in Schlachten in denen normalerweise später die breite Masse mit 3-5 Rüstung durch die Gegend läuft etwas merh Potential.
Die Änderung würden Katapulte zudem sehr attraktiv gegen Drachen, Wyrme und Laen-Elite machen.

Davon ausgehend, dass jeder Schuss gegen einen Wyrm (RS8) trifft, gerechnet mit durchschnitsschaden:
(21,5-4)x6=105 (Panzerung halbiert)
(21,5-8)x6=81 (Wie bisher)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2542 [Eressea] Featurewunsch Feature-Wunsch nicht getestet 2019-01-05 15:24 2019-05-12 09:20
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.18.3  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 1105
Zusammenfassung: Neues Schiff "Arche"
Beschreibung:

In 0002118 wurde gewünscht, dass es größere Schiffe gibt. Mein ursprünglicher Plan, dass Schiffe beliebig erweiterbar sein sollten, ist zu kompliziert, und ich lasse mich lieber zu einem Kompromiss überreden, wo wir einfach ein großes Schiff machen, dass man beladen kann, ohne 100-Personen Einheiten aufteilen zu müssen.

  1. Neuer Schiffstyp Arche: Baukosten 2500 Holz, Segeltalent 300, Kapitänstalent 5, Reichweite 3
  2. Die Arche kann nicht durch Magie beschleunigt werden
  3. Meermenschen bekommen den Reichweite +1 Bonus nicht
  4. Die Arche kann wie alle anderen großen Schiffe nur in Ebenen und Wäldern anlegen.
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008314)
Xolgrim   
2019-01-07 18:24   
(Zuletzt bearbeitet: 2019-01-07 18:26)

Die Kapazität fehlt hier noch. Eine weitere Verzehnafchung macht das Schiff absolut unbrauchbar, da die effiziens erheblich von dem Gewicht/Runde verhältniss abhängig ist.

(0008320)
Enno   
2019-01-12 21:53   

Das Ziel war, dass man damit Einheiten transportieren kann, ohne sie aufteilen zu müssen, nicht, alle anderen Schiffe überflüssig zu machen. Verzehnfachung klingt für mich, als wenn es das Ziel erreicht.

(0008323)
Xolgrim   
2019-01-13 12:19   

Das ist in meinen Augen eher ein Lastkahn für Waren, mit halber MM-Kara Geschwindigkeit transportiert damit doch keiner Personen ...

(0008324)
Iridiana   
2019-01-13 12:58   

Naja, wenn es alle nötigen Ressourcen verzehnfacht und auch die Kapazität verzehnfacht, dann ist es bei gleicher Geschwindigkeit genauso gut wie die kleinen Schiffe.
Es hätte dann den Vorteil der leichteren Beladbarkeit (psychologisch) und den Nachteil , dass man es vielleicht halb voll herumfahren muss, wenn man nicht auch die zehnfache Menge an zu transportierenden Waren gerade vor Ort hat (logistisch/probabilistisch).
Ich würde das Ding schon bei Geschwindigkeit 5 niemals bauen, weil es zu ineffizient ist, erst ab 6 würde ich überhaupt überlegen.
Wenn die Geschwindigkeit fest 3 ist, würde ich bei der 20-fachen Kapazität langsam anfangen, über einen Bau nachzudenken.
Ansonsten sind die kleinen Schiffe klar besser und ich belade halt die.

(0008326)
Enno   
2019-01-13 16:21   

Mir schien der Leidensdruck der durch das Verladen von Truppen auf Karavellen entsteht, höher als von Euch hier argumentiert. Wenn das kein Problem ist, kann ich mir Flotten, Großschiffe, usw. aber auch sparen.

(0008327)
Iridiana   
2019-01-14 08:20   

Der Leidensdruck ist natürlich ein Problem. Ich würde ihn aber nicht gegen Ineffizienz tauschen.

(0008328)
Xolgrim   
2019-01-14 16:43   
(Zuletzt bearbeitet: 2019-01-14 17:14)

Vor einem Jahr waren noch schnellere Schiffe im Gespräch, da die Distanzen immer grösser werden. Bei mir sind es aktuell 132 Regionen von der Heimat bis zur am weitesten entfernten vollständig besiedelten Kolonie. Das sind 22 Wochen mit MM-Kara. Mit der halb so schnellen Arche würden Passagieren 5,5 Monate Lernzeit entgehen, das ist zu krass. Da ich alles händisch mache, brauche ich auch mal 3-4 Wochen um eine 100er Flotte zu beladen, selbst das lohnt aber ja dann noch eher. Wenn die Arche ein schlechteres Gewicht/Woche verhältnis haben soll als andere Schiffe, wären die Baukosten eventuell noch etwas, das man hinnehmen kann oder reichweite 4 (MM-Bonus möglich) bzw. Reichweite 5 (kein MM-Bonus).

Vor kurzem wolltest du Schiffe auch noch beliebig erweiterbar machen, warum jetzt die auf 10-Fache größte begrenzte Variante so viel schlechter sein soll, verstehe ich nicht.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2575 [Eressea] Gebäude kleinerer Fehler immer 2019-04-06 16:06 2019-05-11 20:53
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: d08a
Spiel: E2
Report: 1116
Zusammenfassung: Burgenbauer nutzen Talent nicht vollständig aus
Beschreibung:

Ich habe letzte Runde eine Einheit an einer Burg weiterbauen lassen. Die zu erweiternde Burg hatte die Größe 1135 und sollte um 200 Größenpunkte erweitert werden (expliziter Befehl MACHE 200 BURG e3t4). Der Bautrupp besteht aus 50 Personen T16 = 800 Talentpunkte. Damit konnte man früher eine Burg um 200 Größenpunkte erweitern. Das scheint jetzt nicht mehr möglich zu sein (seit wann kann ich nicht genau sagen, es fällt mir nur jetzt zufällig auf). Es wurden nur 115 Steine verbaut, genau so viele, wie bis zur nächsten Größenstufe der Burg notwendig waren. Da scheint der Bau dann gestoppt zu haben, denn die Burg hat jetzt eine Größe von 1250.

Schritte zur Reproduktion:

ID der Burg: e3t4
ID der Einheit: pcei
ID der Region: 3ab19r

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008417)
EON   
2019-04-07 20:37   

Ich kann den Bug bestätigen, es wird nur bis zur nächsten Größenstufe gebaut. Habe ich vor einiger Zeit schon mal beobachtet und diese Woche überprüft:

Partei gLod
Region Halbmondebene (z7mjez)
1116 : Wilde Burgenbauer (v2iL) baut für 26 an Halbmondfestung (haLb) weiter.
1117: Wilde Burgenbauer (v2iL) baut für 9 an Halbmondfestung (haLb) weiter.
Die Halbmondfeste hat diese Woche 1250 erreicht
Die Wilden Burgenbauer haben T13 und sind 8.
Sie haben noch 207 Steine

Einziger Unterschied zu Deinem Report: Ich habe keine explizite Menge angegeben, wie viel verbaut werden soll.

(0008422)
Xolgrim   
2019-04-13 08:03   

Scheint nicht immer der Fall zu sein:

1117: Burgenbauer (o4L7) baut für 2000 an Askarborga (jffg) weiter. (1000 T9er mit MACHE 7527 Burg jffg)
Die 250er Burg ist nun eine 2250er Festung und hat die Grenze der 1250er Festung somit übersprungen ohne 'hängen' zu bleiben.

(0008423)
Thoran   
2019-04-13 15:07   

Das würde dann ja genau passen: Die 1000 Burgenbauer haben 9000 Talentpunkte. Davon werden 4000 für den Ausbau bis zur Größe 1250 benötigt. Die restlichen 5000 Talentpunkte würden dann die Festung um weitere 1000 Größenpunkte erweitern. Insgesamt also die erwartete Erweiterung.
Stellt sich nur die Frage: Warum lautet der Befehl da MACHE 7527 BURG jffg?

(0008424)
Xolgrim   
2019-04-13 15:41   

@Thoran Weil ich immer 7777er Zitadellen baue. Ich habe aber auch Burgenbauer bei denen es wie bei Euch nur bis zur nächsten Ausbaustufe funktioniert hat, die habe ich hier nicht gepostet, weil zwei Beispiele sicherlich reichen und das Gegenbeispiel ggf. aufschlussreicher ist für Enno.

(0008457)
Enno   
2019-05-11 20:47   

Ich glaube ich hab's:

Archibalds Architekturbüro auf Ar-Chijakra (pcei) baut für 183 an MesLi
  (e3t4) weiter.

  MesLi (e3t4), Größe 1318, Festung; MesLi ist eine uralte Grenzbefestigung,
(0008458)
Enno   
2019-05-11 20:53   

Dieser Fehler trat offenbar immer dann auf, wenn eine neue Ausbaustufe begonnen war. Dann wurde die nur beendet, und keine neue angefangen. Fehler ist in nächster Test-AW voraussichtlich repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2550 [Eressea] Schiffe kleinerer Fehler nicht getestet 2019-01-20 19:36 2019-05-05 21:02
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: 2b4z
Spiel: E2
Report: 1040
Zusammenfassung: Sonnensegel ist nicht kompatibel mit Zaubern
Beschreibung:

Es gibt mehrere mögliche Zaubereffekte auf Schiffe (Wasserelementar, Sturmelementar, Sonnensegel, Meermenschenbonus), die nicht alle miteinander kombiniert werden können. Ich glaube nicht, dass das notwendig ist, und es wäre auch einfacher, wenn es da weniger Code gäbe.

Schritte zur Reproduktion:

Das betrifft vor allem die Treueschwur (4jwt).

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008445)
Enno   
2019-04-30 22:04   

Man kann offenbar alle Effekte zumindest theoretisch miteinander kombinieren, und die Funktion shipspeed respektiert die alle. Ich kann mich nicht erinnern, was das Problem bei der Treueschwur war - gibt es eventuell Zauber, die nicht gezaubert werden können, wenn schon ein anderer Effekt auf dem Schiff liegt? Da war etwas mit Sonnensegeln, glaube ich.

(0008446)
Enno   
2019-05-01 09:45   
(Zuletzt bearbeitet: 2019-05-01 09:45)
Treueschwur (4jwt), Trireme, 0% beschädigt; 2bko.

    Die Winde scheinen dieses Schiff besonders zu beguenstigen. (z3mc)

Runde 1120, Schiff 4jwt, Trireme (7) und Meermensch (+1) und Sonnensegel (+1) keine weitere magische Beschleunigung.

Erwartete Geschwindigkeit: 9, Tatsächlich: 8.

Ob in der Runde gezaubert wurde, und welche Zauber auf dem Schiff liegen, muss ich wohl selber rausfinden.

(0008447)
Enno   
2019-05-01 19:39   

In Runde 1117 passiert folgendes:

Graurock (dtcg) in Naha (167,-402): '@ZAUBERE STUFE 1 "Beschwöre einen
  Sturmelementar" 4jwt' - Auf Treueschwur (4jwt) liegt beeits ein Zauber.
(0008448)
Enno   
2019-05-01 20:11   

Ich glaube, ich hab's.

Graurock (dtcg) beschwört einen magischen Wind, der die Schiffe über das
  Wasser treibt.
(0008453)
Enno   
2019-05-05 20:23   

Hat in der Test-AW für 1121 nicht geklappt. Habe ich vergessen, das zu mergen? Siehe 1121-2b4z.nr

(0008454)
Enno   
2019-05-05 20:26   

Pull request zu machen vergessen.

(0008455)
Enno   
2019-05-05 21:02   

Neuer Test, Report von L12a: Die Treueschwur (4jwt) segelt von Ozean (-84,149) nach Ozean (-86,164). Sie durchquert dabei 15 Regionen (statt 8 im aktuellen Report). Sieht gut aus?


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2580 [Eressea] General kleinerer Fehler nicht getestet 2019-04-27 21:18 2019-05-05 20:23
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.6  
    Zielversion: 3.19.6  
Partei: enno
Spiel: E2
Report: 1120
Zusammenfassung: Muschelplateau verteilt keine Muscheln mehr?
Beschreibung:

Meine Einheit darr ist jetzt seit zwei Wochen ind er Region, und hat keine Muschel erhalten. Ich glaube, der Code ist kaputt (benutzt faction.get_key() falsch).

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008441)
Enno   
2019-04-28 18:31   

Wird gefixt in 3.19.6

(0008452)
Enno   
2019-05-05 20:23   

confirmed fixed.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2541 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2019-01-05 15:16 2019-05-04 12:03
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: 0
Spiel: E2
Report: 1105
Zusammenfassung: Parteiübernahmen vereinfachen
Beschreibung:

Wenn ein Spieler ausscheidet, dessen Partei für seine Allianz wichtig ist, und sich kein neuer Spieler findet, führt das oft zu ungewolltem Doppelspiel, weil es schwer oder unmöglich ist, die Partei zu übergeben. Das möchte ich ändern.

  1. Parteien können ganze Gruppen übergeben. Mit GIB zieL GRUPPE wird die gesamte Gruppe der befehlenden Einheit an die Partei der Einheit zieL übergeben (die sich wie bei GIB zieL EINHEIT in der selben Region befinden muss).
  2. Einheiten (und Gruppen) können an eine Partei anderer Rasse übergeben werden. Die Zielpartei kann dabei maximal eine Zweitrasse aufnehmen, die übergebende Partei kann ab dem Moment keine neuen Personen mehr rekrutieren.
  3. Menschen können zusätzlich zur Zweitrasse weiterhin Migranten aller Rassen aufnehmen (Ungeklärt: wie wird bei denen die Zweitrasse bestimmt?)
  4. Einheiten, die zur Zweitrasse der Partei gehören, unterliegen den selben Beschränkungen wie Migranten (z.B. können sie nicht rekrutieren).
  5. Für die Übergabe von Zweitrassen-Einheiten müssen beide beteiligten Parteien mindestens 200 Wochen alt sein.
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008407)
Enno   
2019-04-07 15:07   

Es gibt noch immer Unsicherheit zu herrschen, was mit Doppelspielern passieren soll. Bis das geklärt ist, mache ich hier nicht weiter.

(0008443)
Enno   
2019-04-30 21:12   

Lösung für eine Untermenge des Problemes: STIRB <passwort> [PARTEI <nummer>].

(0008449)
Enno   
2019-05-01 20:51   

Das ist so gut wie fertig implementiert, ich will nur noch ein paar Tests schreiben.

(0008450)
Enno   
2019-05-04 12:03   

Implementiert als STIRB <passwort> [ PARTEI <nummer> ]


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2577 [Eressea] MACHE kleinerer Fehler nicht getestet 2019-04-07 21:27 2019-04-30 18:58
Reporter: blutelfen Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.6  
    Zielversion: 3.19.6  
Partei: o6ot
Spiel: E2
Report: 1117
Zusammenfassung: Berg hat kaum Steine
Beschreibung:

Im Berg Buverbot neben meiner Heimatregion wollte ich Steine abbauen. Es gab aber auf T1 nur einen Stein zum Abbauen. Also habe ich meine Steinmetze auf T2 trainiert und abgebaut. Sie haben vier Steine erzeugt. Jetzt hat der Berg 5 Steine auf T3.

Das klingt nach einem extrem mageren Berg.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008419)
Enno   
2019-04-07 21:40   

So einen Bug habe ich doch gerade erst repariert? War das nur für Eisen?

(0008442)
Enno   
2019-04-30 18:56   

In der Tat, das hat nicht weit genug gereicht mit der letzten Änderung.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2578 [Eressea] KAUFE/VERKAUFE Unschönheit nicht getestet 2019-04-14 11:35 2019-04-26 20:50
Reporter: EON Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.19.4  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: haLb
Spiel: E2
Report: 1118
Zusammenfassung: Handel scheint verdientes Geld anderer Einheit direkt auszugeben
Beschreibung:

1117: Ein Unterhalter mit 40 Silber, ein Händler mit 5 Balsam. Für Balsam wird 20 geboten, Weihrauch kostet 4.
Unterhalter (T2) setzt unterhalte,
Händler setzt VERKAUFE ALLES Balsam und KAUFE 28 Weihrauch

1118: Ein Unterhalter mit 0 Silber (hat 40 verdient diese Woche) und ein Händler mit 20 Weihrauch und 80 Silber
Ich vermute, der Händler hat das Silber des Unterhalters für Weihrauch ausgegeben, dann 100 Silber durch Verkauf verdient und den Unterhalt der Beiden von seinen Einnahmen aus dem Verkauf des Balsams gezahlt

In der Befehlsreihenfolge laut https://wiki.eressea.de/index.php/Befehlsreihenfolge passieren Kauf, Verkauf und Unterhaltung quasi gleichzeitig, in Punkt 25.
In Punkt 26 steht aber erst Unterhalten, dann Kaufen, dann Verkaufen (Silberstückchenweise bzw. einzeln). Damit wäre es konsistent, aber gefährlich. Hätte ich nichts zum Verkaufen gehabt wären meine Einheiten verhungert, obwohl der Unterhalter ausreichend Einnahmen hat. Ich bin mir nicht sicher, ob das so gewollt ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008437)
Enno   
2019-04-26 06:26   

Warum sind diese Einheiten anonym? Es würde mir ungemein helfen, wenn du Einheitennummern angibst.

(0008440)
EON   
2019-04-26 20:50   

Sorry, habe ich vergessen.
Kapriolus Kaperkorn (beb0) ist der Unterhalter
Hanno Hebemann (9073) der Händler


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2523 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2018-11-25 15:12 2019-04-26 10:09
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.17.8  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 1102
Zusammenfassung: Fehlender Bezug bei Meldung im CR
Beschreibung:

Ein im Moment eher ästhetisches Problem: Es gibt Meldungen im Report, die sich auf nichts beziehen. Zum Beispiel übergibt eine Einheit alle Personen an die Bauern, taucht dadurch nicht mehr im Report auf, aber die Meldung bezieht sich darauf. Dadurch kann zum Beispiel Magellan sie keiner Region zuordnen und sie taucht gewissermaßen freischwebend auf. Aber auch im NR ist nicht nachzuvollziehen, wo die Übergabe stattfand.

Die beste Lösung, die mir derzeit einfällt, wäre ein zusätzlicher Regions-Tag, aber das bläst alle GIB- und andere Meldungen auf zu "In XYZ übergibt A 123 Dinge an B."

Schritte zur Reproduktion:
Zusätzliche Informationen:

MESSAGE 1043133872
1350316572;type
"Bauern (f9oz) übergibt 1000 Personen an die Bauern.";rendered
712403;unit
1000;amount

Angehängte Dateien:
Notiz
(0008438)
Enno   
2019-04-26 06:30   

Spricht etwas dagegen, einen eigenen neuen Meldungstyp für GIB PERSONEN zu machen, in dem die Region mit angegeben wird? Evtl. nur in dem Fall, dass die Einheit nach dem GIB keine Personen mehr hat?

Es gibt aber sicher noch andere Fälle, in denen die Einheit nicht im Report steht (wenn sie z.B. verhungert oder im Kampf gestorben ist). Das scheint mir ein generelleres Problem zu sein, das mit GIB erst einmal nichts zu tun hat.

(0008439)
Solthar   
2019-04-26 10:09   

Stimmt, das betrifft eigentlich jede Meldung mit einem unit-Parameter und ohne region-Parameter. Wobei manche wahrscheinlich wichtiger sind als andere. Mann könnte also jede solche Meldung suchen und den Meldungstext ändern. Man könnte es durch Logik abfangen und die Nachrichten irgendwie abwandeln. Das klingt alles nicht so gut.

Es werden doch in irgend einem Schritt im Code leere Einheiten entfernt. Könnte man da eine Meldung hinzufügen, etwa "Einheit (abc) in Region xyz löst sich auf ..."? Ist eigentlich sichergestellt, dass eine solche Region auch im Report ist, wenn dort keine Einheiten mehr sind?


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2560 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2019-02-10 14:47 2019-04-25 08:10
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ioen
Spiel: E2
Report: 1109
Zusammenfassung: Drachenodem zu stark?
Beschreibung:

Vorweg: Eventuell sollte man die Kategorie ATTACKIERE mal in KAMPF umbenennen.

Ich habe die Vermutung, das Drachenodem gerade etwas überskaliert. Letzte Woche gab es einen unfreiwilligen Kampf gegen einen Drachen, dass das nicht wirklich gut ausgeht, war absehbar. Aber das der Drache 60 Personen, davon 50 gut gerüstet und mit passabler Ausdauer, mit einem Zauber weg friert, kommt für mich zumindest doch sehr unerwartet. So einen angriff hätte ich ggf. von einem Wyrm erwartet, nicht jedoch von einem normalen Drachen.

                                Kämpfe

            In Cuana'Frohr (-4,-36) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Monster (ii).

Heer 0: Monster (ii)
Kämpft gegen: Heer 1(ioen)
Hilft: Heer 0(ii)
Attacke gegen: Heer 1(ioen)
... in der 1. Kampflinie:

  • Karrotur der Wissende (tLyf), 1 Drache, aggressiv, bewacht die Region.

Heer 1: Iøniger (ioen)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(ioen)
... in der 1. Kampflinie:

  • Weltentorer (sm7m), 10 Nebelmeermenschen, vorne, hat: 20 Silber.
  • Seesoldaten (ve2f), 50 Nebelmeermenschen, vorne, Talente: Pferdedressur 1,
    Reiten 2, Hiebwaffen 14, Segeln 4, Unterhaltung 3, Ausdauer 8, hat: 44795
    Silber, 50 Plattenpanzer, 50 Schilde, 50 Schwerter.

Einheiten vor der 1. Runde:
Heer 0(ii): 1, Heer 1(ioen): 60
Karrotur der Wissende (tLyf) zaubert Eisiger Drachenodem: 60 Krieger wurden
getötet.

Einheiten nach dem Kampf:
Heer 0(ii): 1
Weltentorer (sm7m) erzielte 1 Treffer und tötete 0 Gegner.
Seesoldaten (ve2f) erzielte 37 Treffer und tötete 0 Gegner.
Weltentorer (sm7m) verlor 10 Personen.
Seesoldaten (ve2f) verlor 50 Personen.
Heer 0(ii): 0 Tote, 0 Geflohene, 1 Überlebende.
Heer 1(ioen): 60 Tote, 0 Geflohene, 0 Überlebende.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008431)
Enno   
2019-04-24 12:41   

Im Code steht zum erwarteten Schaden:
/* Jungdrache 3->54, Drache 6->216, Wyrm 12->864 Treffer */

(0008433)
Enno   
2019-04-24 15:26   

Das ist kein Bug, so viel Schaden machen die Viecher (seit immer schon). Man muss die in der Taktikrunde besiegen, fürchte ich.

(0008434)
defaitist   
2019-04-24 19:41   

Und warum plötzlich so viel höhere Verluste. Habe wohl schon mehr als 2000 Wyrme erschlagen, auch Taktikrunden verloren, aber die Verletzungen waren gering. Irgendwas hat sich verändert, vielleicht Magieresistenz als Mulitplikator des Schadens? Habe nur mitbekommen, dass mit der Magieresistenz in letzter Zeit einige Probleme aufgetreten sind.

(0008435)
Xolgrim   
2019-04-25 08:02   
(Zuletzt bearbeitet: 2019-04-25 08:03)

Die Berechnung der Magieresistenz lief falsch, dies ist von einigen Monaten repariert worden. Ein Drache macht Drache 6 bis 216 Treffer zu 11-26 HP schaden pro Odem.
Deine Trolle haben 141HP und eine Magieresistenz von 10%, also wird der Schaden um 10% reduziert. Deine 50 Trollsoldaten haben also 50x141=7050HP und sie wurden von 4 Drachenodems getroffen welche zwischen 6x11=66 und 216x26=5616 Schaden verursachen, im Schnitt eher 114x18,5=2109

2109x0,9=1898x4=7592

Ich meine mal irgendwo gelesen zu haben, dass höhere Talente auch leicht höhere Magieresistenz bringen, finde dazu aber gerade nichts (war vermutlich im Code). Das würde erklären, warum deine Trolle "so wenig" abbekommen haben. Die Zeiten in denen man Wyrme mit 100 guten Soldaten erlegen kann ohne Verluste hin zu nehmen scheinen vorbei zu sein.

(0008436)
Enno   
2019-04-25 08:10   

Was Xolgrim sagt. Die Magieresistenz war kaputt, und die Biester waren weniger angriffslustig, deshalb hat es lange Zeit so wenig Ärger mit Drachen gegeben. Inzwischen funktionieren sie "wie gewollt", und eine weitere Änderung ist fürs erste nicht notwendig.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2568 [Eressea] Monster schwerer Fehler nicht getestet 2019-03-30 14:23 2019-04-24 15:24
Reporter: defaitist Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.1  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: styx
Spiel: E2
Report: 1115
Zusammenfassung: Drachenodem absurd mächtig
Beschreibung:

Bei den letzten Bugfixes ist offensichtlich Drachenodem um eine Zehnerpotenz zu hoch beim Schaden angesetzt worden. Anders kann ich mir diese Kampfergebnisse nicht erklären:

         In Hochebene von Throal (1,0) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Trollische Räte-Union (styx).

Heer 0: Trollische Räte-Union (styx)
Kämpft gegen: Heer 1(ii)
Hilft: Heer 0(styx)
Attacke gegen: Heer 1(ii)
... in der 1. Kampflinie:

  • Ausbildungskorps Barsaive (kovi), 50 Trolle, vorne, Talente: Hiebwaffen
    32, Steuereintreiben 5, Ausdauer 14, hat: 22 Kriegsäxte, 28 Bihänder, 50
    Plattenpanzer, 50 Schilde.

Heer 1: Monster (ii)
Kämpft gegen: Heer 0(styx)
Hilft: Heer 1(ii)
... in der 1. Kampflinie:

  • Kurtorgul, der Mächtige (6i9k), 2 Drachen, aggressiv.

Einheiten vor der 1. Runde:
Heer 0(styx): 50, Heer 1(ii): 2
Kurtorgul, der Mächtige (6i9k) zaubert Eisiger Drachenodem: 0 Krieger wurden
getötet.
Kurtorgul, der Mächtige (6i9k) zaubert Eisiger Drachenodem: 0 Krieger wurden
getötet.

Einheiten vor der 2. Runde:
Heer 0(styx): 50, Heer 1(ii): 2
Kurtorgul, der Mächtige (6i9k) zaubert Eisiger Drachenodem: 3 Krieger wurden
getötet.
Kurtorgul, der Mächtige (6i9k) zaubert Eisiger Drachenodem: 1 Krieger wurde
getötet.

Einheiten nach dem Kampf:
Heer 0(styx): 46
Ausbildungskorps Barsaive (kovi) erzielte 63 Treffer und tötete 2 Gegner.
Ausbildungskorps Barsaive (kovi) verlor 4 Personen, 46 überlebten.
Kurtorgul, der Mächtige (6i9k) verlor 2 Personen.
Heer 0(styx): 4 Tote, 0 Geflohene, 46 Überlebende.
Heer 1(ii): 2 Tote, 0 Geflohene, 0 Überlebende.
Ausbildungskorps Barsaive (kovi) erbeutet 3 Drachenblut.
Ausbildungskorps Barsaive (kovi) erbeutet 2 Drachenköpfe.
Ausbildungskorps Barsaive (kovi) erbeutet 18 Silber.

Schritte zur Reproduktion:

Banale Drachen, gerade mal 4 Odemattacken. Aber 4 Tote, das ist auch mit Klauenattacken nicht zu erklären. Die Trolle haben Magieresistenz, die Drachen bekommen keinen Nahkampfbonus da hoffnungslos im Kampftalent unterlegen und haben immerhin 111 Lebenspunkte pro Troll.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008393)
Xolgrim   
2019-03-31 09:59   

@defaitist Nur am Rande, deine Trolle haben 141HP. Die Formel berechnet den HP BONUS durch Ausdauer nicht die gesamt HP der Einheit. Die Basismenge muss da noch drauf gerechnet werden.

(0008432)
Enno   
2019-04-24 15:24   

Duplikat von Bug 2560


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2579 [Eressea] Schiffe kleinerer Fehler nicht getestet 2019-04-23 20:51 2019-04-24 12:38
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: evt
Spiel: E2
Report: 1119
Zusammenfassung: Schiff verschwunden
Beschreibung:

Schiff mit Einheiten nach Auswertung Nr. 1119 einfach verschwunden. Keine Meldung über Kämpfe, Hunger u. dgl.

Schritte zur Reproduktion:

Schiff = Fischkutter (zsL6)
Insassen = Käptn (xc8h) und Segler (49qp)

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008428)
Enno   
2019-04-24 12:27   

Wie üblich bei solchen Bugs, ist das nicht einfach reproduzierbar, weil abhängig von einem zufälligen Event :-(

(0008429)
Enno   
2019-04-24 12:33   
(Zuletzt bearbeitet: 2019-04-24 12:34)

Zitat aus Deinem Report:

                   In Ozean (-33,51) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Monster (ii).

Heer 0: Monster (ii)
Kämpft gegen: Heer 1(evt)
Hilft: Heer 0(ii)
Attacke gegen: Heer 1(evt)
... in der 1. Kampflinie:
  - Seeschlange (dsgs), 1 Seeschlange, aggressiv, hat: Silberbeutel.

Heer 1: Elfen von Thalassa (evt)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(evt)
... in der 4. Kampflinie:
  * Segler (49qp), 6 Lichtelfen, flieht, Talente: Reiten 1, Segeln 4, hat: 24
    Silber.
  * Käptn (xc8h), 1 Lichtelf, flieht, Talente: Segeln 6, hat: 2710 Silber.

Einheiten vor der 1. Runde:
Heer  0(ii): 1, Heer  1(evt): 0+0+0+7
Seeschlange (dsgs) zaubert Feuriger Drachenodem: 5 Krieger wurden getötet.

...

Segler (49qp) verlor 6 Personen.
Käptn (xc8h) verlor 1 Personen.
(0008430)
Enno   
2019-04-24 12:38   

Kein Bug. Seeschlange greift Karavelle an, Mannschaft stirbt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1982 [Eressea] General schwerer Fehler nicht getestet 2013-11-30 17:24 2019-04-07 21:37
Reporter: Pyanfar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: hani
Spiel: E2
Report: 853
Zusammenfassung: Illaun-Klonzauber defekt?
Beschreibung:

Meine Magierin "Namenloser Geist (udnh)" zauberte in 605 mit "Seelenkopie" einen Klon von sich, Einheit "Klon von Namenloser Geist (udnh) (htg)", der danach mit NUMMER EINHEIT zu Einheit "clon" wurde.

Diese woche starb meine Magierin melodramatisch-tragisch im Gefecht mit einem Wyrm (Präkampfzauer-fail...), und es passierte: nix.

Nun beschreibt die Zauberbeschreibung eine gewisse Chance, das "die Seele zu schwach ist, den Klon zu erreichen"...
Ich habe allerdings keinerlei Meldung zum Thema Seelenwanderung in Klon, kein Ereignis, nix unter Magie - und der Klon ist auch noch da.

Entweder der Zauber ist buggy, oder aber bei einem Fehlschlag fehlt ne Fehlermeldung und eine Entfernung des Klones...

Ich vermute leider bug und bitte um Reinkarnation :)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005048)
Pyanfar   
2013-11-30 17:26   

Nachtrag, grad gesehen: beim Zaubern von Seelenkopie taucht im Regionsreport noch "Interner Fehler: Meldung 'sp_clone_effet' nicht definiert." auf.

(0005264)
CTD   
2014-07-23 16:45   

Mit dem Bug hast du recht, so wie es ausieht fehlt der gesamte Code welcher beim Tod des Magieres ausgelöst werden sollte. Da gibt es einfach nix, nicht mal eine Abfrage ob da vieleicht ein Magier gestorben ist. Ich muss das noch mal genauer untersuchen, aber im Moment sind Clone wohl sinnlos.

(0005392)
Pyanfar   
2014-09-29 02:54   

So am Rande erwähnt gibt es den Zauber auch bei E3 (und E4?), wo er dann recht sicher auch nix bringt. Die zugehörige Luxusressource ist damit, soweit ich weiß, auch überflüssig, da sie anscheinend nur für diesen Zauber benötigt wird... den ich nicht abgeschafft, sondern funktionsfähig möchte ;)

(0005393)
CTD   
2014-09-29 08:58   

Es steht auf meiner ToDo Liste, zusammen mit vielen anderen Magieproblemen, aber es steht nicht ganz oben.
Luxusgüter haben eh das Problem das es sie in rauhen Mengen gibt, im Moment sind sie in E3 eigentlich überflüssig, den einzigen Beitrag zum Spiel den sie bringen ist der logistische Aufwand sie von den Märkten zu den Magiern zu bekommen.

(0005540)
Enno   
2014-12-13 22:07   

Die Einheit cLon heisst in Runde 853 "entphaste Erscheinung", und sie hat ein at_clonemage Attribut, das auf "Namenloser Geist" zeigt.
Der Magier seinerseits hat ein at_clone Attribut, das auf die Einheit cLon verweist, insofern hat das auch geklappt. So weit scheint das also noch alles seine Richtigkeit zu haben. Wie CTD schon sagt, fehlt hier lediglich die Logik, die einen toten Magier mit seinem Clon austauscht.
Ich nehme an, dass das erwartete Verhalten ist, dass der Magier mit dem Clon getauscht wird (Clon kriegt Talente, und alle Gegenstände gehen verloren)? Sollte der Clon genau die Talentwerte des toten Magiers haben, oder die Werte zum Zeitpunkt, als die Kopie angelegt wurde? Letzteres wäre nach aktuellem Stand schwierig.

(0005650)
Pyanfar   
2015-01-23 22:29   

Ich weiß nicht, ob es möglich ist, die Talente zum Zeitpunkt des Klonvorganges "inaktiv" beim Klon zu speichern, ich bin nicht so der C-Kenner...

Es wäre natürlich weniger mächtig, bringt aber dann die Versuchung mit sich, den Klon ab und zu upzudaten, indem der alte auf einen lecken Boot auf hoher See ausgesetzt wird.

Die aktuellen Werte zu übernehmen, ist sicherlich einfacher. Falls du das entschärfen willst, gibt es halt -1 auf Magie oder gleich alles.

Der Klon sollte auch noch die Rasse auf die des Magiers wechseln, und Besitzrechte auf Vertrauten und evt. noch aktive Verzauberungen müsste er auch erben - vielleicht reicht es ja, die ID des Magiers an den Klon zu geben?
Oder den Mechanismus nutzen, der bei NUMMER EINHEIT greift (ich habs noch nicht probiert, aber da geht der Vertraute ja auch nicht flöten. Oder?).

(0005653)
CTD   
2015-01-26 09:37   

Also logisch wäre wenn er:
Die Rasse und alle Talent des Magiers im Moment de Todes erbt (Die Seele der Magiers reist nach dem Tod in den Clone). Auch max Aura.
Alle Verzauberungen und Ausrüstung sind natürlich verloren. Ein Vertrauter sollte auch übernommen werden, muss aber nicht unbedingt.

(0005654)
CTD   
2015-01-26 09:42   

Man kann der Einfachheit halber intern auch einfach den Clon umbringen, HP auf 1 und Aura auf 0 setzen (Ist halt doch recht anstengend, so ein Seelenreise), und den Magier in die Region (das Gebäude) des Clones verschieben.
Als Chance das es nicht klappt würde ich nur so 2-5% Einbauen, der Spruch ist so teuer das er normalerweise auch Erfolg haben sollte. Am besten ganz weg lassen, das reduziert den Frustfaktor.

(0005656)
mideg   
2015-02-01 09:56   

Wenn man den Magier in die Region des Klons teleportiert, sollte aber noch seine Ausrüstung als Kampfbeute verbleiben, nicht nur gelöscht werden.

(0005830)
Xolgrim   
2015-05-17 11:00   

scheiße alles weg was ich geschrieben hatte... also nochmal...
Ich wäre auch dafür die Sterbewahrscheinlichkeit auf 0% zu setzen, das ist zu frustanfällig. Im gegenzug wäre ich allerdings dafür, das ein 100%iger Clon eher die Ausnahme ist und mit gewisser wahrscheinlichkeit leichte bis starke abzüge auf alle Talente erfolgen (20 Permanente Aura und 5 Drachenköpfe finde ich nicht (mehr) so super viel). Als Beispiel aus der Hüfte geschossen:

15% 100%iger Clon
50% geringe Verluste (-2 auf alle Talente)
25% höhere Verluste (-4 auf alle Talente)
7% starke verluste (-6 auf alle Talente)
3% Sabbernder Idiot (-10 auf alle Talente)

Selbst im letzteren Fall dürfte von den meisten Magiern noch genug (Magie) Talent übrig bleiben, dass sich der Spruch trotzdem gelohnt hat.

(0006425)
Pyanfar   
2015-12-17 22:34   

Hmm, ich weiß, wir Illauner sind eine Minderheit, aber... werden die Klone noch irgendwann repariert?
Ansonsten würde ich langsam mal den 5. Magier neu anlernen :)

(0006426)
CTD   
2015-12-18 11:14   

Ja, irgendwann werden wir den mal reparieren, aber es wird wohl eher nicht pasieren das irgendwelche vor X Runden gestorbenen Magier dann wieder "auferstehen". Die Werte von denen sind ja schon lange nicht mehr in der Datenbank.
Im Bestfall wird der Clon an irgendeinen anderen existierenden Magier "gehängt" im worst case einfach gelöscht. Ein fix dürfte vor allem dafür sorgen das nach dem fix erschaffene Clone wie beschrieben arbeiten.

Mach also am besten einen neuen Magier.

Was die wirkung an geht, so wäre das für E3/E4 nicht so toll, denn da ist zum einen das Talent (deutlich) kleiner 20 und zum anderen ist es ein Lebensprojekt 5 Drachenköpfe zu bekommen. Da sollte man vieleicht die Kosten auf 1-2 senken.
10% - 100% Clone
10% - Alles -1
20% - Alles -2
20% - Alles -3
20% - Alles -4
10% - Alles -5
10% - Alles -6
(Ich denke -4 tut auch schon weh, auch in E2)

(0006427)
Pyanfar   
2015-12-18 15:00   

Tja, als Ersatz für die fehlenden Datenbank-werte könnte ich gerne die Original-verpackte AW aus der Woche, in der der Magier starb, zur Verfügung stellen... :)
Als ich die Klonzauber gezaubert habe, war meine Partei bei weitem nicht so reich, das war damals schon ein Investment für mich, ist ja immerhin 7 REALjahre her.

(0008358)
Enno   
2019-02-10 19:18   

Vielleicht kriege ich es zeitlich noch hin, den Zauber zum nächsten Release zu löschen. Dann zaubert den wenigstens niemand, und verliert die ganze Aura.

(0008415)
Enno   
2019-04-07 17:55   

Ich habe mal als ersten Schritt den Zauber aus dem Spiel geschmissen (und aus allen Zauberlisten ).

(0008416)
Enno   
2019-04-07 17:57   

Der Spruch kostet 20 permanente Aura und ein WdL. Wäre schön, wenn ich die Klione auflösen könnte, und den Magiern zumindest Aura und Trank zurück geben.

(0008418)
Enno   
2019-04-07 21:37   

Ich löse dann jetzt auch die existierenden Klone auf und gebe den Magiern, soweit sie noch existieren, ihre Aura zurück.

Klon von Rincewind (7jk9) (zu9u) in Zemur (0,0): 1 Klon verschwand über Nacht.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2576 [Eressea] General kleinerer Fehler N/A 2019-04-07 09:31 2019-04-07 16:05
Reporter: Waldgoettin Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: onyx
Spiel: E2
Report: 1117
Zusammenfassung: Weltenportal Aster -4,-9 funktioniert nicht
Beschreibung:

Alle Einheiten, die das Weltentor in 1116 betreten haben, stehen weiterhin im Portal. Sämtliche Einheiten sind direkt vom Schiff in das Portal gelaufen.

Partei onyx, Region Aster -4,-9, Weltentor (eso0)

Die Einheiten der Partei goLd sind ebenfalls noch im Weltentor.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008401)
Enno   
2019-04-07 09:51   

Mir ist prinzipiell immer geholfen, wenn ein Bugreport eine Einheitennummer enthält.

(0008402)
Waldgoettin   
2019-04-07 09:59   

z.B. Einheit Primus Celur (zm3f)

(0008403)
Enno   
2019-04-07 10:11   

Mist. Wieder einmal nicht einfach reproduzierbar: teleported Primus Celur (zm3f) to Schattenlande (27,-96).

(0008404)
Waldgoettin   
2019-04-07 13:02   

Vielleicht liegt es am gleichzeiten Verlassen des Schiffs und Betreten des Portals?

Ich habe noch mehr Einheiten, die da ankommen werden, wo man das checken könnte.

(0008409)
Enno   
2019-04-07 15:33   

Nein, dann wäre das doch reproduzierbar.

Aber ich hatte gerade Glück, mein zusätzliches Logging hat etwas gefunden, in einer anderen Auswertung (1103):
ERROR: No target for tunnel Weltentor (zL6y) [tnnL]
ERROR: Did not teleport Kundschafter (oh7) from tunnel Weltentor (zL6y)

(0008411)
Waldgoettin   
2019-04-07 15:45   

Was mir komisch vorkommt in der Testauswertung, da sind jetzt alle, die diese Runde durch das das Tor sind, auch die Goldsucher, in Schattenlande gelandet. Xol hatte gesagt, für jede Einheit wird gewürfelt, wo sie rauskommt. Das sieht jetzt in dem Fall nicht so aus?

(0008412)
Enno   
2019-04-07 15:50   

Haha, ich glaube ich hab's! Bei der Auswahl der Zielregion wird eine Zufallszahl gewürfelt, mit der die Liste der Regionen indiziert wird. Die Zahl liegt in [0, n) für n Regionen, aber ein Lua table wird ab 1 indiziert, nicht ab 0.

(0008413)
Enno   
2019-04-07 16:05   

Ja, das war's. Ausserdem ist table.maxn wohl unnötig, weg damit.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2530 [Eressea] General Unschönheit nicht getestet 2018-12-04 18:52 2019-04-07 15:36
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.2  
Produkt-Build: Lösung: nicht reproduzierbar  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.4  
    Zielversion: 3.20.0  
Partei: 777
Spiel: E2
Report: 1103
Zusammenfassung: Falsche Zeilenumbrüche in Fehlermeldungen
Beschreibung:

Einige Fehlermeldungen haben zu frühe Zeilenumbrüche. Beispiele:

Wache von IdS (kfo4): 'Nah SO SO
' - Dieser Befehl ist unbekannt.

Garde von Dagus (kio) in Dagus (-1,3): 'NACH SO O
' - Die Einheit trägt
zuviel Gewicht, um sich bewegen zu können.

Als Gegebeispiel eine Fehlermeldung bei welcher der Zeilenumbruch noch korrekt dargestellt wird, auch aus dieser Woche:

Reker (os1) in Ritus (2,-1): 'LERNE Ausdauer' - Die Einheit kann keine
weiteren langen Befehle ausführen.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008410)
Enno   
2019-04-07 15:36   

Kann ich mit dem aktuellen Code nicht reproduzieren, weder im NR noch im CR ist ein zusätzlicher Umbruch.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2570 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-03-31 23:02 2019-04-07 15:25
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: grau
Spiel: E2
Report: 1116
Zusammenfassung: Trennung (gestrichelte Linie) zwischen Report Header und erster Region fehlt im *.nr
Beschreibung:

Betrifft nur die Testauswertung!

Durch das Verschieben des Blocks mit den HELFE Status fehlt der ersten Region eine Abtrennung vom Header des Reports.
Bei mir geht es zum Beispiel nach den Zauberbeschreibungen (erzeugt mit ZEIGE ALLE ZAUBER) direkt mit der Region Bacafafus los. Normalerweise kommt vor jeder Region eine gestrichelte Linie, die hilft den .nr leichter zu lesen.

Schritte zur Reproduktion:
Zusätzliche Informationen:

"3.20.0-f9b2c4079";Build

Angehängte Dateien:
Notiz
(0008408)
Enno   
2019-04-07 15:25   

Es gibt jetzt wieder vor jeder Region eine Linie. Neu ist, dass hinter der Linie eine Leerzeile steht, auch wenn in der Region keine Einheiten sind (das war bisher uneinheitlich).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2571 [Eressea] Reportformat Unschönheit nicht getestet 2019-03-31 23:06 2019-04-07 15:05
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: unlösbar  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.20.0  
Partei: grau
Spiel: E2
Report: 1116
Zusammenfassung: Leerzeichen zwischen Almosenmeldung und Regionsbotschaft fehlt
Beschreibung:

Zwischen der Meldung der Almosen und einer eventuellen Regionsbotschaft fehlt eine Leerzeile:

Auszug aus dem *.nr:

Graugnome (grau) gibt ein Almosen von 10 Silber an Die Trolllegion (troL).
Eine Botschaft von Nuri Walterm (yu7m): 'Werte Völker Gacecirs. Ich würde
mich freuen, wenn Ihr die Hallen der Freunschaft betretet und Euch ein
Plätzchen an einem der wärmenden Feuer sucht. Es sollte für jeden Platz
sein oder wir bauen einfach weiter, bis jeder einen Platz hat!'

Schritte zur Reproduktion:

Einheit yu7m hat @Botschaft

Zusätzliche Informationen:

Die Leerzeile fehlt auch in der Testauswertung.

Angehängte Dateien:
Notiz
(0008405)
Enno   
2019-04-07 15:04   

Die Almosen sind eine Regionsbotschaft, deshalb gibt es da keine Trennung. Reporttechnisch besteht da kein Unterschied,

(0008406)
Enno   
2019-04-07 15:05   

Das war früher nicht so, und da werde ich wohl auch in Zukunft nichts ändern.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2574 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2019-04-03 18:29 2019-04-05 20:52
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.4  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.0  
    Zielversion: 3.20.0  
Partei: 0
Spiel: E2
Report: 1116
Zusammenfassung: Die freundlicheren Hungerregeln von E3 in E2 anwenden.
Beschreibung:

Hunger verhindert keine langen Befehle, macht weniger Schaden.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008397)
Enno   
2019-04-03 18:29   

In config.json:

    &quot;hunger.long&quot;: false,
    &quot;hunger.damage&quot;: &quot;1d9+9&quot;,
(0008398)
Xolgrim   
2019-04-05 20:48   

Zitat aus den E3 Regeln "Die erhöhte Talentverscheibung (bei Dämonen) nach unten wirkt auch bei herkömmlichem Hungern." Das sollten wir dann auch in E2 aktivieren, wenn wir die Hungerregel übernehmen.

(0008399)
Enno   
2019-04-05 20:51   
(Zuletzt bearbeitet: 2019-04-05 20:52)

Das ist primär eine Folge der anderen Dämonenregel gewesen: " Dämonen, die keine Bauern zu fressen bekommen, erleiden keinen Schaden mehr, die Talentverschiebung erfolgt jedoch mit höherer Wahrscheinlichkeit und nur noch nach unten." - an den Dämonen etwas zu ändern, war nicht Teil meines Plans.

(0008400)
Enno   
2019-04-05 20:52   

Sprich mich lieber im Chat an, als fertige Tickets wieder auf zu machen, die keinen Bug haben ;-)


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2573 [Eressea] ATTACKIERE Unschönheit immer 2019-04-01 14:47 2019-04-01 14:47
Reporter: Bruck Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: keine BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 9999
Zusammenfassung: Adamantiumrüstung ohne Magieresistenz
Beschreibung:

Beim updaten der Kriegstabellen im Wiki mit Hilfe von des Codes in Github sind mir ein paar Dinge aufgefallen.
Wenn ich den Code richtig verstehe und nicht auf die falsche Stelle schaue gibt die Adamantiumaxt Magieresistenz, Adamantiumrüstung aber nicht. Ich denke mal gewollt ist es wie bei Laen, das beides 30% schutz bietet. (Adamantiumschild gibt es nicht zum vergleichen.

Schritte zur Reproduktion:

https://github.com/eressea/server/blob/136e093c961ad751910099e65fdfcaaeec807cb6/res/adamantium.xml

Zeile 31:
Ist Zustand: <armor ac="7" penalty="0.1"/>
Soll Zustand:<armor ac="7" penalty="0.1" magres="0.3"/>

Zusätzliche Informationen:

Pflichtfelder unten sind doof, wenn man keine E2 Partei mehr hat. ;)

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2572 [Eressea] ATTACKIERE kleinerer Fehler immer 2019-04-01 14:35 2019-04-01 14:35
Reporter: Bruck Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: hdbs
Spiel: E3
Report: 498
Zusammenfassung: E3 Gobos können vermutlich Bihänder benutzen.
Beschreibung:

Beim updaten der Kriegstabellen im Wiki mit Hilfe von des Codes in Github sind mir ein paar Dinge aufgefallen.
Wenn ich den Code richtig verstehe und nicht auf die falsche Stelle schaue können Gobos in E3 danach Bihänder benutzten. Sollten sie nach den Regeln aber nicht.

Schritte zur Reproduktion:

https://github.com/eressea/server/blob/136e093c961ad751910099e65fdfcaaeec807cb6/res/e3a/weapons.xml

Zeile 115:
Ist Zustand: <item weight="200" score="30">
Soll Zustand: <item weight="200" score="30" deny="goblin">

Und Zeile 8, aber ich glaube Rostige Bihänder gibt es gar nicht. :
Ist Zustand: <item weight="200" score="20">
Soll Zustand: <item weight="200" score="20" deny="goblin">

Zusätzliche Informationen:

Hängt vielleicht mit:
https://bugs.eressea.de/view.php?id=2434
zusammen. Die Änderungen am 29.04.2018 in Github hab ich aber nicht genug verstanden um das richtig zu verstehen. Ich glaube, das deny="goblin fehlte einfach schon davor.

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2569 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2019-03-31 10:16 2019-03-31 21:32
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.4  
    Zielversion: 3.19.4  
Partei: orkx
Spiel: E2
Report: 1116
Zusammenfassung: Rosthauch macht negative Waffen
Beschreibung:

Der Magier "Gul-" der Partei "Clan des schwarzen Sumpfes" zaubert diese Woche in einem Kampf Rostregen, was dazu führt, dass ich diese Fehler im Logfile habe: "serious accounting error. number of items is -1"

Da gehen Waffen kaputt, und die Zieleinheit hat plötzlich -1 Äxte.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008396)
Enno   
2019-03-31 21:21   

Das Problem trat auf, wenn die Einheit während des Kampfes schon Waffen verloren hat. Warum das passiert, ist vielleicht auch eine gute Frage.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2567 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-03-24 15:21 2019-03-25 20:22
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.3  
    Zielversion: 3.19.3  
Partei: Ljpg
Spiel: E2
Report: 1115
Zusammenfassung: Anzeige Helfe-Status im NR ist kaputt.
Beschreibung:

Es gibt da Parteien in der Liste, denen kein Status gesetzt ist, und das Ende der Liste witrd doppelt ausgegeben.

Wir helfen Clan des schwarzen Sumpfes (orkx) (ALLES), Scylithe (scLt) (ALLES),
Vermächtniss der Tiefe (Lotd) (ALLES), Erben des Barlagosch (6w47) (SILBER,
GIB, BEWACHEN), Makaros Stämme - Makaro's tribes (scaL) (GIB), Piraten vom
Kap Agulhas (3uk8) (), Jarltum von Nynork (cdh) (), Kgr. Nabban (yp2h) () und
Alberichs besoffene Zwerge (m4hb) (ALLES).
Alberichs besoffene Zwerge (m4hb) (ALLES)., UNITED NATIVES (L) (GIB), Yetis
von Lapsung (i40n) (), Les Maîtres Du Temps (enno) (GIB), Tetis

Schritte zur Reproduktion:

Fehler ist schon im letzten Release gewesen, hat sicher mit der neuen struct allies zu tun, nicht mit der neuen Position am Ende des Reports.

Zusätzliche Informationen:

Bei den Gruppen der Partei ist es auch kaputt.

Angehängte Dateien:
Notiz
(0008385)
Enno   
2019-03-24 15:38   

So wie es aussieht, sind da die HELFE-Stati in den Daten kaputt (Status 0), schon seit einer Weile. In Runde 1100 sind sie noch korrekt gewesen, der Fehler muss danach passiert sein. Wann war das Release noch gleich?

(0008386)
Enno   
2019-03-24 15:42   

In 1105 hat Troicent bereits eine Gruppe mit kaputtem Status für hoLo.

(0008387)
Enno   
2019-03-24 15:47   

Aha! In den Daten von 1102 ist noch alles gut, aber beim Schreiben nach der AW ist ein Fehler drin.

(0008388)
Enno   
2019-03-24 15:59   

Ja, in der Woche geht der Status der Partei Scylithe (1322705) kaputt. Investigating ...

(0008392)
Enno   
2019-03-25 20:22   

Datenfile wird nächste Woche repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2549 [Eressea] REKRUTIERE kleinerer Fehler nicht getestet 2019-01-20 11:47 2019-02-25 19:25
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.1  
    Zielversion: 3.19  
Partei: wiki
Spiel: E2
Report: 1108
Zusammenfassung: Beförderung fehlgeschlagen
Beschreibung:

In der Anleitung steht: Sowohl für die Zahl der möglichen Helden als auch für die Kosten von Befördere werden die Personenzahlen nach dem rekrutieren in der aktuellen Wochen herangezogen.

Das habe ich diese Woche auf die Probe gestellt. Ich habe 10 Personen rekrutiert, um von 47 auf 57 zu kommen, und eine von ihnen befördert. Das hat nicht geklappt.

Schritte zur Reproduktion:

Fehlermeldung im NR: Odin Allfather (pj4j) in Akershus (-2,2): 'BEFÖRDERE' - Die Partei hat bereits 0 von 0 Helden.

Zusätzliche Informationen:

Statistik im Report sagt:

    Deine Partei hat 57 Personen in 32 von maximal 2500 Einheiten.
     Deine Partei hat 0 Helden und kann maximal 1 Helden ernennen.
Angehängte Dateien:
Notiz
(0008335)
Enno   
2019-01-20 16:21   
(Zuletzt bearbeitet: 2019-02-02 17:44)

Ich glaube, das Problem hier ist der Scheduler, der die Befehlsreihenfolge implementiert. Da steht, dass BEFOERDERE (promote_cmd) nach REKRUTIERE (economics) kommt, aber so wie es dort steht, wird das so gemacht:

foreach region r:
    rekrutiere neue personen in r
    foreach unit u in r:
        befoerdere u?

das heisst, die Einheit wird bereits befoerdert, ehe in allen Regionen die REKRUTIERE Befehle fertig ausgefuehrt wurden, wir haben erst 54 Personen zu dem Zeitpunkt, und kriegen den Fehler.

(0008336)
Enno   
2019-01-20 16:53   

Bug gefixt, Test geschrieben.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2535 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-08 21:40 2019-02-25 19:25
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.1  
    Zielversion: 3.19  
Partei: enno
Spiel: E2
Report: 1104
Zusammenfassung: Leerzeichen in Anzeige Kampfzauber
Beschreibung:

Da ist ein Leerzeichen vor der Stufe:

Kampfzauber: Wolfsgeheul( 4), Hagel( 4), Heilung( 4)

Einheit teLe (und sicher alle anderen Magier)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2531 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-04 21:30 2019-02-25 19:25
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.1  
    Zielversion: 3.19  
Partei: 0
Spiel: E2
Report: 1103
Zusammenfassung: Kein Passwort in der Vorlage
Beschreibung:

Es ist mal wieder ein Spieler verwirrt, weil in der Vorlage das Passwort nicht drin steht. Da muss sich etwas machen lassen, zumindest beim ersten Zug. Evtl. muss es nur noch offensichtlicher sein, dass man das eintragen muss, z.B. mit einem Kommentar in der Vorlage, der das sagt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008268)
Enno   
2018-12-06 19:34   
(Zuletzt bearbeitet: 2018-12-06 19:35)

Neuer Plan: Solange ein Spieler keine Befehle eingeschickt hat, generiere ich jede Woche ein neues Passwort für die Partei, dass dann mit einer changepasswd Meldung im Report gezeigt wird, wo es auch Magellan sehen sollte. Das erfordert ein etwas kompliziertes Refactoring, aber ich sehe immerhin schon, wie das gemacht werden muss. In die Vorlage kommt ein Kommentar mit einer Warnung, dass man es aus dem Report kopieren muss.

(0008319)
Enno   
2019-01-12 21:28   

Ab dem nächsten Release werden neue Parteien jede Woche ein neues Passwort kriegen, das in der Zugvorlage steht. Alle anderen Parteien kriegen eine Nachricht in die Vorlage, die sie warnt, dass sie das selber tun müssen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2521 [Eressea] General kleinerer Fehler nicht getestet 2018-11-22 11:20 2019-02-25 19:25
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.8  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.1  
    Zielversion: 3.19  
Partei: 1wpy
Spiel: E2
Report: 1101
Zusammenfassung: Fehlende Übersetzung: ghost
Beschreibung:

Eine Einheit wird bei mir als "ghost" angezeigt:

  • Botschafter (7g2y), Monster (ii), 1 ghost, hat: 4 Zauberbeutel.

Sowohl im NR als auch im CR.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008246)
Enno   
2018-12-01 11:23   

Die Einheit ist ein Template, d.h. sie hat ein at_racename Attribut. Der String "ghost" kommt im Code nirgends vor. Woher kommen diese Dinger? Ich nehme an, ein Zauber oder sowas?

(0008247)
Enno   
2018-12-01 11:25   

Oh yes! Das ist save_special_items, wo eine Monstereinheit erzeugt wird, um Spezialitems (hier: Zauberbeutel) nicht verfallen zu lassen. Das sollte eh anders.

(0008248)
Enno   
2018-12-01 11:39   

Oh, es ist noch komplizierter. Geister sind eine echte Rasse (Vertraute), und haben eine Übersetzung, aber bufunit übersetzt den String aus at_racename nicht.

(0008249)
Enno   
2018-12-01 12:19   

Besser:

  • Botschafter (7g2y), Monster (ii), 1 Geist, hat: 4 Zauberbeutel.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2504 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-10-27 21:53 2019-02-25 19:25
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.8  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.19.1  
    Zielversion: 3.19  
Partei: ovis
Spiel: E2
Report: 1098
Zusammenfassung: Spieler gesteuerte Untote lernen
Beschreibung:

Im Gegensatz zu früher ist es Spieleruntoten (durch Zauber erhoben) möglich zu lernen. Auch wenn ich für eine begrüßenswerte Aufwertung der sonst eher nutzlosen Einheiten halte fürchte ich einen Bug.

Schritte zur Reproduktion:

Panzerschildkröte (fbv7)

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008360)
Enno   
2019-02-16 17:09   

Sollten sie auf jeden Fall nicht könne:

&lt;race name=&quot;skeleton&quot;  [...] learn=&quot;no&quot; />

Und das RCF_LEARN Bit ist auch nicht gesetzt, wird aber nur von der Monster-KI getestet, nicht von study_cmd.

(0008361)
Enno   
2019-02-16 17:54   

Oh nein ... Es gibt da zwei konkurrierende Flags: RCF_NOLEARN und RCF_LEARN. Tolle Namen, Enno.

(0008362)
Enno   
2019-02-16 17:55   

RCF_NOLEARN wird nirgendwo gesetzt, das ist ein Vestigium, glaube ich.

(0008363)
Enno   
2019-02-16 20:16   

Das war unerwartet kompliziert zu reparieren.

(0008364)
Enno   
2019-02-16 20:33   

Unerwartetes Problem: Es gibt keine Partei ovis. Die Einheit gehört der Partei turt?

(0008365)
Enno   
2019-02-16 20:34   

Im Report con turt kann ich aber den Bugfix verifizieren:

Panzerschildkröte (fbv7) in Lozasur (4,0): 'LERNE Wahrnehmung' - Skelette können nichts lernen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2118 [Eressea] Featurewunsch Feature-Wunsch N/A 2015-07-20 17:56 2019-02-16 20:39
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.5  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 937
Zusammenfassung: Große und schnellere Schiffe (Schiffe 2.0)
Beschreibung:

Hi Enno, damit ich dich nicht immer per Skype nerven musst und Du es trotzdem nicht aus den Augen verlierst. Bitte Schiffe 2.0 implementieren.

https://docs.google.com/spreadsheets/d/1unloIu_Fa8pYdpXS4drdDk0iVg2VZAwzqiVwAEPeZ80/edit#gid=0

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0006034)
Enno   
2015-08-07 13:32   

Feature ist implementiert, aber noch nicht für irgendwelche Schiffe aktiviert:
https://github.com/eressea/server/pull/270

Nächster Schritt wird sein, das für das Drachenschiff zu konfigurieren.

(0006189)
Enno   
2015-11-02 16:04   

das design muss noch einmal überdacht werden, das schaffen wir vor 3.7 nicht mehr

(0007675)
Enno   
2017-12-16 11:53   

Hier hat sich einiges getan. Der aktuelle Plan sieht vor, dass Karavelle und Trireme vergrößert werden können, wie Zitadellen. Der Code dafür wird kompliziert, und hoffentlich bis März fertig. Am besten fange ich damit an, mal ein Inventar vom bestehenden Code zu machen, und die noch zu machende Arbeit aufzulisten.

(0007721)
Enno   
2017-12-27 21:56   

Ich habe gerade die Beschleunigung der Drachenschiffe implementiert wie in eressea-dev vorgeschlagen, d.h.:

Talent
Kapitän Reichweite
2 5
6 6
18 7
54 8
162 9

(0007795)
Enno   
2018-01-28 16:21   

Der Code für die großen Schiffe wird bis März wohl nicht mehr fertig. Die Drachenschiffe schaffen es aber in Version 3.15.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2539 [Eressea] General kleinerer Fehler N/A 2018-12-17 00:27 2019-02-16 16:58
Reporter: Colonia Ataraxia Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: nicht reproduzierbar  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: moor
Spiel: E2
Report: 1103
Zusammenfassung: Falscher Hinweis zu Passwort und NMR
Beschreibung:

Folgender Text stand im Report (NR und CR):

[Start Text]
Ereignisse

Deine Befehle hatten ein falsches Passwort (...).

                         Warnungen und Fehler

Deine Partei hat letzte Runde keinen Zug abgegeben!
[Ende Text]

Es wurde aber ein Report mit richtigem Passwort eingeschickt, alle Befehle wurden auch entsprechend umgesetzt. Der Text war also nicht zutreffend und ohne weitere Auswirkung.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008300)
Xolgrim   
2018-12-17 16:51   

@Colonia Ataraxia: Hast du zuvor eine Befehlsversion eingesendet, in der das Passwort falsch war?
Der Server liest alle Befehle ein. Wird dabei ein Fehler festgestellt, gibt es eine Fehlermeldung. Da man nicht immer sämtliche Befehle einsenden muss sondern es auch möglich ist Teilbefehle, beispielsweise für nur eine Einheit, einzusenden, weiss der Server aber nie genau für welche Einheit er nun schon (korrekte) Befehle vorliegen hat.
Im NR gibt es daher für jeden Fehler den du in einer Woche einmal eingesendet hast eine Warnung, auch wenn der Fehler in der letzten Befehlsversion behoben wurde.
Eventuell hat das hier auch damit zu tun?
Wenn du nie Fehlerhafte Befehle eingesendet hast letzte Wochen, muss es jedoch was anderes sein

(0008301)
Colonia Ataraxia   
2018-12-17 21:08   

Hallo Xolgrim,
danke für die schnelle Antwort.
In der relevanten Woche habe ich nur 1x Befehle eingeschickt, in der entsprechenden Mail waren Befehle für alle Einheiten enthalten.
Unabhängig von der Warnung: Woher kommt der Hinweis zum NMR?

(0008302)
Enno   
2018-12-18 17:38   

Das ist in Version 3.17.9 passiert, sagt mein CR aus der Woche (dafür gibt es leider keine Version in Mantis).

(0008303)
Enno   
2018-12-18 17:40   

Nein, falsch. Das war schon 3.18.1. Ist ja Runde 1103.

(0008304)
Enno   
2018-12-18 17:50   

Ich habe das mit der alten Version reproduziert gekriegt, Tatsache. Da passt der bcrypt hash in den Daten nicht zu dem, der aus dem Passwort ermittelt wird. Aber im aktuellen Code hat es geklappt.

(0008305)
Enno   
2018-12-18 18:45   

Verrückt.

(0008306)
Enno   
2018-12-18 18:56   

Oh manno. Ist das wieder so eine GNU vs. Windows Geschichte? Das darf doch echt nicht wahr sein.

(0008307)
Enno   
2018-12-18 19:06   

Auf den ersten 23 Zeichen passt der hash, danach nicht mehr. Und dann in der Woche danach stimmt es wieder. Krass.

(0008308)
Enno   
2018-12-18 19:17   

Das einzige, was mir dazu jetzt einfällt, ist Bug 2527 - aber das handelte sich da nur um Passworte, die mehr als 16 Zeichen haben. Und vor allem sollte keine der da gemachten Änderung sich auf das Hashing auswirken, ich habe die gerade alle noch einmal gelesen.

(0008309)
Colonia Ataraxia   
2018-12-18 23:30   

Alle Befehle wurden ja richtig ausgeführt, somit ist nichts "Schlimmes" passiert.
Mein Passwort hat mehr als 23 Zeichen...

(0008359)
Enno   
2019-02-16 16:58   

Ich kann das leider nicht reproduzieren, aber schätze, dass das irgendwie mit der Umstellung des Längenlimits zu tun hatte.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2554 [Eressea] ZAUBER kleinerer Fehler immer 2019-02-08 16:02 2019-02-10 16:06
Reporter: Fiete Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: neu Produktversion: 3.18.5  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: atnf
Spiel: E2
Report: 1109
Zusammenfassung: Schneekugel auch bei aktiven Vulkanen ermöglichen
Beschreibung:

bisher wirkt die Schneekugel laut xmasitems.lua nicht bei aktiven Vulkanen, da die Transformationen so festgelegt sind:
local transform = {
ocean = "glacier",
firewall = "volcano",
volcano = "mountain",
desert = "plain"
}

Da aber eine Schneekugel sogar Feuerwände schmelzen lassen kann, wird sie auch aktive Vulkane transformieren können und ich schlage diese Ergänzung vor:
local transform = {
ocean = "glacier",
firewall = "volcano",
volcano = "mountain",
desert = "plain",
activevolcano = "mountain"
}

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008347)
Xolgrim   
2019-02-09 15:42   

Dafür! Designfehler meinerseits gewesen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2552 [Eressea] Tarnung/Wahrnehmung kleinerer Fehler nicht getestet 2019-02-03 15:02 2019-02-03 16:05
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.4  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.19  
Partei: opy
Spiel: E2
Report: 1108
Zusammenfassung: Fehler bei BEKLAUE
Beschreibung:

In der Region Fancilrifel klaut die Einheit pnhL der Einheit 13ep 50 Silber. Sie hat weniger Tarnung, aber einen RdU. Resultat im NR des Opfers:

Ing-gal (13ep) ertappte Aruyria Dragon (pnhL) beim versuchten Diebstahl.
Ing-gal (13ep) wurden in Fancilrifel (0,0) 50 Silberstücke geklaut.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Beim näheren Hingucken im Debugger stellt sich heraus, dass da offenbar zwei Fehler sind:

effsk = effskill(u, SK_STEALTH, NULL);
n = effsk - max_skill(r, f, SK_PERCEPTION);

if (n &lt;= 0) {
    /* Wahrnehmung == Tarnung */
    if (u_race(u) != get_race(RC_GOBLIN) || effsk &lt;= 3) {
  1. n <=0 bedeutet "Tarnung ist schlechter als Wahrnehmung". Das stimmt, aber beachtet den RdU nicht.
  2. Das mit effsk <= 3 ist hier FALSE, weshalb der else Block mit dem Goblin-Spezialklau benutzt wird (goblin = true).
  3. Es wird die "thiefdiscover" NR Meldung erzeugt, ehe überhaupt nach dem Ring geguckt wird.
Angehängte Dateien:
Notiz
(0008344)
Enno   
2019-02-03 15:07   

Der RdU erklärt, warum man die Einheit nicht im Report sieht. Auf BEKLAUE hat ein RdU keine Auswirkung, nur der Flinkfingerring (erhöht die geklaute Summe). Der Fehler hier schient mir im Goblin-Code zu liegen.

(0008345)
Enno   
2019-02-03 16:05   

Sekunde mal. Die Graugnome sind ja Goblins. Dann ist das auch nicht verkehrt gewesen (nur unübersichtlich).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2551 [Eressea] General kleinerer Fehler nicht getestet 2019-01-31 21:08 2019-01-31 21:14
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.3  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.19  
Partei: wiki
Spiel: E2
Report: 1108
Zusammenfassung: Kann keine Helden benennen
Beschreibung:

Deine Partei hat 0 Helden und kann maximal 1 Helden ernennen.

Fehler:
Odin Allfather (pj4j) in Akershus (-2,2): 'BEFÖRDERE' - Die Partei hat bereits 0 von 0 Helden.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008343)
Enno   
2019-01-31 21:14   

Das hatte ich letzte Woche schon gemeldet und gefixt (aber wegen ZAT Ausfall vergessen).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2548 [Eressea] ATTACKIERE schwerer Fehler nicht getestet 2019-01-20 09:27 2019-01-24 19:00
Reporter: Jutta Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: sybr
Spiel: E2
Report: 1108
Zusammenfassung: Viel zu wenig Treffer im Kampf.
Beschreibung:

Meine 250 T27 Bogenschützen mit Elfenbogen haben mit gewonnener Taktikrunde nur 127 Treffer
im ganzen Kampf gemacht. Das kann doch nicht stimmen?

Schritte zur Reproduktion:
Zusätzliche Informationen:

E2
Region: Herina Laorg
Einheit: viele kleine Goblins. (d9s8)

Angehängte Dateien:
Notiz
(0008341)
Enno   
2019-01-24 18:38   

Ich habe noch einmal mit aktuellem Code ausgewertet, und da steht auch:

viele kleine Goblins. (cypg) erzielte 31 Treffer und tötete 0 Gegner.
viele kleine Goblins. (d9s8) erzielte 96 Treffer und tötete 1 Gegner.
viele kleine Goblins (ifdo) erzielte 7 Treffer und tötete 0 Gegner.

Da gab es viele Überlebende, ja. Mal genauer gucken.

(0008342)
Enno   
2019-01-24 19:00   

Sorry: Deine Gegner haben ca. T18 Hiebwaffen, und stehen in einem Gebäude, dass 12 Punkte zusätzliche Verteidigung bringt, und auf dem ein Zauber liegt, der diese 12 Punkte verdoppelt. Du kämpfst also effektiv mit T27 gegen T48, das ist schwer, da einen Treffer zu landen. Dazu kommt dann, dass Dein Bogen nur marginal mehr Schaden macht, als die Feinde Rüstung haben, das konnte nichts werden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2540 [Eressea] ZAUBER schwerer Fehler nicht getestet 2019-01-04 17:06 2019-01-21 11:11
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.4  
    Zielversion: 3.19  
Partei: cbc
Spiel: Deveron
Report: 235
Zusammenfassung: Vertrauter mit Sprüchen, aber ohne Aura
Beschreibung:

Mein Singdrache hat zwar jetzt wieder seine Zauber zurück bekommen, ist aber noch ohne Aura.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Einheitennummer des Vertrauten: m4ga

Angehängte Dateien:
Notiz
(0008310)
K   
2019-01-05 23:17   

Verwand zu 0002536. Bei mir gibt es auch seit E2 Rund 1103 keine Vertrautenaura.

(0008311)
Thoran   
2019-01-06 11:24   

Für E2 kann ich das nicht beurteilen, weil meine Magiere dort Tunnelwürmer bzw. Wölfe als Vertraute haben, die aber beide von Natur aus keine Aura und keine eigeenen Sprüche haben.
Ich kann das lediglich für Deveron festhalten, denn da haben meine Magiere neben Luchsen auch einen Singdrachen. Letztere Rasse hat eigene Sprüche und sollte also auch eigene Aura haben.

(0008317)
Enno   
2019-01-12 20:30   

Ich habe gerade mal in E2 geschaut, der Singdrache Pebbls vom Volk des silbernen Mondes (m0o7) hat 404 Aura, die auch im Report angezeigt werden. Muss ich wohl mal die E4 Daten ausgraben.

(0008318)
Enno   
2019-01-12 20:35   
(Zuletzt bearbeitet: 2019-01-13 16:22)

Laut Spieldaten sollte der gute Fuchur (m4ga) 20 Aura haben. Im NR von Woche 235 sehe ich die auch:

* Fuchur (m4ga), 1 Singdrache, flieht, Talente: Magie 10, Ausdauer 8,
  Waffenloser Kampf 7, hat: Heiltrank, Ring der Unsichtbarkeit, Schild. Aura
  20/105, ...

Auch im aktuellen Report sehe ich die Aura. Könnt ihr bitte nochmal gucken, ich kann das scheinbar nicht reproduzieren.

(0008321)
K   
2019-01-12 22:08   

Ätherschildkröte (ht42) hat im CR keine Aura soweit ich das sehe, aber im NR und konnt diese Runde auch mit eigener Aura zaubern.

(0008322)
Enno   
2019-01-12 22:24   

Aha, es geht um den CR hier? Keine Ahnung, warum der anders sein sollte, aber ich checke das.

(0008325)
Thoran   
2019-01-13 13:52   

Hier der aktuelle Auszug aus dem CR von Auswertung 236 (Sprüche und gesetzte Kampfzauber habe ich entfernt, da in Deveron zur Zeit der letzte Krieg stattfindet und ich dem Gegner ja keinen Vorteil verschaffen will ;-) ):
--- snip ---
EINHEIT 1032202
"Fuchur";Name
"Er stimmt in die Lieder seines Meisters ein - manche halten das eher für Lärm, andere fürchten den Gesang.";Beschr
1116153;familiarmage
15960;Partei
1;Anzahl
"Singdrachen";Typ
3;Kampfstatus
1100;weight
COMMANDS
"// #call Verfolgen cuz8"
"// #every 3 2 { #call Dauerlerner Ausdauer }"
"// #every 3 3 { #call Dauerlerner 'Waffenloser Kampf' }"
"// #every 3 1 { #call Dauerlerner Magie }"
"LERNE 'Waffenloser Kampf'"
TALENTE
1350 10;Magie
1080 8;Ausdauer
840 7;Waffenloser Kampf
SPRUECHE
// entfernt
KAMPFZAUBER 0
// entfernt
KAMPFZAUBER 1
// entfernt
GEGENSTAENDE
1;Heiltrank
1;Ring der Unsichtbarkeit
1;Schild
--- snap ---

Da ist, wie man erkennt, keine Aura aufgeführt.

Im NR hingegen ist angegeben, wieviel Aura der Vertraute hat - nur gucke ich in den NR so gut wie nie rein.

(0008337)
Fiete   
2019-01-21 00:19   

Update aus Runde 1108, falls aktuelle Daten hilfreich. Unterschied zwischen NR und CR bei der Aura-Frage. Im NR vorhanden, im CR nicht:

IM NR:

* Monopolist (8n6g), Kleine Mannen (atnf), 1 Einhorn, flieht, Talente:
  Magie 37, Tarnung 5, Wahrnehmung 6, Ausdauer 6, hat: 7550 Silber,
  Gehirnschmalz. Aura 2319/2456, Zauber: Schutzzauber, Heldengesang,
  Gesang der Friedfertigkeit, Friedenslied, Lied der Heilung, Monster
  friedlich stimmen, &quot;LERNE Magie 74200&quot;.

  Auf der Einheit liegen 7 Wirkungen Gehirnschmalz.

IM CR:

EINHEIT 403288
"Monopolist";Name
510093;familiarmage
107747;Partei
504987;Anderepartei
1;Anzahl
"Einhörner";Typ
1299888;Burg
5;Kampfstatus
12550;weight
COMMANDS
"// Xscript Lernen Ausdauer"
"// script Lernen Magie"
"// script Lohn 5"
"// script Trankeffekt Trank=Gehirnschmalz Vorrat=1 notSuccessACK=true"
"LERNE Magie 74200"
"// setTag eTag1 Vertraute-Gwyrrd"
TALENTE
18900 37;Magie
30 5;Tarnung
30 6;Wahrnehmung
630 6;Ausdauer
SPRUECHE
"Schutzzauber"
"Heldengesang"
"Gesang der Friedfertigkeit"
"Friedenslied"
"Lied der Heilung"
"Monster friedlich stimmen"
GEGENSTAENDE
7550;Silber
1;Gehirnschmalz
EFFECTS
"7 Gehirnschmalz"

(0008338)
Enno   
2019-01-21 04:01   

Ich glaube, dass das easy sein sollte, ich muss es nur machen.

(0008339)
Enno   
2019-01-21 10:50   

Da steht:

      if (is_mage(u)) {
          stream_printf(out, &quot;%d;Aura\n&quot;, get_spellpoints(u));
          stream_printf(out, &quot;%d;Auramax\n&quot;, max_spellpoints_depr(u->regi     on, u));
      }

is_mage(u) ist aber nur true bei Zauberern, die nicht grau sind (also nicht fuer Monster und Vertraute). Doof, und unnoetig.

(0008340)
Enno   
2019-01-21 11:11   

Der Bug war super easy. Ich mache mal ein neues Minor Release mit dem Fix.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2544 [Eressea] Monster kleinerer Fehler nicht getestet 2019-01-11 19:03 2019-01-11 19:06
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.3  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.19  
Partei: ii
Spiel: E2
Report: 1106
Zusammenfassung: Monster bewegen sich nicht?
Beschreibung:

Es wird in monsters.c eine Konstante RCF_MOVERANDOM verwendet, die nirgendwo anders im Code erwähnt ist, und insbesondere nicht beim Laden der Rassen aus XML. So wie ich das sehe, ist zufällige Bewegung von Monstern dann wohl kaputt?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008316)
Enno   
2019-01-11 19:06   

Oh, nein! Stimmt so nicht. Das passiert in exparse.c, Funktion start_races, da werden die Glags nach der Reihenfolge in flag_names gesetzt. Das war im alten xmlparser.c anders, deshalb habe ich mich da gerade selbst verwirrt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2536 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-12-09 11:01 2019-01-06 03:26
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.3  
    Zielversion: 3.18.3  
Partei: turt
Spiel: E2
Report: 1104
Zusammenfassung: eigene Zauber von Vertrauten werden nicht angezeigt
Beschreibung:

Geistervertraute zeigen keinerlei eigenen Zauber an, weder im CR noch in NR.

Schritte zur Reproduktion:

Einheitennummer:
dtnx
8y8f
ht42

Zusätzliche Informationen:

Auch ZEIGE ALLES ZAUBER ergab nichts.

Angehängte Dateien:
Notiz
(0008277)
K   
2018-12-09 11:04   

Ergänzung: Sie haben auch keine eigenen Aura mehr.

(0008283)
Enno   
2018-12-09 16:02   

Reproduziert: Die Einheit dtnx hat in den Spieldaten graue Magie, 64 Aura, und keine Zauber. Die Anzeige im NR zeigt in der Tat nichts an.

(0008284)
Enno   
2018-12-09 16:05   

Ich tippe mal darauf, dass das in Report 1102 das erste Mal aufgetreten ist. Schaue ich mir sofort an.

(0008285)
Enno   
2018-12-09 16:12   

Nein, der ist schon im 1101 Datenfile grau und ohne Zauber gewesen. Grau ist sogar richtig, glaube ich, denn er soll ja gerade NICHT die Zauber der Partei bekommen, sondern nur eigene benutzen. Von 1101 nach 1102 sollte die Reparatur der Vertrauten passiert sein, es fragt sich, warum das nicht bei dieser Einheit gezogen hat.

(0008286)
K   
2018-12-09 16:40   

Die Einheit war in Ordnung bis 1102 (Aura, Zauber etc) und ist seit 1103 kaputt.

(0008287)
K   
2018-12-09 16:43   

Evtl. durch bugfix 0002521?

(0008288)
Enno   
2018-12-09 18:00   

Korrektur: In Datenfile 1101 hat sie noch Zauber, in der Datei 1102 nicht. Das ist sicher irgendwo in der Konvertierung für Bug 0002451 passiert, aber ich kann es nicht reproduzieren. Nein, 0002521 hatte nichts damit zu tun, das war ein reines Anzeige-Problem.

(0008289)
Enno   
2018-12-09 18:11   

Eine Neuauswertung von 1102 (d.h. Datenfile 1101) schreibt die Zauber ins Datenfile. WTF?

(0008290)
Enno   
2018-12-09 18:17   

Wie? Das erste, was read_spellbook bei der Einheit aus 1102.dat liest, ist "end", also "hier sind keine Zauber".

(0008291)
Enno   
2018-12-09 18:54   

Wenn ich die Auswertung 1102 mit dem aktuellen Source wiederhole, stehen die Zauber im resultierenden Datenfile. Aber im Original sind sie nicht. Hat sich da noch etwas geändert? Ich muss wohl mal den alten Code ausgraben.

(0008292)
Enno   
2018-12-09 19:05   

Das Versionswirrwarr macht mich total irre. Mir fehlt da heute die Konzentration, aber es ist definitv was kaputt, das wird eine schwere Reparatur.

(0008293)
Enno   
2018-12-09 19:32   

Ich habe das jetzt, so gut ich kann, noch einmal durchgeführt. Also, zuerst mit der Version 3.17.9 die AW 1102 wiederholt, und da sind die Zauber im NR wie im Original auch. Danm mit dem aktuellen Code (also nicht mit 3.18.1) die AW 1103 noch einmal aus dem gerade erzeugten Datenfile gemacht, und siehe da: Die Zauber sind im Report, müssen also auch in den Daten gewesen sein. Ich fürchte fast, es hat da eine Zwischenversion gegeben, in der es den Bug gab, der das Datenfile geschrottet hat. Es gibt da noch eine Datei 1102.orig, die eventuell korrekt war? ICh habe zwischen dem 25. und 27. November neue Parteien ausgesetzt, offenbar mit dem neuen Code, denn die interne Version hat sich dabei geändert:

eressea$ file 1102.*
1102.dat: eressea data version 364
1102.orig: eressea data version 360

Jetzt könnte ich natürlich noch die .orig Datei probieren, aber es wird um eine erneute Reparatur aller Vertrauten wohl kein Weg herum gehen.

(0008294)
Enno   
2018-12-09 19:39   

Das war's! Die 1102.orig Datei hat die Zauber noch gehabt, die sind also beim Aussetzen der neuen Spieler verschwunden, und welche Code-Version das war, ist so nicht nachvollziehbar. Damit ist die Hoffnung auf eine Reproduktion und Verständnis der Ursachen wohl gestorben, und ich kann nur versuchen, den Schaden rückgängig zu machen.

(0008295)
Enno   
2018-12-09 19:51   

Ich sehe jetzt erst, dass der Geist ZAUBERE "Hohe Kunst der Überzeugung" gemacht hat. Das ist ein Spruch des Magiers, die sollte er als eigene Zauber habender Vertrauter ja eigentlich nicht können. Ist das evtl. ein Folgefehler?

(0008296)
Enno   
2018-12-09 19:55   

Es sieht so aus, als wenn es reicht, den alten Reparaturcode einfahch noch einmal auszuführen. Das ist doch mal eine gute Nachricht. REsultat:

  • Ätherschildkröte (dtnx), Magie (turt), 1 Geist, flieht, Talente: Magie
    11, Stangenwaffen 7, Ausdauer 7, Waffenloser Kampf 5, hat: Amulett des
    wahren Sehens, Zauberbeutel, Ring der Unsichtbarkeit. Aura 64/64, Zauber:
    Stehle Aura, Mächte des Todes, Gesang der Angst, "ZAUBERE "Hohe Kunst der
    Überzeugung"".

Allerdings zaubert das Biest immer noch den Zauber, den es nicht hat. Wir sind hier also bei weitem noch nicht fertig.

Ätherschildkröte (dtnx) konnte 155 Bauern anwerben.
(0008299)
Enno   
2018-12-15 15:41   

Ich probiere es diese Woche noch einmal mit dem Vertrautenfix.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2491 [Eressea] General kleinerer Fehler nicht getestet 2018-09-11 18:58 2018-12-11 18:33
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion: 3.17.2  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 1092
Zusammenfassung: Verfluchte Gegenstände verhalten sich nicht, wie sie sollen
Beschreibung:

Mir scheint, dieser Code in laws.c verursacht, dass "verfluchte" Gegenstände im Astralraum zerfallen. Ich vermute, dass aber das Gegenteil beabsichtigt war, oder?

static void astral_crumble(unit *u) {
    item **itemp = &u->items;
    while (*itemp) {
        item *itm = *itemp;
        if ((itm->type->flags & ITF_NOTLOST) == 0) {
            if (itm->type->flags & (ITF_BIG | ITF_ANIMAL | ITF_CURSED)) {
                ADDMSG(&u->faction->msgs, msg_message(&quot;itemcrumble&quot;,
                    &quot;unit region item amount&quot;,
                    u, u->region, itm->type->rtype, itm->number));
                i_free(i_remove(itemp, itm));
                continue;
            }
        }
        itemp = &itm->next;
    }
}
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008089)
Xolgrim   
2018-09-11 19:04   

Für beutel des nagativen gewichts könnte das auch gewollt gewesen sein. Warum die not lost sind verstehe ich eh nicht.

(0008090)
Solthar   
2018-09-11 22:44   

Die sind aber nicht CURSED. Was der Unterschied ist, könnte ich gar nicht so schnell sagen. CURSED kann man nicht weggeben, ist die Grundidee, glaube ich. Nur ein paar sehr handgeschneiderte Gegenstände haben dieses Attribut.

(0008091)
Solthar   
2018-09-12 09:02   

Hab mir bei der Gelegenheit die Attribute mal angeschaut:
notlost: snowball/man/globe, birthdaycake, lebkuchenherz, questkey1/2, museumexitticket (aber nicht museumticket), magicbag, pegasus, elvenhorse, dolphin, mistletoe,
notlost und cursed: ring_of_levitation, aog, jadee_ring/dress, wentee_ring/dress, lmsreward,
cursed: seashell, presspass

CURSED:
battle.c: geht nicht kaputt, wenn Besitzer stirbt (BUG? sollte NOTLOST sein?)
give.c: kann nicht übergeben werden; verhindert Einheiten- oder Personenübergabe (BUG? aber nicht, wenn Partei oder Einheit stirbt (unit.c:gift_items())?
CURSED | NOTLOST: battle.c: wird auf jeden Fall erbeutet (BUG? Sollte cursed wirklich erbeutet werden?)
CURSED & !NOTLOST:
laws.c: zerfällt im Astralraum
NOTLOST:
faction.c: wird auf jeden Fall übergeben, wenn Partei stirbt
unit.c: wird nicht an Bauern übergeben, wenn Partei stirbt (BUG? s.o., gift_items())
laws.c: verhindert Astralraumzerfall

Zusammenfassend:
Die Intention von CURSED scheint zu sein, dass es nicht übergeben werden kann, die von NOTLOST, dass es nicht verschwinden kann. Was ist aber mit Gegenständen, die beides sind? Kann ich sie erbeuten, wie eine verfluchte Waffe in D&D? Oder eben nicht, weil es ein personalisierter Gegenstand ist wie ein Presseausweis? Im Code scheinen beide Ideen vorzukommen.

Weitere mögliche Fehler:
sp_combatrosthauch / sp_rosthauch / sp_seduce ignorieren die Flags
sp_undeadhero kann CURSED umgehen

(0008092)
Solthar   
2018-09-12 11:56   

Oh je, verfluchte Gegenstände können durch RESERVIERE übergeben werden (aber nicht durch GIB).

(0008093)
Xolgrim   
2018-09-12 17:32   

Ich habe ein "Amulett des Treffens" im Kampf erbeutet, kann das aber nicht abgeben. Das muss dann aus obiger Liste "imsreward" oder "aog" sein, die restlichen Dinge sind ja recht klar am Namen zu erkennen.
Mindestens beim Ring der Levitation ist es gewollt gewesen, dass der nach dem tode des Besitzers weiterhin existiert.

(0008096)
Enno   
2018-09-12 21:11   

Ja, das Amulett des Treffens ist aog (Amulett of Gathering). Zu der Motivation für den Astralraum-Code kann ich nicht mehr viel sagen, das ist lange her. Wir wollten auf jeden Fall vermeiden, dass man mit Pferden Massenhaft Material transportiert, und keine Schiffe mehr für eine Invasion braucht. Der Beutel des n. Gewicht fällt da wohl auch drunter.

Mir sind diese Flags auch nicht geheuer, es kann gut sein, dass die gelegentlich vertauscht worden sind. Ich werde mir das selber noch einmal ansehen müssen, Danke aber auf jeden Fall für die detailierte Auflistung!

(0008100)
Solthar   
2018-09-12 23:23   

Zur Ergänzung: Verwirrend ist hier auch, dass Gegenstände auf verschiedene Weisen verändern können: Da gibt es i_change und i_remove, die nicht nur direkt, sondern auch von change_resource aufgerufen werden und zwar über den Hook resource_type.uchange(), was aber möglicherweise i_change auch ganz übergehen kann ... Schwer zu sagen, wo da überall abfragen auf ITF_CURSED und NOTLOST sein müssten.

(0008298)
Enno   
2018-12-11 18:33   

lmsreward ist übrigens der "Gürtel der Heldentaten", der Lohn für den Sieg bei einem "Last Man Standing" Event, den es wohl mal gab. Hat den wohl jemand? Vor einer Weile, als ich mal Inventar gemacht habe, gab es davon zwei Stück.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2538 [Eressea] REKRUTIERE kleinerer Fehler nicht getestet 2018-12-11 18:14 2018-12-11 18:26
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.2  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.19  
Partei: enno
Spiel: E2
Report: 1104
Zusammenfassung: Einheiten rekrutieren nicht, obwohl Silber und Rekruten vorhanden
Beschreibung:

Magnus Carlsen (maca) in Die Welt (92,-303) rekrutiert 0 von 1 Personen.
Matt Gray (wm6p) in Die Welt (92,-303) rekrutiert 0 von 5 Personen.

Schritte zur Reproduktion:

MACHE TEMP wurde von der Einheit stan gegeben.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008297)
Enno   
2018-12-11 18:26   

Oh. Ich habe in der Region offenbar noch eine weitre Einheit mit 6 Personen rekrutiert, die hat alle Rekruten bekommen. Und mehr als 6 Bauern kriegt man dort nicht. Mein Fehler.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2534 [Eressea] ZAUBER Unschönheit nicht getestet 2018-12-08 11:04 2018-12-09 10:38
Reporter: Pyanfar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: gnom
Spiel: E3
Report: 486
Zusammenfassung: Falsche Fehlermeldung bei Vertrautenzauber
Beschreibung:

Habe (mehr aus Versehen) meinen Vertrauten drac einen Zauber (Gaukeleien) zaubern lassen, den nur der Magier beherrscht. Der Magier ist aber weitzweitweg, definitiv ausserhalb der Reichweite, die durch Magietalent von Magier vorgegeben ist.
Die Fehlermeldung lautet: "Drachine (drac) in Riva (5, 9): 'ZAUBERE STUFE 4 Gaukeleien' - Solarika, Erforscherin stellarer Energien (soLa) kann nicht genug Energie aufbringen, um diesen Spruch durch Drachine (drac) zu wirken."

Das wäre theoretisch richtig, da die Kosten ungefähr 4*2^20 betragen würden - aber die Meldung ist verwirrend, denn der Magier ist ja auch ausser Reichweite. Keine Ahnung, in welcher Reihenfolge der Code da testet, aber ich würde zu große Entfernung separat melden :)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008269)
Enno   
2018-12-08 17:39   

Wir melden generell den ersten Fehler, der auftritt, und brechen dann die Bearbeitung ab.

(0008276)
Enno   
2018-12-09 10:38   

Die Meldung ist nicht falsch, sie ist nur nicht so vollständig, wie Du Dir das wünscht. Ich sehe hier keinen Handlungsbedarf.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2533 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2018-12-08 01:40 2018-12-09 10:23
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.3  
    Zielversion: 3.18.3  
Partei: d08a
Spiel: E2
Report: 1103
Zusammenfassung: Änderung im Kampf?
Beschreibung:

Seit mehreren Monaten (genauer gesagt fand der erste Kampf gegen die Untoteneinheit in Runde 1082 statt) schon kämpfen 70 meiner Zwerge gegen anfangs knapp 1600, mittlerweile etwas über 1900 Juju-Zombies.

Bisher haben meine Krieger nicht eine Wunde davon getragen, sprich: die Einheit war nie erschöpft oder gar verwundet. Nach dem Kampf in dieser Woche jedoch wird ihr Gesundheitszustand als verwundet gemeldet.

Das wundert mich ein wenig und ich kann es mir nur dadurch erklären, dass mit der Änderung vom 01.12. unabsichtlich (?) irgendwas am Kampfverhalten geändert worden ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Einheit auf meiner Seite: ao5e
Untoteneinheit: ypLx
erste Kampf: Runde 1082 in Firenland (nuxrzy)
aktueller Kampf: Runde 1103 in Wüste der sanften Dünen (fkr3s1)

Angehängte Dateien:
Notiz
(0008270)
Enno   
2018-12-08 17:41   

Es hat sich absichtlich etwas gendert: Die Berechnung von Magieresistenz war kaputt, weshalb man z.B. im Kampf gegen Wyrme so gut wie immer fliehen konnte. Ob und wie sich das auf Juju-Zombies auswirkt, kann ich nicht auf die Schnelle sagen, aber ich denke, in einem Kampf mit 70 gegen 1900 sollte man damit rechnen, dass man verletzt werden koennte.

(0008271)
Thoran   
2018-12-09 01:21   

Wenn das mit einer Änderung an der Magieresistenz zusammenhängt, dann müssten Juju-Zombies aber doch über magische Angriffe verfügen, oder?

(0008272)
Enno   
2018-12-09 03:09   

Dafür müssten die entweder magische Angriffe haben, oder magische Waffen. Ihre natürlichen Angriffe sind ein bewaffneter, und zwei Schwäche-Attacken, aber nichts magisches, also Waffen. Haben die welche?

@Solthar hat allerdings für die Änderung im Kampfcode einiges umgestellt, und dabei u.a. einen Fehler verbockt, der dazu geführt hat, dass Einheiten die falschen Waffen und Talente zugeordnet wurden. Der ist erst jetzt (1104) repariert worden, und daran könnte es auch noch liegen, fürchte ich. Muss ich wohl doch mal im Detail nachvollziehen.

(0008273)
Enno   
2018-12-09 03:13   

cppcheck meint zum Kampfcode übrigens:

[src/battle.test.c:406] -> [src/battle.test.c:409]: (style) Variable 'rc.armor' is reassigned a value before the old one has been used.
[src/battle.test.c:501] -> [src/battle.test.c:506]: (style) Variable 'rc.magres' is reassigned a value before the old one has been used.
[src/battle.test.c:543] -> [src/battle.test.c:545]: (style) Variable 'achain.projectile' is reassigned a value before the old one has been used.

(0008274)
Enno   
2018-12-09 10:18   

Noch einen zweiten Fehler gefunden, und nach der erneuten Reparatur sieht das dann so aus:

  1. Rotte Cokêfolzas - 'Alte Kameraden' (ao5e) erzielte 311 Treffer und
    tötete 9 Gegner.
    Verdammte des Bösen (ypLx) verlor 9 Personen, 1926 überlebten.
    Heer 0(d08a): 0 Tote, 0 Geflohene, 70 Überlebende.
    Heer 1(ii): 9 Tote, 0 Geflohene, 1957 Überlebende.
(0008275)
Enno   
2018-12-09 10:23   

Wird sofort repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2532 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-04 21:31 2018-12-06 19:32
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.2  
    Zielversion: 3.19  
Partei: 0
Spiel: E2
Report: 1103
Zusammenfassung: HTML Befehle werden ohne Warnung abgelehnt
Beschreibung:

Ein Spieler (heidel@gmx.de) hat seine Befehle als HTML-only eingesendet, und ausser dem Wort "Warnung" in der ECheck-Antwort bekommt er keinen Hinweis, was denn verkehrt war. Das kann man besser machen.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008267)
Enno   
2018-12-06 19:32   

Das sollte jetzt eine explizite Warnung geben, wenn in der Mail nichts erkennbares ist.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2529 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-12-03 21:56 2018-12-04 18:53
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18.2  
Partei: enno
Spiel: E2
Report: 1103
Zusammenfassung: Beste Einheit steigt bei LERNE AUTO auf.
Beschreibung:

In St. Oberolm lernen eine ganze Reihe meiner Einheiten Steuereintreiben mit LERNE AUTO. Die beste von ihnen, die eigentlich alle anderen lehren sollte, ist Kaiserliche Steuerbeamte (znyw). Im Report steht: Steuereintreiben 6 (+1), obwohl diese Einheit niemanden hat, der sie lehren könnte, und sie als beste Einheit vom Algorithmus eigentlich zum Lehren eingespannt werden sollte. Was ist hier passiert?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008263)
Xolgrim   
2018-12-03 22:12   

Gibt es ggf. schlechtere EInheiten die auch lehren können und lehrt diese Einheit deshalb nicht vollständig, sondern lernt auch ein wenig?

(0008264)
Enno   
2018-12-04 18:45   

Ich weiss doch, wie der Code das macht, der fängt immer bei der besten Einheit an.

(0008265)
Enno   
2018-12-04 18:51   

Oh, doch, das könnte sein. Die haben ja Steuereintreiben 6 (+1), das heißt, sie hatten vor dem lernen noch T5, und es gibt in der Tat mindestens eine andere T5 Einheit hier. Die hat 10 Leute, was genug ist, die anderen 60 zu lehren. Kann also absolut mit rechten Dingen zugehen.

(0008266)
Enno   
2018-12-04 18:53   

Und genau so war es dann auch. Falscher Alarm.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2528 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-03 12:21 2018-12-03 21:07
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.2  
    Zielversion: 3.18.2  
Partei: 777
Spiel: E2
Report: 1103
Zusammenfassung: Steuerzeichen im CR
Beschreibung:

Der CR von @Xolgrim enthält in den Befehlen ^M Zeichen. Die sind schon in seiner Befehlsmail Datei gewesen, sollten die beim Eingang nicht gefiltert werden? Oder spätestens vom Parser als Whitespace erkannt werden?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008260)
Enno   
2018-12-03 20:54   

Neuer Parser hat dieses Problem offenbar nur unter Unix, nicht auf Windows. Spannend.

(0008261)
Enno   
2018-12-03 21:05   

Hack: Wenn man im create-orders die Eingaben durch tr -d '\r' schickt, scheint das okay zu werden.

(0008262)
Enno   
2018-12-03 21:07   

Das ist erst einmal gut genug so, glaube ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2527 [Eressea] General kleinerer Fehler nicht getestet 2018-12-03 10:13 2018-12-03 19:20
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.2  
    Zielversion: 3.18.2  
Partei: 2
Spiel: E2
Report: 1103
Zusammenfassung: Lange Passworte werden nicht erkannt
Beschreibung:

Es sieht so aus, als wenn Parteien mit langen Passworten (16 oder mehr Zeichen) diese Woche einen NMR hatten, weil der Passwort-Check nicht funktioniert hat. Soweit ich see, betrifft das 8 Spieler, darunter Katja.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008258)
Enno   
2018-12-03 10:15   

Da wurde ein String auf dem Stack benutzt, der nur 16 Bytes lang ist, und es wird nicht auf Overflow gecheckt. Ich habe den erst einmal verlaengert, aber es sollte noch Tests geben, und die neue maximale Laenge eines Passworted sollte irgendwo beim Setzen geprueft werden.

(0008259)
Enno   
2018-12-03 19:20   

Beim Setzen eines Passworts mit mehr als 31 Zeichen wird dieses jetzt zusätzlich verkürzt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2524 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-02 11:51 2018-12-02 21:33
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.2  
    Zielversion: 3.18.2  
Partei: wiki
Spiel: E2
Report: 1103
Zusammenfassung: Fehler in der Talentanzeige
Beschreibung:

In meinem Report steht eine Einheit ohne Talentwert:

  • Eirik Magnusson (xmpo), 1 Meermensch, aggressiv, Talente: Bergbau , Reiten
    2, hat: Pferd, 2 Juwelen, 170 Silber.
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008255)
Enno   
2018-12-02 19:19   

Kann es sein, dass der Unterschied mal wieder an der BSD-Implementation von strlcpy liegt? Denn auf dem Server ist das offenbar reproduzierbar.

(0008256)
Enno   
2018-12-02 19:44   

Oh, das Problem ist str_itoab, haha! Wenn der Talentwert 0 ist, gibt das einen leeren String, nicht "0".

(0008257)
Enno   
2018-12-02 21:33   

Das war ein Fehler in meiner Implementation von itoa, die für den Wert 0 einen leeren String lieferte. Deshlab passiert es auch nicht auf Windows, wo das platformspezifische _itoa benutzt wurde.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2526 [Eressea] Reportformat Fehler im Text N/A 2018-12-02 12:27 2018-12-02 17:14
Reporter: Caranthir Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18.2  
Partei: cara
Spiel: E2
Report: 1103
Zusammenfassung: Fehlende Leerzeichen bei Items
Beschreibung:

In meinem aktuellen Report ist mir an zwei Stellen aufgefallen, dass das Leerzeichen zwischen Anzahl und Itemname fehlt:

  • 1Schneekugel (in "Einheiten können die folgenden Gegenstände beanspruchen: 1Schneekugel")
  • 230Silber (in Ereignisse, Spionagereport: "Im Gepäck von Nimgadol die Rote (r3La) sind 230Silber.")

Das war's, sonst fehlenden wohl keine Leerzeichen. Sehr merkwürdig.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008253)
Enno   
2018-12-02 17:14   

Fazit: Wir brauchen mehr Tests für Dinge wie Befehlsdatei und Reporte.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2525 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-12-02 12:07 2018-12-02 17:13
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.2  
    Zielversion: 3.18.2  
Partei: enno
Spiel: E2
Report: 1103
Zusammenfassung: Default-Befehle fehlen in Zugvorlage und NR
Beschreibung:

In meinem Report steht:

  • Procyon cancrivorus (prod), 3 Erzelfen, flieht, Talente: Unterhaltung 1,
    hat: 3 Holz.

  • Balaena mysticetus (sfvx), 1 Erzelf, flieht, Talente: Holzfällen 1.

  • Anthus cinnamomeus (fiss), 2 Erzelfen, flieht, Talente: Unterhaltung 2.

  • Balaena montalionis (bdyi), 1 Erzelf, flieht, Talente: Waffenbau 1.

  • Anthus novaeseelandiae (fn57), 1 Erzelf, flieht (schwer verwundet,
    hungert), Talente: Stangenwaffen .

Auch hier fehlen übrigens wieder Talentwerte.

Schritte zur Reproduktion:
Zusätzliche Informationen:

In der Zugvorlage:

REGION 58,-330 ; Febomawan
; ECheck Lohn 10

EINHEIT prod; Procyon cancrivorus [3,0$]
EINHEIT sfvx; Balaena mysticetus [1,0$]
EINHEIT fiss; Anthus cinnamomeus [2,0$]
// Watopal: Ghaste (xeh) @ 1096
// Befotawur: 4 Skelette (w5uj) @ 1099
EINHEIT bdyi; Balaena montalionis [1,0$]
EINHEIT fn57; Anthus novaeseelandiae [1,0$]

Angehängte Dateien:
Notiz
(0008251)
Enno   
2018-12-02 12:08   

Im CR stehen auch keine Befehle, sehe ich:

COMMANDS
TALENTE
90 1;Unterhaltung

(0008252)
Enno   
2018-12-02 17:13   

Fazit: Wir brauchen mehr Tests für Dinge wie Befehlsdatei und Reporte.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2520 [Eressea] LERNE/LEHRE kleinerer Fehler immer 2018-11-17 22:40 2018-12-01 10:58
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.8  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18.0  
    Zielversion: 3.18.0  
Partei: turt
Spiel: E2
Report: 1101
Zusammenfassung: LERNE AUTO scheint nicht zu lernen
Beschreibung:

Ein Einheit mit LERNE AUTO Stangenwaffen zeigt keinen Lernfortschritt, im Gegensatz zu anderen mit dem gleichen Befehl in der Region.

Schritte zur Reproduktion:

Rasse: Insekt
Region: Ebene
Einheit: kbfo
Befehl: LERNE AUTO Stangenwaffen
Talente: keine, weder vorher noch nachher

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008239)
K   
2018-11-25 11:19   

Die Einheit hat auch diese Auswertung (1102) wieder keinerlei Talente, trotz des LERNE AUTO Stangenwaffen Befehls.

(0008240)
Enno   
2018-11-27 22:08   

Sorry, habe diese Meldung bisher irgendwie nicht gesehen. Das ist natürlich ernst, wenn das so stimmt.

(0008241)
Enno   
2018-11-30 18:53   

Ja, da ist definitiv was nicht okay, ich sehe das auch, es ist nur schwer einzukreisen, wo das schief geht. Unübersichtliche Region. Evtl. solltest Du hier das traditionelle LEHRE/LERNE benutzen, bis ich das repariert habe.

(0008242)
Enno   
2018-11-30 18:54   

So bald wie möglich ein Bugfix-Release machen!

(0008243)
Enno   
2018-12-01 09:20   

Ich habe die Sache gerade in einem Test reproduziert gekriegt, test_autostudy_run_twoteachers. Es liegt wohl daran, dass eine Schüler-Einheit sehr groß ist, und mehrere Lehrer braucht. Die sprechen sich nicht ordentlich ab, und lehren die Schüler zu viel, deshalb bleibt dann für die folgenden kein Lehrer mehr übrig. Die Einheit, die keine Talente hat, wird als letzte gelehrt, da ist dann niemand mehr da für die.

(0008244)
Enno   
2018-12-01 09:45   

Testauswertung sagt jetzt:

  • Panzerschildkröte (kbfo), 1000 Insekten, flieht, Talente: Stangenwaffen
    2, "LERNE AUTO Stangenwaffen".

Das sieht doch gleich viel besser aus. Da werde ich wohl nochmal das 3.18 Release ändern müssen.

(0008245)
Enno   
2018-12-01 10:58   

Danke für die Meldung, wieder ein Bug gefixt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2519 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-11-17 22:02 2018-11-18 13:26
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.8  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: grau
Spiel: E2
Report: 1101
Zusammenfassung: Inkonsistenz zw. nr und cr bei Parteiname
Beschreibung:

Im nr sehe ich anhand einer Durchreisemeldung ein Boot mit zwei Personen:

Tidhis (-2,2)
[…]
TLS Kleiner Drache (rtf2), Boot, Südwestküste.

    1. Flotille, Kapitänleutnant Durkag (he94), Die Trolllegion (troL), 1 Troll.
  • pechschwarzer Reisender (aus3), zerschlagenes Pech (zp99), 1 Goblin.

Insbesondere sehe ich, dass der Goblin vom Volk "zerschlagenes Pech" ist (oder zumindest vorgibt).

Im cr sehe ich den Goblin nur als Teil von "Partei zp99 (zp99)". Der Name des Volkes hat es also irgendwie nicht in den cr geschafft. Ich habe den cr in Magellan geöffnet, denke aber, dass wenn ich den cr im Texteditor richtig interpretiert habe, das Problem Tool-unabhängig sein sollte. Für den Troll finde ich im Texteditor im cr die zugehörige Partei für den Goblin nicht.

Wie gesagt, es geht um eine Durchreisemeldung, vielleicht ist das Teil des Problems.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008222)
Julian   
2018-11-17 22:14   

Ergänzung:
im nr fehlt in der "Liste der Parteien" ebenfalls die Goblin-Partei, obwohl ich den Namen in der Durchreisemeldung weiter oben sehe.

(0008223)
Julian   
2018-11-17 22:19   

Ich meine natürlich "Liste aller Adressen" am Ende des nr.
(eine Editfunktion wäre toll im bugtracker…)

(0008226)
Enno   
2018-11-18 13:24   

Da gibt es den Bug 2509, das könnte der selbe sein. Ich sende Dir gleich mal eine Vorschau auf die Änderung, sagst Du mir, ob da das Problem gelöst ist?

(0008227)
Enno   
2018-11-18 13:25   

Never Mind, der Report ist so kurz, das kann ich selber prüfen, ja, das ist ein Duplikat.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2509 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-11-02 19:17 2018-11-18 13:25
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: ufo
Spiel: E2
Report: 1098
Zusammenfassung: Partei erscheint im NR, aber nicht im CR
Beschreibung:

In meinem Report habe ich die folgende Einheit:

  • Primeren (xa6w), Onyx Ploohns (onyx), 100 Insekten, bewacht die Region.

Im CR taucht der Name "Onyx Ploohns" nirgendwo auf, und auch die Parteinummer nur an dieser Einheit:
EINHEIT 1552856
"Primeren";Name
1150809;Partei

Schritte zur Reproduktion:
Zusätzliche Informationen:

Das ist für mich eine Durchreiseregion, evtl. liegt es daran?

Angehängte Dateien:
Notiz
(0008177)
Enno   
2018-11-02 19:21   

Ich sehe gerade, dass da noch mindestens zwei andere Einheiten in der Region sind, die weder im CR noch im NR auftauchen:

  • Wanderer (9468), Daelirim (daeL), 1 Meermensch, hat: Silberbeutel.

  • Ritter Yussuf (5ip1), Kgr. Nabban (yp2h), 1 Nebelmensch, hat: Bogen, Pferd.

(0008178)
Enno   
2018-11-02 19:21   

Das ist evtl. aber richtig so, denn die bewachen nicht.

(0008179)
Enno   
2018-11-02 20:28   

In der Parteiliste am Ende vom NR stehen die Onyx Ploohns auch nciht drin, die basiert auf den gleichen Daten wie der CR, das hat sicher den selben Grund.

(0008180)
Enno   
2018-11-02 22:15   

Da ist ein break in cb_add_address, Zeile 1136 , das dafr sorgt, dass in Durchreiseregionen nur die erste gesehene Partei in die Liste kommt. Das ist verkehrt.

(0008184)
Enno   
2018-11-03 14:33   

Hier ist noch etwas faul, prepare_report für AW 1096, Partei 242, schmiert mit einer NULL-Region ab?

(0008185)
Enno   
2018-11-03 14:55   

Oh, ja. Die Region wird auch wieder als Referenz geladen, aber region_create setzt natürlich r->next noch nicht, weil das in new_region passieren sollte. Das tut es aber jetzt nicht, weil das eine zweite Region erzeugen würde.

(0008186)
Enno   
2018-11-03 15:44   

Jetzt habe ich's, glaube ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2516 [Eressea] NACH/ROUTE kleinerer Fehler nicht getestet 2018-11-09 20:06 2018-11-12 18:20
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.7  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18  
Partei: udo
Spiel: E2
Report: 1099
Zusammenfassung: Einheit kann sich nicht bewegen, kriegt falsche Meldung
Beschreibung:

In meinem Report:

Hydrurga leptonyx (mkn9) in Kobo (93,-305): 'ROUTE SW SO SO O O NW P P' - Die
Region wird von Die Listigen von Ozean (jycy), einer nichtalliierten Einheit,
bewacht.

Schritte zur Reproduktion:

Die Einheit war vorher in einem Boot, ist aber wegen eines Kampfes mit eben diesem Wyrm nicht mehr im Boot, und versucht jetzt, in einen Ozean zu laufen. Dabei sollte sie nicht aufgehalten werden, sondern die Meldung "entdeckt, das im Südwesten Ozean ist" bekommen.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008207)
Enno   
2018-11-12 18:20   

Das stimmt so schon: Die Einheit kann sich nicht bewegen, weil sie in dieser Woche in einer bewachten Region ein Schiff verlassen hat (Flucht im Kampf). Dadurch kommt es gar nicht erst zu der Frage, in welche Region sie gehen will, sondern gibt direkt die "wird bewacht" Meldung, die hier einmal nichts mit Durchreise zu tun hat.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2499 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-10-09 16:33 2018-11-12 18:15
Reporter: Dael Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.4  
Produkt-Build: Lösung: nicht reproduzierbar  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: Dael
Spiel: E2
Report: 1095
Zusammenfassung: Einheit sitzt im Weltenportal
Beschreibung:

Wenn man ein Weltenportal betritt, bleibt die Einheit normalerweise nicht in diesem Gebäudetyp sitzen, sondern kommt in einer zufälligen Region einer anderen Welt an.
Vor dem Report Nr. 1095 hat meine Einheit 34an ein Weltenportal betreten und nun sitzt sie in diesem Gebäude.

Kopiert aus dem NR-Report Nr. 1095:

Statistik für Burtokos (...,...):

Unterhaltung: max. 4937 Silber
Lohn für Arbeit: 13 Silber
Rekruten: max. 1 Bauern
Luxusgüter zum angegebenen Preis: 0
Personen: 3
Silber: ...

Weltentor (18hc), Größe 2, Portal.

* Wanderer (34an), 1 Meermensch, flieht, Talente: Tarnung 1, hat: 280
  Silber, &quot;LERNE Tarnung&quot;.

Die Regions-Id von Burtokos ist oqsbdh.
Ich denke, die Einheit sollte nicht im Portal sitzen, sondern hätte in einer zufälligen Region ankommen sollen, oder?

Schritte zur Reproduktion:

Ich lasse diese Woche eine weitere Einheit das Weltenportal 18hc betreten.

Zusätzliche Informationen:

Der CR-Report berichtet diese Versions-Nummer.
"3.17.4";Build

Dieser Bug-Tracker fragt die Versions-Nummer ab. Das ist aber kein Freifeld, in das man sie eintragen könnte, sondern nur vorgegebene Werte sind erlaubt. Die Nummer 3.17.4 wird nicht angeboten. Ich habe die nächst liegende Nummer 3.17.1 gewählt, aber das ist natürlich falsch.

Angehängte Dateien:
Notiz
(0008123)
Enno   
2018-10-09 20:05   

Ich sehe das in Deinem Report, aber kann es auf meinem Rechner in einer Neu-AW nicht nachvollziehen. Ich sehe in deinem Report:

Wanderer (34an) wandert von Flammenberg (27,-14) nach Pakós (26,-13).

Die Einheit hat auch die von Dir angegebene Talente nicht.

* Wanderer (34an), 1 Meermensch, kämpft nicht, hat: 230 Silber.

Sind da evtl. TEMP-Einheiten im Spiel gewesen? Im Original-Report sehe ich:

Wanderer (fpsv) wandert von Flammenberg (27,-14) nach Pakós (26,-13).

Da muss ich wohl mal genauer in die gegebenen Befehle schauen. So schnell kriege ich das heute Abend jedenfalls nicht raus.

(0008124)
Dael   
2018-10-09 21:01   

Ja, das war eine TEMP-Einheit. Die war gerade erzeugt, hat das Weltenportal betreten und als Befehl "Lerne Tarnung" ausgeführt.

(0008125)
Dael   
2018-10-09 23:21   

In dem 1095-Report, den ich habe, gibt es diese "wandert von"-Meldung für 34an nicht. Die einzige Wanderung von Flammenberg aus ist diese:

Wanderer (fpsv) wandert von Flammenberg (27,-14) nach Pakós (26,-13).

Und wenn ich schaue, welche Einheiten in Pakós sind, dann ist da auch kein 34an angekommen, sondern ein fpsv:

Pakós (26,-13), ....

Auf dem Markt ...

Die Region wird von KIG (fkmk) bewacht.

Die Region wurde durchquert von Wanderer (2692), Wanderer (2713), Wanderer
(8822), Wanderer (2739) und Wanderer (2740).
Statistik für Pakós (26,-13):

....

Burg (z54g), Größe 250, Burg.

* Wanderer (2738), 1 Meermensch, flieht, Talente: Unterhaltung 1, &quot;LERNE
  Unterhaltung&quot;.

* Wanderer (8821), 1 Meermensch, flieht, Talente: Unterhaltung 1, hat: 10
  Silber, &quot;LERNE Unterhaltung&quot;.
  • Olen (g076), KIG (fkmk), 200 Blutkatzen, bewacht die Region, hat: 200
    Pferde, 72 Rostige Kettenhemden, 200 Schartige Schwerter, 179 Schwerter.

  • Wanderer (fpsv), 1 Meermensch, kämpft nicht, hat: 230 Silber.

Das ist aus dem zweiten 1095er-Report (du hast am Sonntag einen um 8:52 und einen um 9:28 verschickt):

         Report für Eressea, Sunday, 07. October 2018, 09:23

Wir schreiben die letzte Woche des Monats Blütenregen im Jahre 34 des zweiten
Zeitalters. Es ist Frühling.

Wenn man in Burtokos das Weltenportal betritt, dann kommt man in der 1., 2. oder 3. Welt oder in den Chaoslanden an. Aber Flammenberg und Pakós sind in der 10. Welt. Dorthin bin ich von meiner Heimatinsel Scrat mit dem Boot gefahren. Die dortigen Wanderer sollten nichts mit dem Weltenportal zu tun haben.

(0008126)
Enno   
2018-10-10 19:20   

Okay, das mit der TEMP-Einheit erklärt, warum ich da im Report ganz andere Sachen gesehen habe. Beim Versuch, das zu reproduzieren, betritt eine Einheit das Weltentor, und wird dann später teleportiert, das schient also bei mir zu klappen, aber in der regulären Auswertung nicht. Warum, ist mir weiterhin unklar. Das wird schwierig.

(0008127)
Enno   
2018-10-10 20:46   

In tunnels.lua finde ich so beim einfachen Lesen keinen Fehler. Seltsam.

(0008128)
Dael   
2018-10-10 21:44   

Nächste Woche betritt noch mal einen neue Temp-Einheit das Weltenportal. Dann sehen wir wenigstens, ob es noch einmal passiert oder nicht.
Was soll ich mit Einheit 34an machen? Soll ich sie noch einmal das Weltenportal betreten lassen, in dem sie schon sitzt? Oder wird ein Betreten eines Gebäudes, in dem man sowieso schon sitzt, gleich in eine Nop verwandelt? Soll ich der Einheit "verlasse" und "betrete burg 18hc" befehlen? Oder sie drin sitzen lassen ohne Befehl (außer "lerne tarnung")? Ich vermute, die Portal-Funktionalität ist in den Betrete-Befehl eingehängt? Dann wird sie ohne Befehl wohl einfach sitzen bleiben.

(0008141)
Enno   
2018-10-14 17:09   

Das hat mit BETRETE nichts zu tun. Das ganze ist ein Plugin, das am Ende der Runde alle Portale durchsucht, ob da jemand drin steht, Deine Einheit sollte also diese Woche teleportiert worden sein, es sei denn, der Fehler ist wieder aufgetreten. Ich kann ihn immer noch beim besten Willen nicht reproduzieren.

(0008142)
Dael   
2018-10-14 18:13   

Ich habe eine frisch erzeugt Einheit durch geschickt und die ist als Wanderer (8858) in Taszenzorbes (2s5pbm) angekommen.

Der Einheit 34an habe ich "verlasse" und "betrete burg 18hc" befohlen. Da das Plugin am Ende über alle Portale schaut sollte das weder etwas schaden, noch etwas nützen. Aber 34an sitzt immer noch im Portal 18hc. Gibt es eine Maximalanzahl von Einheiten/Personen, die durch das Portal passt? Vielleicht hat gleichzeitig ein anderer Spieler viele Personen durch geschickt und zufällig hatte 34an in zwei Runden Pech und fiel hinten runter (klingt unwahrscheinlich). Wenn du es nicht nachstellen kannst, dann ist es vielleicht ein Bug im Script oder im LUA-Interpreter, der nur zuschlägt, wenn die Einheit "34an" heißt (bzw. irgendeine super seltene Kombination an Bedingungen an die Unit-Ids, so dass sie nicht funktionieren). Auch unwahrscheinlich, aber wenn es sich nicht reproduzieren lässt, dann muss es irgend was ganz spezielles sein.
Ich wollte 34an jetzt nächste Woche in die dortige Burg schicken und die Woche drauf wieder ins Portal 18hc, um ganz sicher das Betreten zu triggern. Aber da es nicht daran gekoppelt ist, lass ich sie drin sitzen. Sie rekrutiert sich noch eine weitere Person und lernt weiter Tarnung.

(0008162)
Dael   
2018-10-24 17:36   

Die Einheit 34an sitzt weiterhin im Weltenportal. Es muss irgendetwas an ihr besonders sein, so dass das Script, das am Ende über alle Weltenportale geht, sie nicht teleportiert.

(0008163)
Enno   
2018-10-24 18:43   

Ich bin noch nicht wieder dazu gekommen, mir das weiter anzugucken, und mir gehen auch die Ideen aus, woran es liegen koennte, oder wie ich es reproduziere, um das herauszufinden.

(0008164)
Dael   
2018-10-25 16:54   

Wenn das nur in der Produktions-Umgebung passiert, aber nicht wenn du das tunnel.lua-Script alleine laufen lässt, dann ist es vielleicht am besten das in der Produktions-Umgebung zu debuggen? Ich kenne LUA nicht und weiß daher nicht, was es an Debug-Unterstützung bietet. Oft schreibt man sich ja dann, wenn's da nichts zum Debuggen gibt, an alle Verzweigungen und an Stellen mit (Zwischen-)Ergebnissen printf-Ausgaben (wie immer das auch in LUA heißt) in den Code. Vielleicht würde das was helfen?

(0008166)
Enno   
2018-10-26 20:42   

Das löst alles nicht das Problem, dass ich diese Woche überhaupt keine Zeit habe.

(0008182)
Enno   
2018-11-03 13:14   
(Zuletzt bearbeitet: 2018-11-03 13:17)

Note to self: Versuch einer lokalen Auswertung von 1096 (develop branch, rev c981bfb766): Die Region Burtokos hat in tolua_region_getkey kein at_keys Attribut, nur ein at_germs.

Update: Ich habe das falsch verstanden, das Atribut muss an den Zielregionen sein, nicht an denen mit den Toren...

(0008183)
Enno   
2018-11-03 14:29   

Leider auch heute keinen Fortschritt gemacht, weil sich die Sache einfach nicht auf Wunsch reproduzieren lässt :-(

(0008205)
Dael   
2018-11-11 21:00   

Die Einheit hat das Weltentor verlassen. Dann habe ich sie umnummeriert auf Nummer 2845 und für den Report 1100 das Weltentor 18hc wieder betreten lassen. Diesmal wurde sie teleportiert! Sie ist in Febusrad (kow9tm) in der dritten Welt heraus gekommen.

(0008206)
Enno   
2018-11-12 18:15   

Ich sage ja, das ganze funktioniert nur sporadisch nicht. Das macht die Sache ja so schwer nachzuvollziehen. Ich gebe einfach auf, ist unreproduzierbar, und nicht kritisch.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2515 [Eressea] ATTACKIERE Unschönheit nicht getestet 2018-11-07 22:48 2018-11-10 21:04
Reporter: Dael Rechnertyp:  
Bearbeitung durch: Xolgrim Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.17.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: daeL
Spiel: E2
Report: 1099
Zusammenfassung: Schlacht: 79 Krieger nicht einmal erschöpft, einer tot
Beschreibung:

Möglicherweise ist das kein Bug, sondern alles ist richtig. Es ist vielleicht nur ein Wahrscheinlichkeits-Effekt.

In Runde 1099 habe ich mit einer Einheit, die 80 Hiebwaffenkämpfer entahlten hat 29 gewöhnliche und 26 Elite-Monster angegriffen. Nach der Schlacht wurde von der Einheit noch nicht einmal "erschöpft angezeigt, d.h. sie hat im Durchschnitt der Personen noch mehr als 75% ihrer Hitpoints. Eine Person der Einheit wurde in der Schlacht getötet. Die wurde also auf 0 Hitpoints reduziert.
Ich glaube im Forum wurde einmal erklärt, dass man sich eine Schlacht-Runde so vorstellen kann: Alle Kämpfer stellen sich in einer langen Warteschlange hintereinander auf. Die Gegner stehen sich an der Spitze der beiden Warteschlangen gegenüber. Die beiden Warteschlangen-Ersten führen einen Schlag nach den Regeln durch (in den Waffentalent-Differenz, Waffen, Rüstungen, Bonus, Malus, Zufallselement eingeht). Dann stellt sich jeder in seiner Warteschlange wieder hinten an. Die Runde ist beendet, wenn aus der Seite der Schlacht mit den meisten Kämpfern jeder Kämpfer einmal gekämpft hat. Die von der Seite mit weniger Kämpfern müssen mehrmals ran.
Wenn das so geht, dann sollten alle Personen innerhalb einer Einheit relativ gleichmäßig Hitpoints verlieren. Die Streuung sollte dann nur so groß sein wie das Zufalls element bei jedem einzelnen Waffengang. In meinem Fall muss der Durchschnitts-Hitpoints-Wert nach der Schlacht bei über 75% liegen, weil ja kein "erschöpft" angezeigt wird. Und trotzdem muss einer auf 0 Hitpoints runter gehauen worden sein, da er gestorben ist. Das scheint mir eine große Streuung zu sein.

Aber vielleicht ist das Zufallselement tatsächlich so groß, dann ist alles in Ordnung. Ich wollte es nur melden, für den Fall, dass es doch nicht so beabsichtigt ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Hie der Kampfbericht aus Runde 1099:

           In Waldhausen (23,-20) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Daelirim (daeL).

Heer 0: Daelirim (daeL)
Kämpft gegen: Heer 1(ii)
Hilft: Heer 0(daeL)
Attacke gegen: Heer 1(ii)
... in der 1. Kampflinie:

  • Schwertkaempfer (7248), 80 Meermenschen, vorne, Talente: Reiten 1,
    Hiebwaffen 14, hat: 80 Bihänder, 12620 Silber, 80 Plattenpanzer, 80
    Schilde.
    ... in der 2. Kampflinie:
  • Taktiker (2678), 1 Meermensch, hinten, Talente: Armbrustschießen 3,
    Reiten 1, Taktik 14, hat: Mallornarmbrust, 30 Silber.

Heer 1: Monster (ii)
Kämpft gegen: Heer 0(daeL)
Hilft: Heer 1(ii)
... in der 1. Kampflinie:

  • Erschlagene aus dem Dunkel (3qtx), 7 Ghaste, aggressiv.
  • Schwarzknochige Skelette (hzj7), 19 Skelettherren, aggressiv.
  • Erschlagene aus dem Totenreich (i41q), 29 Ghoule, aggressiv.

Taktiker (2678) überrascht den Gegner.

Einheiten vor der 0. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 55

Einheiten vor der 1. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 49

Einheiten vor der 2. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 43

Einheiten vor der 3. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 38

Einheiten vor der 4. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 32

Einheiten vor der 5. Runde:
Heer 0(daeL): 80+1, Heer 1(ii): 26

Einheiten vor der 6. Runde:
Heer 0(daeL): 79+1, Heer 1(ii): 25
Schwertkaempfer (7248) erzielte 172 Treffer und tötete 30 Gegner.
Taktiker (2678) erzielte 1 Treffer und tötete 0 Gegner.
Schwertkaempfer (7248) verlor 1 Personen, 79 überlebten.
Erschlagene aus dem Dunkel (3qtx) verlor 1 Personen, 6 überlebten.
Erschlagene aus dem Totenreich (i41q) verlor 29 Personen.
Heer 0(daeL): 1 Tote, 0 Geflohene, 80 Überlebende.
Heer 1(ii): 30 Tote, 0 Geflohene, 25 Überlebende.

Angehängte Dateien:
Notiz
(0008200)
Xolgrim   
2018-11-08 08:35   

Deine Sichtweise des Kampfes ist mir neu, allerdings habe ich mich mit so Feinheiten auch nie wirklich auseinander gesetzt. Nach meinem Wissensstand sucht sich jeder Soldat zufällig ein Ziel aus und schlägt zu. Die HP jeder einzelnen Person werden während der Schlacht seperat gespeichert (Nach der Schlacht werden einfach nur die HP der gesamten Einheit gespeichert).
Wenn dem so ist, wie ich mich erinnere, ist der Ausgang deines kampfes ungleich wahrscheinlicher.

(0008201)
defaitist   
2018-11-09 09:43   

Zudem bewirken Monstertreffer eine Reduzierung des Kampftalentes um je einen Punkt. Wer also mehrfach getroffen wird, wird immer häufiger wieder getroffen, da irgendwann die Monster Boni wegen Talentüberlegenheit erhalten. Dies ist die sogenannte Monsterfurcht. Deshalb sind Ghoule für mittelmäßige Krieger in Platte doch gefährlich, da sie irgendwann fast immer treffen und dann noch Bonusschaden aufgrund des Talentunterschieds erzielen.

Ist natürlich trotzdem enorm unglücklich gelaufen.

(0008202)
Dael   
2018-11-10 19:47   

Ich dachte, ich hätte das mit der Kampfbeschreibung so irgendwo im Forum gelesen. Aber wenn der Kampfgegner zufällig ist, dann kann das eben auch mal zufällig ziemlich ungleichmäßig auf die Gegner verteilt sein. Und dazu noch die Monsterfurcht - dann sind halt mal irgendwann die Hitpoints weg. Ich greife diese Woche mit meinen 79 verbliebenen Kriegern an. Mal sehen, was passiert.

(0008203)
Dael   
2018-11-10 19:52   

Kann ich diesen "issue" hier eigentlich zu machen? Oder kann das nur Enno?

(0008204)
Xolgrim   
2018-11-10 21:04   

@Dael: Schließen können nur Entwickler und darüber.
Report auf Wunsch von Ersteller geschlossen


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2511 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-11-04 08:29 2018-11-07 08:38
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.7  
    Zielversion: 3.17.7  
Partei: 0
Spiel: E2
Report: 1099
Zusammenfassung: LERNE AUTO lehrt fremde Einheiten
Beschreibung:

Beim Lesen des Codes wegen des aktuellen Crashes ist mir aufgefallen, dass autostudy_init gar keine Unterscheidung macht, welcher Partei die Einheiten eigentlich angehören. Das sollte so natürlich nicht sein.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008199)
Enno   
2018-11-07 08:38   

Sollte mit der AW 1099 gefixt gewesen sein.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2506 [Eressea] General kleinerer Fehler nicht getestet 2018-10-28 10:17 2018-11-05 18:33
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.5  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.7  
    Zielversion: 3.17.6  
Partei: cwz
Spiel: E2
Report: 1097
Zusammenfassung: Berg in neuer Welt hat auf T3 immer noch keine Steine
Beschreibung:

Laut Meldung meines Nachbarzwerges hat die Einheit cgns im Berg Kufus mit Steinbau T3 immer noch keine Steine entdecken können. Da es sich hier um wenige Wochen alte Parteien in einer "neuen" Welt handelt, sollte das eigenlich nicht möglich sein.

Schritte zur Reproduktion:

Einheit cgns, Partei cwz

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008167)
Enno   
2018-10-28 10:19   

Das Terraforming von Hand, das ich hier gemacht habe, könnte der Grund sein.

(0008168)
Enno   
2018-10-28 14:24   

Ich sehe mir das an, und es gibt Steine erst ab Stufe 11. Das darf in jungen Welten nicht sein.

(0008176)
Enno   
2018-10-30 21:02   

Ich habe mir etwas Spezialcode in das SL-Tool gebaut, mit dem man betroffene Regionen reparieren kann. Sie sollten aber am besten gar nicht erst entstehen, das muss ich mir noch einmal anschauen, ob das jetzt repariert ist.

(0008191)
Enno   
2018-11-05 13:45   

@Woschak hat hier noch was zu zu sagen.

(0008193)
Enno   
2018-11-05 18:33   

Danke, da habe ich bei der Reparatur die Liste der betroffenen Inseln zu klein eingeschätzt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2512 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2018-11-04 18:11 2018-11-04 18:12
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: KONTAKTIERE PARTEI
Beschreibung:

Ich plane, einen Befehl "KONTAKTIERE PARTEI foo" zu implementieren, der dazu führt, dass die befehlende Einheit quasi KONTAKTIERE zu allen Einheiten der Partei 'foo' setzt.

Das hat zur Folge, dass der bisherige Befehlssyntax von "KONTAKTIERE [TEMP] foo" auf "KONTAKTIERE EINHEIT [TEMP] foo" geändert wird, damit Einheit mit Namen P, PA, PAR oder PART kontaktiert werden können.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Bis auf weiteres bleibt das Verhalten ohne PARTEI|EINHEIT wie bisher, sollte aber vermieden werden.

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2463 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-07-17 18:39 2018-11-03 20:31
Reporter: Tar_Nelarn Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: td
Spiel: E2
Report: 1084
Zusammenfassung: Weihnachtsbaum defekt?
Beschreibung:

Partei: td
Runde: 1084
Einheit: vp0j

Ich habe im letzten Zug, also für diese Runde, "Benutze Weihnachtsbaum" gesetzt
(tatsächlich sogar via Default in der Runde davor, da ich diese nicht da war).

Ziel war den Weihnachtsbaum genau mit Anfang des Winters zu aktiveren.

1083: Es ist Herbst. (Benutze durch Einheit vp0j)
1084: Es ist Winter. (sollte aktiv sein)

Das benutze hat zwar geklappt, aber die Wirkung blieb aus:

Meldung 1084: Holzfäller (vp0j) benutzt Weihnachtsbaum.

Das erwartete:

In der Region erstrahlen des Nachts bunte Lichter, Gloeckchen klingeln und
frohes Kindergelaechter klingt durch den Wald.

aber blieb aus (sowie der Effekt).

Zuletzt hatte ich in Runde 949 den Vorgang anderen Ortes beobachtet - da schien
alles noch zu funktionieren:

-- nr-Report, Runde 949 --
Ereignisse

Wicht (cmfi) benutzt Weihnachtsbaum.

                          Magie und Artefakte

In der Region erstrahlen des Nachts bunte Lichter, Gloeckchen klingeln und
frohes Kindergelaechter klingt durch den Wald.


Der Effekt hielt dann bis Runde 957 an (9 Wochen), wie erwartet.

Was mag da los sein? Hat sich da was geändert oder habe ich was übersehen?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007971)
Xolgrim   
2018-07-18 17:22   

Ich hab nen Tip für den nächsten Baum. Du kannst die auch schon (lange) vor dem Winter nutzen, die wirkung bleibt auf der Region gespeichert bis der erste Winter vorbei ist (zumindest wenn das Teil tut, was es soll)

(0007973)
Pyanfar   
2018-07-20 03:55   

Ich fürchte, ich weiß was passiert ist: Da scheint der Baum-Effekt aus E3 reingepfuscht zu haben:
"I. Armee III. Division I. Korps (gve3) benutzt Weihnachtsbaum." (Partei 7).
Effekt:
Mallorn: 114028 [+10] (aktuell)

Es sind also nur 10 Mallornbäume dazu gekommen statt des erwarteten %-Zuwachses über den ganzen Winter :(

(0007974)
Tar_Nelarn   
2018-07-20 15:59   

+10? Hmm - nicht ganz der erwartete Effekt.. aber in E2 sollte es schon noch auf die alte Art klappen, oder?

@Xolgrim: Danke - das vereinfacht die Sache in der Tat.

(0007975)
Enno   
2018-07-21 05:47   

Hat das auch mit den Jahreszeiten zu tun, so wie 0002458?

(0007976)
Xolgrim   
2018-07-21 09:11   

@Enno: Eigentlich sollte unabhängig von der Jahreszeit eine Meldung kommen, die den Effekt auf der Region ankündigt. Ich bin mir nur nicht sicher, ob das immer die Meldung ist:

"In der Region erstrahlen des Nachts bunte Lichter, Gloeckchen klingeln und frohes Kindergelaechter klingt durch den Wald."

Oder ob das eine andere Meldung in den anderen Jahreszeiten ist.

(0007977)
Enno   
2018-07-21 10:21   

Die Meldung mit den bunten Lichtern gibt es nur im Winter. Ebenso die Baumvermehrung. Ist also wohl noch ein Element der Jahreszeiten-Anzeige.

(0007978)
Xolgrim   
2018-07-21 10:49   

Habs endlich gefunden... von Runde 939 auf Runde 940 einen Weihnachtsbaum in Ebene der Elemente benutzt. (Das war Sommer) und nur die Meldung erhalten "Xolgrim (xoLg) benutzt Weihnachtsbaum." keine sonstige Meldung auf der Region wie ich in Erinnerung hatte. Im Winter hat der Baum dann wie geplant funktioniert.

(0007979)
Tar_Nelarn   
2018-07-21 15:02   

@Enno:

Hat das auch mit den Jahreszeiten zu tun, so wie 0002458?

Habe gerade geschaut - diese Runde (1085) gab es auch keine bunten Lichter und auch keinen Effekt (Winter war im letzten und in diesem Report, also 1084 und 1085).

@Pyanfar:
Habe nochmal genau hingeschaut - letzte Woche (1084, "Benutze ist aktiv geworden") sind in der Tat 10 Bäume dazugekommen. Diese ist alles unverändert geblieben. Klingt als könntest Du recht haben.

(0008022)
Enno   
2018-08-05 21:34   

Ich gucke mir das diese Woche noch einmal an, wenn ich Zeit finde. Falls es da eine Änderung für E3 gegeben hat (an die ich mich gerade nicht erinnere) war nicht geplant, dass die auch in E2 gilt.

(0008023)
Xolgrim   
2018-08-09 10:21   

Das Weihnachtsbäume in E3 nicht so viel Holz produzieren wie in E2 ist ur-alt und keine neue Änderung glaube ich. Aber die andere Funktion sollte halt nicht für E2 gelten und das tat sie bis vor 'kurzen' (also mindestens Rudne 940 ) auch offenkundig nicht.

(0008026)
Enno   
2018-08-11 13:03   

Oh weia.

    u.region:set_key(&quot;xm06&quot;, true)
    u.region:set_resource(&quot;tree&quot;, 10+trees)

Da wird ein key gesetzt, und die Bäume um 10 erhöht. Letzteres ist der E3 Effekt. Ersteres sollte eigentlich in einem at_keys in der Region gespeichert werden, aber das kann ich nicht finden :-(

Ist also definitiv kaputt, UND mit dem Effekt aus E3 vermischt.

(0008028)
Enno   
2018-08-11 15:48   

Das erste, was mir auffällt: set_key (region, faction, global) hat ein Default-Value von 0 (was einem remove entspricht). Allerdings benutzt use_xmastree es mit einem expliziten Parameter, das sollte also nichts bedeuten.

(0008029)
Enno   
2018-08-11 16:24   

Ich habe ein dunkles Gefühl, dass das ein Fehler im DEFAULT Befehl sein könnte, wenn man einen kurzen Befehl zum Default zu machen versucht.

(0008030)
Xolgrim   
2018-08-12 15:32   

Was heist "zu machen versucht" das funktioniert wunderbar mit kurzen Default Befehlen ...

(0008102)
Enno   
2018-09-15 19:00   

Ich habe gerade mal die at_keys Speicherung an Regionen repariert, wo wohl die Sache mit dem Effekt drin gespeichert wird? Da war etwas schlimm faul. Hoffentlich geht dabei nichts kaputt, bitte mal in die nächste Testauswertung gucken..

(0008189)
Enno   
2018-11-03 20:31   

Das hatte mit DEFAULT in der Tat nichts zu tun, sondern mit einem uralten Fehler in der Lua API für Regions-Keys.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2482 [Eressea] GIB kleinerer Fehler nicht getestet 2018-08-30 16:28 2018-11-03 18:24
Reporter: Bruck Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: hdbs
Spiel: E3
Report: 472
Zusammenfassung: Untote können mit der Kobination RESERVIERE + GIB ALLES nicht umgehen
Beschreibung:

Eventuell nicht in richtiger BUG, aber IMO ein unerwünschtes Verhalten.

Untote nehmen ja nichts an (gewollt) können aber neuerdings abgeben (auch gewollt). Die Kombination habe ich eigentlich gesetzt, damit sie nicht durch Beute überladen werden, und erwarten das sie zwar nichts dazu bekommen (außer Beute), das was sie habe aber reserviert ist und NICHT abgegeben wird.

Rostige Eisenhälse (u438): 1
@RESERVIEREN je 1 Kriegsaxt
@RESERVIERE je 1 Schild
@RESERVIERE JE 1 Plattenpanzer
@gib 4et2 ALLES

In 472 ist alles abgegeben und nichts behalten. Oder anders, der Server hat RESERVIERE vermutlich einfach ignoriert weil Untot, und dann GIB ganz normal ausgeführt. Im Gegensatz zu GIB an untote hat es keine Fehlermeldung gegeben, zumindest das sollte ein BUG sein.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008055)
Enno   
2018-09-08 21:18   

Ich glaube, Du kannst mit der Vermutung Recht haben. Im Code steht:

static int reserve_i(unit * u, struct order *ord, int flags)
{
    char token[128];
    if (u->number > 0 && (u_race(u)->ec_flags & ECF_GETITEM)) {

und ECF_GETITEM ist das Flag, über das Untote signalisieren, dass sie nichts annehmen.

(0008056)
Enno   
2018-09-08 21:20   

Ja, ich sehe es auch beim Auswerten: die Einheit hat keine Reservierungen gemacht, wenn ihr GIB ausgeführt wird.

(0008111)
Enno   
2018-09-22 08:52   

Wenn ich das richtig sehe, ist das korrekte Verhalten hier, dass Untote nichts reservieren, es dann aber eine Fehlermeldung gibt, wenn sie es trotzdem probieren?

(0008187)
Enno   
2018-11-03 16:13   

Evtl. ist die beste Lösung, dass Untote nur eigene Gegenstände reservieren können.

(0008188)
Enno   
2018-11-03 18:24   

Gefunden, gefixt; hat: Kriegsaxt, Plattenpanzer, Schild.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2510 [Eressea] General kleinerer Fehler nicht getestet 2018-11-03 10:01 2018-11-03 13:51
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: ii
Spiel: E2
Report: 1096
Zusammenfassung: Verschwundene Region
Beschreibung:

Im Datenfile 1095 gibt es eine Einheit Perrankar, die Listige (496864), die ein Bewegungsziel hat fr eine Region mit der ID 345090632. Diese Region ist in den Daten aber nicht zu finden, und mit dem neuen read_region_reference / region_create Code in 3.18 gibt das einen CRash, weil spaeter in plan_monsters auf r->terrain zugegriffen wird, und das NULL ist. Wie kann es sein, dass eine Region nicht in den Spieldaten ist? Wird evtl. die ID neu gesetzt, wenn sie im Chaos versinkt? Die Einheit ist in der Ebene Nali (20,6), das ist ehemaliges Alliance-Territorium, erste Welt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008181)
Enno   
2018-11-03 10:06   
(Zuletzt bearbeitet: 2018-11-03 10:07)

Korrektur: Die ID ist im Datenfile, es ist die Ebene Anorien (28, -2). Aber in new_region wird mit rfindhash(x, y) nach ihr gesucht, und dann wird sie ein zweites Mal erzeugt, weil die Referenz nur die UID kennt, und nicht mit X,Y gehasht hat. Oops.

Dito wird in readregion die REgion mit dinfregion(x, y) gesucht, was bestimmt auch verkehrt ist?


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2507 [Eressea] General kleinerer Fehler nicht getestet 2018-10-28 15:00 2018-10-29 20:21
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.6  
    Zielversion: 3.17.6  
Partei: 0
Spiel: E2
Report: 1098
Zusammenfassung: LERNE AUTO Dudelidu stürzt ab.
Beschreibung:

Wenn expensive_skill() mit NOSKILL aufgerufen wird, weil das Talent nicht geparsed wird ein Array mit negativem Index indiziert, was undefiniertes Verhalten ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008169)
Enno   
2018-10-28 21:43   

Fehler ist gefunden, und bei mir lokal repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2505 [Eressea] MACHE kleinerer Fehler nicht getestet 2018-10-28 09:57 2018-10-29 20:20
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.6  
    Zielversion: 3.17.6  
Partei: wiki
Spiel: E2
Report: 1098
Zusammenfassung: Einheit verbaut zu viele Steine in neue Burg
Beschreibung:

Anleitung sagt: "Eine Einheit kann pro Runde Talentstufe x Personen / Mindesttalent Steine verbauen"
Meine Einheit (g1h1) hat 2 Personen mit T1, und 4 Steine, baut eine neue Burg mit MACHE BURG.
Erwartung: Einheit kann 2 Steine verbauen, ich stehe in einem Handelsposten Größe 2.

Resultat:
Eiríkr Þorvaldsson (g1h1) baut für 4 an Burg (og8x) weiter.

Katastrophe! Ich brauche die anderen beiden Steine für einen zweiten Handelsposten, meine ganze Partei ist darauf ausgelegt, dass das klappt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008170)
CwZ   
2018-10-29 14:27   

In Woche 1096, Einheit 8pez (Burgenbau 3) hat den Befehl "MACHE Burg".
Erwartung: Einheit verbaut 3 von 4 zu verfügung stehenden Steinen zu einer Burgen Größe 3.

Resultat: Einheit 8pez (8pez) baut für 4 an Burg (w5he) weiter.

(0008173)
Enno   
2018-10-29 19:36   

Für den von mir gemeldeten Fall ist das jetzt korrekt. Den anderen Fall schaue ich mir aber auch noch an, ehe ich dieses Ticket schließe.

(0008174)
Enno   
2018-10-29 20:16   

Bei einem neuen Versuch von Auswertung 1096 mit dem reparierten Code sehe ich da jetzt:
Einheit 8pez (8pez) baut für 3 an Burg (Lkd0) weiter.

Wenn Du nicht protestierst, gebe ich Dir den Stein gerne zurück, und mache die Burg entsprechend kleiner. Aufpassen, die Einheit 8pez hat dann mit sofortiger Wirkung einen Stein (und kann sich nicht bewegen).

(0008175)
Enno   
2018-10-29 20:20   

Spieldaten sind angepasst.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2508 [Eressea] General kleinerer Fehler nicht getestet 2018-10-28 21:53 2018-10-29 19:08
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.18  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: 0
Spiel: Deveron
Report: 1098
Zusammenfassung: valgrind error message
Beschreibung:

In current develop version

Schritte zur Reproduktion:

0 Factions with 1 NMR
==15228== Conditional jump or move depends on uninitialised value(s)
==15228== at 0x188C02: report_region (report.c:1244)
==15228== by 0x18CFCF: report_plaintext (report.c:2206)
==15228== by 0x193192: write_reports (reports.c:1682)
==15228== by 0x193563: reports (reports.c:1765)
==15228== by 0x137C1E: tolua_write_reports (bindings.c:395)
==15228== by 0x4E44C74: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E50824: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44F9D: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E40FDA: lua_callk (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E54A1F: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44C74: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44F91: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228==
==15228== Conditional jump or move depends on uninitialised value(s)
==15228== at 0x188C02: report_region (report.c:1244)
==15228== by 0x18D1AF: report_plaintext (report.c:2238)
==15228== by 0x193192: write_reports (reports.c:1682)
==15228== by 0x193563: reports (reports.c:1765)
==15228== by 0x137C1E: tolua_write_reports (bindings.c:395)
==15228== by 0x4E44C74: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E50824: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44F9D: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E40FDA: lua_callk (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E54A1F: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44C74: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228== by 0x4E44F91: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.2.so.0.0.0)
==15228==

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008171)
Enno   
2018-10-29 16:06   

1244 if (edges[e].exist[d]) {

Da muss edges initialisiert werden, das liegt auf dem Stack.

(0008172)
Enno   
2018-10-29 16:22   

Ich glaube, das war's. Noch einmal coverity drüber senden, dann sollte es gut sein.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2493 [Eressea] General schwerer Fehler nicht getestet 2018-09-16 19:29 2018-10-26 20:41
Reporter: defaitist Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: hoch BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: styx
Spiel: E2
Report: 1093
Zusammenfassung: Kräuter vermehren sich anscheinend nicht mehr
Beschreibung:

Ich versuche in meinen Regionen ein pflegeleichtes und nachhaltiges Kräutersammeln ohne großes Nachjustieren zu etablieren. Von Frühling bis Herbst werden je 10 Kräuter pro Woche gesammelt, in den drei Wintermonaten wird nicht gesammelt, damit sich die Bestände erholen können. Beim Übergang wird zur Sicherheit jeweils eine Woche FORSCHE KRÄUTER gesetzt.

Das hat die letzten Jahre geklappt, die Bestände sind immer im Winter leicht angestiegen. Diese Woche jedoch wird der Bestand beibehalten, es gibt in allen Regionen die gleiche Meldung wie in Woche 1085.

Und auch da ist mir aufgefallen, dass die meisten Regionen schon damals nicht mehr "sehr viele", sonder nur noch "viele" Kräuter vorgewiesen haben. Dies lässt mich vermuten, dass die Wachstumsraten erneut reduziert wurden, als Reaktion auf die vorherige Änderung habe ich MACHE KRÄUTER in MACHE 10 KRÄUTER geändert.

Intendiert oder was kaputtgegangen?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008107)
Enno   
2018-09-20 18:31   

Auf keinen Fall beabsichtigt gewesen.

(0008108)
defaitist   
2018-09-22 01:51   

Aber ihr schaut rein? Denn sonst geht die Welt auf eine Kräuterknappheit zu und ich möchte nicht im Herbst feststellen, dass ich kaum noch Kräuterbestände habe und dann die WdL nachzüchten müssen.

(0008109)
Enno   
2018-09-22 08:40   

Wenn Du mir noch sagen würdest, welche Einheit das ist, und was Du gemacht hast, um das zu reproduzieren, wird das leichter nachzuprüfen.

(0008110)
Enno   
2018-09-22 08:49   

Im Winter vermehren sich Kräuter nicht. Jetzt im Frühling tun sie es, das habe ich mir gerade angeschaut.

(0008165)
defaitist   
2018-10-26 14:14   

Nur als Anmerkungen, damit es danach endgültig geschlossen werden kann. In zwei Regionen mit geringem Bestand haben nun meine Kräutersammler durchgehend jede Woche geforscht und die Bestände steigen wieder an. Das als endgültiger Beweis, dass sich die Bestände von Frühling bis Herbst erholen und dann im Winter stagnieren.

Danke für die Aufklärung.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2503 [Eressea] Monster Unschönheit nicht getestet 2018-10-21 09:05 2018-10-23 18:23
Reporter: Caranthir Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: dringend BS-Version:  
Status: erledigt Produktversion: 3.17.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.5  
    Zielversion: 3.17.5  
Partei: cara
Spiel: E2
Report: 1097
Zusammenfassung: Erhöhte Wahrscheinlichkeit für neue Untote?
Beschreibung:

Auf unserer Insel (Partei dgpf und meine Partei) sorgen wir dafür, dass immer deutlich weniger Bauern vorhanden sind, als in einer Region maximal ernährt werden können. So wollen wir das Auftreten von Untoten vermeiden. Bisher hat das über die Spieljahre hinweg gut funktioniert, aber nun ist zum zweiten Mal in Folge eine Untotengruppe neu entstanden. Gefühlt scheint sich seit der kürzlich aufgetretenen Drachenplage die Wahrscheinlichkeit für Untote erhöht zu haben. Auch auf anderen Inseln, auf der Einheiten meiner Partei sind, gab es neue Untotengruppen.

Bitte mal überprüfen, ob sich hier etwas in eine ungewollte Richtung verändert hat (gefühlt hat es das jedenfalls).

Schritte zur Reproduktion:

N/A

Zusätzliche Informationen:

Reporte können bei Bedarf nachgereicht werden.

Angehängte Dateien:
Notiz
(0008149)
Xolgrim   
2018-10-21 09:22   

Die sind nicht zufällig in den Regionen entstanden in denen für kurze Zeit die Drachen standen und die Bauern gefressen haben?

(0008150)
Caranthir   
2018-10-21 09:25   

Nein, das war auf dieser Insel in nur einer Region, die auch eine andere war.
Es sieht ("gefühlt") so aus, dass die Jungdrachenwahrscheinlichkeit zurückgesetzt wurde, aber die Untotenwahrscheinlichkeit nicht. Falls die zu der Zeit auch höher war als früher.

(0008154)
Enno   
2018-10-21 18:03   

Eressea hat bisher keine Möglichkeit, während der Auswertungen eine Statistik zu erstellen (z.B. die Zahl der erzeugten Monster). Da baue ich mal ein API, implemntiere das für Monster, und checke die Werte für eine Auswertung mit unterschiedlichen Versionen des Codes.

(0008155)
Enno   
2018-10-21 19:21   

Anzahl erzeugte Einheiten mit den Daten von 1096 und aktuellem Code:
monsters.create.dracoid: 23
monsters.create.dragon: 12
monsters.create.seaserpent: 30
monsters.create.undead: 178

(0008156)
Enno   
2018-10-21 19:45   

Nochmal, weil ein Fehler in meinem Code war (allerdings nicht signifikant in diesem Fall):
monsters.create.dracoid: 26
monsters.create.dragon: 16
monsters.create.seaserpent: 28
monsters.create.undead: 156
Eressea version 3.17.3-7-g38c1dfe26

monsters.create.dracoid: 26
monsters.create.dragon: 13
monsters.create.seaserpent: 29
monsters.create.undead: 84
Eressea version 3.16.0-63e950037

(0008157)
Enno   
2018-10-21 19:48   

Was man da sieht, ist dass sich zumindest seit dem ersten Release von 3.16 die Anzahl Untote sich beinahe verdoppelt hat. Für eine Sample Size von einer Auswertung, zugegebenermaßen. Drachen, Seeschlangen und andere Monster sind dagegen gleich geblieben. Bleibt die Frage, warum?

(0008158)
Enno   
2018-10-21 20:17   

Am Code hat sich in der Tat etwas getan, da habe ich irgendwann zwischen den Versionen den Aufruf von chaosfactor() rausgekürzt. Kann sein, dass ich mich bei der Berechnung der Wahrscheinlichkeit verrechnet habe. Ein "smoking gun" nennt man das wohl.

(0008159)
Enno   
2018-10-22 20:05   

Ich werde ein außerplanmäßiges Minor Release machen, Version 3.17.5, um das zu reparieren. Die Änderung ist minimal, und sollte nicht auf Dezember warten müssen.

(0008160)
Caranthir   
2018-10-22 20:07   

Sehr schön, ich bedanke mich!

(0008161)
Enno   
2018-10-22 20:07   

Das Problem hier war, dass früher die Wahrscheinlichkeit für Untote in Chaos-Regionen höher war als anderswo. Beim Versuch, sie überall gleich zu machen, habe ich einen Fehler gemacht, und sie Chaos-Wahrscheinlichkeit ist zum neuen Normal geworden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2502 [Eressea] ZAUBER schwerer Fehler immer 2018-10-21 01:32 2018-10-23 18:23
Reporter: defaitist Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: dringend BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion:  
Partei: styx
Spiel: E2
Report: 1097
Zusammenfassung: Feuerballzauber macht keinerlei Schaden
Beschreibung:

Wie schon zuvor vermutet bei den kleinen Feuerbällen der Flammenschwerter, so macht auch der richige, durch Magier direkt gezauberte Feuerball keinerlei Schaden.

           In Düsterwald (114,-37) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Trollische Räte-Union (styx).

Heer 0: Trollische Räte-Union (styx)
Kämpft gegen: Heer 1(ii)
Hilft: Heer 0(styx)
Attacke gegen: Heer 1(ii)
... in der 1. Kampflinie:

  • Valenz, der Meister der Schatten (Loki), 1 Troll, vorne, Talente: Magie
    Draig 22, Segeln 0, Stangenwaffen 13, Taktik 7, Tarnung 9, Wahrnehmung 4,
    Steuereintreiben 5, Ausdauer 19, hat: Hellebarde, 2 Heiltränke,
    Laenkettenhemd, Laenschild, Mistelzweig, 178128 Silber, 2 Wundsalben, 4
    Siebenmeilentees, 2 Gehirnschmalz, Ring der Unsichtbarkeit, Ring der
    Macht, 3 Speere, Gürtel der Trollstärke. Aura 437/437, Zauber:
    Feuerball, Rosthauch, Fluch der Pestilenz, Gabe des Chaos, Wahnsinn des
    Krieges, Blutrausch, Machtübertragung, Beschwöre Schattendämonen,
    Beschwöre Schattenmeister, Mächte des Todes, Astraler Riss, Feuerteufel,
    Chaossog, Todeswolke, Drachenruf, Vertrauten rufen, Chaosfluch,
    Pentagramm, Astrales Chaos, Feuerwand, Verwünschung, Untote Helden,
    Unheilige Kraft, Kleines Blutopfer, Erschaffe einen Ring der
    Unsichtbarkeit, Kleine Flüche, Erschaffe ein Amulett des wahren Sehens,
    Erschaffe ein Flammenschwert, Erschaffe einen Gürtel der Trollstärke,
    Kampfzauber: keiner, Feuerball, Untote Helden; Ein pechschwarzer Troll, um
    den Schattenzungen zucken und dessen dunkelrote Augen unheilvoll glühen.
    Nach dem Tod Houdini Hügellands in verwüsteten Nornenwald übernahm er
    die Position des Dritten Schattenmagiers bei den drolligen Trollen und hat
    geschworen, seinen Tod zu rächen mit der Zerschlagung der Dragonsworn und
    all ihrer Verbündeten bis zur totalen Vernichtung dieser, sollte es denn
    darauf hinauslaufen und der Feind uneinsichtig weiterkämpfen.

Heer 1: Monster (ii)
Kämpft gegen: Heer 0(styx)
Hilft: Heer 1(ii)
... in der 2. Kampflinie:

  • Xxaaxz'ckk (mi5m), 4 Dracoide, hinten, hat: 3 Bögen.

Valenz, der Meister der Schatten (Loki) überrascht den Gegner.

Einheiten vor der 0. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) zaubert Feuerball: 0 Krieger wurden
getötet.

Einheiten vor der 1. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) versucht Feuerball zu zaubern, doch
der Zauber schlägt fehl!

Einheiten vor der 2. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) zaubert Feuerball: 0 Krieger wurden
getötet.

Einheiten vor der 3. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) zaubert Feuerball: 0 Krieger wurden
getötet.

Einheiten vor der 4. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) zaubert Feuerball: 0 Krieger wurden
getötet.

Einheiten vor der 5. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) zaubert Feuerball: 0 Krieger wurden
getötet.

Einheiten vor der 6. Runde:
Heer 0(styx): 1, Heer 1(ii): 0+4
Valenz, der Meister der Schatten (Loki) erzielte 257 Treffer und tötete 0
Gegner.
Valenz, der Meister der Schatten (Loki) kann in Düsterwald (114,-37) keine
Untoten rufen.
Heer 0(styx): 0 Tote, 0 Geflohene, 1 Überlebende.
Heer 1(ii): 0 Tote, 0 Geflohene, 4 Überlebende.

Schritte zur Reproduktion:

Zum Vergleich die Resultate von 100 Flammenschwertern gegen uralte Untote, die bekanntlich nur ca. 20 Schadenspunkte besitzen:

Einheiten vor der 0. Runde:
Heer 0(styx): 529, Heer 1(ii): 18226, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.

Einheiten vor der 1. Runde:
Heer 0(styx): 529, Heer 1(ii): 15839, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.

Einheiten vor der 2. Runde:
Heer 0(styx): 529, Heer 1(ii): 13416, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.

Einheiten vor der 3. Runde:
Heer 0(styx): 529, Heer 1(ii): 11011, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.

Einheiten vor der 4. Runde:
Heer 0(styx): 529, Heer 1(ii): 8513, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.

Einheiten vor der 5. Runde:
Heer 0(styx): 529, Heer 1(ii): 6009, Heer 2(styx): 2384
100 Krieger von 7. Schwadron Blau (kj2) benutzen ihre Flammenschwerter.

  1. Schwadron Blau (kj2) tötete 0 Krieger.
    4 Krieger von Meisterfechter (wxon) benutzen ihre Flammenschwerter.
    Meisterfechter (wxon) tötete 0 Krieger.
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008151)
Xolgrim   
2018-10-21 09:32   

Sollte in Version 1.80 behoben sein, also mit dem nächsten Update. Bekommst du die Test AW von Eressea? Falls nein kannst du dich von Enno auf die Liste setzen lassen. Dann bekommst du zusätzlich jeden Sonntag die normale AW welche aber mit den aktuellsten Änderungen durchgeführt wurde schon bevor diese live gehen.

(0008152)
defaitist   
2018-10-21 13:12   

Seit 8 Jahren kriege ich ja noch nichtmal die E-Announce und wurde trotz mehrfacher Nachfrage nicht wieder auf diese Liste gesetzt. Zudem birgt eine Testauswertung nur die Gefahr von Verwechslung und ernsthaft fatalen Folgen für Befehlseinsendungen.

Ist beruhigend, dass die Magieresistenz repariert wurde, oder was auch immer die Ursache dieses Fehlers ist.

PS: Die "Warnmail" bei Reportnachforderungen durch eine zweite Adresse ist auch kaputt. Teile mir ja die Partei, ist vor ca. 3/4 Wochen das erste mal aufgefallen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2480 [Eressea] ATTACKIERE schwerer Fehler nicht getestet 2018-08-28 13:46 2018-10-23 18:23
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Solthar Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: 1wpy
Spiel: E2
Report: 1090
Zusammenfassung: Drachenodem macht keinen Schaden, Magieresistenz kaputt?
Beschreibung:

2600 Unbewaffnete ohne Ausdauer haben gegen einen Wyrm gekämpft. Der hat fleißig Drachenodem gezaubert, es gab aber nur 4 Tote durch die konventionellen Angriffe. Der Drachenodem macht bei 800 Gegnern 11-26 Schaden, sollte also viele töten.

Schritte zur Reproduktion:
Zusätzliche Informationen:
               In Sotat (53,11) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Monster (ii).

Heer 0: Monster (ii)
Kämpft gegen: Heer 1(1wpy), Heer 2(1wpy)
Hilft: Heer 0(ii)
Attacke gegen: Heer 1(1wpy)
... in der 1. Kampflinie:

  • Die Sanddrachen von Pannonia (ha81), 1 Wyrm, aggressiv, bewacht die Region.

Heer 1: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy)
... in der 2. Kampflinie:

  • Schlauer Bauer (kLzi), 1 Meermensch, defensiv, Talente: Pferdedressur 5,
    Reiten 5, Hiebwaffen 8, Segeln 8, Stangenwaffen 2, Taktik 12, Tarnung 2,
    Ausdauer 2, hat: 5 Pferde, 8150 Silber, Plattenpanzer, Schild, Schwert.

Heer 2: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy)
... in der 2. Kampflinie:

  • Segler (h5pq), 2600 Meermenschen, defensiv, Talente: Unterhaltung 8, hat:
    1988 Pferde, 15360551 Silber.

Schlauer Bauer (kLzi) konnte dem Gegner eine Falle stellen.

Einheiten vor der 0. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2600

Einheiten vor der 1. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2600
Die Sanddrachen von Pannonia (ha81) zaubert Großer Drachenodem: 0 Krieger
wurden getötet.

Einheiten vor der 2. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2599
Die Sanddrachen von Pannonia (ha81) zaubert Großer Drachenodem: 0 Krieger
wurden getötet.

Einheiten vor der 3. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2599
Die Sanddrachen von Pannonia (ha81) zaubert Großer Drachenodem: 0 Krieger
wurden getötet.

Einheiten vor der 4. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2598
Die Sanddrachen von Pannonia (ha81) zaubert Großer Drachenodem: 0 Krieger
wurden getötet.

Einheiten vor der 5. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2597
Die Sanddrachen von Pannonia (ha81) zaubert Großer Drachenodem: 0 Krieger
wurden getötet.

Einheiten vor der 6. Runde:
Heer 0(ii): 1, Heer 1(1wpy): 0+1, Heer 2(1wpy): 0+2596
Schlauer Bauer (kLzi) erzielte 1 Treffer und tötete 0 Gegner.
Segler (h5pq) erzielte 985 Treffer und tötete 0 Gegner.
Segler (h5pq) verlor 4 Personen, 2596 überlebten.
Heer 0(ii): 0 Tote, 0 Geflohene, 1 Überlebende.
Heer 1(1wpy): 0 Tote, 0 Geflohene, 1 Überlebende.
Heer 2(1wpy): 4 Tote, 0 Geflohene, 2596 Überlebende.

Angehängte Dateien:
Notiz
(0008044)
Solthar   
2018-08-28 13:47   
(Zuletzt bearbeitet: 2018-08-28 17:42)

Bei genauerem Hinsehen ist dafür commit 5af5daa3 für Bug 0002378 verantwortlich.

@@ -1184,8 +1184,9 @@ terminate(troop dt, troop at, int type, const char *damage, bool missile)
         return false;
     }

     if (magic) {
+        res = frac_sub(frac_one, res);
         res = frac_mul(frac_make(da, 1), res);
         da = res.sa[0] / res.sa[1];
     }

Ist falsch (und res schlecht benannt), da in calculate_armor schon von 1 subtrahiert.

Magieresistenz ist also invertiert und sollte dringend gefixt werden.

(0008045)
Bruck   
2018-09-01 17:14   

Ich hab Null Ahnung vom Code, mir ist aber aufgefallen das in unseren ganzen letzten Schlachten in E3 die Flammenschwerter auch nie jemanden getötet haben. Hängt das eventuell zusammen?
Beispiel aus einer letzten Kampfrunde mit sehr vielen Toten:

  • 6 Krieger von Rag Set (eped) benutzen ihre Flammenschwerter.
  • Rag Set (eped) tötete 0 Krieger.
    Normale Treffer zum Vergleich:
    Rag Set (eped) erzielte 269 Treffer und tötete 23 Gegner.
(0008046)
Xolgrim   
2018-09-01 18:59   

Wenn ich die Meldung mit der Benutzung wirklich nur auf den magischen Schaden bezieht, dann kommt da noch was bei rum. Diese Woche hatte ich die Meldung

15 Krieger von Konzilianische Garde (zorn) benutzen ihre Flammenschwerter.
Konzilianische Garde (zorn) tötete 2 Krieger.

Gegen Ghast kann die geringe Opferzahl durchaus sein. Insgasamt haben die 15 Flammenschwerter in 6 Runden 3 Gegner getötet.

(0008047)
Solthar   
2018-09-02 14:44   

Ist definitiv kaputt und alle magischen Attacken und Kampfzauber betroffen. Ghoule sind ironischerweise im Gegensatz zu Menschen nicht immun, weil sie Magieresistenz haben.

function test_wyrm_fight()
  local r = region.create(0, 0, &quot;plain&quot;)
  local f = faction.create(&quot;human&quot;, &quot;hodor@eressea.de&quot;, &quot;de&quot;)
  local u1 = one_unit(r, f)
  local monster = unit.create(get_monsters(), r, 1, &quot;wyrm&quot;)
  u1.number = 30
  u1.hp = u1.hp_max * u1.number
  monster:add_order(&quot;ATTACK &quot; .. itoa36(u1.id))
  process_orders()
  assert_equal(0, u1.number);
end
(0008051)
Enno   
2018-09-08 10:29   

Danke für den PR, ich gucke mir das an und baue es ein, wenn es meinem Review Stand hält.

(0008054)
Enno   
2018-09-08 21:13   

@Solthar ich habe im Review auf Github etwas zu Deiner Lösung geschrieben. Willst du weiter machen mit diesem Bug?

(0008134)
Enno   
2018-10-13 20:26   

Habe den PR akzeptiert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2500 [Eressea] Monster Unschönheit nicht getestet 2018-10-09 16:54 2018-10-14 18:36
Reporter: Dael Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: nicht reproduzierbar  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: Dael
Spiel: E2
Report: 1095
Zusammenfassung: Wieder erhöhte Jungdrachenerzeugnungswahrscheinlichkeit?
Beschreibung:

Im Report Nr. 1095 wurden mir zwei Jungdrachen-Sichtungen gemeldet. In den allermeisten Reports entstehen gar keine Jungdrachen. Nun enthält die Erzeugung ein Zufallselement und es kann daher durchaus sein, dass zwei Jungdrachen entstanden sind, obwohl die Erzeugungs-Wahrscheinlichkeit sehr gering ist. Es ist halt Zufall. Aber da wir kürzlich eine Jungdrachen-Schwemme hatten, könnte es auch sein, dass der Wert für die Erzeugungs-Wahrscheinlichkeit wieder verrutscht ist?

Schritte zur Reproduktion:

Mal sehen, ob im nächsten Report wieder Jungdrachen entstehen.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008122)
Enno   
2018-10-09 19:46   

Ich habe keinen Grund zur Annahme, das es da eine Regression gegeben haben sollte, zumal auch kein anderer Spieler das gemeldet hat.

Es gab allerdings irgendwo eine Wortmeldung, die Drachenplage habe sich auch auf E3 und Deveron ausgewirkt, das sollte ich mir mal angucken, deshalb lasse ich mir diesen Report mal zur Erinnerung stehen.

(0008129)
Dael   
2018-10-10 21:50   

Da es Zufall ist, können natürlich auch mal zwei Jungdrachen entstehen. Warten wir mal nächste Woche ab, ob weitere entstehen oder nicht. Wenn auch in den nächsten Wochen weitere entstehen sollten, dann ist das bei der Rate, die ich bisher beobachtet habe, mit hoher Wahrscheinlichkeit eine andere Erzeugungswahrscheinlichkeit. Und wenn keine weiteren entstehen, dann war es einfach nur Zufall, dass es in den Regionen, die ich sehe, halt mal zwei waren.

(0008143)
Dael   
2018-10-14 18:15   

Keine weiteren Jungdrachen diese Woche in E2. Es war also einfach nur Zufall, dass es in der vorigen Woche mal zwei auf einmal gab.

(0008144)
Enno   
2018-10-14 18:36   

Dann sagen wir mal, das war Zufall. Occam's Razor.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2209 [Eressea] General kleinerer Fehler immer 2016-05-20 22:09 2018-10-14 11:51
Reporter: hochl Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: hoch BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion:  
Partei: 6q
Spiel: E2
Report: 977
Zusammenfassung: Seeschlangen bleiben nie stehen
Beschreibung:

Seit laengerem jage ich 2 Seeschlangen. Diese bewegen sich leider jede Runde und toeten eine Menge meiner Bewacherschiffe, die ich im Meer um meine Insel geparkt habe, damit ich Monster sehen kann. Frueher haben sich Seeschlangen nicht jede Runde bewegt, sondern sind hier und da stehen geblieben, aber so wie es jetzt ist wuerde man massenhaft Schlangenjaegerschiffe benoetigen um die Viecher mal zu erwischen. Ausserdem schwimmen sie nach einem erfolgreichen Kampf auch weiter!

Schritte zur Reproduktion:
Zusätzliche Informationen:

Seeschlangen sind: aunt und cice.

Angehängte Dateien:
Notiz
(0006572)
Enno   
2016-05-20 23:16   

Sind die früher vielleicht stehen geblieben, weil ATTACKIERE ein langer Befehl war?

(0006573)
Solthar   
2016-05-21 00:35   

Nein, nicht direkt. Ich habe da vor Monaten was dran geändert, weil Seeschlangen nicht mehr vernünftig funktioniert hatten. Seitdem jagen sie wieder Schiffe. Dadurch sind sie wahrscheinlich auch ein wenig mobiler geworden. Trotzdem kann man sie noch recht leicht jagen, man muss nur schneller oder geduldiger sein. Ich kann da keinen Bug erkennen.

(0006574)
hochl   
2016-05-21 01:55   
(Zuletzt bearbeitet: 2016-05-21 01:56)

Also die Jungs aendern jede Runde die Position -- man braucht also 6 Schiffe die zu fangen. Finde ich etwas uebertrieben. Vielleicht sollten sie zumindest ab und an ne Runde Pause machen? Die muessen ja auch mal schlafen :D

(0006575)
Solthar   
2016-05-21 23:04   

Sie sollten nicht jede Runde die Position wechseln. Falls sie das täten, wäre es unbeabsichtigt.

(0006576)
Xolgrim   
2016-05-22 09:19   

Seeschlangen arbeiten doch mit Piraterie wenn ich das recht im kopf habe, d.h. sie jagen selber aktiv nach Schiffen. Ist ja nicht so, dass es Fluchttiere wären.
Von daher sollten eigentlich eine Hand voll Schiffe mit Soldaten die regelmässig um deine Insel kreisen den job auch erledigen, die Seeschlangen müssten diese recht zügig angreifen.

(0006579)
defaitist   
2016-05-26 19:10   

Die Seeschlangen haben in den letzten Wochen mehr als ein Dutzend Handelskaravellen versenkt, da sie nun sofort angreifen, anders als in der Vergangenheit, wo sie erst eine Woche nach Erreichen der neuen Region einen Angriff starteten. Somit ist ihre Kill-Rate nun fast bei 100% und sie weichen zudem Jägern aus, da sie ein intelligentes PIRATERIE zu nutzen scheinen, sie folgen nicht den kreuzenden Jägern. Was auch immer ihr umgestellt habt, das Mikromanagement ist orbitant gestiegen, jetzt werden keine einzel fahrenden Handelsschiffe mehr eingesetzt werden können, nur noch Flottenverbände mit Begleitschutz, da zudem allein in den von mir verwalteten Region in den Welten 4 und 5 gleichzeitig zehn neue Seeschlangen aufgetaucht sind und mit ihrer Aggressivität weit heftiger als jeder Drache effektiv den Handel zwischen den Inseln stören.

(0006580)
Solthar   
2016-05-26 20:02   

Danke für den Bericht. Das klingt für mich danach, dass sich die Seeschlangen endlich so verhalten, wie sie es sollten! Sie benutzen übrigens keine irgendwie intelligentere PIRATERIE als andere Einheiten.

(0006581)
hochl   
2016-05-26 20:26   
(Zuletzt bearbeitet: 2016-05-26 20:27)

So eine ploetzliche Umstellung finde ich nicht gut. Wenn du 21 Jahre spielst und dich irgendwie mit dem Verhalten `angefreundet' hast, und dann aendert sich das urploetzlich ohne Ankuendigung dermassen drastisch, dann ist das schlecht.

Zudem, wie oben schon geschrieben, wird das im Endstadium nur mehr Mikromanagement bedeuten, aber keinen wirklich neuen Spielinhalt. Oder anders ausgedrueckt: Die Aenderung nervt, weil sie zusaetzliche Zeit kostet, die viele alte Spieler vermutlich nicht haben, ohne einen erkennbaren Mehrwert zu bringen.

Zusaetzlich muesste auch die Haeufigkeit der Seeschlangen reduziert werden, denn es gibt unglaublich viele, ich habe manchmal den Eindruck man toetet eine und es kommen 2 neue.

Ist das wirklich eine Aenderung im Sinne des Spiels?

(0006582)
Xolgrim   
2016-05-26 22:23   

Was war denn früher anders? Ich habe noch nie Schiffe ohne Begleitschutz durch die Weltmeere reisen lassen aufgrund eben von Seeschlangen. Mit der Einführung von Flotten (wenn/wann auch immer die kommen mögen) wird das aber wieder deutlich einfacher zu händeln werden.

(0006583)
defaitist   
2016-05-27 03:03   

Wenn die Änderungen eine Motivation zum Spielausstieg sein soll, dann weiter so.

(0006584)
hochl   
2016-05-27 13:15   

Naja deshalb aufhoeren waere sicher uebertrieben. Aber zumindest mein Usecase von Schiffen wird dadurch zerstoert. Da man von Leutchttuermen nicht alles im Ozean sehen kann, habe ich einfach auf jedes Ozeanfeld ein Boot mit einem Spaeher gestellt. Diese Spaehboote haben bis jetzt (also ca. 20 Jahre ...) prima als Fruehwarnsystem funktioniert. Durch die Aenderung werden die jetzt reihenweise von Seeschlangen gefruehstueckt. Ich finde die Teile sollten gefaehrlich und selten, oder harmlos und haeufig sein. Aber gefaehrlich und haeufig, das ist ziemlich arg. Allein um meine recht kleine Hauptinsel sind z.Z. 2 oder 3 Seeschlangen unterwegs. Die Antwort muesste also sein, in jeder Ozeanregion statt einem Boot 50 Elitesoldaten zu stattionieren, da ja auch jederzeit neue Seeschlangen von ausserhalb einsickern. Das koennte ich natuerlich machen, aber ich habe nicht die Zeit alle Schiffe auf die Schnelle umzustellen.

(0006585)
Solthar   
2016-05-27 21:43   

Ich habe mir mal die Mühe gemacht, das auszuwerten: Seit ungefähr Runde 865 haben Seeschlangen nicht mehr angegriffen. Seit ungefähr 959 greifen sie wieder an. Aber nicht viel häufiger als davor nach meiner Erfahrung. Das kann natürlich abweichen, wenn man die Biester wuchern lässt. Wie man das verhindern kann, hat Xolgrim ja angedeutet.

Wo wir wirklich mal drauf schauen müssen, ist die Monsterdichte. Drachen und Seeschlangen entstehen einfach zufällig, unabhängig davon, wie viele es in der Nähe gibt.

(0006598)
CTD   
2016-06-04 21:29   
(Zuletzt bearbeitet: 2016-06-04 21:30)

Vieleicht zum Verständniss, Piraterie schaut auf die Umliegenden Seeregionen, und bewegt sich dann auf ein Schiff in einem der 6 Felder zu, wenn da eins ist. Sind in mehrere Feldern Schiffe ist das Zufall. Durchzugsmeldungen werden von Piraterie nicht ausgewertet. Wenn man sich also in das Feld der Seeschalnge bewegt, und sie zieht in der gleichen Runden raus, einfach stehen bleiben und dafür sorgen das in den Seefeldern um die Seeschlange keine anderen Schiffe sind, dann kommt sie ganz von allein zurück.

Wo man vieleicht nochmal schauen kann ist, ob:
A) Die Chance das die Seeschlange sich bewegt wenn Piraterie nichts findet zu hoch ist.
B) Ob die Angriffsschance auch richtg gesetzt ist, nicht jede Begegung mit einer Seeschlange sollte zu einem Kampf führe.

(0006609)
Pyanfar   
2016-06-07 23:06   

Seeschlangen jagen meine Schiffe?
DAS ist mir noch nicht aufgefallen.
Ich habe vor ein paar Monaten versucht, eine Seeschlange auf einer Handelsroute zu jagen, und bin mehrfach in einem sehr kleinen Seegebiet nur 1 Region weit gefahren. Da hätte eigentlich das Piraterie greifen müssen... ich greife die Testreihe nochmal auf, wir haben da ein "Bermudadreieck", wo Schiffe gefressen wurden.

Ich bin nicht so betroffen wie der Hochländer, und kann mit der aktuellen Lage wohl leben, aber... dass die Viecher nicht von Leuchtürmen aus zu sehen sind, ist wirklich ärgerlich. Vielleicht würde da eine Änderung helfen?
Gefährlich sind sie immer noch, und aktiv jagen muss man sie auch, aber sie lassen sich so etwas umgehen.

@Solthar: Drachendichte, ja, da haben wir in Welt 1-3 viel Spaß mit. Mein Rekord liegt bei iirc 103 Drachen in einer Region (oder waren es 113?)...

(0007668)
Enno   
2017-12-16 00:09   

Können wir diesen Burgreport schließen? Hier scheint mir ja kein Fehler vorzuliegen.

(0007681)
CTD   
2017-12-16 21:01   

Ja, ich denke schon.

(0008139)
Enno   
2018-10-14 10:04   

Nachdem ich die ganze Sache nochmal gelesen habe: Vielleicht würde es Abhilfe bedeuten, wenn Seeschlangen in einer Woche, in der sie ATTACKIEREn nicht auch noch andere Befehle gäben? Also sich vor allem nicht direkt aus der Region heraus bewegen?

(0008140)
Enno   
2018-10-14 11:51   

Neues beabsichtigtes Monsterverhalten: Wenn ein Monster attackiert, bewegt es sich in der selben Woche nicht mehr.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2416 [Eressea] General Absturz nicht getestet 2018-01-28 11:33 2018-10-14 09:59
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: wird nicht behoben  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 1061
Zusammenfassung: valgrind meldet Fehler in BerkeleyDB driver
Beschreibung:

Ich habe diese Woche das Backend für Befehle von SQLite auf libdb umgestellt. Aus der Testauswertung heute:

testing turn 1060 of game 2
==21178== Syscall param pwrite64(buf) points to uninitialised byte(s)
==21178== at 0x62E6773: pwrite_nocancel (syscall-template.S:82)
==21178== by 0x56266E8: __os_io (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x561388C: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5613A82:
memp_bhwrite (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5612CBA: memp_alloc (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5615537:
memp_fget (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55D7102: db_new (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x553E726:
bam_split (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5536B09: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55374B4: ram_append (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55C0994:
db_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55D239C: db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== Address 0x8ed1ec8 is 328 bytes inside a block of size 8,280 alloc'd
==21178== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==21178== by 0x5623EE4: os_malloc (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55F1535:
env_alloc (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x56122E8: memp_alloc (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5615537:
memp_fget (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55D7102: db_new (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x553E726:
bam_split (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x5536B09: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55374B4:
ram_append (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55C0994: db_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x55D239C:
db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
==21178== by 0x4F452C: db_driver_order_save (berkeley.c:49)
==21178==

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007790)
Enno   
2018-01-28 11:39   

Passiert auch in E3 / 442 und E4 / 192.

(0007793)
Enno   
2018-01-28 16:09   

Ich habe versucht, das mit einem kleinen Programm zu reproduzieren, ohne Erfolg. Es passiert nur, wenn ich auswerte.

Bis heute habe ich SQLite als Backend für die Befehle benutzt, an der Änderung liegt es, dass das jetzt erst auftaucht. Der BerkeleyDB Driver ist offenbar noch nicht reif. Entweder finde ich den Bug, oder ich stelle wieder auf SQLite um, die Alternative habe ich ja immer. Das sollte also 3.15 nicht beeinträchtigen, selbst wenn ich den Bug hier nicht finde.

(0007796)
Enno   
2018-01-28 17:45   

Auch wenn ich die Auswertung auf den Befehl parse_order("@GIB abcd ALLES Gurgelkraut", default_locale) reduziere (in process_orders hinein gehackt), kriege ich immer noch den Valgrind-Fehler. Wenn ich in einem kleinen Testprogramm nor Datenbank öffnen, Datensatz schreiben, Datenbank schließen tue, passiert nichts. Ich werde also erstmal auf das SQLite Backend zurück wechseln. Die CMake Konfiguration könnte da vereinfacht werden, sehe ich.

(0007797)
Enno   
2018-01-28 18:27   

commit 6fca773 prefers sqlite over db. That's good enough for a 3.15 launch.

(0007821)
Enno   
2018-02-18 10:29   

The current 3.16 branch still prefers db over sqlite3 if /usr/include/db.h exists. Since I now consider db broken, I should change that default.

(0008010)
Enno   
2018-07-31 11:03   

Depriorisiert, weil ich inzwischen SQLite für alles benutze.

(0008138)
Enno   
2018-10-14 09:59   

Der Treiber wird zur Zeit nicht benutzt. Wenn ich ihn mal irgendwann doch brauche, muss ich mich um das Problem kümmern, aber bis dahin ist der sicher eh dem Bitrot zum Opfer gefallen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2472 [Eressea] GIB kleinerer Fehler nicht getestet 2018-08-17 22:15 2018-10-14 09:57
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: wird nicht behoben  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18  
Partei: quar
Spiel: E2
Report: 1087
Zusammenfassung: ALLES lässt sich nicht abkürzen
Beschreibung:

Hi,

in Runde 1086 hat Einheit 53Lt versehentlich folgenden Befehl erhalten:
GIB yqog a Schild

In Runde 1087 kam dann folgende Fehlermeldung:
Quin'Sal (53Lt) in Vifudut (-4, 1): 'GIB yqog a Schild' - Die Einheit hat diesen Gegenstand nicht.

ALLES solte durch "a" abzukürzen sein. Die Einheit hatte übrigens durchaus Schilde. Wahrscheinlich ein Folgefehler.

Grüße,
Xeno

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008135)
Enno   
2018-10-14 09:25   

Der Parser ist so seltsam, das ich für die Abkürzungen eigentlich meine Hand nicht ins Feuer legen würde. Aber ich schaue mal, warum.

(0008136)
Enno   
2018-10-14 09:34   

Dachte ich es mir doch. "A" ist nicht die Kurzform von ALLES, sondern von AGGRESSIV. Der Parser liest deinen Befehl also als GIB yqog AGGRESSIV Schild, und das ist illegal. Abkürzungen müssen innerhalb ihrer Klasse eindeutig sein, wobei die Klassen teilweise sehr ungeschickt definiert, und bei den Schlüsselworten gibt es nur zwei Klassen: Befehlsworte (wie ATTACKIERE, LERNE, GIB, KAEMPFE) und Parameter (wie AUTO, AGGRESSIV, ALLES, SCHIFF). Das ist auch nicht einfach zu ändern, und seit ewigen Zeiten so (Atlantis Legacy).

(0008137)
Enno   
2018-10-14 09:57   

Irgendwo muss ich eine Grenze ziehen, um was ich mich kümmere, und Support für Ein-Buchstaben Abkürzungen fällt da deutlich nicht rein. Ich habe zwar eine Idee, wie ich das lösen könnte, aber es ist den Aufwand nicht wert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2497 [Eressea] LERNE/LEHRE Absturz immer 2018-10-07 05:59 2018-10-12 19:33
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: sofort BS-Version:  
Status: erledigt Produktversion: 3.17.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.2  
    Zielversion: 3.17.2  
Partei: 0
Spiel: E2
Report: 1095
Zusammenfassung: Crash in LERNE AUTO
Beschreibung:

running turn 1094, game 2
15 Factions with 1 NMR
eressea: /home/eressea/eressea/git/src/automate.c:69: learning: Assertion `n <= s->u->number' failed.
Aborted

Schritte zur Reproduktion:
Zusätzliche Informationen:

Einheit yncw hat hier Lerne auto Wahrnehmung

Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2498 [Eressea] General kleinerer Fehler nicht getestet 2018-10-07 08:58 2018-10-09 19:43
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 1095
Zusammenfassung: Befehlsdatei wird doppelt erzeugt
Beschreibung:

Wenn bei einer Neu-AW die Befehlsdatei schon existiert, darf sie nicht neu erzeugt werden. Heute wurden die Befehle aus dem Backup-Ordner orders.dir.1094 ein zweites Mal an orders.1094 angehängt, inklusive der dort gesicherten orders.queue Datei (die da eigentlich auch nicht hin gehört).

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008120)
Enno   
2018-10-07 09:31   

Ich sollte die einfach immer neu erzeugen. War da verwirrt, was der eignetliche Mechanismus ist. Habe das nur in den installierten Skripten repariert, das muss also noch in git eingecheckt werden.

(0008121)
Enno   
2018-10-09 19:43   

Alles klar und eingecheckt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2495 [Eressea] General kleinerer Fehler nicht getestet 2018-09-30 13:32 2018-10-01 10:15
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18  
Partei: cf2t
Spiel: E2
Report: 1094
Zusammenfassung: Meermenschen starten mit einem mehr als fertigen Boot
Beschreibung:

Aus dem ersten Report:

Boot m00t (m00t), Boot, (325/50).

Sehe ich das richtig, das Boot hat Größe 325 von 50?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008118)
Xolgrim   
2018-10-01 10:15   

Du hast ein unbeschädigtes Boot welches mit 325GE von möglichen 50GE beladen ist. Kein Bug -> User Error


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2478 [Eressea] ATTACKIERE schwerer Fehler nicht getestet 2018-08-19 13:19 2018-09-23 20:01
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: quar
Spiel: E2
Report: 1089
Zusammenfassung: Langer Befehl trotz langem Kampf
Beschreibung:

Hallo,

laut Anleitung ist ein Kampf lang, wenn die Region weder von einem selber noch einem Verbündeten bewacht wird.
Einheiten mit KÄMPFE FLIEHE sollten auch nach langen Kämpfen noch in der Lage sein, sich zu bewegen, aber keine anderen langen Befehle auszuführen. Letztere Einschränkung scheint nicht zu funktionieren:

Meine Einheit tckc war in einen Kampf verwickelt, stand auf KÄMPFE FLIEHE und ist erflogreich geflohen. Die Region wurde nur von Gegnern bewacht (einer davon ist als einer meiner Verbündeten Parteigetarnt). Trotzdem konnte die Einheit erfolgreich lernen, was ich daran sehe, dass ihr Talent aufgestiegen ist. Das hätte eigentlich nicht möglich sein sollen.

Grüße,
-Xeno

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008113)
Enno   
2018-09-22 09:07   

Das ist nicht ganz einfach zu reproduzieren, weil Deine Einheit eine Menge Glück hatte. Sie ist nicht gestorben, hat es geschafft zu fliehen, und hatte Glück beim Lernen.

(0008115)
Enno   
2018-09-23 17:58   

Ich glaube, ich hab's. Der relevante Code ist hier in aftermath():

        if (df->alive == 0) {
            flags = UFL_DEAD;
        }
        else if (relevant) {
            flags = UFL_LONGACTION;
            if ((du->status != ST_FLEE) && (df->run.hp &lt;= 0)) {
                flags |= UFL_NOTMOVING;
            }
        }

Man beachte die erste Bedingung: Wenn die Einheit keine Personen mehr hat, wird das UFL_DEAD Flag gesetzt. Das verhindert später, dass man eine tote Einheit mit GIB PERSONEN wieder zum Leben erwecken kann. Ansonsten wird UFL_LONGACTION gesetzt (verhindert lange Befehle) und für fliehende Einheiten auch noch UFL_NOTMOVING (verhindert Bewegung).

Das Problem hier ist, dass "alive" nicht die Anzahl der überlebenden Personen ist, sondern die Zahl der noch kämpfenden. Es kann also sein, dass die Zahl 0 ist, wenn z.B. aus einer Einheit alle Kämpfer geflohen sind, wie in der Fehlermeldung.

(0008116)
Enno   
2018-09-23 20:01   

Danke für die Meldung, das muss ein lang stehender bug gewesen sein. Seltsam, dass den vorher noch nie jemand bemerkt hat.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2494 [Eressea] Monster schwerer Fehler nicht getestet 2018-09-22 23:28 2018-09-23 11:10
Reporter: Erchamion Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: hoch BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: aman
Spiel: E2
Report: 1093
Zusammenfassung: Jungdrachenplage
Beschreibung:

Die Jungdrachenplage ist längst noch nicht Geschichte. Folgende jüngst in verschiedenen Regionen von E2 aufgetauchte Jungdrachen existieren immer noch:

Die Furchtlosen von Bozori (3fv3):3
Die Grünen von Nekabun (jpei):2
Die Weißen von Suhulol (tfph):2
Die Schönen von Gekurkohol (zsbp):2
Die Sanddrachen von Goldenes Fevenos (h859):2
Torgadol, die Goldene (g0ta):1
Gordorgol die Glänzende (L360):1
Die Weitblickenden von Pansydsivad (v4wu):4

Auf einer Insel hat es mich sogar besonders hart erwischt, denn dort sind nicht nur Jungdrachen (JD) aufgetaucht, sondern auch einige ausgewachsene Drachen (D):

Die Furchtlosen von Evendim (efms):2 (D)
Die Allmächtigen von Mückenwassermoore (g0ag):3 (JD)
Die Wissenden von Wetterberge (3ivz):3 (JD)
Die Wissenden von Wetterberge (9iik):2 (D)
Tortadol, die Glänzende (fj2y):1 (D)
Fordidol der Allmächtige (v140):1 (JD)

Schritte zur Reproduktion:
Zusätzliche Informationen:

Es betrifft meine beiden Parteien aman und taur.

Angehängte Dateien:
Notiz
(0008114)
Enno   
2018-09-23 11:10   

Das Löschen der Drachen war fehlerhaft. Du bist auch nicht der Erste, dem das aufgefallen ist. Ich habe das diese Woche wiederholt, und im kommenden Report werden die Biester verschwunden sein. Habe gerade mal eine Stichprobe mit den ersten 5 der von Dir genannten Einheiten gemacht, die sind alle tot.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2492 [Eressea] Monster schwerer Fehler nicht getestet 2018-09-16 12:37 2018-09-23 11:10
Reporter: Traumtaenzer Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.2  
    Zielversion: 3.17.2  
Partei: gz
Spiel: E2
Report: 1093
Zusammenfassung: Neue Drachen sind nicht futsch!
Beschreibung:

in 0002486 von mir gemeldet, ich finde keinen Button, um etwas hinzuzufügen.

Ennos letzter Beitrag dort: "Bug ist gefixt, und alle diese Woche entstandenen Drachen und Seeschlangen sind futsch."

Bei mir sind sie alle noch da, wie von mir ursprünglich gemeldet. Gut, dass ich meine Befehle nach Ennos Ankündigung nicht mehr ändern konnte, daher sind die Drachenkammerjäger wenigstens unterwegs/ angekommen.

Habe ich nur dieMonstter immer noch, oder geht es anderen auch so?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008103)
Jutta   
2018-09-16 12:38   

Ich sehe auch noch zahllose Drachen. Das ist nicht gefixt.

(0008104)
Enno   
2018-09-16 15:01   

Fehler gefunden, glaube ich. Wir probieren das nochmal, diese Woche sollte es klappen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2486 [Eressea] Monster kleinerer Fehler nicht getestet 2018-09-09 10:47 2018-09-16 20:41
Reporter: Traumtaenzer Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.2  
    Zielversion: 3.17.2  
Partei: gz
Spiel: E2
Report: 1092
Zusammenfassung: E2 Wundersame Drachenvermehrung?
Beschreibung:

Auf meiner (kleinen) Heimatinsel tauchen in dieser Runde 1 x 2 Drachen und 3 x 2 Jungdrachen auf, das hatte ich in der Haeufigkeit noch nie. Dazu gibt es noch 2 x Erheben der Toten. Auf einer anderen Insel gibt es 1 x Jungdrachen neu. Ist das ein statistisches Artefakt oder gibt es diese Haeufung auch bei anderen SpielerInnen?

Neu- Tolfalas (kleine Insel)
Gletscher: In Wykyvon (3,0) wurden 2 Jungdrachen gesichtet.
Gletscher: In Fosorred (-2,5) wurden 2 Jungdrachen gesichtet.
In Fosorred (-2,5) erhoben sich die Toten aus den Gräbern.
Sumpf: In Torf (1,5) wurden 2 Jungdrachen gesichtet.
Sumpf: In Mufar (5,0) wurden 2 Drachen gesichtet
Gletscher: In Werindehil (4,3) erhoben sich die Toten aus den Gräbern.

Sichtung auf einer anderen Insel
Wüste: In Widal (-7,19) wurde 1 Jungdrache gesichtet.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008061)
K   
2018-09-09 13:32   

In Noggelheim (xfckde) wurden 2 Drachen gesichtet. -- Die Roten von Noggelheim (svso): 2
In Fuvon - Tiur (1fte1f) wurden 3 Jungdrachen gesichtet. -- Die Weitblickenden von Fuvon - Tiur (kyqo): 3

falls weitere Beispiele helfen.

(0008063)
Xolgrim   
2018-09-09 18:38   

Hier auch inflationäre Vermehrung auf eigentlich weitestgehend befriedeten inseln.

In Witkiportel (113,34) wurde 1 Jungdrache gesichtet.
In Limarkankot (116,34) wurden 2 Jungdrachen gesichtet.
In Norwardstor (117,37) wurden 2 Jungdrachen gesichtet.
In Gladius (132,36) wurden 3 Jungdrachen gesichtet.
In Widal (133,41) wurde 1 Jungdrache gesichtet.
In Osten (138,36) wurden 2 Jungdrachen gesichtet.
In Phum (139,37) wurden 2 Jungdrachen gesichtet.
In Hisdigid (-16,19) wurden 3 Jungdrachen gesichtet.
In Weißes Gebirge (-15,19) wurde 1 Jungdrache gesichtet.

(0008064)
hochl   
2018-09-09 20:25   
(Zuletzt bearbeitet: 2018-09-09 20:28)

Ich habe im Schnitt zwischen 1 und 4 Monster in meinem Report, diese Runde sind es 11 Regionen mit Monstern, allesamt Jungdrachen oder Seeschlangen. Da laeuft was schief ... Severity ist sicher mehr als Minor, wenn das jetzt ueberall so ist und dann jede Runde dann haben wir die Drakokalypse.

(0008066)
Enno   
2018-09-09 21:03   

Ich gucke mir das lieber so bald wie möglich an.

(0008067)
Enno   
2018-09-09 21:04   

In meinem Report gibt es auch mindestens 5 neue Sichtungen.

(0008068)
hochl   
2018-09-09 23:20   

Unterschaetze bitte nicht, was das fuer einen Aufwand bedeutet, allein die diese Runde vermutlich zu viel erzeugten Drachen und besonders Seeschlangen zu bekaempfen. Wenn das global in Eressea passiert ist muesste es ja statistisch sofort sichtbar sein wie die Drachenpopulation angewachsen ist. Ich halte es fuer sinnvoll entweder nochmal ohne Drachen auszuwerten oder alle neuen Drachen/Seeschlangen der letzten 2 Wochen per Skript aus dem Spiel zu befoerdern. Eine Seeschlange toeten kostet mich selbst mit Skripten sicher 15 Minuten Zeit (Einheiten auswaehlen, Befehle machen zum hinfahren, schlachten und rueckfahren etc.). Das ist logistischer Aufwand der sich schnell potentiert. Wenn jetzt ueberall Jungdrachen auftauchen sitzten die evtl. jahrelang irgendwo, werden zu Wyrmen und fangen dann das wandern an. Und dann kommen sie wieder alle zu meinem Silberberg .... :/

(0008069)
Thoran   
2018-09-10 02:01   

Auch bei mir sind in diesem Report in 40 (!) Regionen Jungdrachen oder Drachen neu gesichtet worden. Hier die entsprechenden Auszüge aus meinem Report:
---snip---
In Báwuzêmét (-142,286) wurden 2 Jungdrachen gesichtet.
In Tirelsyn (-210,191) wurden 3 Jungdrachen gesichtet.
In Kikosân (-42,280) wurde 1 Drache gesichtet.
In Rudo (-149,283) wurden 3 Jungdrachen gesichtet.
In Lesker (-148,285) wurde 1 Drache gesichtet.
In Fébôtet (-145,287) wurden 3 Jungdrachen gesichtet.
In Mumodgurus (-143,288) wurden 2 Drachen gesichtet.
In Dolsabus (-150,285) wurden 3 Jungdrachen gesichtet.
In Nubupelad (-185,112) wurden 2 Jungdrachen gesichtet.
In Fulvukuhot (-181,111) wurden 3 Jungdrachen gesichtet.
In Sandkralle (-180,111) wurden 2 Jungdrachen gesichtet.
In Budvo (-188,114) wurden 3 Jungdrachen gesichtet.
In südostliche Karal (-168,99) wurden 2 Jungdrachen gesichtet.
In Kalwis (-17,25) wurden 2 Drachen gesichtet.
In Ladene (-16,16) wurde 1 Jungdrache gesichtet.
In Zealand (-14,11) wurden 2 Jungdrachen gesichtet.
In Veereveer (-13,9) wurden 2 Jungdrachen gesichtet.
In Rhodannin Glacier (-3,20) wurde 1 Drache gesichtet.
In In den Wehsanden (-7,3) wurden 3 Jungdrachen gesichtet.
In Im Schneegebirge (-6,2) wurden 2 Jungdrachen gesichtet.
In Grosssee (-3,1) wurden 2 Jungdrachen gesichtet.
In Steingarten (-2,2) wurden 4 Jungdrachen gesichtet.
In Im Birkenmoor (-2,3) wurden 3 Jungdrachen gesichtet.
In Bydcuvol (2,13) wurde 1 Jungdrache gesichtet.
In Fósmor (15,1) wurde 1 Jungdrache gesichtet.
In Shitara (17,-5) wurden 2 Drachen gesichtet.
In Fíkirgolsêd (20,-7) wurde 1 Drache gesichtet.
In Sellôd (-36,-5) wurde 1 Jungdrache gesichtet.
In Feuchter Hase (-28,-9) wurden 2 Jungdrachen gesichtet.
In Safen (1,-14) wurden 3 Jungdrachen gesichtet.
In Tyrsis (14,-17) wurden 3 Drachen gesichtet.
In Cêtinmèfud (-14,-19) wurden 3 Jungdrachen gesichtet.
In Fepacyr (-13,-19) wurden 3 Jungdrachen gesichtet.
In Futcodafàt (-8,-20) wurde 1 Jungdrache gesichtet.
In Tysîl (-8,-18) wurden 2 Jungdrachen gesichtet.
In Gerbebykíd (-11,-21) wurden 3 Jungdrachen gesichtet.
In Pefibar (64,-21) wurden 2 Jungdrachen gesichtet.
In Retit (64,-20) wurde 1 Drache gesichtet.
In Naleor (91,-18) wurden 3 Jungdrachen gesichtet.
---snap---
Stört mich persönlich nicht sonderlich, da ich wohl alle innerhalb der nächsten zwei Wochen werde erschlagen können. Wenn sich das aber mit Seeschlangen genauso verhält, dann stört das die Schiffahrt natürlich ungemein - und ist, wie der Hochländer schreibt, deutlich aufwendiger zu "beheben".

(0008070)
Enno   
2018-09-10 17:30   

Unterschaetze bitte nicht, was das fuer einen Aufwand bedeutet, allein die diese Runde vermutlich zu viel erzeugten Drachen und besonders Seeschlangen zu bekaempfen.

Ich unterschätze das auf gar keinen Fall, schließlich ist das auch in meiner Heimat passiert ;-) Wenn sich das als echter Fehler herausstellt, und ich Zeit dazu finde, dann kann es also gut sein, dass die neuen Monster von einer seltenen Krankheit befallen werden.

(0008071)
Enno   
2018-09-10 17:38   

Es sieht ganz so aus, als wenn das hier passiert ist: https://github.com/ennorehling/eressea/commit/50183081#diff-c9fccbabae614cdec2a3c1514d8c0a62L879

Da ist die Berechnung von spawn_chance plötzlich ganz anders, was habe ich mir wohl dabei gedacht?

(0008072)
Enno   
2018-09-10 17:39   

Ja, die Chance wurde ungewollt von 0.06% auf 6% erhöht. Aua.

(0008073)
Enno   
2018-09-10 17:57   

Bug ist gefixt, und alle diese Woche entstandenen Drachen und Seeschlangen sind futsch.

(0008105)
hochl   
2018-09-16 20:27   

Die Drachen/Seeschlangen die neu hinzugekommen sind sind noch immer in meiner Auswertung, ich denke der Drakozid hat nicht wie angekündigt geklappt.

(0008106)
Xolgrim   
2018-09-16 20:40   

Wie in 0002492 beschrieben (hoffentlich) bereits gelöst


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2488 [Eressea] Monster kleinerer Fehler nicht getestet 2018-09-09 19:24 2018-09-13 16:17
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: ovis
Spiel: E3
Report: 456
Zusammenfassung: Spieleruntote teilen sich und neue Einheit gehört zur Monsterpartei
Beschreibung:

Eine Einheit Untote (Rasse: Untote), durch die kürzliche hinzugefügte Möglichkeit des Zusammenlegens evtl. zu groß geworden, hat sich geteilt und die neue Einheit (damit ein Teil der Untote) gehört dann der Monsterpartei (ii).

Schritte zur Reproduktion:

Runde 455 --- Miliz (d77n):229

Runde 456 --- Miliz (d77n):119
Runde 456 --- Schlurfende Gespenster der Gefolterten (d1zr):110 <- jetzt Monstereinheit

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008075)
Enno   
2018-09-10 18:39   

Das ist in Runde 456 passiert? Das ist schon eine Weile her, oder?

Und, nur um noch einmal zu fragen: Die Einheit, die sich da geteilt hat, das war deine, nicht eine von den Monstern? Mir ist gar nicht bewusst gewesen, dass Spielereinheiten (oder überhaupt irgendwelche) das tun.

(0008082)
Xolgrim   
2018-09-10 21:03   

Das ist lustig, dass du das nicht weisst. Wir haben uns da vor einiger Zeit nämlich drüber unterhalten über das splitten. Das müsste im Zuge der Hirntöter änderung gewesen sein (Wo du die ganzen kleinen Einheiten zusammen gelegt hast um Speicher zu sparen). Jede Monster Einheit mat einen maximalen Wert, wie gross die EInheit sein darf, bei Jungdrachen, Drachen und Wyrmen ist der recht klein (3?) Bei Jujus und co deutlich grösser. Du meintest damals aber, dass das wohl irgendwie nicht richtig funktionieren würde.

(0008084)
K   
2018-09-11 07:20   

Ja, eine Weile her, die Einheit hatte Parteitarnung behalten und ich dachte sie wäre von einem Alliierten. Diese Runde hat sie sich als Monster (ii) enthüllt und ich habe nachgeforscht woher sie stammt. Das mit der Teilung war mir auch unbewusst, das erste Mal das ich das erlebe.

(0008086)
Enno   
2018-09-11 14:59   

@Xolgrim Ja, daran erinnere ich mich. Besonders an meine Einschätzung, dass das wohl nicht funktioniert.
@K Es hat m.W. eine Änderung gegeben, die dafür sorgt, dass Monster sich nicht mehr parteitarnen. Kann das zur Verwirrung beigetragen haben?

(0008088)
K   
2018-09-11 15:36   

Sieht hat es eher erleichtert, so habe ich das Problem diese Runde überhaupt er realisiert :)

(0008097)
Enno   
2018-09-12 21:27   

Versuch einer Reproduktion mit aktuellem Code:

  1. Miliz (d77n) gehörte zu Beginn der Woche noch zur Partei Flausch (ovis), und hatte 229 Personen. Soweit richtig.
  2. Das ändert sich bei einer zweiten Auswertung leider nicht, da muss also Zufall im Spiel sein (oder der Bug ist gefixt).
(0008098)
Enno   
2018-09-12 21:32   
(Zuletzt bearbeitet: 2018-09-12 21:32)

Gefunden: Der Code zur Teilung ist in age_undead, die Mindestgröße ab der es passiert ist 90, und die Chance einer Teilung ist 25%.

Die neue Einheit gehört dann zu Monster (ii), das war damals wohl Absicht. Dass mal jemand so große Untoteneinheiten zaubern würde, damit hatten die Entwickler nicht gerechnet.

(0008099)
Enno   
2018-09-12 21:53   

Nach kurzer Rücksprache mit Experten hat sich ergeben, dass diese Rasse inzwischen überhaupt nicht mehr neu entstehen kann. Ein Spielmechanismus, um die Anzahl Untoter in Spielerhand zu reduzieren, ist also fast total unnötig, und ich könnte das Feature einfach löschen.

(0008101)
Enno   
2018-09-13 16:17   

Ich habe das Feature einfach entfernt, und erkläre das Problem damit für gelöst.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2490 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-09-10 02:04 2018-09-10 18:31
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.17.1  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: d08a
Spiel: E2
Report: 1092
Zusammenfassung: Sichtbarkeit von Landregionen aus Leuchttürmen
Beschreibung:

Es scheint, als ob mit der neuen Version aus Auswertung 1092 (Version 3.17.1) die Sichtbarkeit aus Leuchttürmen heraus gegenüber der Auswertung 1091 (Version 3.16.6) wieder geändert worden ist. Landregionen, die eigentlich aufgrund der Entfernung zum Leuchtturm von diesem aus sichtbar sein sollten, werden jetzt im Report nicht mehr aufgeführt. Es werden nur noch Seeregion als "vom Turm erblickt" angezeigt. Ist das so gewünscht?

Schritte zur Reproduktion:
Zusätzliche Informationen:

In Runde 1091 konnte mein Leuchtturmwärter (k8rx) vom Leuchtturm (v12n) in Mofodol (id: f6wza4) aus z.B. die Region Waz-Kogel (id: 9ww9vg) sehen. In Runde 1092 ist das nicht mehr der Fall. Der Leuchtturm ist in meinem Besitz und die besitzende Einheit hat auch genügend Silber, um den Unterhalt zu bezahlen.

Angehängte Dateien:
Notiz
(0008074)
Enno   
2018-09-10 18:31   

Der Leuchtturm ist zum Schutz und zur Beobachtung von Ozeanen gedacht, und gibt keinen Einblick in Landregionen. Das war auch früher so, und sollte mit der Änderung in 0002462 wieder richtig sein. Dass sich das von Report 1091 auf 1092 geändert hat, ist also Absicht. Keine Absicht war, dass die Ankündigung dazu verloren gegangen ist, weil die Mailingliste kaputt ist.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2462 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-07-16 21:42 2018-09-10 18:27
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.5  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: 0
Spiel: E2
Report: 1084
Zusammenfassung: Leuchttürmen zeigen Landregionen, keine Bewacher an
Beschreibung:

Hier werde ich mal dokumentieren, was alles an Leuchttürmen verkehrt ist, bzw. war (weil ich die gerade repariere).

Schritte zur Reproduktion:
  1. Die Anleitung sagt: "Ab einer Größe von 10 verhindert ein Leuchtturm im Umkreis von log10(Leuchtturmgröße)+1 Feldern das Abtreiben von Schiffen durch Stürme". In Wirklichkeit passierte das bereits ab Größe 1 (direkt benachbarte Ozeanregionen waren immer geschützt).

  2. Für den Schutz vor Abtreiben muss niemand im Leuchtturm stehen. Trotzdem hat es in check_leuchtturm einen Test für das Wahrnehmungstalent. Da die Funktion aber immer mit NULL aufgerufen wird, sollte das nichts tun. Funktion wird in lighthouse_guarded umbenannt, und unbenutzte Extra-Parameter entfernt.

  3. Man kann durch Feuerwände (FORBIDDEN_REGION) hindurch Ozeane sehen, die auf der gegenüber liegenden Seite sind.

  4. Man kann mit dem Leuchtturm Landregionen sehen.

  5. Wenn ein Leuchtturm zerstört wird, wirkt er in der selben Woche noch (at_lighthouse wird nicht entfernt).

Zusätzliche Informationen:
Angehängte Dateien: lh_0_0.jpg (207,954 Bytes) 2018-07-23 16:24
https://bugs.eressea.de/file_download.php?file_id=93&amp;type=bug
jpg
Notiz
(0007972)
Enno   
2018-07-18 20:50   

Habe gerade die notwendigen Änderungen in meinen develop-branch gebracht.

(0007985)
Solthar   
2018-07-23 16:22   

Das mit den Feuerwänden hat sich aber nicht groß geändert.

(0007986)
Enno   
2018-07-23 18:04   

Feuerwände und Landregionen sind weiterhin durchsichtig, das stimmt. Dafür gibt es keine einfache Lösung. Die Feuerwände auf diesem Bild scheinen alle Nachbarn von vom Leuchtturm gesehenene Regionen zu sein, mehr als ihren Regionstyp sieht man da nicht.

(0007990)
Solthar   
2018-07-23 22:07   

Es ging mir um die Regionen dahinter, die sichtbar sind. Aber wenn das nicht das Ziel der Änderungen war und zudem die Sicht wieder auf Ozeane beschränkt ist, dann kann das hier auch wieder zu, es gibt Wichtigeres.

(0007994)
Enno   
2018-07-24 12:06   

Ist dieses Bild aus einem privaten Test, oder aus der Testauswertung vom Sonntag? Ich habe nämlich das Gefühl, dass die nicht verschickt worden ist, und will das gerne bestätigen.

(0007996)
Solthar   
2018-07-24 13:08   

Privater Test. Testauswertung habe ich in der Tat keine bekommen.

(0007997)
Xolgrim   
2018-07-24 15:56   

In der Test AW sehe ich keine EInheiten mehr in regionen die ich sonst nicht einsehe. Scheint also zu funktionieren.

(0007998)
Enno   
2018-07-24 17:01   

Danke!


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2489 [Eressea] General kleinerer Fehler nicht getestet 2018-09-09 20:29 2018-09-09 21:01
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.18  
    Zielversion: 3.18  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: BELAGERE ist aktiv in E2
Beschreibung:

In Bug 1896 sollte der Befehl eigentlich auch für E2 abgeschaltet worden sein. Das ist aber offenbar mit der Umstellung auf JSON Konfiguration wieder rückgängig gemacht worden, so wie ich den Code lese.

Es ist überhaupt bescheuert, dass das über eine Abschaltung des Befehles gemacht wurde, und der Code nicht entfernt wurde.

Schritte zur Reproduktion:

Kill it with Fire!

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008065)
Enno   
2018-09-09 21:01   

I have a local commit that removes every last piece of this feature.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2487 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-09-09 11:18 2018-09-09 15:47
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.2  
    Zielversion: 3.17.2  
Partei: ufo
Spiel: E2
Report: 1092
Zusammenfassung: LERNE AUTO hat nicht funktioniert
Beschreibung:

In meinem Report:

Mercy of Sarrse (dkpL) in Blum (2,1): 'LERNE AUTO Segeln' - Dieses Talent
wurde nicht erkannt.
Kalr (o57y) in Blum (2,1): 'LERNE AUTO Segeln' - Dieses Talent wurde nicht
erkannt.
Amaat (3ftt) in Blum (2,1): 'LERNE AUTO Segeln' - Dieses Talent wurde nicht
erkannt.
usw.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008057)
Enno   
2018-09-09 12:03   

Es sieht so aus, als habe ich den automate branch nicht nach master, sondern nach develop gemerged? Hier ist beim Release etwas derbe schief gelaufen.

https://github.com/eressea/server/compare/v3.16.6...master

(0008058)
Enno   
2018-09-09 12:14   

Oder auch nicht. Es sieht so aus, als wenn ich mit dem github Interface überfordert bin.

(0008059)
Enno   
2018-09-09 13:16   

Es gab für AUTO keine Übersetzung im .po File, scheint mir. Und keinen Lua-Test, der das gefangen hätte.

(0008060)
Enno   
2018-09-09 13:28   

Ich fürchte, es ist möglich, mit dem Befehl teure Talente kostenlos zu lernen (nicht Magie, aber z.B. Taktik).

(0008062)
Enno   
2018-09-09 15:47   

Bugs gefixt, Tests geschrieben.
Testauswertung zeigt keine Fehler, Einheiten haben Talentzuwachs, teure Talente sind verboten. Alles prima.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2378 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2017-10-21 22:55 2018-08-28 13:46
Reporter: Traumtaenzer Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.13.1  
Produkt-Build: Lösung: nicht reproduzierbar  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: gz
Spiel: E2
Report: 1047
Zusammenfassung: Hirntoeter weiterhin unsterblich?
Beschreibung:

Gelesen habe ich:

https://bugs.eressea.de/view.php?id=2173
https://bugs.eressea.de/view.php?id=2166

Kampf gegen Hirntoeter meinerseits auf der normalen Ebene:

In Fosorred (-2,5) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Sidhe von Zemur (gz).

Heer 0: Sidhe von Zemur (gz)
Kämpft gegen: Heer 1(-?-)
Hilft: Heer 0(gz)
Attacke gegen: Heer 1(-?-)
... in der 1. Kampflinie:

  • Traumtaenzer (ukw0), 1 Nebelelf, Held, aggressiv, Talente: Tarnung 12,
    Hiebwaffen 29, Reiten 5, Pferdedressur 4, Ausdauer 15, Segeln 2, Taktik 1,
    hat: 2 Wagen, Elfenpferd, Flammenschwert, 12 Pferde, Laenschwert, 11500
    Silber, Wundsalbe, 5 Heiltränke, Plattenpanzer, Ring der Unsichtbarkeit,
    Schild, Schneeball; Herrscher der Sidhe. Wenn er eine Rede haelt, einigt
    er die Seinigen auf jeden Fall, welche Meinung sie auch immer haben
    moegen, nach selbiger sind alle komplett verwirrt. In seltenen Faellen
    gelingt es ihm tatsaechlich, einen Schimmer der Realitaet am Horizont zu
    sichten.
  • Schwerttaenzer (u1un), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 13, Hiebwaffen 20, Segeln 3, Taktik 1, hat: 100
    Kettenhemden, 100 Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (489r), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 12, Hiebwaffen 20, Segeln 2, Taktik 1, hat: 100
    Kettenhemden, 100 Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (dcnw), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 12, Hiebwaffen 20, Segeln 3, Taktik 1, hat: 100
    Kettenhemden, 100 Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (o9o9), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 13, Hiebwaffen 20, Segeln 3, Taktik 1, hat: 100
    Kettenhemden, 100 Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (i6L2), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 13, Segeln 8, Hiebwaffen 20, hat: 100 Kettenhemden, 100
    Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (tvev), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 13, Segeln 8, Hiebwaffen 20, hat: 100 Kettenhemden, 100
    Pferde, 100 Schilde, 100 Schwerter.
  • Schwerttaenzer (9gmr), 100 Nebelelfen, aggressiv, Talente: Tarnung 2,
    Reiten 2, Ausdauer 13, Segeln 8, Hiebwaffen 20, hat: 100 Kettenhemden, 100
    Pferde, 1056 Silber, 100 Schilde, 100 Schwerter.
    ... in der 2. Kampflinie:
  • Nebelwanderer (ov3u), 1 Nebelelf, Held, hinten, Talente: Bogenschießen
    26, Reiten 4, Tarnung 10, Segeln 1, Pferdedressur 2, Taktik 22, Ausdauer
    13, hat: Wagen, Kettenhemd, Elfenbogen, 2 Pferde, 2 Heiltränke, Ring der
    Unsichtbarkeit, Schild; Wo er auch immer reitet, da folgen schattenhafte
    Gestalten, deren Aussehen noch niemand, der sie gesehen, zu beschreiben
    vermochte, und der Nebel scheint mit geisterhaften Stimmen zu fluestern.
  • Tumbe Bolzen (1h1b), 100 Nebelelfen, hinten, Talente: Tarnung 2, Reiten 2,
    Ausdauer 10, Segeln 6, Armbrustschießen 20, hat: 100 Armbrüste, 100
    Pferde.
  • Tumbe Bolzen (L4bv), 100 Nebelelfen, hinten, Talente: Tarnung 2, Reiten 3,
    Ausdauer 10, Segeln 8, Armbrustschießen 20, hat: 100 Armbrüste, 100
    Pferde.
  • Bogenmiliz (32a), 100 Nebelelfen, hinten, Talente: Reiten 3, Tarnung 2,
    Bogenschießen 27, Ausdauer 12, Segeln 1, hat: 100 Kettenhemden, 100
    Elfenbögen, 100 Pferde, 100 Schilde; Sie sind die Besten im Umgang mit
    dem Bogen. Und das ist aeusserst dreist gelogen!
  • Bogenmiliz (367a), 100 Nebelelfen, hinten, Talente: Tarnung 2, Reiten 2,
    Ausdauer 11, Bogenschießen 24, Segeln 3, Taktik 1, hat: 100 Pferde, 100
    Mallornbögen.

Heer 1: Unbekannte Partei
Kämpft gegen: Heer 0(gz)
Hilft: Heer 1(-?-)
... in der 1. Kampflinie:

  • Hirntöter (2iLu), 14 Hirntöter, aggressiv, bewacht die Region, hat: 25
    Phiolen; Wabernde grüne Schwaden treiben durch den Nebel und verdichten
    sich zu einer unheimlichen Kreatur, die nur aus einem langen Ruderschwanz
    und einem riesigen runden Maul zu bestehen scheint.

Nebelwanderer (ov3u) überrascht den Gegner.

Einheiten vor der 0. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 1. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 2. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 3. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 4. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 5. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
1 Krieger von Traumtaenzer (ukw0) benutzen ihre Flammenschwerter.
Traumtaenzer (ukw0) tötete 0 Krieger.

Einheiten vor der 6. Runde:
Heer 0(gz): 701+401, Heer 1(-?-): 14
Nebelwanderer (ov3u) erzielte 60 Treffer und tötete 0 Gegner.
Traumtaenzer (ukw0) erzielte 89 Treffer und tötete 0 Gegner.
Tumbe Bolzen (1h1b) erzielte 200 Treffer und tötete 0 Gegner.
Tumbe Bolzen (L4bv) erzielte 200 Treffer und tötete 0 Gegner.
Schwerttaenzer (u1un) erzielte 499 Treffer und tötete 0 Gegner.
Schwerttaenzer (489r) erzielte 474 Treffer und tötete 0 Gegner.
Schwerttaenzer (dcnw) erzielte 480 Treffer und tötete 0 Gegner.
Schwerttaenzer (o9o9) erzielte 469 Treffer und tötete 0 Gegner.
Schwerttaenzer (i6L2) erzielte 475 Treffer und tötete 0 Gegner.
Schwerttaenzer (tvev) erzielte 484 Treffer und tötete 0 Gegner.
Schwerttaenzer (9gmr) erzielte 480 Treffer und tötete 0 Gegner.
Bogenmiliz (32a) erzielte 600 Treffer und tötete 0 Gegner.
Bogenmiliz (367a) erzielte 600 Treffer und tötete 0 Gegner.
Heer 0(gz): 0 Tote, 0 Geflohene, 1102 Überlebende.
Heer 1(-?-): 0 Tote, 0 Geflohene, 14 Überlebende.

Wenn ich das richtig verstanden habe, hat der Besitzer des Flammenschwertes mit 7 Flammenattacken (1x / Runde) nicht getroffen/ keinerlei Schaden angerichtet (das waere dann Pech), oder die Hirntoeter sind durch Flammenschwert nicht angreifbar (waere dann Bug?)

Werde das wiederholen und weiteres Flammenschwert hinschicken. Mehr als zwei habe ich nicht .

Schritte zur Reproduktion:
Zusätzliche Informationen:

Region Fosorred (-2,5) ist ein durch eine Schneekugel erzeugter Gletscher (war vorher Ozean). Lage 6te Welt. Wo die Hirntoeter hergekommen sind, weiss ich nicht.

laut cr "3.13.2";Build

Angehängte Dateien:
Notiz
(0007580)
Xolgrim   
2017-10-22 08:22   

Sodele, dann fangen wir einmal an. Hirntöter sind gegen nichtmagische attacken Immun, das ist sicher bekannt. Also sind deine 1000 Soldaten nicht relevant (nur dafür, damit dein Held nicht so viele Schläge ab bekommt). Sowohl die Tatsache, dass dein Anführer ein Held ist, als auch seine Kampffähigkeit spielen keine Rolle. Sobald eine Einheit gut genug ist ein Flammenschwert zu führen (T5? T7? Irgendwie soetwas), zaubert sie einmal Pro runde einen niederstufigen Feuerball.

Durch die gewonnene Taktikerrunde hast Du 6 und nicht 7 Treffer. "Einheiten vor der 6. Runde:" könnte auch einfach "Nach dem Kampf" heissen. Da werden noch die Postkampfzauber durchgeführt und dann ist die Woche rum.
Wir haben also im Kern 6 Feuerbälle gegen 14 Hirntöter. Ob die Schaden genommen haben, kann man aus deinem Report noch nicht entnehmen, nur das sie offensichtlich zu wenig Schaden genommen haben um zu sterben. Hirntöter haben neben physischer Immunität zu allem überfluss auch noch magische resistenz. Einfach die kommende Woche nochmal drauf hauen und wenn bei denen nicht mindestens verwundet steht, kann man sich das hier noch einmal genau anschauen.

(0007582)
Solthar   
2017-10-22 17:47   

Ich habe jüngst erst Hirntöter getötet.

(0007583)
Solthar   
2017-10-22 17:47   

Mit Flammenschwertern.

(0007586)
Enno   
2017-10-22 19:15   

Ich glaube, Xolgrim hat Recht, und man kann hier nicht aus einem Kampf darauf schliessen, dass die Hirntöter (wieder) kaputt sind. Ohne zusätzliche Informationen werde ich mir das wohl nicht im Detail ansehen, das ist Arbeit, und die Chancen sind hoch, dass es zu nichts führt, weil nichts kaputt ist.

(0007590)
Traumtaenzer   
2017-10-28 21:53   

Im zweiten Versuch ueber 6 Runden wieder keinerlei Erfolg. Immer noch 14 Hirntoeter uebrig, die dann auch noch die Region verlassen haben (Fosorred (-2,5): Die Region wurde durchquert Hirntöter (2iLu)). Wohin? Keine Ahnung, in den benachbarten Landregionen koennen sie nicht sein, wenn ich sie dort nicht sehen kann, waeren sie mir in Fosorred auch nicht nicht aufgefallen. Bleiben nur noch Ozeanregionen... ich haette sie lieber an Land, im Ozean sind diese "Mistviecher" fuer Schiffe ein Desaster.

Fortsetzung waere mir nur moeglich, wenn die Hirntoeter wieder an Land auftauchen. Aber da Solthar ja kuerzlich Flammenschwerter erfolgreich gegen Hirntoeter verwendet hat, duerfte ein Bug nicht vorliegen.

(0007591)
Xolgrim   
2017-10-29 09:44   

Waren die HT denn erschöpft zu Kampfbeginn?

(0007592)
Enno   
2017-10-29 16:24   

Ich gucke es mir an, nur damit hier Ruhe ist.

(0007593)
Traumtaenzer   
2017-10-29 16:53   

Die HT waren nicht erschoepft

(0007594)
Enno   
2017-10-29 17:24   

Na super. Es gibt da einen (neuen?) Bug im Parser, der beim Einlesen der aktuellen Befehle auftritt, jedenfalls auf meinem eigenen Rechner. Deshalb omme ich gar nicht erst zu den Kämpfen, bis ich den gefixt habe.

(0007596)
Enno   
2017-10-29 18:44   

Es stimmt jedenfalls schon einmal, was Xolgrim sagt: Elfenbogen und andere "normale" Waffen sind hier witzlos, weil nur magischer Schaden den HT etwas anhaben kann.

Feuerschwerter machen 1-10 Attacken mit magischem (Fernkampf-)Schaden von 2d8 vom Typ AT_SPELL, wirken also genauso wie Zauber.

Hirntöter haben 90% Magieresistenz, die geht in die Schadensberechnung mit ein. Außerhalb des Astralraums wird die halbiert, bleiben 9/20. Dazu werden pro Talentpunkt Magie 5% Resistenz addiert (haben die aber glaube ich nicht), Zeuberwirkungen und Einhörner haben sie auch nicht, in einem Steinkreis stehen sie nicht, so dass die effektive Resistenz 45% (oder 9/20) ist. Wenn sie Laen-Ausrüstung hätten, würde die Resistenz noch damit verrechnet, haben sie aber auch nicht.

Der magische Schaden wird mit dieser Magieresistenz multipliziert. Das erscheint mir verkehrt, da sollte glaube ich geteilt werden? Aber bei 45% ist das fast egal, da kommen 8 effektive Schadenspunkte heraus. Rüstungsschutz gibt es keinen. Jeder HT hat 21 Trefferpunkte, da prallt der erste Treffer ab.

In meiner Test-Auswertung sterben mehrere Personen von den Hirntötern, es ist also nicht so, dass die unsterblich sind. Die Sache mit der Resistenz-Multiplikation gucke ich mir noch einmal an.

(0007597)
Enno   
2017-10-29 19:04   

Ich habe die Schadensberechnung bei Magieresistenz repariert, Fehler in den Hirntötern kann ich nicht finden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2479 [Eressea] NACH/ROUTE kleinerer Fehler immer 2018-08-26 12:47 2018-08-26 13:02
Reporter: meer Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: orkz
Spiel: Deveron
Report: 220
Zusammenfassung: Einheiten, die sich selbst folgen, führen ohne Feldermeldung keine langen Befehle aus
Beschreibung:

Eine Einheit kill führt ein Heer aus mehreren Einheiten an, die alle @Folge Einheit kill gesetzt haben.

Dummerweise hüstel wurde der Einheit kill neben NACH auch selbst der Befehl @Folge Einheit kill gegeben.

Jetzt kommt es dazu, dass Einheit kill einfach keinen langen Befehl ausführt und ohne Meldung nichts macht.

Erwünscht hätte ich mir eines der folgenden Ergebnisse:

  • die Einheit führt ihren normalen langen Befehl aus
  • die Einheit tut nichts, aber es gibt eine Fehlermeldung
Schritte zur Reproduktion:

Ich versuche die Einheit seit mehreren Wochen zu bewegen - es gab zunächst auch andere Probleme, aber ich bin mir ziemlich sicher, dass es in den letzten zwei Runden an dieser Befehlskombi lag.

Zusätzliche Informationen:

Ich hoffe, die Kategorie Nach/Route ist richtig, auch wenn es um FOLGE geht.

Angehängte Dateien:
Notiz
(0008043)
meer   
2018-08-26 13:02   

Nachtrag: Auch wenn die Einheit noch immer in derselben Region steht, scheinen alle Einheiten zu denken, dass sie sich bewegt hat - zumindest scheinen auch die anderen Einheiten, die ihr folgen wollten, keine langen Befehle ausgeführt zu haben.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2476 [Eressea] NACH/ROUTE kleinerer Fehler nicht getestet 2018-08-19 05:27 2018-08-21 22:29
Reporter: Halima Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.18  
Partei: Hali
Spiel: E2
Report: 1089
Zusammenfassung: Einheit transportiert nicht
Beschreibung:

Hi Enno,
nicht allzu dramatisch, die Schmiede steht, aber die Arbeiter wurden nicht transportiert

Befehl lautete:
EINHEIT vrtn; Fuhrmann [1,0$]
Transportiere 8vjn ni58 dt98 a6ev weyr
Nach NW W

Die Einheiten hatten "Fahre" gesetzt, die erstgenannte Einheit 8vjn wurde auch transportiert, die weiteren jedoch nicht
(jede der weiteren Einheiten produzierte die Fehlermeldung "'FAHRE vrtn' - Die Einheit transportiert uns nicht."

Weiß nicht warum, habe auch in der wiki unter "Fahre" nachgeschaut, dort ist "TRANSPORTIERE 311 777 ; Lasse 311 und 777 mitfahren" als Beispiel angeführt, dem bin ich ja gefolgt.

Tnx für nachschauen

Martin

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008033)
Julian   
2018-08-19 10:40   

Ich denke dass Beispiel bei FAHRE ist falsch. Bei TRANSPORTIERE steht nichts von optionalen zusätzlichen Einheiten, die angegeben werden können (https://wiki.eressea.de/index.php/TRANSPORTIERE).

Ich gebe dir jede Einheit die transportiert werden soll einen eigenen TRANSPORTIERE Befehl. Das passt auch zum beobachteten Verhalten, dass nur die erste gelistete Einheit transportiert wurde.

Als Feature Wunsch wäre dass aber nett, wenn es ginge mehrere Einheitennummern bei einem TRANSPORTIERE Befehl anzugeben.

(0008034)
Julian   
2018-08-19 10:42   

*Ich gebe bei jeder Einheit...

(0008040)
Xolgrim   
2018-08-19 15:31   

Bei Transportiere steht nichts von mehreren Nummern die man angeben kann. Wie Halima aber richtig geschrieben hat, steht es in dem Beispiel unter https://wiki.eressea.de/index.php/FAHRE explizit als angegebenes Beispiel mit:
"TRANSPORTIERE 311 777 ; Lasse 311 und 777 mitfahren"
Vorausgesetzt Halima hat alle Befehle korrekt gegeben, liegt hier also definitv ein Fehler von. Entweder im Code oder in der Anleitung.

(0008042)
Enno   
2018-08-21 22:29   

Kein Bug. TRANSPORTIERE kann nur eine Einheit als Argument bekommen, um mehrere Einheiten zu transportieren, muss man den Befehl mehrfach geben.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2477 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-08-19 12:10 2018-08-21 22:27
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.6  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: ufo
Spiel: E2
Report: 1089
Zusammenfassung: 0 Bauern werden zu Ghoule
Beschreibung:

Aus meinem Report:

0 Bauern werden zu Ghoule und schliessen sich Schrumpfkopfsammler - UN-Wachen (z08) an.

+ Schrumpfkopfsammler - UN-Wachen (z08), Die den Kater haben (aua)
  (Schrumpfkopfsammler (2raf)), 163 Ghoule, bewacht die Region, hat:
  Rostiges Kettenhemd, Schartiges Schwert.

Das ist ja eher ein Non-Event (0 Bauern schliessen sich jede Woche fast jeder Einheit an), und davon sollte nicht berichtet werden.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Die Region hat keine Bauern, man kann hier nicht rekrutieren, und die Einheit scheint parteigetarnt zu sein?

Angehängte Dateien:
Notiz
(0008036)
Enno   
2018-08-19 12:19   

Anderswo:

27 Bauern werden zu Skelettherren und schliessen sich Skelette der Gefolterten  (75kg) an.

Skelettherren sind fieses Zeug, sollten die wirklich Bauern konvertieren? Reicht es nicht, dass die "einfachen" Untotenrassen das tun?

(0008039)
Thoran   
2018-08-19 13:57   

Eine ähnliche Nachricht, nämlich
--- snip ---
Hirntöter (bny8) verspeiste 0 Bauern.
Hirntöter (vs9g) verspeiste 0 Bauern.
Hirntöter (qmf3) verspeiste 0 Bauern.
--- snap ---
erscheint seit einiger Zeit im Astralraum.

(0008041)
Enno   
2018-08-21 22:27   

Das war so leicht, habe ich sofort erledigt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2456 [Eressea] BEWACHE kleinerer Fehler nicht getestet 2018-07-02 21:16 2018-08-19 13:40
Reporter: EON Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: gLod
Spiel: E2
Report: 1083
Zusammenfassung: Reiter wird von bewachender Einheit (Monster) aufgehalten, die die Region verlässt
Beschreibung:

Diese Woche wurde eine meiner Einheiten die sich eigentlich zwei Regionen bewegen sollte von Monstern aufgehalten, die die mittlere Region bewacht haben. Das wäre an sich normal, wenn die Monster nicht diese Woche in eine andere Region gezogen wären - ich bin mir nicht sicher, ob das so sein sollte.

  • Einheit Steintransport (5h7v) kann reiten und hat Pferde, ist nicht überlastet
  • Regionen: Glutstein (Lh6er5) - Hagelsturm (6t1m4c) - Tivun (L8t1mL)

Meldungen:
Steintransport (5h7v) reitet von Glutstein nach Hagelsturm
Steintransport (5h7v) wurde in Hagelsturm von Fürchterliche Kreaturen (bm67) aufgehalten.
Regionsmeldung:
Durchreise: Fürchterliche Kreaturen (bm67)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007939)
Xolgrim   
2018-07-02 21:30   
(Zuletzt bearbeitet: 2018-07-02 21:31)

Wenn ich mir die Befehlsreihenfolge so anschaue, gehe ich schwer davon aus, dass das so gewollt ist.
BEWACHE NICHT (3) also wenn ich bewache selber aufheben will
NACH (29)
BEWACHE AN (30)

Bewache nicht erfolg also seh früh, das lässt vermuten, dass es für die darauf folgenden Befehle relevanz hat. NACH erfolgt unmittelbar vor dem neuen Bewache (was man jedoch nur setzen kann, wenn man sich nicht bewegt hat, sont würe man die betretene Region ja sofort bewachen)

(0007940)
EON   
2018-07-02 21:43   

Die Frage die sich mir stellt ist, wann BEWACHE aufgrund von NACH gelöscht wird. Schließlich passiert mein NACH bzw. ROUTE theoretisch gleichzeitig mit dem NACH der Monster, technisch gesehen muss aber natürlich eines vor dem anderen ausgewertet werden.
Wenn das BEWACHE NICHT im Rahmen von NACH ausgeführt wird, dann hängt es davon ab, welche Einheit zuerst ausgewertet wird.
Wenn sich NACH in zwei Phasen teilt (erst alle Einheiten bewegen, dann das BEWACHE aller bewegten Einheiten löschen) bin ich zufrieden. Das wäre vermutlich sogar die beste Variante, da Einheiten, die sich wegen Überlast etc. nicht bewegen könnten dann weiter bewachen.
Erst Bewache löschen wäre für mich auch in Ordnung, ist hier aber offensichtlich nicht passiert.
Wichtig ist mir eigentlich nur, dass es deterministisch ist ;-)

(0007941)
Xolgrim   
2018-07-03 20:07   

Das Bewache wird vermutlich einfach gar nicht gelöscht, sofern man nicht bewache nicht oder kämpfe flieh beflieht, die Einheit entwaffnet oder sterben lässt. Am Anfang der nächsten Runde ist eine einheit die NACH befohlen hat nicht mehr in der Region, bewacht dort also nicht. In der Nachbarragion bewacht sie nicht, da bewache und bewegen sich ausschliesst. Also im endeffekt "bauglich" mit deiner Variante 2.

(0008035)
Enno   
2018-08-19 12:16   

Ich bin mir fast sicher, dass das von der Reihenfolge in der Region abhängt. Wenn das NACH deiner Einheit bearbeitet wird, ehe dass das NACH des Monsters ausgeführt wurde (weil das Monster weiter "unten" in der Region steht, dann bewacht es halt noch. Das kann man nicht einfach ändern, und halte ich auch nicht für dringend nötig.

Vermute ich das richtig? Habe ich deine Beschreibung verstanden?

(0008037)
EON   
2018-08-19 12:31   

Fast. Meine Einheit war ja nicht in der selben Region wie die bewachenden Monster, also standen die Monster nicht weiter unten in der selben Region, sondern die Region in der die Monster standen kam später dran, vermute ich. Ein großes Problem ist das nicht, es war nur überraschend für mich, da mein Transporter nicht dort ankam wo er sollte.

(0008038)
Enno   
2018-08-19 13:40   

Hier liegt kein Fehler vor, das ist einfach ein Artefakt der Befehlsverarbeitung im Server. Davon gibt es einige, und solange man das nicht als Exploit ausnutzen kann, sehe ich keinen Bedarf, daran etwas zu ändern.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2471 [Eressea] Featurewunsch kleinerer Fehler N/A 2018-08-05 06:57 2018-08-18 10:58
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: LERNE AUTO
Beschreibung:

Siehe Email an eressea-dev Liste, 13. Mai: Automatisches LEHRE

Alle Einheiten, die das selbe Talent LERNEN, lehren einander, wenn
das opportun ist. Nach einer vorgegebenen Strategie. Als Spieler gebe ich also
nur noch LERNE Befehle, es sei denn ich will manuell in den Prozess eingreifen
(alle Lehrer und von ihnen gelehrten Einheiten werden von der Automatik
ausgenommen).

Oder einfacher: alle Einheiten der Partei in dieser Region, die LERNE AUTO <talent> mit gleichem Talent befehlen, helfen sich so gut sie können untereinander aus.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008021)
Enno   
2018-08-05 06:58   

Es gibt bereits seit einer Weile einen Branch "automate" in meinem Fork des Servers. Das funktioniert im Grunde, es fehlen aber z.B. noch Meldungen im Report.

(0008032)
Enno   
2018-08-18 10:58   

Pull Request: https://github.com/eressea/server/pull/797


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2465 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-07-22 00:17 2018-08-11 13:07
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: turt
Spiel: E2
Report: 1085
Zusammenfassung: "Lied der Verführung" teleportiert Gegenstände
Beschreibung:

Der Zauber "Lied der Verführung" teleportiert die Beute zum Magier, sollte man ihn durch einen Vertrauten (andernorts) zaubern. Ich bin nicht sicher ob das beabsichtigtes Verhalten ist.

Schritte zur Reproduktion:

Magier: zkx0
Vertrauter: ht42
Opfer: pg1p

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007987)
Enno   
2018-07-23 18:08   

Das ist ganz doof, weil die "zaubernde" Einheit für den Spruch der Magier ist. Das ganze ist in etwa wie ein Fernzauber, und wegen der Möglichkeit zum Teleport von Dingen ist Lied der Verführung explizit kein Fernzauber, glaube ich. Dann dürfte er eigentlich auch von Vertrauten nicht zauberbar sein, das ist ein Fehler im Design.

(0007999)
Enno   
2018-07-25 19:37   

Lösungsvorschlag: Wenn der Magier nicht in der selben Region ist, bekommt die erste Einheit seiner Partei, die in der Region des Opfers steht, den Kram.

(0008000)
Enno   
2018-07-25 19:43   

Danke, Bug ist gefixt.

(0008024)
K   
2018-08-11 11:40   

Tut mir leid für die etwas späte Antwort, aber wäre der Vertraute nicht etwas intuitiver als Empfänger? Ein, für manchen Spieler, scheinbar beliebige Einheit bringt sicher mal was durcheinander.

(0008025)
Xolgrim   
2018-08-11 11:54   

Habe ich auch schon angemerkt, aber die Erste Einheit der Region war wohl in der Umsetzung wesentlich einfacher. Die alternative wäre gewesen den Zauber für Vertraute ganz zu verbieten, da ist das wohl ein erträglicher Kompromiss.

Ggf. sollte man das in die Zauberbeschreibung aber mit rein schreiben? Kann unangenehm werden, wenn man versehentlich wichtige Einheiten mit dem Spruch überläd.

(0008027)
Enno   
2018-08-11 13:07   

Ich halte die Lösung erst einmal für gut genug, und will mich nicht weiter damit befassen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2458 [Eressea] REKRUTIERE schwerer Fehler nicht getestet 2018-07-07 22:10 2018-08-02 14:31
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: dringend BS-Version:  
Status: erledigt Produktversion: 3.16.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: keja
Spiel: E2
Report: 1084
Zusammenfassung: Insekten konnten in letzter Herbstwoche nicht rekrutieren!
Beschreibung:

"3.16.4";Build

Insekten konnten von Runde 1083 nach 1084 nicht rekrutieren. 1083 war die letzte Herbstwoche, 1084 ist die erste Winterwoche.

Aus dem nr 1083:
"Hinweise

Es ist Spätherbst, und diese Woche ist die letzte vor dem Winter, in der
Insekten rekrutieren können."

Aus dem nr 1084: (z.B.)

"Legat Cevzorex (Lhj7) in Racil (1,-3): 'REKRUTIERE 1' - Insekten können im
Winter nur in Wüsten rekrutiert werden."

(Einheit vzLL hatte den Befehl die temp-Einheit zu erzeugen, die die Nummer Lhj7 bekommen hat)

Insgesamt konnten 62 gewünschte Insekten nicht rekrutiert werden! Das klingt nicht viel. Mein junges Volk hat aber erst 382 Personen. Der Bug trifft mich sehr schwer, da mir jetzt etwa 60 Steuereintreiber fehlen, die mein Wachstum im Frühjahr sichergestellt hätten.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007950)
Julian   
2018-07-07 22:35   

Sicher verwandt mit Bug 2396

(0007951)
Julian   
2018-07-08 10:34   

Selber Bug ist auch in der Testauswertung.

(0007952)
Enno   
2018-07-08 12:36   

Die Jahreszeiten sind Mist, sagte ich aber schon mehrfach.

(0007953)
Xolgrim   
2018-07-08 19:52   

Bei der Gelegenheit möchte ich noch einmal Werbung für die Startgeschenke bei neuen Partein machen. Gerade für Insekten und Trolle sind die alten Startgeschenke eigentlich Elementar Wichtig. Trolle hatten früher T2 in Wahrnehmung mit der Starteinheit und Insekten hatten 9 Netswärme als Startgeschenk. Das sind beides in meinen Augen sehr wichtige Startgeschenke. Bei den anderen Rassen ist das nicht sooo wichtig. Aber insekten welche diese WOche anfangen zu spielen, können einfach mal 9 Wochen nicht rekrutieren. Ein Troll der neben einen Gobo startet, kann mit -1 Wahrnehmung auch einfach mal nichts tun gegen den +1 Tarnungs Gobling, aber das nur am Rande.

(0007954)
Enno   
2018-07-10 20:34   
(Zuletzt bearbeitet: 2018-07-10 20:35)

@Xolgrim Mal abgesehen davon, dass Du Recht hast, und ich das reparieren sollte: Ich könnte auch relativ einfach allen Parteien, die jetzt maximal 20 (?) Wochen alt sind, die Geschenke nachträglich geben (Trolle kriegen eine Person mit T2 Wahrnehmung, Insekten kriegen 9 Nestwärme für ihre älteste Einheit).

(0007955)
Xolgrim   
2018-07-10 20:39   
(Zuletzt bearbeitet: 2018-07-10 20:41)

@Enno: Das klingt doch mal nach nem Plan für die neuen Partein. Gib der neuen Person am besten den defaul befehl Arbeite, nicht dass da jemand aufs Silberstück genau geplant hat und deswegen wer hungert (Urlaubszeit ist NMR Zeit ;)
Ändert natürlich nichts daran, dass in Eressea eigentlich immer gilt, was im aktuellen Report steht gilt für diesen Report. Steht da die Region hat 3 Bäume, dann kann ich die fällen weil sie diese Woche da sind. Steht da es ist Herbst, sollte nicht schon Winter sein ..

(0007956)
Julian   
2018-07-10 20:43   

Also mir würden die 20 Wochen nicht helfen, da meine Insekten 5 Wochen vor dem letzten Winter das Licht der Welt erblickt haben. Mir konkret würde aber nächste Runde so ein Nestwärme-Trank helfen... tüdelüü
Gehört hier nicht hin, aber wie wirkt der Trank eigentlich? Personen-, regions- oder parteiweit? Sprich würde je Insektenvolk ein solcher Trank helfen um den aktuellen Bug auszugleichen, so dass sie in der nächsten Winterwoche rekrutieren können?

(0007957)
Xolgrim   
2018-07-11 15:51   

Um das eigentliche Problem hier nicht zu verwässern haben ich für die Startgeschenke einen eigenen Bug als Featurewunsch aufgemacht: 0002460

(0007960)
Enno   
2018-07-12 20:29   

Trolle und Insekten mit Parteialter unter 20 Wochen bekommen in der kommenden Auswertung ein Geschenk.

(0007961)
Enno   
2018-07-12 20:30   

Ansonsten ist hier glaube ich die Meldung verkehrt, dass man noch einmal rekrutieren kann. Die sollte eine Woche früher kommen?

(0007962)
Julian   
2018-07-12 21:37   

Nein die Meldungen sind alle korrekt! Nur hat es eben nicht entsprechend funktioniert.
In der letzten Herbstwoche (1083) kam die Meldung "Es ist Spätherbst, und diese Woche ist die letzte vor dem Winter, in der Insekten rekrutieren können." Nur konnte man eben nicht mehr rekrutieren in dieser Woche, die man in den Befehlen von 1083 -> 1084 eingeschickt hat. Es sollte aber so sein wie Xolgrim sagt, wenn im Report steht, dass Herbst ist, dann ist für den folgenden Zug den die Spieler einschicken noch Herbst. Die Jahreszeit sollte sich erst NACH dem abarbeiten aller Befehle oder zumindest sehr spät in der Befehlsreihenfolge. Punkt 34 (die Bauern, Pferde und Wälder vermehren sich, falls möglich; die übrig gebliebenen Bauern wandern umher) erscheint mir ein sinnvoller Zeitpunkt.

Und persönlich wäre mir ja lieber alle 12 Insektenvölker bekämen so einen Trank. Seit Runde 1053 gibt es konstant 12 Insektenvölker und das zwölfte war meins (es kann natürlich sein, das danach noch ein neues ausgesetzt wurde, während ein altes Insektenvolk zufällig in derselben Runde 4 NMRs hatte, halte das aber für unwahrscheinlich). Sprich es gibt keine Insektenvölker <20 Runden.

(0007967)
Enno   
2018-07-14 10:56   

Ich verschiebe die Reparatur der Jahreszeiten-Anzeige mal auf ein Major Release.

Das Problem ist folgendes: Wenn im Report 1083 steht "Es ist Herbst", dann meint das eigentlich "die gerade gemachte Auswertung fand im Herbst statt". Denn der Kalender wird umgeblättert, sobald die Auswertung beginnt (vor allen Befehlen). Der Report 1084 ist eine Meldung über das, was in Woche 1084 passiert ist.

Ich kann das auf zwei Wegen ändern: Entweder, der Report sagt "Es war Herbst", oder er sagt in Bezug auf die nun kommende Woche "Es ist Winter" (denn die letzte Herbstwoche ist gerade vorbei), oder die aktuelle Woche wird erst direkt vor dem Schreiben der Reporte erhöht (so dass der Bericht quasi am Wochenanfang, statt am Wochenende kommt).

Welche Lösung auch immer ich wähle (und die sind unterschiedlich schwierig), es wird da Erklärungsbedarf geben bei den Spielern, die sich an den Status Quo gewöhnt haben.

(0008016)
Enno   
2018-08-01 15:40   

Dann mal los. Runde 1084 heisst: Jahr 34, Jahreszeit 0, Woche 0, Monat 3. Jahreszeit 0 ist laut recruit() aber Winter.

(0008017)
Enno   
2018-08-01 16:24   

Im Code, der die Warnung für Insekten erzeugt, steht:

            get_gamedate(date->turn + 1, &next);
            if (next.season == 0) {
                ADDMSG(&f->msgs, msg_message(&quot;nr_insectfall&quot;, &quot;&quot;));
            }

Das heisst, die Warnung wird erzeugt, wenn nächste Woche (date + 1) Winter (season 0) ist. Das ist so natürlich falsch.

(0008018)
Enno   
2018-08-01 16:32   

Im Report 1083 steht:

Wir schreiben die letzte Woche des Monats Sturmmond im Jahre 34 des zweiten
                        Zeitalters. Es ist Herbst.

Das ist so zu interpretieren, dass die in diesem Report beschriebenen Ereignisse in der letzten Herbstwoche stattgefunden haben.

Damit ist diese Aussage falsch:

Es ist Spätherbst, und diese Woche ist die letzte vor dem Winter, in der
  Insekten rekrutieren können.

Denn es war Spätherbst, und die Ereignisse der nächsten Woche werden sich entsprechend im Winter abspielen.

(0008019)
Enno   
2018-08-02 11:13   

Ich glaube, das ist klarer:

Insekten können wegen des Winterwetters in der kommenden Woche nur in Wüsten
oder mit Hilfe des Nestwärme-Tranks Personen rekrutieren.

bzw.

Es ist Spätherbst, und die kommende Woche ist die letzte vor dem Winter,
in der Insekten rekrutieren können.

Das sagt, dass es sich auf die kommende Woche bezieht, im Gegensatz zu allen anderen Meldungen im Report, die sich auf die vergangene beziehen. Wenn die Meldung über den Spätherbst dann noch eine Woche früher kommt, damit sie stimmt, ist das glaube ich die Lösung.

(0008020)
Enno   
2018-08-02 14:31   

Ich glaube, diesmal habe ich es richtig verstanden, und die Insekten-Meldungen kommen zum korrekten Zeitpunkt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2168 [Eressea] ATTACKIERE schwerer Fehler nicht getestet 2015-11-29 01:08 2018-08-01 11:56
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.7.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: d08a
Spiel: E2
Report: 956
Zusammenfassung: Kampf gegen Seeschlange überlebt - aber ertrunken?
Beschreibung:

Ich hatte diese Woche einen unfreiwilligen Kampf gegen eine Seeschlange:

---snip---
In Ozean (-75,55) findet ein Kampf statt.

Der Kampf wurde ausgelöst von einer unbekannten Partei.

Heer 0: Unbekannte Partei
Kämpft gegen: Heer 1(d08a)
Hilft: Heer 0(-?-)
Attacke gegen: Heer 1(d08a)
... in der 1. Kampflinie:

  • Seeschlange (nw2t), 1 Seeschlange, aggressiv.

Heer 1: Thorans Axtträger (d08a)
Kämpft gegen: Heer 0(-?-)
Hilft: Heer 1(d08a)
... in der 4. Kampflinie:

  • Skiur Segelzwerg (n2oh), 1 Zwerg, flieht, Talente: Unterhaltung 3,
    Stangenwaffen 10, Segeln 8, Wahrnehmung 4, Schiffbau 1, Ausdauer 10,
    Holzfällen 1, Taktik 2, hat: Kettenhemd, Hellebarde, 720 Silber, Schild;
    Er fand dieses Boot der Haurrean Uharteren am Strand. (Bem: #*693 Am hohen
    Pass#SoldFuer: 10-20 Runden#)

Skiur Segelzwerg (n2oh) konnte dem Gegner eine Falle stellen.

Einheiten vor der 0. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1

Einheiten vor der 1. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Seeschlange (nw2t) zaubert Eisiger Drachenodem: 0 Krieger wurden getötet.

Einheiten vor der 2. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Seeschlange (nw2t) zaubert Eisiger Drachenodem: 0 Krieger wurden getötet.

Einheiten vor der 3. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Seeschlange (nw2t) zaubert Eisiger Drachenodem: 0 Krieger wurden getötet.

Einheiten vor der 4. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Seeschlange (nw2t) zaubert Eisiger Drachenodem: 0 Krieger wurden getötet.

Einheiten vor der 5. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Seeschlange (nw2t) zaubert Eisiger Drachenodem: 0 Krieger wurden getötet.

Einheiten vor der 6. Runde:
Heer 0(-?-): 1, Heer 1(d08a): 0+0+0+1
Skiur Segelzwerg (n2oh) erzielte 4 Treffer und tötete 0 Gegner.
Heer 0(-?-): 0 Tote, 0 Geflohene, 1 Überlebende.
Heer 1(d08a): 0 Tote, 0 Geflohene, 1 Überlebende.
---snap---

Seltsamerweise hat mein Zwerg den Kampf überlebt. Statt weiterzusegeln, wie es eigentlich sein Befehl war (Kämpfe auf See sind ja kurz und deshalb hätte er seinen langen Befehl ausführen können), ist er aber offenbar über Bord gesprungen und ertrunken:

---snip---
Skiur Segelzwerg (n2oh) ertrinkt in Ozean (-75,55).
---snap---

Das Boot, an Bord dessen er sich befand, war vor dem Kampf mit 23 von 50 GE beladen. Auch bei einem Schaden von 20%, der ja durch einen solch lange Kampf entsteht, hätte das Boot also noch tragfähig sein sollen.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Das die Seeschlange meinen Segler nicht getötet hat deutet für mich (insbesondere in Verbindung mit Fehler 2166 - Unsterbliche Hirntöter?) darauf hin, dass eventuell bei magischen Angriffen irgendwas schief läuft.

Angehängte Dateien:
Notiz
(0006332)
Thoran   
2015-11-29 01:11   

Ich stelle auch gerade noch fest, dass es einen weiteren - ähnlichen - Fehlerreport gibt: 1974. Auch da ist ein durch eine Seeschlange angegriffener Bootsinsasse ertrunken. Du konntest das aber damals nicht reproduzieren. Vielleicht klappt es ja mit obigem Kampf.

(0006333)
Xolgrim   
2015-11-29 11:28   

Kürzlich wurde implementeirt, dass fliehende Einheiten Burgen und Schiffe verlassen.
Vom Grundgedanken her macht das Sinn. Wenn eine Übermacht an Soldaten eine kleine Einheit Tarner angreift, die in einer Burg stehen, dann fliehen dise sonst jede runde nahezu verlustfrei und können so Wochen oder Monatelang die Kontrolle über die Burg behalten. Bei Schiffen verhält es sich ähnlich.
Bei Schiffen sollte man wohl die Einschränkung einbauen, dass dieses verhalten auf dem Ozean arg unerwünscht ist?

PS: Thoran ich würde Dir ja mein Beileid aussprechen, aber Zwerge die Segeln sind selber Schuld daran wenn sie ersaufen...

(0006340)
Enno   
2015-12-02 11:56   

Kürzlich wurde implementeirt, dass fliehende Einheiten Burgen und Schiffe verlassen

Das sollten sie natürlich nicht auf dem Ozean, das sollte ich mal überprüfen.

(0006341)
Enno   
2015-12-02 12:01   

Die von @Xolgrim erwähnte Änderung (force_leave in battle.c) wirft nur diejenigen Einheiten aus Schiff oder Burg, die gegen den Besitzer gekämpft haben, und tut das auch nur in Landregionen. Ist also hier sicher nicht der Grund, außerdem gibt es da eine Meldung "<foo> bittet <bar>, das Schiff <baz> zu verlassen".

(0006342)
Enno   
2015-12-02 12:04   

Der Versuch, den Kampf erneut zu provozieren, hat leider nicht geklappt. Nebenfrage: Warum ist die Seeschlange eigentlich parteigetarnt? Haben Monster das früher mal gemacht? Und woher/wofür hat sie ein solch hohes Magietalent?

(0006345)
Thoran   
2015-12-02 12:26   

Seeschlangen sind öfter mal parteigetarnt. Diese Woche habe ich zwei Seeschlangen in meinem Report, davon ist eine parteigetarnt (gnmb), die andere nicht (Einheit 7fdo).

Das hohe Magietalent scheint aber ja keine Auswirkungen zu haben: Die Seeschlange hat fünfmal Eisigen Drachenodem gezaubert, aber meinem Zwerg keinen Schaden zugefügt (Ausdauer 10 sind umgerechnet 77 Trefferpunkte, was jetzt auch nicht so exorbitant viel ist).

@Xolgrim: Ich bin ja auch für die Einführung einer Unterwelt ;-) Dann könnte man die Erzstollen benutzen, um von einer Insel zur anderen zu gelangen, und wäre nicht auf die gefährlichen Seereisen angewiesen.

(0006374)
Solthar   
2015-12-05 21:42   

Seeschlangen haben eine Attacke vom Typ AT_STRUCTURAL, die Schiffe beschädigt. Die macht 1d10 / ship->size % Schaden. Bei einem Boot also bis zu 200%. Warum so viel und warum bisher nicht?

(0006375)
Solthar   
2015-12-05 22:22   

Anders gefragt, wieviel Schiffschaden sollten Seeschlangen machen? Die einzigen anderen Wesen, die AT_STRUCTURAL benutzen, sind anscheinend Tunnelwürmer.

Nicht vergessen: Monster greifen seit Mitte 2014 nicht mehr an, also könnte die schuldige Änderung schon länger zurückliegen.

BTW, ich konnte das hiermit reproduzieren.

function find_monsters()
return get_faction(666)
end

function test_monster_attack()
plan_monsters()
local r1 = region.create(0, 0, "ocean")
local f1 = faction.create("drac@eressea.de", "human", "de")
local f2 = find_monsters()
local u1 = unit.create(f1, r1, 1)
local u2 = unit.create(f2, r1, 1)
u2.guard = true
u1.ship = ship.create(r1, "boat")

local oldpar = eressea.settings.get(&quot;rules.monsters.attack_chance&quot;)
eressea.settings.set(&quot;rules.monsters.attack_chance&quot;, &quot;1&quot;)

u1.number = 200
u2.race = &quot;seaserpent&quot;
u2.number = 1
u2:set_skill(&quot;unarmed&quot;, 10)
plan_monsters()

process_orders()
plan_monsters()

process_orders()

-- write_reports()

eressea.settings.set(&quot;rules.monsters.attack_chance&quot;, oldpar)

end

(0006610)
Pyanfar   
2016-06-07 23:23   

Blöde Frage, ist das nun geklärt?
Wenn wir nun auf Seeschlangejagd gehen (siehe http://bugs.eressea.de/view.php?id=2209 ), und dann noch der neue Überlade"schutz" greift, macht das Kriegsschiffe schnell total manovrierunfähig, wenn zuviele Trupen an Bord stehen, und die Schlange nicht sofort stirbt.

(0006611)
Enno   
2016-06-08 10:07   

Soweit ich das sehe, hat sich hier nichts getan, da der Fehler weder reproduzierbar ist, noch jemand eine Erklaerung hat, wie es dazu kommen koennte.

(0006612)
Solthar   
2016-06-08 12:19   

Ich habe die Erklärung doch gegeben. Wir sollten da eine Nachricht einfügen, wenn das zerstörte Schiff sinkt. Sollte es für den (jeden) Angriff der Seeschlange auch eine Meldung geben?

Ich muss den Code für die Flotten sowieso anfassen, da werde ich das einfügen.

(0008011)
Enno   
2018-07-31 19:56   

Schiffe kriegen 5% Schaden pro Runde, die der Kampf gedauert hat. Wenn am Ende des Kampfes ein Schiff zu viel Schaden hat, sinkt es ohne Meldung, und die Einheiten fallen ins Meer, und ertrinken.

Eine Meldung, dass ein Schiff sinkt, sollte der Besitzer wohl immer bekommen?

(0008012)
Enno   
2018-07-31 22:09   

Die Funktion sink_ship tut (fast) das richtige, und gibt den Einheiten auf dem Schiff eine Chance, sich in eine benachbarte Landregion zu retten. Die sollte vielleicht nicht nur von SABOTIERE benutzt werden, sondern in allen Fällen, wo ein Schiff sinkt?

(0008013)
Enno   
2018-08-01 10:16   

Funktioniert beinahe, sieht aber noch etwas verwirrend aus:

Boot ztj6 (ztj6) versinkt in den Fluten von Ozean (0,0).
Boot ztj6 (ztj6) versinkt in den Fluten von Ozean (0,0).
Einheit g6qz (g6qz) überlebt unbeschadet und rettet sich nach Ozean (0,0).
Einheit g6qz (g6qz) ertrinkt in Ozean (0,0).

Doppelte Meldung über den Untergang, Einheit rettet sich beim Versinken, ertrinkt dann anschließend, wenn Schwimmer eliminiert werden. Hmm. Kann man nach dem Versinken noch auf ein anderes Boot klettern? Oder ist so eine Rettung immer für die Katz?

(0008014)
Enno   
2018-08-01 11:53   
(Zuletzt bearbeitet: 2018-08-01 11:53)

So ist's besser:

Boot ztj6 (ztj6) versinkt in den Fluten von Ozean (0,0).
Einheit g6qz (g6qz) ertrinkt in Ozean (0,0).

Ich streiche die ganze Sache mit der Überlebenschance bei SABOTIERE, das war sowieso ein latenter Exploit.

(0008015)
Enno   
2018-08-01 11:56   

Überflüssigen Code löschen ist das Beste auf der Welt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2469 [Eressea] General kleinerer Fehler immer 2018-07-29 21:10 2018-07-31 11:01
Reporter: Tokahe Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.6  
    Zielversion: 3.16.6  
Partei: kr51
Spiel: E2
Report: 1086
Zusammenfassung: Zeige Tränke führt zu falschen Angaben
Beschreibung:

Hallo zusammen,

in meinen Befehlen habe ich standardgemäß ein @Zeige Alles Tränke drin. Seit einigen Wochen führt der zu falschen Angaben. Zur besseren Übersicht habe ich aus dem NR die Daten kopiert:

                             Neue Tränke

                               Heiltrank
                                Stufe 4

                   Benötigte Kräuter: Gurgelkraut

 Für einen Heiltrank nehme man die Schale eines Windbeutels und etwas

Gurgelkraut, rühre eine kleingehacktes Elfenlieb dazu und bestreue alles mit
den Blüten einer Eisblume. Dies muß vier Tage lang gären, wobei man am
zweiten Tag einen Spaltwachs dazutun muß. Dann ziehe man vorsichtig den oben
schwimmenden Saft ab. Ein solcher Trank gibt vier Männern (oder einem Mann
vier mal) im Kampf eine Chance von 50%, sonst tödliche Wunden zu überleben.
Der Trank wird von ihnen automatisch bei Verletzung angewandt.

                           Elixier der Macht
                                Stufe 4

                    Benötigte Kräuter: Elfenlieb

Eines der seltensten und wertvollsten alchemistischen Elixiere, verleiht
dieser Trank dem Anwender für einige Wochen die Kraft eines Drachen. Der
Trank erhöht die Lebensenergie von maximal zehn Personen auf das fünffache.
Die Wirkung ist direkt nach der Einnahme am stärksten und klingt danach
langsam ab. Zur Herstellung benötigt der Alchemist ein Elfenlieb, einen
Windbeutel, ein Stück Wasserfinder und einen Grünen Spinnerich. Über dieses
Mischung streue er schließlich einen zerriebenen Blasenmorchel und rühre
dieses Pulver unter etwas Drachenblut.

                              Bauernlieb
                                Stufe 4

                     Benötigte Kräuter: Alraune

Das Bauernlieb betört Mann und Frau gleichwohl und läßt in ihnen den Wunsch
nach Kindern anwachsen. Für eine große Portion höhle man eine Alraune aus,
gebe kleingehackten Blasenmorchel, Elfenlieb und Schneekristall dazu, streue
ein wenig geriebenen Steinbeißer darüber und lasse dieses zwanzig Stunden
lang auf kleiner Flamme kochen. Bis zu 1000 Bauern vermag der Trank das Glück
von Zwillinge zu bescheren.

                             Berserkerblut
                                Stufe 3

                Benötigte Kräuter: Weißer Wüterich

Will man seine Krieger zu Höchstleistungen antreiben, sei das Berserkerblut
empfohlen. Um es herzustellen, braucht man einen Weißen Wüterich, etwas
Flachwurz, Sandfäule und eine Alraune. Alle Zutaten müssen möglichst klein
geschnitten und anschließend zwei Stunden lang gekocht werden. Den
abgekühlten Brei gebe man in ein Tuch und presse ihn aus. Der so gewonnene
Saft reicht aus, um zehn Kämpfer besser angreifen zu lassen.

                             Pferdeglück
                                Stufe 3

                Benötigte Kräuter: Blauer Baumringel

 Für das Pferdeglück zerhacke man einen Kakteenschwitz, einen blauen

Baumringel und etwas knotigen Saugwurz und koche das ganze mit einem Eimer
Wasser auf. Dann füge man etwas Sandfäule dazu und lasse diesen Sud drei
Tage lang ziehen. Letztlich gebe man es den Pferden zu trinken, auf dass sie
sich doppelt so schnell vermehren.

                              Nestwärme
                                Stufe 3

                     Benötigte Kräuter: Eisblume

Nestwärme erlaubt es einem Insekt, im Winter außerhalb von Wüsten neue
Rekruten anzuwerben. Zur Zubereitung nimmt der geübte Alchemist einen
Kakteenschwitz, vermischt ihn mit einer Portion Spaltwachs, die in einer
sternklaren Nacht gesammelt wurde, gibt zur Vertreibung des Winters einige
Blütenblätter der Eisblume in den Sud, und rührt alles mit einem grünen
Spinnerich bis es eine violette Farbe annimmt. Ein Trank reicht eine Woche
lang für eine ganze Region.

                            Dumpfbackenbrot
                                Stufe 3

                    Benötigte Kräuter: Eulenauge

 Das Dumpfbackenbrot ist eine sehr gemeine Sache, macht es doch jeden

Lernerfolg zunichte oder läßt einen gar Dinge vergessen! Für zehn Portionen
verknete man einen geriebenen Fjordwuchs, einen zerstoßenes Eulenauge und
einen kleingeschnittenen Grünen Spinnerich zu einem geschmeidigen Teig.
Diesen backe man eine Stunde lang bei guter Hitze und bestreiche das Ergebnis
mit etwas Höhlenglimm. Wer dieses Brot gegessen hat, kann eine Woche lang
nichts lernen, und so er nichts zu lernen versucht, wird er gar eine Woche
seiner besten Fähigkeit vergessen.

                             Gehirnschmalz
                                Stufe 3

                   Benötigte Kräuter: Wasserfinder

Für das Gehirnschmalz verrühre man den Saft eines Wasserfinders mit recht
viel geriebenem Windbeutel und ein wenig Gurgelkraut. Dies lasse man kurz
aufwallen. Wenn die Flüssigkeit nur noch handwarm ist, gebe man etwas
Steinbeißer dazu. Das ganze muß genau siebenmal rechtsherum und siebenmal
linksherum mit einem großen Löffel gerührt werden. Wenn keine Bewegung mehr
zu erkennen ist, fülle man den Saft ab. Der Saft gibt mit einer Chance von
1/3 bis zu zehn Personen einen zusätzlichen Lernversuch.

                              Bauernblut
                                Stufe 2

                   Benötigte Kräuter: Höhlenglimm

Zu den gefährlichsten und geheimsten Wissen der Alchemisten zählt die

Kenntnis um diesen Trank. Den finstersten Höllen entrissen, ermöglicht die
Kenntnis dieser Formel die Herstellung eines Elixiers, welches Dämonen als
Nahrung dient. Von normalen Lebewesen eingenommen, führt es zu schnellem Tod
und ewigen Nichtleben. Die Herstellung benötigt nebst Fjordwuchs, etwas
Höhlenglimm und einem Blauen Baumringel auch einen Bauern aus der Region,
welcher in einem tagelangen blutigen Ritual getötet wird. Ein Fläschchen des
Tranks kann den Hunger von 100 Dämonen für eine Woche stillen.

                               Wundsalbe
                                Stufe 2

                Benötigte Kräuter: Weißer Wüterich

Ist man nach einem einem harten Kampf schwer verwundet, ist es ratsam, etwas
Wundsalbe parat zu haben. Streicht man diese magische Paste auf die Wunden,
schließen sich diese augenblicklich. Für die Herstellung benötigt der
Alchemist nebst einem Blauen Baumringel einen Würzigen Wagemut und einen
Weißen Wüterich. Eine solche Portion heilt bis zu 400 Lebenspunkte.

                            Schaffenstrunk
                                Stufe 2

                     Benötigte Kräuter: Alraune

Man lasse einen Würzigen Wagemut drei Stunden lang in einem Liter Wasser
köcheln. Dann gebe man eine geriebene Alraune dazu und bestreue das ganze mit
bei Vollmond geerntetem Spaltwachs. Nun lasse man den Sud drei Tage an einem
dunklen und warmen Ort ziehen und seie dann die Flüssigkeit ab. Dieser
Schaffenstrunk erhöht die Kraft und Ausdauer von zehn Männern, so dass sie
doppelt soviel schaffen können wie sonst.

                           Wasser des Lebens
                                Stufe 1

                    Benötigte Kräuter: Elfenlieb

Das 'Wasser des Lebens' ist in der Lage, aus gefällten Baumstämmen wieder
lebende Bäume zu machen. Dazu wird ein knotiger Saugwurz zusammen mit einem
Elfenlieb erwärmt, so dass man gerade noch den Finger reinhalten kann. Dies
gieße man in ein Gefäß und lasse es langsam abkühlen. Der Extrakt reicht
für 10 Holzstämme.

                          Trank der Wahrheit
                                Stufe 1

                    Benötigte Kräuter: Flachwurz

Dieses wirkungsvolle einfache Gebräu schärft die Sinne des Trinkenden
derart, dass er in der Lage ist, eine Woche lang auch die komplexesten
                      Illusionen zu durchschauen.

                             Goliathwasser
                                Stufe 1

                   Benötigte Kräuter: Gurgelkraut

Zuerst brate man das Gurgelkraut leicht an und würze das Zeug mit ein wenig
Fjordwuchs. Man lasse alles so lange kochen, bis fast alle Flüssigkeit
verdampft ist. Diesen Brei stelle man über Nacht raus. Am nächsten Morgen
presse man den Brei aus. Die so gewonnene Flüssigkeit, Goliathwasser genannt,
verleiht bis zu zehn Männern die Tragkraft eines Pferdes.

                            Siebenmeilentee
                                Stufe 1

                Benötigte Kräuter: Blauer Baumringel

Für den Siebenmeilentee koche man einen Blauen Baumringel auf und gieße
dieses Gebräu in einen Windbeutel. Das heraustropfende Wasser fange man auf,
filtere es und verabreiche es alsdann. Durch diesen Tee können bis zu zehn
Menschen schnell wie ein Pferd laufen.

Der Fehler ist aber auch im CR, das kann ich an meinen falschen Berechnungen der herzustellenden Tränke erkennen. Was ich nicht nachgerechnet habe, ist der Verbrauch an Kräutern, wenn ein Trank gebraut wird, insofern ist ggfs. nicht Zeige falsch, sondern die Alchemie an sich.

Eine Korrektur wäre gut.

Danke,

Michael aka Tokahe

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008004)
Enno   
2018-07-30 20:24   

Nur, um sicher zu sein, dass ich das verstehe: Der Fehler ist, dass bei jedem Trank nur ein benötigtes Kraut als Zutat angegeben wird? Listen im Report auszugeben ist immer schon ein Drama, siehe auch Fehler im Kampfreport neulich, oder die Liste der Straßen.

(0008005)
Enno   
2018-07-30 20:26   

Es kann aber auch die Alchemie an sich kaputt sein, wenn das eine Spätwirkung der XML-Umstellung ist... Weia.

(0008006)
Enno   
2018-07-31 09:29   

Fehler ist gefunden, war im XML-Parser.

(0008007)
Enno   
2018-07-31 10:11   

Sieht jetzt viel besser aus, glaube ich:

                            Siebenmeilentee
                                Stufe 1

          Benötigte Kräuter: Blauer Baumringel, Windbeutel
(0008009)
Enno   
2018-07-31 10:35   

Weil das eine Regression in einem viel benutzten Feature ist (Tränke brauen ist auch betroffen), repariere ich das sofort zum kommenden Wochenende.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2468 [Eressea] General kleinerer Fehler nicht reproduzierbar 2018-07-29 20:24 2018-07-31 11:00
Reporter: Tokahe Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.16.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.6  
    Zielversion: 3.16.6  
Partei: kr51
Spiel: E2
Report: 1086
Zusammenfassung: Leere
Beschreibung:

Hallo zusammen,

auf meine Bitte hin wurde die bisherige Leere, die den Abschluss der 17. Welt (die Welt in der Aussetzen neuer Parteien eingestellt wurde) bildet, durch eine Feuerwand ersetzt. Dabei wurde eine Region, die nicht direkt am Rand ist, vergessen und stellt weiterhin eine Leere da. Daher wäre nett, wenn die Leere, durch einen Ozean, eine Feuerwand oder auch eine normale Region ersetzt werden könnte. Eine Nichtregion in der Karte ist irgendwie doof.

Die Nachbarregionen der Leere sind:

Feuerwand (-10, 17) (twdp2o)
Feuerwand (-9, 16) (y9g8rg)
Ozean (-9, 15) (gncmLa)
Ozean (-10, 15) (kc77mm)
Ozean (-11, 16) (8avq5)
Ozean (-11, 17) (1Lr23r)

Reicht das an Informationen oder braucht ihr noch etwas?

Danke,

Michael aka Tokahe

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien: Export2.cr (31,948 Bytes) 2018-07-29 20:24
https://bugs.eressea.de/file_download.php?file_id=94&amp;type=bug
Notiz
(0008008)
Enno   
2018-07-31 10:31   

Okay. Das Loch ist gefüllt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2467 [Eressea] Mail kleinerer Fehler nicht getestet 2018-07-24 09:56 2018-07-24 12:06
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.5  
    Zielversion: 3.16.5  
Partei: daeL
Spiel: E2
Report: 1085
Zusammenfassung: Befehlsbestätigung funktioniert nicht.
Beschreibung:

Seit dem Wochenende gibt es keine ECheck-Bestätigungen für eingegangene Befehle mehr.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007995)
Enno   
2018-07-24 12:06   

Sollte jetzt wieder klappen, mutt kannte das Zertifikat des neuen Mailservers noch nicht.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2466 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-07-23 15:33 2018-07-23 22:11
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.16.5  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 1085
Zusammenfassung: Beschreibung Wurmloch
Beschreibung:

Die Dinger tauchen ab und zu plötzlich auf, haben aber keine sichtbare Beschreibung.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007984)
Solthar   
2018-07-23 15:37   

Die Beschreibung des Effekts ist auch etwas lakonisch-kurz: "In Heimat (0,0) erscheint ein Wurmloch."

(0007989)
Enno   
2018-07-23 18:24   

Es war damals, als sie eingeführt wurden, Absicht, dass es keine Informationen zu den Dingern gab, und die Spieler erst alles selber herausfinden mussten. Das hat die Spannung für die Spielleitung erhöht.

(0007992)
Solthar   
2018-07-23 22:10   

Das finde ich auch cool, trotzdem könnten sie eine bessere Beschreibung haben, ohne dass daraus ersichtlich ist, wie sie funktionieren. Das würde einfach die Phantasie anregen.

(0007993)
Solthar   
2018-07-23 22:11   

Ich bin sowieso gerade dabei, mir die Übersetzungen anzuschauen. Ich überlege mir mal was.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2063 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2015-01-04 12:24 2018-07-23 22:08
Reporter: Kildaron Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: cere
Spiel: E2
Report: 910
Zusammenfassung: Rassen ohne Beschreibungstext
Beschreibung:

Warum gibt es bei vielen Rassen keine Beschreibung?
Sind die im laufe der Jahre verschwunden oder waren nie welche hinterlegt?

Beispiel:
aquarian: No information available for this race.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005698)
CTD   
2015-03-02 13:28   

Vermutlich gab es die nie.
Aber du kannst ja gern mal ein paar schöne Texte für Rassen / Monster / Gegenstände zusammenschreiben wo du weißt das die Beschreibung fehlt, dann baue ich die ein.

(0005706)
Enno   
2015-03-30 18:06   

Der Titel dieses Eintrages war ziemlich nichtssagend, ich habe das mal verbessert.

(0005707)
Xolgrim   
2015-03-31 19:03   

Text beispielhaft an Meermenschen:

Meermensch: Wir wollen an dieser Stelle niemandem vorschreiben, wie er sich die Rassen Eresseas vorzustellen hat. Es soll schon Spieler gegeben haben, die Ihre Insekten als Engel mit weißen Flügeln gesehen haben... Daher folgend nur einige Grundlegende Werte: 20 Trefferpunkte, Angriff: -2, Verteidigung: -2. Kann Waffen benutzen. 2 Angriffe: ein magischer Angriff, ein Angriff mit der Waffe oder unbewaffnet (1d5).

(0007983)
Solthar   
2018-07-23 15:26   

Dagegen. Beschreibungen sollten unbedingt in-game sein. Die Rassenbeschreibungen in den Regeln können hier als Vorlage dienen. Bei den Spielerrassen finde ich die Beschreibung allerdings relativ unwichtig, eben weil sie in den Regeln stehen. Hier geht die Parteibeschreibung vor.

(0007988)
Enno   
2018-07-23 18:13   

Das ist aber ein alter Bug, wie kommst Du dazu, den jetzt wider auszugraben?

(0007991)
Solthar   
2018-07-23 22:08   

Weil ich vor 0002466 nach "Beschreibung" gesucht habe.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2464 [Eressea] Mail schwerer Fehler immer 2018-07-21 23:34 2018-07-22 19:04
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.4  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: cbc
Spiel: Deveron
Report: 216
Zusammenfassung: Reportnachforderung funktioniert nicht mehr
Beschreibung:

Ich habe heute versucht den Report sowohl für eine Partei in E2 als auch für mehrere Parteien in Deveron nachzufordern. Bisher (8 Stunden später) ist noch keiner der nachgeforderten Reporte eingetroffen.

Da zur Zeit Urlaubszeit ist, wäre es - zumindest in Deveron - nicht unwichtig, wenn das repariert werden könnte, gerade auch, weil in Deveron die spielentscheidende Phase ist (das Spiel soll beendet werden, wenn im momentan laufenden Krieg der Sieger feststeht). In E2 ist das - meiner Ansicht nach - weniger wichtig, da wären die vom Server ausgeführten Defaultbefehle vollkommen in Ordnung.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007980)
Xolgrim   
2018-07-22 08:23   

Gestern hat das noch alles wunderbar funktioniert. Ich hab's heute zur Validierung noch einmal versucht und bei mir läuft es nun auch nicht mehr. Vermutlich ein Nebeneffekt des Umzugs?

(0007981)
Julian   
2018-07-22 09:53   

Eressea Development (@eresseadev) twitterte um 8:33 nachm. on Sa., Juli 21, 2018:
Wegen eines dummen Patzers meinerseits kann diese Woche der Report nicht per Mail nachgefordert werden.
(https://twitter.com/eresseadev/status/1020753687541698560?s=03)

(0007982)
Enno   
2018-07-22 19:04   

https://twitter.com/eresseadev/status/1020753687541698560


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2461 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-07-15 10:45 2018-07-15 13:40
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.17.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: 1wpy
Spiel: E2
Report: 1084
Zusammenfassung: Fehlende Angreiferpartei im Kampfreport
Beschreibung:

Bei Kämpfen mit nur einer Angreiferpartei fehlt diese:

              In Gepi (-77,-148) findet ein Kampf statt.

Der Kampf wurde ausgelöst von .

Heer 0: Unbekannte Partei
Kämpft gegen: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy)
Hilft: Heer 0(-?-)
Attacke gegen: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy)
... in der 1. Kampflinie:

  • Dunkle Ghoule (n2yw), 4 Ghaste, aggressiv, bewacht die Region.
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007969)
Enno   
2018-07-15 12:00   

Der Code ist doch gerade erst geändert worden... Grummel.

(0007970)
Enno   
2018-07-15 13:40   

Gefixt in commit 820264aa


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2447 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-06-10 12:15 2018-07-15 10:45
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.16.3  
Partei: 1wpy
Spiel: E2
Report: 1080
Zusammenfassung: Fehlende Angreiferpartei im Kampfreport
Beschreibung:

Im Kampfreport steht:
Der Kampf wurde ausgelöst von Seekoenigtum Gerengko (1wpy) und Seekoenigtum
Gerengko (1wpy).

Die Partei Monster (ii) muss jedoch ebenfalls angegriffen haben, denn sie taucht als Heer 0 auf und meine Einheiten, die nicht angegriffen haben, waren im Kampf.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Der Kampf wurde ausgelöst von Seekoenigtum Gerengko (1wpy) und Seekoenigtum
Gerengko (1wpy).

Heer 0: Monster (ii)
Kämpft gegen: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy), Heer 4(1wpy), Heer
5(1wpy)
Hilft: Heer 0(ii)
Attacke gegen: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy), Heer 4(1wpy), Heer
5(1wpy)
... in der 1. Kampflinie:

  • Skelette der Erschlagenen (955m), 712 Skelettherren, aggressiv (schwer
    verwundet), bewacht die Region.

Heer 1: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy), Heer 4(1wpy), Heer 5(1wpy)
Attacke gegen: Heer 0(ii)
... in der 1. Kampflinie:

  • Korrexer Nautilusgarde (mcmv), 99 Meermenschen, vorne, bewacht die Region,
    Talente: Reiten 5, Hiebwaffen 27, Segeln 10, Tarnung 9, Steuereintreiben
    2, Ausdauer 13, hat: 99 Bihänder, 8670 Silber, 11 Wundsalben, 2
    Berserkerblut, 99 Plattenpanzer, 99 Schilde, Gürtel der Trollstärke.

Heer 2: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy), Heer 4(1wpy), Heer 5(1wpy)
Attacke gegen: Heer 0(ii)
... in der 1. Kampflinie:

  • Rekruten (5pbL), 117 Meermenschen, vorne, bewacht die Region, Talente:
    Pferdedressur 1, Reiten 6, Hiebwaffen 26, Tarnung 8, Steuereintreiben 4,
    Ausdauer 13, hat: 117 Kettenhemden, 117 Laenschwerter, 11490 Silber, 117
    Schilde, Gürtel der Trollstärke.
    ... in der 4. Kampflinie:
  • Ersatzzwerge (2it9), 3 Meermenschen, flieht, Talente: Bergbau 19, Ausdauer
    3, hat: 470 Silber.
  • Miliz (pk1b), 1 Meermensch, flieht, Talente: Pferdedressur 1, Reiten 2,
    Hiebwaffen 1, Stangenwaffen 2, Tarnung 1, Unterhaltung 6, Ausdauer 1, hat:
    Pferd, 110 Silber, Speer.

etc...

Angehängte Dateien:
Notiz
(0007919)
Enno   
2018-06-18 20:17   

Es stimmt, dass die Monster hier angegriffen haben müssen, denn bei ihrem Heer steht:

Attacke gegen: Heer 1(1wpy), Heer 2(1wpy), Heer 3(1wpy), Heer 4(1wpy), Heer 5(1wpy)

Leider ist das schwer zu reproduzieren, weil es vom Zufall abhängig ist, ob die Monster attackieren. Bei meinem Test gerade taten sie es z.B. nicht.

(0007920)
Enno   
2018-06-18 20:34   

Fehler gefunden, repariert in commit 2b0b7cd0f


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2457 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-07-04 17:15 2018-07-13 22:48
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.5  
    Zielversion: 3.16.5  
Partei: pdfs
Spiel: E2
Report: 1083
Zusammenfassung: CR hat inkonsistente Informationen von Burgenbesitzern
Beschreibung:

Der CR zeigt seit neuerem in einer durchgereisten Region die Burg und deren Besitzer an, zu dem Besitzer gibt es aber keinen EINHEIT-Block. Also enthält er die Referenz auf eine nicht existierende Einheit. Das hat bei Magellan zu Datenverlusten geführt. Ich bin noch dabei, das Problem zu analysieren ...

846024208;id
"Tencor";Name
"Ebene";Terrain
"travel";visibility
4501;Bauern
945;Pferde
32;Baeume
3;Schoesslinge
...
DURCHSCHIFFUNG
"IKV-N Whitestar (hf1o)"
BURG 1403557
"Festung";Typ
"Burg";Name
1323;Groesse
1663436;Besitzer
89062;Partei
...

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007943)
Enno   
2018-07-04 21:15   

Was wäre hier denn richtig? Den Burgenbesitzer nicht mit anzeigen? Ich glaube ja, im NR ist er ja schließlich auch nicht zu sehen.

(0007944)
Enno   
2018-07-04 21:16   

Wird das in Magellan repariert? Kann ein Bugfix im Server bis zum nächsten Release (3.17) warten?

(0007945)
Thoran   
2018-07-05 00:34   

Das hat mit Sicherheit mit den Änderungen bzgl. der Bugreports 2395 und/oder 2425 zu tun.

Vorher waren von Leuchttürmen aus bzw. von durchreisenden Einheiten alle bewachenden Einheiten der Region - wenn es eine Landregion war - zu sehen und ebenso alle Einheiten, die sich innerhalb einer Burg oder an Bord eines Schiffes befanden. Alle anderen Einheiten der Region wurden nicht gesehen. Bei einer Seeregion wurden alle Schiffe und alle Einheiten an Bord der Schiffe gesehen. Sowohl für Land- als auch Seeregion galt dabei, dass man nur die Einheiten, nicht jedoch ihren Besitz sehen konnte.

Nach den Bugfixes waren eine Zeitlang weder Einheiten an Bord von Schiffen in Seeregionen noch die Einheiten in einer Landregion zu sehen, die sich innerhalb einer Burg bzw. an Bord eines dortigen Schiffes befanden (jeweils von einem Wahrnehmer in einem benachbarten Leuchtturm oder von einer durchreisenden Einheit).

Seit der letzten Version sind Schiffsinsassen in Seeregionen vom Leuchtturm aus wieder sichtbar, ebenso Einheiten in Burgen und an Bord von ankernden Schiffen (wie zuvor jeweils ohen ihren Besitz). Durchreisende Einheiten hingegen sehen weder Schiffsinsassen auf dem Ozean (wenn ein eigenes Schiff durch die Region gesegelt ist) noch sehen sie Burgenbesitzer oder Schiffsinsassen an Land (wenn eine eigene Einheit sich durch die Region bewegt hat).

(0007946)
Solthar   
2018-07-05 18:23   

Ich denke, Magellan kriegt das auch so hin. Wobei der Mergecode, wo das Probleme liegt, ein Alptraum ist.

(0007947)
Enno   
2018-07-05 20:23   

Verstehe ich den Kommentar von Thoran richtig, dass hier die Einheiten fehlen, die man sonst bei einer Durchreise sehen sollte? Ich habe keine Ahnung, wie das früher war, und was man im Fall der Durchreise gesehen hat.

(0007948)
Thoran   
2018-07-05 21:36   

Ja, das verstehst Du richtig.

Wenn man in einer Region keine eigenen Einheiten hat und eigene Einheiten durch diese Region gereist (ob auf See oder an Land ist unerheblich), dann hat man früher alle Einheiten gesehen, die entweder die Region bewachen oder die sich in Gebäuden befinden oder die sich an Bord von Schiffen aufhalten. Von keiner dieser Einhten hat man den Besitz gesehen.

(0007963)
Enno   
2018-07-13 22:48   

Für die Zukunft: Einheiten, die nicht bis zur Unsichtbarkeit getarnt sind, kann man sehen:

  1. wenn man eine Einheit in der Region hat,
  2. wenn man die Region von einem Leuchtturm aus sieht,
  3. wenn man durch die Region gereist ist, und die Einheit steht in Gebäude oder Schiff, oder bewacht die Region.

Das sind glaube ich die Regeln, und so habe ich das jetzt repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2396 [Eressea] REKRUTIERE kleinerer Fehler nicht getestet 2017-12-16 21:38 2018-07-08 12:35
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: sfs
Spiel: E2
Report: 1055
Zusammenfassung: Insekten können in letzer Herbstwoche scheinbar nicht rekrutieren
Beschreibung:

Laut nr-Report ist diese Woche die letzte, in der Insekten rekrutieren können. Aktuell ist die zweite Woche des Monats Sturmmond. Nächste Woche ist also die dritte Woche des Monats Sturmmond und daher auch noch Herbst! Laut Regeln können Insekten im Winter nicht rekrutieren

Für meine noch junge 3-Wochen alte Insekten Partei ist das ein Problem, da ich 5 Wochen eingeplant hatte, in denen ich rekrutieren darf.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Report für Eressea, Saturday, 16. December 2017, 21:21
Wir schreiben die zweite Woche des Monats Sturmmond im Jahre 33 des zweiten Zeitalters. Es ist Herbst.
[...]
Es ist Spätherbst, und diese Woche ist die letzte vor dem Winter, in der Insekten rekrutieren können.

Angehängte Dateien:
Notiz
(0007696)
Enno   
2017-12-21 09:46   

Ich sagte doch, dass die Jahreszeiten verwirrend sind. @Xolgrim meinte, die seien total logisch, aber für mich als Programmierer sind sie das nicht, weil die Auswertung immer schon die folgende Runde betrachtet, nicht die im NR angegebene. Seufz. Vielleicht ist das die Lösung? Die turn Variable erst für den Report anheben, nicht vor der AW schon? Das macht eine Menge Tests kaputt, und muss vorsichtig eingeführt werden, aber ich glaube, es wäre eine gute Lösung.

(0007697)
Enno   
2017-12-21 09:47   

Zur Information: Es sollte momentan gelten, dass man als Insekt rekrutieren kann, wenn im Report nicht steht, dass es Winter ist. Die Meldung ist also wahrscheinlich einfach falsch.

(0007698)
Enno   
2017-12-21 09:48   

http://www.catb.org/jargon/html/O/off-by-one-error.html

(0007699)
Enno   
2017-12-21 10:34   

Fehler gefunden, den kann ich sicher ohne große Umbauten reparieren. Hier wird 1 Woche zu viel addiert:

get_gamedate(turn + 1, &date);
thisseason = date.season;
get_gamedate(turn + 2, &date);
nextseason = date.season;

Das gilt nur für die Anzeige der Warnung, glaube ich.

(0007700)
Enno   
2017-12-21 10:47   

Was bei dieser Gelegenheit auch mal gemacht werden könnte: Dies ist eine der Warnungen, die nur im NR stehen, und die Magellan-Benutzer deshalb nie zu sehen bekommen.

(0007701)
Enno   
2017-12-22 11:16   

Zusammen mit der Immunität vor Attacken sollte das demnächst in NR und CR auftauchen (und richtig ist es auch).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2445 [Eressea] General kleinerer Fehler nicht getestet 2018-06-09 21:46 2018-07-07 12:22
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.17.0  
    Zielversion: 3.17.0  
Partei: 0
Spiel: Deveron
Report: 210
Zusammenfassung: WARNING: multiple translations
Beschreibung:

In E3 und Deveron sind einige Strings doppelt. DAs führt zu verwirrenden Zeilen im Log:

WARNING: multiple translations for key spellinfo::concealing_aura
WARNING: multiple translations for key spellinfo::raindance
WARNING: multiple translations for key spellinfo::earn_silver#gwyrrd
WARNING: multiple translations for key describe::lifepotion
WARNING: multiple translations for key spellinfo::blessedharvest
WARNING: multiple translations for key spellinfo::earn_silver#draig
WARNING: multiple translations for key spellinfo::earn_silver#cerddor
WARNING: multiple translations for key spellinfo::earn_silver#illaun
WARNING: multiple translations for key spellinfo::earn_silver#tybied
WARNING: multiple translations for key spellinfo::concealing_aura
WARNING: multiple translations for key spellinfo::raindance
WARNING: multiple translations for key spellinfo::earn_silver#gwyrrd
WARNING: multiple translations for key describe::lifepotion
WARNING: multiple translations for key spellinfo::blessedharvest
WARNING: multiple translations for key spellinfo::earn_silver#draig
WARNING: multiple translations for key spellinfo::earn_silver#cerddor
WARNING: multiple translations for key spellinfo::earn_silver#illaun
WARNING: multiple translations for key spellinfo::earn_silver#tybied

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007900)
Enno   
2018-06-09 21:48   

Wir hatten auch einen Bug, wo eine message (tactics_won) keinen Text hatte (weil er para_tacticswon heisst). Das mit dem para Präfix ist ein dummer Hack, und gehört anders gelöst.

(0007949)
Enno   
2018-07-07 12:22   

Moving those duplicate strings into a new file.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2420 [Eressea] LERNE/LEHRE Feature-Wunsch nicht getestet 2018-02-16 23:08 2018-07-04 16:30
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 1063
Zusammenfassung: Silberkosten LERNE Magie
Beschreibung:

Der Befehl LERNE Magie hat einen optionalen Parameter für die Silberkosten. Der ist rein informativ. Wenn er kleiner ist als der wirklich benötigte Wert, wird trotzdem das eigentlich benötigte Silber ausgegeben. Zudem wird der Wert in den Defaultbefehlen nicht richtig aktuell gehalten, wenn sich das Magielevel ändert. Stattdessen wird einfach der Wert uas der letzten Runde übernommen. Man muss also jede Runde selber nachrechnen. Das ist sehr lästig und führt zu Fehlern.

Änderungsvorschlag:

  1. Es wird beim Lernen nur die angegebene Menge Silber verbraucht. Entsprechend weniger wird gelernt. Also zum Beispiel bei LERNE Magie 500 statt eigentlich benötigter LERNE Magie 1500 nur 1/3 Lernchance. Vielleicht ist das aber keine gute Idee aus "historischen Gründen".

  2. Der Server sollte den wirklich benötigten Wert ausrechnen und im Befehl setzen. Das muss er sowieso machen, da kann er auch gleich den Benutzer informieren. Eventuell gibt es da Probleme im Detail. Kann man alle Boni zuverlässig und sinnvoll einrechnen, so dass sie auch nächste Woche gelten? Bei einer Akadamie zum Beispiel? Elfen?

  3. Den Parameter ganz weglassen. Nicht gerade die beste Lösung, aber die einfachste.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007899)
Xolgrim   
2018-06-02 10:20   
(Zuletzt bearbeitet: 2018-06-02 10:23)

Lösung 3 funktioniert doch schon ... Wenn du deinem Magier den Befehl "LERNE MAGIE" gibst steht da nächste Woche auch nur "LERNE MAGIE"

PS: Ist der Parameter irgendwo in der Aneltung festgehalten? Ich habe da auf die Schnelle nichts zu gefunden

(0007942)
Enno   
2018-07-04 16:30   

Der Parameter ist doof. Er erfordert eine Sonderbehandlung für den LERNE Befehl, wenn man Magie lernt, und ich werde ihn wohl abschaffen im Rahmen des geplanten LERNE AUTO Befehls.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2455 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-06-29 22:03 2018-06-30 08:58
Reporter: Tar_Nelarn Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 2j4d
Spiel: E2
Report: 1080
Zusammenfassung: Das Einfahren in einen Hafen scheint helfe bewache zu benötigen
Beschreibung:

Nach meinem Verständnis der Anleitung müsste ein Hafen für jedes Schiff offen stehen, insbesondere kein helfe bewache nötig sein. Ich bilde mir ein, dass das bisher auch so war?

Jetzt scheint es aber anders zu sein:

Partei Handelsgilde Troicents (2j4d)

Runde 1080, Test:

Die Binsen 51 (9g2w) segelt von Tesohas (0,2) nach Ozean (-1,3).
(wollte aber wieder zurück in den Hafen aus dem es kam)

Die Mannschaft der Binsen 51 (9g2w) kann in letzter Sekunde verhindern, dass
das Schiff in Tesohas (0,2) auf Land aufläuft.

Der Hafen in der Zielregion wird von einer anderen Partei gehalten (td) - testweise wurde das helfe bewache diese Runde abgeschaltet. In der Folgerunde wurde es wieder aktiviert und der Hafen konnte wieder befahren werden.

Einheit die den Hafen hält: td00, Partei td
Kapitän des Schiffes: j827, Partei 2j4d (verkleidet als td)
Hafen: ni9o

Han Loren, Gouverneur von Tesohas (td00) bezahlt den Unterhalt von Hafen (ni9o).
-> aktiv sollte er also gewesen sein.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007938)
Enno   
2018-06-30 08:58   

Wie Du glaube ich selber schon bemerkt hast, ist diese Meldung ein Duplikat, und wir haben beschlossen, dass das schon immer so war, es hat nur keiner gemerkt. Ich habe die Anleitung entsprechend angepasst.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2454 [Eressea] Schiffe schwerer Fehler nicht getestet 2018-06-24 14:34 2018-06-30 08:58
Reporter: soul Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.2  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: td
Spiel: E2
Report: 1079
Zusammenfassung: Schiffe können nicht in Häfen einreisen ohne Helfe Bewache des Hafenbesitzers
Beschreibung:

Schiffe können nicht in Häfen einreisen ohne Helfe Bewache des Hafenbesitzers.

Laut Regeln:
Schiffe größer als ein Boot können auch in Nichtebenen anlegen, wenn ein Hafen vorhanden ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Region Vonnet hat den Hafen.
Partei td und 4oze

Angehängte Dateien:
Notiz
(0007930)
Enno   
2018-06-24 19:05   

Die Nummer des Schiffes würde mir auch helfen.

(0007931)
soul   
2018-06-24 19:15   

Schiffe pd7u und ggyg.

(0007932)
Enno   
2018-06-24 20:50   

Meldung gefunden. Der Report von 4oze war es, den ich hier angucken musste (nicht td):

Die Schnelles Holz (pd7u) konnte in Vonnet (54,-251) nicht einreisen, die Küste ist zu gefährlich für das Schiff.
(0007933)
Enno   
2018-06-25 17:29   

Der Code sagt, es muss entweder kontaktiert oder HELFE BEWACHE gesetzt sein. An der Stelle hat sich auch seit langem nichts getan. Ihr seid ganz sicher, dass das früher nicht so war?

(0007934)
Enno   
2018-06-25 17:36   

Mit dem Code von Version 3.15.0 passiert das auch. Kein Einlass ohne Kontakt.

(0007935)
Enno   
2018-06-25 17:39   

Auch mit Version 3.14.5 (ein halbes Jahr alt) ist es so, dass man den Kontakt braucht. Ich glaube, ihr irrt Euch.

(0007936)
Enno   
2018-06-25 17:44   

Ich glaube, hier ist lediglich die Anleitung unvollständig. Dort steht zwar "Voraussetzung ist allerdings, daß der Hafeneigner dem Kapitän HELFE BEWACHE gesetzt hat oder der selben Partei angehört.", das bezieht sich dort aber nur auf die Durchreise, nicht die anderen Funktionen des Hafens.

(0007937)
Enno   
2018-06-26 19:54   

Der einzige Fehler, der hier möglicherweise vorliegt, ist in der Anleitung.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2452 [Eressea] ATTACKIERE schwerer Fehler immer 2018-06-24 06:33 2018-06-24 19:04
Reporter: Caranthir Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: dringend BS-Version:  
Status: erledigt Produktversion: 3.16.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.3  
    Zielversion: 3.16.3  
Partei: cara
Spiel: E2
Report: 1082
Zusammenfassung: Duplikat zu 2448: Magier haben Kampfzauber nicht benutzt
Beschreibung:

Der Fehler aus Bug 0002448 scheint noch aktiv zu sein. In der gestrigen Auswertung 1082 haben meine Magier ihre Kampfzauber (Schockwelle) nicht ausgeführt, wie auch schon in 1081. Bitte prüfen, ob 0002448 nochmal geöffnet werden muss. Jedenfalls sollte der Bugfix sofort ausgerollt werden.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007921)
Enno   
2018-06-24 12:06   

Ich fürchte, das liegt daran, dass ich die Version 3.16.3 noch nicht in Produktion habe. Der Fehler ist zwar gefixt, aber wegen meiner sehr aufregenden letzten Wochen ist da der letzte Schritt nicht gemacht worden (im CR steht jedenfalls noch 3.16.2).

(0007926)
Fiete   
2018-06-24 16:28   

Schliesse mich dem Wunsch von Caranthir an, unsere Hirntöter-Töter (Gwyyrds) zaubern keinen Hagel. Präkampfzauber (Wölfe) funktionieren glücklicherweise, so gab es noch keine toten Magier.

(0007929)
Enno   
2018-06-24 19:04   

Release ist fertig, nächste Auswertung ist das in Ordnung.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2453 [Eressea] General kleinerer Fehler nicht getestet 2018-06-24 12:02 2018-06-24 19:03
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.3  
    Zielversion: 3.16.3  
Partei: ene6
Spiel: E2
Report: 1082
Zusammenfassung: Neue Parteien verhungern sofort
Beschreibung:

Einheit 1bzv (1bzv) verliert in Sungad (0,0) 1 von 1 Personen durch Unterernährung.
Unglücklicherweise wurde deine Partei ausgelöscht.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007922)
Enno   
2018-06-24 12:13   

Ich vermute, dass das am neuen Equipment Code liegt, nachdem die Definition aus dem XML geflogen ist. In equipment.lua stehen zwei Definitionen (warum zwei?):

local mysets = {
    ['first_unit'] = {
        ['items'] = {
            ['money'] = 2500,
            ['log'] = 10,
            ['stone'] = 4
        }
    },
    ['seed_unit'] = {
        ['items'] = {
            ['log'] = 50,
            ['stone'] = 50,
            ['iron'] = 50,
            ['laen'] = 10,
            ['sword'] = 1,
            ['mallorn'] = 10,
            ['skillpotion'] = 5,
            ['lifepotion'] = 5,
            ['money'] = 20000
        },
        ['skills'] = {
            ['perception'] = 30,
            ['melee'] = 1
        }
    },
(0007923)
Enno   
2018-06-24 12:16   

Aufklärung: seed_unit ist ein Relikt aus autoseed.lua, als die Parteien noch vollautomatisch gesetzt wurden. first_unit wird von addplayer benutzt, und hätte beim Aussetzen passieren sollen, wenn nicht rules.equip_first auf einen anderen Namen gesetzt ist (ist es nicht).

Eine Normalisierung dieser beiden Namen wäre bestimmt gut.

(0007924)
Enno   
2018-06-24 12:23   

Wenn in C equip_unit aufgerufen wird, delegiert das an den Callback lua_equipunit. Der checkt, ob es im Lua-State eine globale Funktion namens equip_unit gibt. Das geht schief (lua_isfunction() ist FALSE), deshalb passiert nichts.

Die Funktion equip_unit ist aber in equipment.lua! Warum also?

(0007925)
Enno   
2018-06-24 12:30   

Oh! Es scheint, der Mapper lädt andere Module als das Spiel. Insbesondere nicht die Spiel-spezifischen Module. Das geht natürlich nicht.

(0007927)
Enno   
2018-06-24 18:10   

Der Bug ist gefixt, nur die Parteien in den Daten muss ich jetzt noch reparieren.

(0007928)
Enno   
2018-06-24 19:03   

Habe das unfertige Release von 3.16.3 erweitert um diesen Bugfix, und die betroffenen Parteien repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2448 [Eressea] ATTACKIERE schwerer Fehler nicht getestet 2018-06-10 13:29 2018-06-24 06:26
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.3  
    Zielversion: 3.16.3  
Partei: quar
Spiel: E2
Report: 1080
Zusammenfassung: Magier haben Kampfzauber nicht benutzt
Beschreibung:

Meine Magiereinheit (7a64) war diese Runde in Magna Yandana (ID:Lkdrnu) in einen Kampf verwickelt.
Sie Stand auf DEFENSIV, hatte volle Aura, hat attackiert und hatte einen Kampfzauber gesetzt, der bei ihr auch im Kampfbericht aufgeführt wird.

Ein Verbündeter Taktiker (Lp5) hat für uns die Taktikerrunde gewonnen, der Kampf ging aber über die Taktikerrunde hinaus. Im Kampfbericht gibt es keinen Hinweis darauf, dass mein Magier gezaubert hat und er hat auch keine Aura verloren. Jedenfalls hat er immer noch volle Aura und keine Nachricht, dass er welche regeneriert hätte. Er scheint nicht gezaubert zu haben.

Das war sowohl bei der ersten Auswertung 1080 so, als auch bei der Neuauswertung.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007909)
xenomorph   
2018-06-10 13:38   

Ich hatte diese Runde noch einen anderen Kampf, an dem mehr Magier beteiligt waren, die auch alle nicht gezaubert haben. Aber da kann ich mir nicht absolut sicher sein, dass die hätten zaubern müssen, weil dieser Kampf schon in der Taktikerrunde vorbei war.

(0007913)
Enno   
2018-06-11 21:06   

Ja, das sieht so aus als wenn offensive Kampfzauber nicht funktionieren. Doof.

(0007915)
Enno   
2018-06-11 21:25   

Scheinbar haben Meermenschen (und warhscheinlich alle anderen Rassen) keine magische Attacke mehr. Fehler in der XML Konvertierung?

(0007916)
Enno   
2018-06-11 21:29   

Das sollte von rc_create gesetzt werden. Huh.

(0007917)
Enno   
2018-06-11 21:35   

Jetzt besser:

Gera (7a64) zaubert Hagel: 0 Krieger wurden getötet.

(0007918)
Enno   
2018-06-11 21:36   

Danke, Fehler gefunden und repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2443 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-05-20 19:36 2018-06-11 21:14
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.1  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.3  
    Zielversion: 3.16.3  
Partei: drac
Spiel: E3
Report: 459
Zusammenfassung: Rechtschreib- und Layoutfehler im Testreport
Beschreibung:

Im NR

  • Im Kampfreport: Vor
    "Krieger der Finsternis (drtw) konnte dem Gegner eine Falle stellen."
    fehlt eine Leerzeile

  • Fehlende Leerzeichen
    "Ozean (41,36) (vom Turm erblickt), Ozean. Im Nordwesten der Region liegt die
    Ebene von Parl (40,37), imNordosten Ozean (41,37), imOsten Ozean (42,36),
    imSüdosten Ozean (42,35), imSüdwesten Ozean (41,35) und imWesten Ozean
    (40,36)"
    usw.

"ImNordwesten befindet sich eine zu 38% vollendete Straße."

"Die Region wird vonDrachenclan (drac)bewacht."

"Die Region wurde durchquert vonTöter (k983)."

  • Fehlende Überschriften "Ereignisse" und "Warnungen und Fehler". Ist das Absicht?
    "Statistik für Donnerebene (43,38):

    Bauerneinnahmen: 13 Silber
    Rekruten: max. 5 Bauern
    Moral der Bauern: 8
    Personen: 1
    Silber: 1696
    Steine: 937
    Der Unterhalt von Plankenschmiede von Ugor (s5vc) konnte nicht gezahlt werden,
    das Gebäude war diese Woche nicht funktionstüchtig."

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007888)
Julian   
2018-05-21 13:33   

Fehler ist ebenfalls bei E2 aufgetreten, siehe Testreport Partei "keja".

(0007889)
Enno   
2018-05-23 17:53   

Das hat sicher mit der Umstellung von .xml auf .po Dateien zu tun.

(0007893)
Enno   
2018-05-24 16:36   

Fehlende Leerzeilen und Leerzeichen habe ich. Das mit den Überschriften bei Regionsmeldungen ist komplizierter.

(0007896)
Enno   
2018-05-24 20:22   

Das mit den Überschriften ist mir zu kompliziert, um es noch diesen Monat zu machen, und so schlimm ist es ja wohl auch nicht.

(0007903)
Xolgrim   
2018-06-10 07:59   

http://www.pbem-spiele.de/forum/viewtopic.php?f=16&amp;t=4232&amp;p=34622&amp;sid=3e3e7a07257c5f61bc4b2c36d4929cfa#p34622

Der Fehler scheint noch immer zu bestehen.

(0007906)
Enno   
2018-06-10 10:14   

Der Fehler mit den Straßen ist ein anderer als der von mir behobene. Ich schaue mal rein.

(0007907)
Enno   
2018-06-10 10:19   

fehlende Leerzeichen, grammatikalisch korrekte Sätze basteln ist nicht einfach.

(0007908)
Enno   
2018-06-10 10:43   

Das mit den Straßen ist zu kompliziert, als dass ich es heute morgen richtig hinkriege. Hebe ich mir für einen anderen Tag auf. Den NR interessiert eh (fast) niemand.

(0007911)
Enno   
2018-06-10 19:24   
(Zuletzt bearbeitet: 2018-06-10 19:34)

Nach der Regionsstatistik sollte eine Leerzeile sein, und die folgenden Regionsmeldungen wie unbezhalte Gebäude oder Almosten sollten um mindestens zwei Leerzeichen eingerückt sein. Oder wie früher eine Überschrift tragen (Ereignisse, etc)

(0007914)
Enno   
2018-06-11 21:10   

Jetzt habe ich das aber hinbekommen mit den Leerzeichen und Zeilenenden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2449 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2018-06-10 17:19 2018-06-11 20:53
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.2  
    Zielversion: 3.16.2  
Partei: cbc
Spiel: Deveron
Report: 211
Zusammenfassung: Interner Fehler: Meldung 'para_tactics_won' nicht definiert.
Beschreibung:

Die Meldung, dass ein Taktiker die Taktikrunde gewonnen hat, taucht weder im CR noch im NR auf.
Stattdessen erscheint dort:
--- snip (NR) ---
...
Heer 2: Tamul (tamu)
Kämpft gegen: Heer 1(cbc)
Hilft: Heer 0(yuka), Heer 2(tamu)
Attacke gegen: Heer 1(cbc)
... in der 1. Kampflinie:

  • Aliaut (9zif), 1 Ork, vorne, hat: Kriegsaxt, Silberbeutel, Schild.
  • Rugzug (350w), 1 Troll, vorne, bewacht die Region, hat: 68 Hellebarden,
    Silberbeutel, 90 Plattenpanzer, 72 Schilde, Schwert.
    Interner Fehler: Meldung 'para_tactics_won' nicht definiert.

Einheiten vor der 0. Runde:
...
--- snap ---

--- snip (CR) ---
...
MESSAGE 1445137616
1801908756;type
"Heer 2: Tamul (tamu)";rendered
2;index
"Tamul (tamu)";name
MESSAGE 1445139680
1803906635;type
"Kämpft gegen: Heer 1(cbc)";rendered
"Kämpft gegen: Heer 1(cbc)";string
MESSAGE 1445139824
1803906635;type
"Hilft: Heer 0(yuka), Heer 2(tamu)";rendered
"Hilft: Heer 0(yuka), Heer 2(tamu)";string
MESSAGE 1445139968
1803906635;type
"Attacke gegen: Heer 1(cbc)";rendered
"Attacke gegen: Heer 1(cbc)";string
MESSAGE 1445142912
1684814935;type
"... in der 1. Kampflinie:";rendered
1;row
MESSAGE 1445143280
1803906635;type
" - Aliaut (9zif), 1 Ork, vorne, hat: Kriegsaxt, Silberbeutel, Schild.";rendered
" - Aliaut (9zif), 1 Ork, vorne, hat: Kriegsaxt, Silberbeutel, Schild.";string
MESSAGE 1445144336
1803906635;type
" - Rugzug (350w), 1 Troll, vorne, bewacht die Region, hat: 68 Hellebarden, Silberbeutel, 90 Plattenpanzer, 72 Schilde, Schwert.";rendered
" - Rugzug (350w), 1 Troll, vorne, bewacht die Region, hat: 68 Hellebarden, Silberbeutel, 90 Plattenpanzer, 72 Schilde, Schwert.";string
MESSAGE 1445143168
107463271;type
"Interner Fehler: Meldung 'para_tactics_won' nicht definiert.";rendered
"para_tactics_won";name
MESSAGE 1445146112
564544796;type
"Einheiten vor der 0. Runde:";rendered
0;turn
...
--- snap ---

Schritte zur Reproduktion:
Zusätzliche Informationen:

Obiger Kampf fand in der Region "Gubekon, Reich der Yuka" (ID: 5L9srg) statt. Meine am Kampf beteiligte Einheit hat die Nummer 7cn4 (die ist aus dem Kampf geflohen und jetzt in einer Nachbarregion).

Angehängte Dateien:
Notiz
(0007910)
Thoran   
2018-06-10 18:16   

In E2 tritt dieser Fehler übrigens nicht auf. Dort wird die Meldung, dass ein Taktiker den Kampf gewonnen hat, wie gewohnt angezeigt.

(0007912)
Enno   
2018-06-11 20:53   
(Zuletzt bearbeitet: 2018-06-11 20:53)

Bekannt - das ist in Deveron passiert, ich habe es dann aber gesehen und repariert, ehe ich E2 und E3 ausgewertet habe.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2444 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-05-20 19:37 2018-05-24 16:41
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion:  
Partei: drac
Spiel: E3
Report: 459
Zusammenfassung: Stark abweichende Punkte im Testreport
Beschreibung:

Deine Partei hat 826206 Punkte. Der Durchschnitt für Parteien ähnlichen
Alters ist 360070 Punkte.

vs.

Deine Partei hat 3194673 Punkte. Der Durchschnitt für Parteien ähnlichen
Alters ist 1631440 Punkte.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007890)
Enno   
2018-05-23 17:55   

Absicht, glaube ich. Ich habe im Zuge des XML-Parser Umbaus für einige Waffen die Punkte angehoben, weil sie vorher fast keine Punkte wert waren.

(0007892)
Solthar   
2018-05-24 09:34   

Aber die Punkte sind niedriger im Testreport.

(0007894)
Enno   
2018-05-24 16:40   

Oh ja. Die Änderung mit den default scores war nur im alten Parser, im neuen kriegen die Sachen alle 0 Punkte, wenn im XML keine angegeben wurden. Das erklärt das wohl.

(0007895)
Enno   
2018-05-24 16:41   

In meinem privaten Branch schon repariert.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2441 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2018-05-14 19:42 2018-05-14 19:42
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 1076
Zusammenfassung: Neuer Befehl "Gib Luxusgüter" analog zu Gib Kräuter
Beschreibung:

Ich fand die Einführung von GIB KRÄUTER eine gute Sache die mir im täglichen Befehleschreiben die Arbeit erleichtert.
Gib Luxusgüter wäre für mich auch so ein Kandidat, der mir die Arbeit erleichtern würde.
Falls es keine große Arbeit macht das einzubauen, wäre das eine nette Erweiterung des Gib befehls.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2440 [Eressea] General kleinerer Fehler nicht getestet 2018-05-13 13:14 2018-05-13 16:14
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.15.3  
Partei: whob
Spiel: E2
Report: 1077
Zusammenfassung: Zufallsbegegnungen kaputt?
Beschreibung:

Es gibt ein Flag RF_ENCOUNTER, dass zufällig an neuen Regionen gesetzt wird (wann immer 'terraform' eine Landregion erzeugt). Das soll dazu führen, dass die erste Einheit, die diese Region betritt, ein Zufallsereignis erlebt (jemand schließt sich der Partei an, etc). Danach wird das Flag gelöscht. Ich glaube, das Feature ist kaputt.

Schritte zur Reproduktion:

Es sollte also keine Region geben, bei der das Flag gesetzt ist, und die besiedelt ist, aber die gibt es. Es gibt derzeit 164 Regionen mit diesem Flag, und nicht alle sind leer.

Gegenbeispiele:
Reltovuddel (-37,-5)
Bibapivas (-36,-6)
Defiszisyr (-38,-2)
Susleddir (30,48)
Rosut (32,49)

Zusätzliche Informationen:

Das Sandmeer von Kusidvu (88, 118), uid=573073727 hat mehrere Einheiten der Partei whob, wie kann das sein?

Angehängte Dateien:
Notiz
(0007885)
Enno   
2018-05-13 13:55   

Das Flag wird in einer Testauswertung mit 10% Chance gesetzt durch: 1) Schneekugeln, und b) Chaos.
Die encounters() Funktion wird scheinbar gar nicht aufgerufen?

(0007886)
Enno   
2018-05-13 13:55   

Aha! if (config_get_int("rules.encounters", 0)) ... Na klar.

(0007887)
Enno   
2018-05-13 16:14   

Ich habe den gesamten Code mit allen seinen Anhängseln einfach gelöscht, weil keines der aktiven Spiele ihn benutzt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2439 [Eressea] MACHE Fehler im Text immer 2018-05-10 07:24 2018-05-13 13:04
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: oLm
Spiel: E2
Report: 1075
Zusammenfassung: Fehlermeldung für Straßen geht immer noch von einer Straße pro Region aus
Beschreibung:

"Gebirgspioniere (q8je) in Sumpf der langen Schatten (23,2): 'MACHE Straße W' - In dieser Region gibt es keine Brücken und Straßen mehr zu bauen."

Das stammt aus der Zeit, in der es noch keine Richtungen bei den Straßen gab, sondern lediglich eine abstrakte Straße pro Region. In der Meldung müsste es daher mittlerweile heissen:

"In dieser Richtung gibt es keine Brücken und Straßen mehr zu bauen."

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007883)
Enno   
2018-05-13 13:03   

Das ist error_roads_finished, einfache Änderung am Text, sofort gemacht.

(0007884)
Enno   
2018-05-13 13:04   

Gefixt in commit 666d5715


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2438 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-05-08 23:17 2018-05-13 13:01
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: XML Definition von "Lied des Ortes Analysieren" ist verkehrt.
Beschreibung:

Der Zauber macht offenbar irgendeine Analyse, und die regiontarget. buildingtarget, unittarget Flags stehen am falschen Element (an resource statt an spell):

&lt;spell name=&quot;analyse_object&quot; rank=&quot;5&quot; parameters=&quot;kc+&quot; ship=&quot;true&quot; variable=&quot;true&quot;>
  &lt;resource name=&quot;aura&quot; amount=&quot;3&quot; cost=&quot;level&quot; regiontarget=&quot;true&quot; unittarget=&quot;false&quot; buildingtarget=&quot;true&quot; shiptarget=&quot;true&quot;/>
&lt;/spell>

Hat keinen Test, ist noch nie aufgefallen. Unser XML sollte echt ein Schema haben, damit man so etwas leichter finden kann.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007881)
Enno   
2018-05-08 23:19   

Bei den Zaubernamen sind wir uns nicht einig, ob die English (US) oder (UK) sind, wir schreiben abwechselnd analyze oder analyse.

(0007882)
Enno   
2018-05-13 13:01   

Yeah, XML Schema ist zu viel Arbeit, und Test auch. Aber der Bug ist einfach zu fixen, das reicht mir heute mal.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2437 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-05-07 20:19 2018-05-07 20:24
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Ruf der Realität kostet Aura auch wenn niemand teleportiert werden kann
Beschreibung:

Der Zauber "Ruf der Realität" kann aus diversen Gründen fehlschlagen. Erst einmal die üblichen, z.B. hat der Magier zu wenig Aura oder eine zu niedrige Stufe, oder der Zauber war syntaktisch falsch. In diesem Fall kosten alle Zauber keine Ressourcen, und gelten als "nicht gezaubert" für die Berechnung der Kosten von wweiteren Zaubern (verdoppelt sich mit jedem Mal).

Anders ist das, wenn die Zieleinheit ungültig ist: Wenn das Ziel nicht im Astralraum steht, oder in einer Region, die nicht "über" der Region des Magiers liegt, schlägt der Zauber fehl (zumindest für dieses Ziel), kostet aber trotzdem Aura und der Kosten-Multiplikator wird erhöht.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007880)
Enno   
2018-05-07 20:24   

Ist korrigiert. Wenn keine der Einheiten im Astralraum ist, kostet der Zauber nichts. Die Logik dafür musste leider in sp_fetchastral gepackt werden, anderswo kann man die Korrektheit der Ziele nicht prüfen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2435 [Eressea] MACHE kleinerer Fehler immer 2018-04-29 13:05 2018-05-06 19:26
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: turt
Spiel: E2
Report: 1074
Zusammenfassung: Ring der flinken Finger wirkt nicht bei MACHE KRÄUTER
Beschreibung:

Der Ring wirkt nach meiner Erfahrung bei jedem anderen MACHE, bei Kräutern allerdings nicht.

Schritte zur Reproduktion:

Panzerschildkröte (459g) in Basudod (ggdwee) findet 2 Würzige Wagemut.
Eine Person mit Talentwert 2 und dem Ring der flinken Finger.
In der Region wurde bisher kaum gesammelt, der Pool sollte recht voll sein.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007870)
Enno   
2018-05-01 10:35   

Das ist Absicht, glaube ich. MACHE ist ein sehr überladenes Schlüsselwort, hinter dem sich ganz verschiedene Vorgänge verbergen (Rohstoffe abbauen, Gegenstände machen, Schiffe und Burgen bauen, Kräuter suchen, etc). Auch bei MACHE TEMP hat der Ring keine Auswirkungen.

(0007871)
Thoran   
2018-05-01 14:39   

Bei Alchemisten wirkt ein Ring der flinken Finger ebenfalls nicht. Auch dort ist das beabsichtigt, allerdings finde ich den Hinweis, in dem man das nachlesen konnte zur Zeit nicht.

(0007872)
Enno   
2018-05-01 15:39   

Dass der Ring in der Anleitung kaum erwähnt wird, stammt sicher noch aus der Zeit, als wir von Magie und Zauberwirkungen nicht gesprochen haben. Es war ursprünglich so gedacht, dass Spieler selber herausfinden sollten, was ein Zauber tut, und die ZEIGE Beschreibung lediglich einen Anhaltspunkt dazu gibt.

(0007879)
Enno   
2018-05-06 19:26   

Es besteht wohl Einigkeit, dass das kein Bug ist.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2436 [Eressea] Schiffe kleinerer Fehler nicht getestet 2018-05-03 21:38 2018-05-03 23:01
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E3
Report: 0
Zusammenfassung: Taktik-Bonus von Schiffen wirkt nicht
Beschreibung:

In E3 verdoppeln einige Schiffe die Taktik. Das klappt nicht, weil im XML factor=2.0" statt value="2.0" steht. xmlreader.c kennt das nicht, und multipliziert mit 0 (ein echt schlechter Default-Wert).

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007873)
Enno   
2018-05-03 21:45   
(Zuletzt bearbeitet: 2018-05-03 21:45)

Oh, nein! Personen auf Schiffen, nicht nur in E3, kriegen niemals Taktik, weil ihr Talent immer mit 0 multipliziert wird.

(0007874)
Thoran   
2018-05-03 22:13   

Wenn es so ist, dass bei Personen auf Schiffen in E2 das Taktiktalent niemals zur Anwendung kommt, dann stimmt aber folgender Kampfreport (aus Runde 1072) nicht, denn da hat meine Schiffsmannschaft zumindest laut Kampfreport die Taktikrunde gewonnen:

--- snip---
In Ozean (-40,-2) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Thorans Axtträger (d08a).

Heer 0: Thorans Axtträger (d08a)
Kämpft gegen: Heer 1(ii)
Hilft: Heer 0(d08a)
Attacke gegen: Heer 1(ii)
... in der 1. Kampflinie:

  • Mannschaft der sanften Brise (3hzb), 30 Zwerge, vorne, Talente:
    Holzfällen 1, Schiffbau 4, Segeln 5, Stangenwaffen 20, Taktik 3,
    Unterhaltung 4, Wahrnehmung 4, Ausdauer 15, hat: 2 Adamantium, Apfel, 30
    Kettenhemden, 30 Hellebarden, 4 Laen, 15 Laenkettenhemden, 6 Laenschilde,
    Laenschwert, 10 Holz, 135 Mallorn, 4 Mallornbögen, 6 Mallornarmbrüste, 9
    Mallornlanzen, 80 Mallornspeere, 5840 Silber, Wundsalbe, Heiltrank, 30
    Schilde, 3 Gürtel der Trollstärke; Elegant gleitet ihr Schiff dahin.
    (Bem: #*831 Cokêfolzas#SoldFuer: 20-30 Runden#)

Heer 1: Monster (ii)
Kämpft gegen: Heer 0(d08a)
Hilft: Heer 1(ii)
... in der 1. Kampflinie:

  • Seeschlange (ca6x), 1 Seeschlange, aggressiv.

Mannschaft der sanften Brise (3hzb) überrascht den Gegner.
---snap---

(0007875)
Enno   
2018-05-03 22:20   

Das sind erst einmal Vermutungen basierend auf einer ersten Lesung des Codes. Richtig getestet ist das noch nicht, das mache ich dann im Rahmen des Bugfixes.

(0007876)
Enno   
2018-05-03 22:24   

Kommando zurück, E2 ist nicht betroffen. Das ganze hängt mit "rules.tactics.formula" zusammen? Betrifft also nur E3. Da haben wir offenbar an Taktik generell etwas geändert für E3?

Der Taktikfaktor ist überhaupt komisch. Der wird verwendet in select_opponent?

(0007877)
Enno   
2018-05-03 22:45   

Die Regel sagt:

Die Insassen von Ruderschiffen bekommen einen Angriffsbonus und haben eine 20% Chance pro Talentpunkt Differenz des eigenen Taktikers, in der Taktikerrunde angreifen zu können, anstatt nur 10% (siehe geänderte Taktikregel). Dieser Bonus wirkt nur bei Seeschlachten.

Das sollte so jetzt wieder gelten. Ich schreibe noch einen automatischen Test, dann ist das gut.

(0007878)
Enno   
2018-05-03 23:01   

Test geschrieben, zufrieden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2434 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2018-04-29 10:40 2018-04-29 13:56
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E3
Report: 456
Zusammenfassung: Rassenbeschränkung auf Waffen/Rüstungen funktioniert nicht
Beschreibung:

In E3 gibt es den Turmschild, der nur von Zwergen benutzbar sein soll, sowie die Repetierarmbrust. Außerdem dürfen Goblins nicht alle Waffen benutzen, z.B. keine Hellebarde. Schuppenpanzer können nur Zwerge und Halblinge verwenden.

Ich glaube, dass diese Beschränkung nicht gilt. Das Studium von xmlreader.c lässt das jedenfalls vermuten.

Schritte zur Reproduktion:

Leider gibt es keine Tests. Ich glaube, test_goblins in tests/e3/items.lua sollte das einmal leisten, aber dort sind keinerlei assert Statements, weil es quasi unmöglich ist, das zu merken, wenn jemand mit einer Waffe kämpft, die er nicht benutzen kann.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007868)
Enno   
2018-04-29 12:47   

Huh. Bei der Waffe benutzen wir hier itype->mask_allow über rc_can_use. Das ist aber nicht über <modifier> gesetzt, wie ich dachte. Ist besser so, denke ich, aber wieso ist das dann beim Turmschild so <modifier type="canuse" function="mod_dwarves_only"/>?

(0007869)
Enno   
2018-04-29 13:56   

Ich habe den Code übersichtlicher gemacht, und im Debugger getestet, dass goblins keinen Turmschild und keine Äxte benutzen können. Test zu schreiben ist unter den Umständen zu kompliziert (der Kampf ist katastrophaler Wurstcode).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2432 [Eressea] Monster kleinerer Fehler nicht getestet 2018-04-22 00:03 2018-04-22 00:19
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.16.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: ii
Spiel: E2
Report: 1066
Zusammenfassung: Bauernmob verfolgt den Magier nicht mehr.
Beschreibung:

Der Code in plan_monsters, der at_hate behandelt, kann so nicht funktionieren. Es wird dort zuerst die Verfolgte Einheit gelesen:

unit *tu = (unit *)ta->data.v;

Wenn diese existiert, und nicht in der aktuellen Region ist, versucht der Bauernmob, den Magier zu verfolgen, und startet das Pathfinding damit, die Zieleinheit neu zu suchen:

tu = findunit(ta->data.i);

Das kann nicht stimmen. ta->data ist entweder eine Einheit (in ta->data.v), oder eine Einheiten-Nummer (in ta->data.i), aber nicht beides. Außerdem haben wir die Einheit doch schon? Die zweite Zeile ist also offenbarer Humbug.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007867)
Enno   
2018-04-22 00:19   

Das war easy. Könnte Tests vertragen, ist aber kein so wirklich wichtiges Feature.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2425 [Eressea] Gebäude kleinerer Fehler immer 2018-03-10 19:24 2018-03-29 17:32
Reporter: Fiete Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: xb5n
Spiel: E2
Report: 1066
Zusammenfassung: Leuchttürme zeigen nur Schiffe, keine Besatzungen
Beschreibung:

Ich glaube, derzeit werden keine Einheiten auf Schiffen angezeigt, sondern nur die Schiffe.

Wahrnehmer (ygea), ein T33 der Partei Die Kinder Yondallas (xb5n) sitzt im 100er Leuchtturm (kr2y) und sieht diverse Boote in den umliegenden Regionen, Boote: Dreveki (itro), Dreveki (netz), Dreveki (cwuy) ... weitere.

Nach ersten Mails ist ziemlich sicher, dass diese Boote besetzt sind. In einem Fall kann ich es 100% sagen:
Die Erbeutete K 09/16 (e9tv) wird als leer angezeigt, ist aber durch Bündnisreport nachweislich durch D'ndul (tv3u) der Partei Oxygarum specialis (6j46) besetzt (und gesteuert).

Schritte zur Reproduktion:
Zusätzliche Informationen:

vermutlich relevant zu Bug 2395

Angehängte Dateien:
Notiz
(0007840)
Bruck   
2018-03-11 05:04   

Nur für den Fall das das NICHT gewollt war, Einheiten in Gebäuden und Schiffen in Landregionen werden auch nicht angezeigt.

(0007841)
Bruck   
2018-03-11 05:07   

Hmmm... wo ist der Edit Button... Sorry für Doppelpost. Mein Beitrag bezieht sich auf E3.

(0007844)
Enno   
2018-03-11 12:01   

In visible_unit testen wir ob mode >= seen_unit, aber seen_lighthouse ist 2, und seen_unit ist 4. Es war wohl früher mal so, dass man nur Einheiten sehen konnte, wenn man selber eine Einheit in der Region hatte. Warum ist da kein Test für Bug 2395, der das anmeckert?

(0007845)
Enno   
2018-03-11 12:03   

Zitat aus meinem letzten Kommentar zu 2395:

Ich hab's. Tests habe ich noch keine geschrieben, aber am Beispiel von meinem Report aus Runde 1055 scheint es jetzt richtig zu sein.

(0007846)
Enno   
2018-03-11 12:05   
(Zuletzt bearbeitet: 2018-03-11 12:06)

Im NR deiner Partei ist die Einheit übrigens sichtbar:

Die Erbeutete K 09/16 (e9tv), Karavelle, 1% beschädigt; In 663 von TE
erbeutet.

  + D'ndul (tv3u), Kleine Mannen (atnf) (Oxygarum specialis (6j46)), 5
    Meermenschen.

Ich zitiere mich hier noch einmal aus Bug 2395:

Es ist zum kotzen, dass hier für jeden Report-Typ so viel Code dupliziert wird.

Der CR hat also wohl den selben Bug, den der NR in 2395 hatte, immer noch.

(0007847)
Enno   
2018-03-11 13:01   

So wie das aussieht, schreibt der NR immer alle Einheiten in den Report, die auf einem Schiff stehen. Der CR kümmert sich um so Dinge wie Sichtbarkeit, Wahrnehmung, Tarnung, etc. Die korrekte Lösung liegt evtl. irgendwo in der Mitte?

(0007848)
Enno   
2018-03-11 13:02   

Aha! Bei Einheiten auf Schiffen wirkt Tarnung nicht, insofern ist das egal.

(0007849)
Enno   
2018-03-11 14:42   

Bug ist gefixt, in CR und NR sollten Einheiten in Burgen und Schiffen immer sichtbar sein, wenn das Schiff oder die Burg zu sehen ist. Das wird heute noch in der Testauswertung aktiviert, die ich extra dafür verzögert habe.

(0007862)
Fiete   
2018-03-27 21:55   

Fehler besteht.
Runde 1069, Partei xb5n, Einheit Wahrnehmer (ygea) ist Besitzer von 100er Leuchtturm kr2y und hat T33 Wahrnehmung und sieht das Schiff Die Erbeutete K 09/16 (e9tv) ohne Besatzung.
(und alle anderen Schiffe auf See anderer Parteien auch.)

Genanntes Schiff ist aber besetzt durch Einheit D'ndul (tv3u) der Partei Oxygarum specialis (6j46), insofern ist die Info aus dem CR falsch.

(0007863)
Enno   
2018-03-28 08:11   

Bist du sicher, dass Du das mit Version 3.16 getestet hast? Das wäre die Test-AW, denn das offizielle Release ist erst im Juni.

(0007864)
Fiete   
2018-03-28 21:04   

Ich bin mir sicher, dass ich nicht mit der Test-AW gearbeitet habe, denn die habe ich noch nicht. Dazu gab es gestern eine Mail an enno@eressea mit der Bitte um Aufnahme in den Testerkreis für meine richtige eigene Partei.

Sry - damit mein Kommentar bitte vorerst in die Warteschleife. ,-)

(0007865)
Enno   
2018-03-29 17:32   

Du bekommst eine Test-AW für atnf, okay.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2430 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2018-03-24 11:40 2018-03-25 12:45
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: turt
Spiel: E2
Report: 1068
Zusammenfassung: Zauber "Schaler Wein" ohne Meldung
Beschreibung:

Ich lies eine Monstereinheit verzaubern, erhielt aber keinerlei Meldung über den Zauberausgang/-erfolg/-effekt.
Aura und Materialien (Knotiger Saugwurz) wurden verbraucht.

Schritte zur Reproduktion:

Magier: bx8w
Opfer: ax64
Befehle: ZAUBERE "Schaler Wein" ax64

Zusätzliche Informationen:
Angehängte Dateien:
Zu diesem Eintrag gibt es keine Notizen.

Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2429 [Eressea] KAUFE/VERKAUFE kleinerer Fehler nicht getestet 2018-03-17 22:31 2018-03-20 11:51
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.3  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: keja
Spiel: E2
Report: 1068
Zusammenfassung: Insekt kann ohne Burg in Wüste nicht handeln
Beschreibung:

Einheit 7p88 ist ein Insekt, kann Handeln 2 und steht in einer Wüste. In der Wüste steht keine Burg. Einheit 7p88 hatte den Befehl 2 Balsam zu kaufen. Dies hat nicht geklappt. Laut Regeln dürfen Insekten in Wüsten und Sümpfen aber ohne Burg handeln.

Arbeiter (7p88) in Gecugyt (0,2): 'KAUFE 2 Balsam' - Ohne einen Handelsposten
gibt es keinen Markt.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Vermutlich verwandt mit Bug 2379

Angehängte Dateien:
Notiz
(0007861)
Julian   
2018-03-18 17:24   

Bug ist vermutlich schon behoben!

Auszug aus der Testauswertung ("3.16.0-9243f30";Build):
Arbeiter (7p88) bezahlt 8 Silber für den Kauf von Luxusgütern.
Arbeiter (7p88) kauft 2 Balsam.

Sollte also mit dem nächsten Release erledigt sein, denk ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2379 [Eressea] General kleinerer Fehler nicht getestet 2017-10-22 21:47 2018-03-20 11:51
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 1wpy
Spiel: E2
Report: 1040
Zusammenfassung: Insekten dürfen mit beliebigen Gebäuden handeln?
Beschreibung:

Ich stolperte über folgenden Code:

economy.c:1598 in buy()
if (u_race(u) == get_race(RC_INSECT)) {
/ entweder man ist insekt, oder... /
if (r->terrain != newterrain(T_SWAMP) && r->terrain != newterrain(T_DESERT)
&& !rbuildings(r)) {
cmistake(u, ord, 119, MSG_COMMERCE);
return;
}
}

Da steht, Insekten dürfen nicht handeln, wenn sie nicht in Sumpf oder Wüste sind und es kein Gebäude ist. Das bedeutet, sie dürfen handeln, wenn es ein Gebäude gibt, egal welches. Alle anderen brauchen eine Burg. Das klingt falsch. Außerdem ist da jede Menge duplizierter Code. Das muss ich mir noch mal ansehen.

Schritte zur Reproduktion:

1

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007599)
Enno   
2017-11-04 19:05   

Wir haben scheinbar keinerlei Tests für KAUFE oder VERKAUFE, ich werde mal ein paar bauen, und schauen ob ich dabei diesen Bug reproduzieren kann.

(0007600)
Enno   
2017-11-05 15:16   

Die Regel, um die es hier geht, lautet konkret: Insekten können in Wüsten und Sümpfen auch ohne Burgen handeln.

Einfachster Test: Region ohne Burg, Insekt handelt, bekommt ein Handelsgut. Failed.

(0007601)
Enno   
2017-11-05 19:17   

Test für Insekten im Sumpf geschrieben, Bug gefixt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2423 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-03-03 09:22 2018-03-20 11:51
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: keja
Spiel: E2
Report: 1065
Zusammenfassung: Insekt steht mit Handeln 1 in der Wüste
Beschreibung:

Einheit 7p88 ist ein Insekt und steht in einer Wüste. Die Einheit wurde diese Runde rekrutiert und hatte als Befehl "Lerne Handeln". Im aktuellen Report sehe ich die Einheit mit Handeln 1. Insekten haben ein Malus auf Handeln (-1). Da die Einheit keinen Lehrer hatte, hatte sie nur einen Lernversuch und sollte noch T0 haben, durch den Rassen-Malus. Wenn Sie aus irgendwelchen glücklichen Umständen doch direkt auf Stufe 1 aufgestiegen sein sollte, dann hätte der Wüsten-Bonus direkt greifen müssen (Wiki: " In Wüsten und Sümpfen haben sie +1 auf alle Talente, in denen sie wenigstens Talent 1 haben, in Gebirgen -1").
Ein Insekt in einer Wüste mit effektivem Talent 1 ist in jedem Fall nicht korrekt.

P.S. Im cr steht >"3.14.5";Build< das kann ich unter Produktversion aber nicht auswählen.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Einheit 7p88

Angehängte Dateien:
Notiz
(0007831)
Enno   
2018-03-04 18:17   

Es gibt nicht zu jedem point-release eine Version in Mantis, weil man die manuell anlegen muss, und ich dazu oft zu faul bin. Im Zweifelsfall die Version davor angeben (3.14.4 gibt es), oder nichts eintragen. Reportnummer ist immer die wichtigste Information für mich.

(0007832)
Enno   
2018-03-04 18:55   

Aha. Der Knackpunkt hier ist der Ausdruck "in denen sie wenigstens Talent 1 haben". Die Einheit hat Talent 1, wenn man ihren Rassenbonus nicht einberehcnet, und die Funktion rc_skillmod, die den Modifikator auf das Talent berechnet, kümmert sich zwar darum, dass das -1 für die Rasse angerechnet wird, aber bezieht das nicht in die Berechnung des Wüstenbonus ein (weshalb die Einheit davon wieder +1 bekommt). Das sollte wohl so nicht sein, ich schaue mal, ob ein Fix da nicht einfach ist.

(0007833)
Xolgrim   
2018-03-04 19:50   

Hmm für mich ist hier genau das erwartete Verhalten eingetreten. Einmal lernen bringt die ienheit auf T1 da kommt der Wüstenbonus drauf und der Rassenmalus von abgezogen. Wenn das nicht so sein soll, dann musst du dir vermutlich auch die Dämonen anschauen

"Alle Talente, in denen sie mindestens Talentstufe 1 haben, verschieben sich mit einer Wahrscheinlichkeit von 25% um bis zu 3 Lernwochen nach oben (mit 60% Chance) oder unten (mit 40% Chance; das Talent steigt oder sinkt also, nicht beides). Die Verschiebung erfolgt nach den langen Befehlen und der Bewegung. Negative Talentwerte entstehen dabei nicht; ein Talent kann nicht unter 0 fallen."

Ich bin mir reichlich sicher, dass das mit Talenten funktioniert, die einmal gelenrt wurden, nicht die auf T1 sind. Reiten kann man so auch nach einmal lernen dazu bekommen und nicht erst wenn man effektiv T4 hat (wegen dem 3er Malus)
Es sei denn daran wurde mal was geändert, es hat zumindest mal so funktioniert wie beschrieben.

(0007834)
Enno   
2018-03-04 20:05   

Es gibt ausserdem, fällt mir gerade auf, auch noch einen weiteren bug: Insekten sollten in Wüsten ohne Burg handeln dürfen, ich glaube, das geht nicht. Hatten wir da nicht schon eine Meldung für?

(0007835)
Enno   
2018-03-04 20:06   

Das mit den Dämonen stimmt, sollte aber mit dieser Sache nichts zu tun haben. Bei den Dämonen geht es nur drum, dass die das Talent einmal gelernt haben.

Ich bin mir ziemlich sicher, der Rassenmalus für Insekten sollte das erste sein, was angewendet wird, und alle weiteren Boni nur eine Wirkung haben, wenn das Resultat davon größer als 0 ist.

(0007836)
Enno   
2018-03-04 20:16   

Bug 2379 war das. Der Bugfix dort war verkehrt.

(0007837)
Xolgrim   
2018-03-04 20:26   

"in denen sie wenigstens Talent 1 haben" (Insekten)
"in denen sie mindestens Talentstufe 1" (Dämonen)

Also rein von der Formulierung her würde ich als Spieler jetzt erwarten, dass das in beiden Fällen identisch abgehandelt wird. Sollte das designtechnisch nicht so gewollt sein, müsste man das in der Anleitung anpassen. Wobei man es ohnehin konkretisieren könnte, die Formulierung lässt halt jetzt schon beide interpretationen zu.

(0007838)
Enno   
2018-03-04 20:32   

Der Bug ist so erst einmal gefixt, Zusätzliche Boni gibt es damit nur noch, wenn das gelernte Talent plus dem Rassenbonus/-malus größer als 0 ist. Das wird mehr als nur Insekten betreffen, denke ich.

(0007839)
Enno   
2018-03-04 20:53   

Ich sollte mal schauen, dass alle anderen Skill-Boni auch Tests haben, und weiterhin funktionieren, wie sie sollen. Die Situation, was Tests anging, war in dieser Ecke des Codes eher nicht so toll.

(0007850)
Enno   
2018-03-11 14:44   

Ich habe das mal in meinem eigenen Report gecheckt, und keine Diskrepanzen bei den Talenten festgestellt. Die Änderung wird ab heute in der Testauswertung aktiv sein.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1986 [Eressea] Featurewunsch schwerer Fehler nicht getestet 2014-01-05 21:03 2018-03-18 16:30
Reporter: Rupalairpel Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei:
Spiel: E3
Report:
Zusammenfassung: Nur etwa jede zweite Partei kann Vertraute herbeirufen
Beschreibung:

Dieser Bugreport ist nur ein solcher, wenn es gewollt ist, dass jede Partei den Spruch "Vertrauten herbeirufen" sprechen können soll. Nach inzwischen 238 Runden können von allen Völkern, die ich gefragt habe, nur etwa die Hälfte Vertraute herbeirufen. Die anderen haben zwar ausreichend gute Magier aber der Spruch gehört nicht zu Ihrer Spruchliste.

Vertraute erlauben viele Optionen im Spiel. Wenn der Zufall darüber entschieden hat, ob man welche haben kann oder nicht, ist das sehr unglücklich.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005651)
Xolgrim   
2015-01-24 10:00   

@Enno: Das haben wir ganz sicher nicht dem Zufall überlassen wollen.

(0005652)
K   
2015-01-25 00:50   

Ist das eben gefixt worden? Bei mir (Partei qy7x) taucht diese Auswertung (291) erstmals der Zauber 'Vertrauten rufen' auf ohne das eine neue Talentstufe für neue Zauber erreicht worden wäre.

(0005844)
meer   
2015-05-23 11:49   

Es gibt mehrere Parteien, die noch immer keine Vertrauten herbeirufen können (tweilweise mit Magietalent 20+) - ich vermute also, dass das noch nicht gefixt ist. :(

(0006925)
Enno   
2017-01-24 17:44   

@Xolgrim: Wir haben eine Liste von Zubern gemacht, aus denen zufällig welche verteilt werden, damit jeder Magier individuell verschieden ist. Es kann sein, dass Vertraute rufen in dieser Liste ist, dann ist das so "gewollt", aber ich sehe ein, dass es unschön ist, wenn man den Vertrauten in Stufe 20 noch immer nicht rufen kann.
Ich muss mir aber den Code dazu noch einmal genauer angucken.

(0006927)
Xolgrim   
2017-01-24 18:06   

@Enno: Ich erinnere mich schon noch daran wie wir das gemacht haben. Aber wenn Vertrautenrufen auf der Zufallsliste ist, dann ist das ganz sicher ein Fehler. Den Spruch muss man jedem Magiegebiet und jedem Spieler verfügbar machen.

(0006928)
Enno   
2017-01-24 21:34   

Der Spruch ist definitiv in der Liste. Wenn man auf Level 9 ist, hat die schon echt viele Einträge, da ist die Chance, dass man den bekommt, nicht groß, und mit jedem weiteren Level wird sie geringer, fürchte ich (man bekommt je Level einen Spruch dazu, aber die Menge der verfügbaren Sprüche steigt auch ständig an).

Der Spruch sollte wohl wegen seiner Einzigartigkeit ab einem bestimmten Level einfach garantiert gegeben werden.

(0006929)
Enno   
2017-01-24 21:44   

In Zahlen: Auf Stufe 9 hat man 36 Sprüche zur Auswahl, von denen man 8 schon haben sollte, also eine Chance von ca. 3.5% dass man den Vertrautenzauber kriegt. Wenn man ihn nicht kriegt, ist die Chance auf den Stufen 10-15 ähnlich schelcht, weil es da je einen neuen Zauber gibt für jeden Zauber, den man bekommt, und in jeder Folgerunde nach 16 steigt sie ein kleines bisschen an, aber fast unmerklich. Die Chance, auf Stufe 20 immer noch keine Vertrauten zaubern zu können, ist über 70%, glaube ich (mit schlechten Schätzungen und ein bisschen Kopfrechnung).

Das selbe gilt auch für die "Erzeuge" Zauber, die alle ebenfalls ab Stufe 9 zugänglich sind. Die Formel für die Zaubervergabe hat wohl damals niemand richtig durchdacht.

(0007622)
meer   
2017-11-26 11:37   

Hallo! :-) Wie sieht es aus - gibt es hier Fortschritte? :-)

(0007623)
Enno   
2017-11-26 11:57   

Nein. Wenn es hier Änderungen gegeben hätte, hätten wir die nicht nur hier besprochen, sondern sicher auch angekündigt. Ich weiß allerdings nicht, ob @Solthar in seinem Spiel nicht das gleiche Problem hat, vielleicht hat er ja Lust, sich das anzusehen?

(0007625)
Solthar   
2017-11-26 17:04   

In meinem Spiel ist das einer der Zauber, den alle Magiegebiete haben. Ähnlich wie Ring der Unsichtbarkeit und Amulett des Wahren Sehens. Im Interesse der Vielfalt wäre es schöner, wenn es Zauber gibt, die man ab einem gewissen Level kriegen /kann/ und ab einem höheren Level haben /muss/. Lohnt das aber die zusätzliche Komplexität?

(0007641)
meer   
2017-12-11 17:58   

Hallo,
eine Frage: Heißt das (was Solthar zu RdU und AdwS gesagt hat), dass es bereits Zauber gibt, die alle zu einem bestimmten Zeitpunkt bekommen? Oder gilt das nicht für E3/Deveron?

(0007642)
Enno   
2017-12-11 19:39   

Ja, es gibt Zauber, die in alle Zauberbücher eingetragen sind. Das könnte man mit den Vertrauten in E3/Deveron wahrscheinlich auch machen, ich probiere das mal.

(0007643)
Enno   
2017-12-11 19:48   

Das hat geklappt, wird also mit der nächsten Version gefixt.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2385 [Eressea] General schwerer Fehler manchmal 2017-11-13 15:16 2018-03-17 13:12
Reporter: Bregan Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: keine BS-Version:  
Status: erledigt Produktversion: 3.13.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: xbw9
Spiel: E2
Report: 1050
Zusammenfassung: Flutwelle verschlingt normale Region
Beschreibung:

Moin!

Ich bin am 12. August 2017 mit einer neue Partei angefangen.

Es ist jetzt schon 2 mal passiert, das eine normale Region mit einer Einheit von mir, von einer Flutwelle verschlungen wurde:

Auswertung 1047:
####
Report für Eressea, Saturday, 21. October 2017, 21:21
Wir schreiben die letzte Woche des Monats Sonnenfeuer im Jahre 32 des zweiten
Zeitalters. Es ist Sommer.

                              Ereignisse

Eine gewaltige Flutwelle verschlingt Bahar (2xtz) in Ozean (-4,5).
####

Auswertung 1050:
####
Report für Eressea, Saturday, 11. November 2017, 21:21
Wir schreiben die letzte Woche des Monats Feldsegen im Jahre 33 des zweiten
Zeitalters. Es ist Sommer.

                              Ereignisse

Eine gewaltige Flutwelle verschlingt Alter Matrose (9qa7) in Ozean (-4,4).
####

Ist das ein Fehler, oder ist das eine Chaos Insel?

Bis dann

Werner

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007608)
Enno   
2017-11-13 22:49   

Ich habe mal als erstes die Spieldaten repariert, damit da kein Chaos auf Startinseln ist. Ich werde mein Tooling aber noch überarbeiten müssen, damit das in Zukunft nicht wieder passieren kann.

(0007860)
Enno   
2018-03-17 13:12   

Es gibt jetzt im Mapper einen Kartenmodus, der das Chaos anzeigt, und einen Befehl, der das Chaos und eventuelle Monster aus gewählten Regionen entfernt. Damit habe ich das im Griff, glaube ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2427 [Eressea] Reportformat kleinerer Fehler immer 2018-03-12 13:48 2018-03-16 21:57
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.3  
    Zielversion: 3.15.3  
Partei: d08a
Spiel: E2
Report: 1066
Zusammenfassung: COMMANDS enthalten keine Quotes mehr in Kommandostrings, z.B. LERNE Waffenloser Kampf
Beschreibung:

Seit der Änderung vom 03. März ist der Befehl, der einer Einheit in der Vorrunde gegeben wurde und der im COMMANDS-Block des CR enthalten ist, nicht mehr so, wie er gegeben wurde.

Aufgefallen ist mir das bisher beim Kommando
LERNE "Waffenloser Kampf"

Bis einschl. Auswertung 1065 sah der COMMANDS-Block der Einheit wie folgt aus:
--- snip ---
COMMANDS
"LERNE \"Waffenloser Kampf\""
--- snap ---

Seit AW 1066 sieht der Block nun so aus:
--- snip ---
COMMANDS
"LERNE Waffenloser Kampf"
--- snap ---

Schritte zur Reproduktion:
Zusätzliche Informationen:

Betroffene Einheit z.B.: 4yyv

Angehängte Dateien:
Notiz
(0007853)
Enno   
2018-03-16 18:34   

Au weia. Das macht bestimmt Probleme.

(0007854)
Enno   
2018-03-16 18:59   

Fragen:

  1. "Waffenloser Kampf" kann man lernen? Tunnelwurm, nehme ich an...
  2. Ich sehe da nur ein LERNE Ausdauer?

Die einzige Einheit, an der ich das sehe, ist diese hier:
EINHEIT 1073966
"Kalter Kerl";Name

Waffenloser Kampf ist das einzige Talent mit Leerzeichen im Namen, daran habe ich bei dem neuen Befehle-Code (Datenbank statt Speicher) wohl nicht gedacht. Es hat sich bei Befehlen viel hinter den Kulissen geändert.

(0007855)
Enno   
2018-03-16 19:48   

Das ist so schlimm, das sollte vor der nächsten AW repariert werden.

(0007856)
Enno   
2018-03-16 20:15   

Habe das im CR repariert, ab jetzt wird das in einfache Anführungszeichen geschrieben. In deinem CR steht bei einem erneuten Test jetzt:

COMMANDS
"// Eigene Berufe:"
"// #every 2 2 { #call Dauerlerner 'Waffenloser Kampf' }"
"// #call Dauerlerner Ausdauer"
"LERNE 'Waffenloser Kampf'"

Ich sehe gerade, im NR steht das auch falsch. Dann muss ich das wohl nochmal ansehen, und die Zugvorlage evtl. auch, die bestellst Du aber wohl leider nicht. Ich finde mir mal eine andere Partei mit dem Problem.

Seufz. Das ist das Resultat einer Optimierung für LERNE Befehle, und "Waffenloser Kampf" ist das einzige Talent, bei dem es nicht klappt, wegen des dummen Leerzeichens. Da habe ich mir ja wieder was schönes eingebrockt.

(0007857)
Enno   
2018-03-16 21:30   

Ah, wunderbar. Code duplication in stream_order und get_command.

(0007858)
Enno   
2018-03-16 21:52   

Ich glaube, ich hab's jetzt:

* Kalter Kerl (n0oe), Eiszwerge (d08a), 1 Schneemann, vorne, bewacht die
  Region, Talente: Ausdauer 18, Waffenloser Kampf 17, hat: 10 Silber,
  Schneeball, &quot;LERNE 'Waffenloser Kampf'&quot;; An ihm kann man sich kaum
  vorbeischleichen.
(0007859)
Enno   
2018-03-16 21:57   

Dann präpariere ich mal gleich ein neues Release.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2428 [Eressea] Reportformat kleinerer Fehler immer 2018-03-12 19:42 2018-03-16 18:33
Reporter: argelas Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: mai
Spiel: E2
Report: 1067
Zusammenfassung: Fix für 0002398: Wochenbericht hat keine Deltas mehr?
Beschreibung:

Mein Wochenbericht zeigt keine Veränderungen mehr in der Bevölkerung an.

Offenbar war das gewünscht, wie man an dem im Betreff genannten Bug sieht. Ich fand die Deltas aber gut. Auch wenn das zur Zeit um die 0% bewegt, die absoluten Zahlen sind ja immer noch in den Tausendern. Außerdem sieht man so auf einen Blick, welche Rassen wachsen und welche stagnieren.

Auch welche Rassen aufgehört haben ist nicht uninteressant. Diese Woche z.B. gab es einen Bug, dass Personen auf Schiffen nicht mehr angezeigt wurden. Zuerst vermuteten wir, dass eine Partei aufgeört hat. Nun wollte ich in den Wochenbericht gucken welche das sein könnte und konnte mangels Deltas kein -1 mehr finden. Es hat tatsächlich eine Partei aufgehört (ohne Zusammenhang mit den Schiffen), aber das war mühsamer herauszufinden.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007851)
Xolgrim   
2018-03-13 20:03   

[10.03.2018 21:54:59] Xolgrim: Statistik im wb ist kaputt
[10.03.2018 21:55:12] Xolgrim: keine anzeige des deltas mehr
[12.03.2018 08:22:21] Enno Rehling: Absicht
[12.03.2018 08:22:45] Enno Rehling: Kann sich jeder selber ausrechnen, wenn er will.
[12.03.2018 08:23:31] Xolgrim: warum das denn?
[12.03.2018 08:23:49] Enno Rehling: Weil es eh falsch war. Anzahl neue PArteien, usw.
[12.03.2018 08:24:08] Xolgrim: das aber sehr schade
[12.03.2018 08:24:13] Enno Rehling: Und weil es Code gespart hat.
[12.03.2018 08:24:24] Xolgrim: Das Delta war doch das interessante
[12.03.2018 08:24:34] Xolgrim: Konnte man große Schlachten und Parteisterben und so sehen
[12.03.2018 08:24:52] Enno Rehling: Mach Dir ein Excel-Sheet, automatisier den Kram.

(0007852)
Enno   
2018-03-16 18:33   

Das ist so gewünscht.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2424 [Eressea] ZAUBER Absturz nicht getestet 2018-03-10 19:00 2018-03-11 11:45
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E2
Report: 1065
Zusammenfassung: Getarnter Dämonen-Magier kann nicht zu Kröte werden
Beschreibung:

Es gibt da eine Zeile in trigger_changerace:
assert(u_race(u) == u_irace(u) || !"changerace-triggers cannot stack!");

Der Code, wie er aktuell implementiert ist, lässt keine doppelte Tarnung zu?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007843)
Enno   
2018-03-11 11:39   

Ich glaube, der Code ist dort, um zu verhindern das jemand Gestaltwandlung auf eine Kröte zaubert. Das tut er aber nicht, sondern macht Probleme. Löschen!


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2426 [Eressea] General Blocker nicht getestet 2018-03-11 08:58 2018-03-11 09:22
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.2  
    Zielversion: 3.15.2  
Partei: 0
Spiel: E3
Report: 449
Zusammenfassung: Crash bei Übergabe von Spezialitems an Monster.
Beschreibung:

Wenn eine Partei ausscheidet, und dabei ihre magischen Spezialgegenstände an eine Monstereinheit gibt, crasht E3, weil es die Rasse für die neue Einheit nicht gibt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007842)
Enno   
2018-03-11 09:22   

Bei der Gelegenheit auch noch die Trankbeschreibungen und Namen entfleddert, die hatten den gleichen Namespace.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2395 [Eressea] Gebäude schwerer Fehler immer 2017-12-16 21:15 2018-03-11 08:54
Reporter: CTD Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: hoch BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 6t0d
Spiel: E3
Report: 436
Zusammenfassung: Leuchtturm zeigt alle Einheiten an
Beschreibung:

Leuchttürme zeigen jetzt alle Einheiten in den gesehen Regionen an, nicht nur die in Gebäuden.
Ziel war es sicher das Drachen und Seeschalngen auf See gesehen werden können, aber so kann man auch die Truppenbewegungen des Feinds gut sehen.
Möglicherweise sieht man sogar Einheiten mit Tarnung / RdU über viele Regionen hinweg, wenn die EInheit im Leuchtturm genug Talent / ein Amulett hat ()nicht getestet).

Das Einheiten außerhalb von Gebäuden und Schiffen gesehen werden sollte auf die Monsterpartei begrenzt sein.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Ich denke in E2 ist die Auswirkung durch Wahrnehmen / Tarnen extrm hoch, und das sollte schnellstmöglich gefixed werden.
Schließlich kann man sonst mit einem guten Wahrnehmer leicht 20 oder mehr Regionen einer Insel abdecken, wenn man einen Leuchtturm strategisch plaziert.

Angehängte Dateien:
Notiz
(0007691)
Solthar   
2017-12-19 12:30   

Es stimmt, es werden jetzt alle sichtbaren Einheiten im CR, aber nicht im NR, angezeigt. Ich kann ausschließen, dass getarnte Einheiten angezeigt werden.

Das bisherige Verhalten war was genau? Ich glaube, es wurden nur Schiffe, Gebäude und deren Insassen angezeigt, nicht EInheiten, die einfach so in den überwachten Regionen waren.

Ich finde das neue Verhalten logischer als das alte. Wieso sollten nur Einheiten in Gebäuden sichtbar sein? Das bisherige Verhalten kommt mir eher wie ein Bug vor: Man wollte Schiffe mit Besatzung sichtbar machen, hat aber bei der Gelegenheit aus Versehen auch solche in Gebäuden sichtbar gemacht.

Ich finde nicht, dass man es auf Monstereinheiten begrenzen sollte. Das ergibt keinen Sinn.

Ich sehe drei Möglichkeiten:

  • Bisheriges Verhalten wiederherstellen
  • Bisheriges Verhalten korrigieren: Nur Schiffe und deren Einheiten werden gesehen, aber keine Gebäude
  • Jetziges Verhalten beibehalten.

Mir gefällt das neue Verhalten am besten. Ich finde, die Leuchttürme können ein bisschen Aufwertung vertragen. Und es spart Einheiten. Man kann jetzt Regionen aus der Ferne überwachen. Man sollte allerdings die Spieler darauf hinweisen, falls das Verhalten so bleibt.

(0007695)
Enno   
2017-12-21 09:42   

Ich glaube nicht, dass hier enorme Eile geboten ist. Niemand wird das Spiel verlieren, oder aussteigen, weil so ein Fehler existiert.

Zur Lösung: Ich finde, Drachen und Seeschlangen im Ozean sollte man von einem LT sehen können, die sind ja fast so groß wie Schiffe. Auch spielerisch macht das Sinn. Das man mit einem Leuchtturm an Land Burgen oder Einheiten erspähen kann, finde ich allerdings auch verkehrt, da bauen sonst irgendwann Spieler ihre Beobachtungstürme irgendwo, wo es nicht einmal ein Meer gibt. An Land kann man sich immer in einem Haus oder Wäldchen verstecken, oder anderweitig von der Landschaft verborgen sein.

(0007702)
Enno   
2017-12-22 20:37   

Ich schaue mal, was hier verkehrt ist, und stelle evtl. einfach das alte Verhalten wieder her.

(0007703)
Enno   
2017-12-22 20:38   

Es wäre mir sehr geholfen worden, wenn ich die Nummer einer fälschlich gesehenen Einheit gesagt bekommen hätte.

(0007704)
Enno   
2017-12-22 21:03   
(Zuletzt bearbeitet: 2017-12-22 21:04)

Beispiel, Partei ufo, Report 1055, E2:
Die Einheit 4xkv der Partei yido in Mystland bewacht die Region, steht in keiner Burg, und wird vom Leuchtturm in Asghard gesehen, wo meine Einheit 75se im Leuchtturm 3887 steht. Ich habe keine eigenen Einheiten in Mystland. Im NR erscheint die Einheit nicht.

(0007705)
Enno   
2017-12-22 21:28   

Hier wird cansee_ex aufgerufen, was den seen_mode der Region gar nicht benutzt?

(0007706)
Enno   
2017-12-23 16:27   

Die Einheit ist laut cansee sichtbar, weil sie bewacht. Es wäre immer noch prima, wenn es ein Beispiel gäbe, wo die Einheit nicht bewacht...

(0007707)
Enno   
2017-12-23 16:29   

Der Kommentar widerspricht, und sagt, man braucht für Bewacher eine Einheit in der Region:

/* simple visibility, just gotta have a viewer in the region to see 'em */
if (leftship(u) || is_guard(u) || usiege(u) || u->building || u->ship) {
    return true;
}

Aber der seen_mode wird wie gesagt gar nicht beachtet. Warum ist das im NR überhaupt anders? Das sollte ich mir mal ansehen für die Region.

(0007708)
Enno   
2017-12-23 16:57   

Im NR steht:

        if (stealthmod > INT_MIN && r->seen.mode >= seen_unit) {
            if (u->faction == f || cansee_ex(f, r, u, stealthmod, r->seen.mode)) {
                nr_unit(out, f, u, 4, r->seen.mode);
            }
        }

Da ist die Logik also ganz anders. Es ist zum kotzen, dass hier für jeden Report-Typ so viel Code dupliziert wird.

(0007709)
Enno   
2017-12-23 17:14   

Offensichtlich ist diese Schachtel-Bedingung zu kompliziert, um mitten im Code zu stehen (und doppelt ist sie auch noch), und gehört in eine eigene Funktion in reports.c, die dann an beiden Stellen benutzt wird. Das ist zumindest ein Schritt in Richtung Besserung, und die Funktion kann dann auch in Isolation getestet werden.

(0007710)
Enno   
2017-12-23 17:39   

Ich hab's. Tests habe ich noch keine geschrieben, aber am Beispiel von meinem Report aus Runde 1055 scheint es jetzt richtig zu sein.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2422 [Eressea] Featurewunsch kleinerer Fehler nicht getestet 2018-02-24 09:21 2018-02-27 19:20
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 999
Zusammenfassung: FOLGE EINHEIT-Meldung
Beschreibung:

Manchmal versucht man feindlichen Einheiten zu folgen, kann aber nicht (zum Beispiel wegen Kampf ohne Bewache). Dann steht im Report "Einheit xyz konnte Einheit abc nicht folgen". Stattdessen könnte da stehen "Einheit xyz konnte Einheit abc nicht nach NO folgen". Das fände ich irgendwie cooler und auch ein Stück logischer. So kann man zumindest den Suchradius einschränken, wenn man die Nachbarregionen nicht alle sieht.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007828)
Enno   
2018-02-25 08:59   

Finde ich auch schön. Hast Du Lust, das zu implementieren?

(0007829)
Solthar   
2018-02-26 12:33   

Schon möglich. Über eine weitergehende Möglichkeit sollte man kurz nachdenken: Durchreisemeldungen haben keine Richtung. Sollten sie das? Dafür spricht die Logik und dass detailliertere Informationen das Spiel reichhaltiger machen. Ich zögere, weil es auch zu viel sein, und es Auswirkungen auf die Spielbalance gibt.

(0007830)
Enno   
2018-02-27 19:20   

Ich zögere da auch, und glaube nicht, dass das notwendig ist. Es ist jetzt schon schwer genug, einem Kampf aus dem Wege zu gehen, glaube ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2421 [Eressea] Featurewunsch Feature-Wunsch nicht getestet 2018-02-22 10:53 2018-02-23 17:36
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 1wpy
Spiel: E2
Report: 999
Zusammenfassung: DEGRADIERE?
Beschreibung:

Habe gerade aus Versehen meine Schmiede zu Helden befördert. Das ist natürlich doof. Soviel ich weiß, gibt es keine Möglichkeit, das zu verändern ohne die Leute zu killen. Wäre ein DEGRADIERE-Kommando machbar? Dass es das nicht gibt ist vermutlich Absicht, damit man nicht hier Helden erschafft um dort gleiche neue zu kreieren, aber geht es nicht doch? Vielleicht, indem man die Heldenzahl für ein paar Wochen reduziert?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007826)
Enno   
2018-02-23 16:30   

Das klingt kompliziert, nicht nur weil man das evtl. wie von Dir gedacht ausnutzen kann. Was soll z.B. mit dem verbrauchten Silber passieren? Ich glaube auch nicht, dass das ein Feature wert ist, denn Du bist in der ganzen Zeit der erste, der sich das wünscht. Wenn du magst, kann ich einmalig das Helden-Flag von Deiner Einheit entfernen, wäre Dir damit geholfen?

(0007827)
Solthar   
2018-02-23 17:36   

Nein, danke. Das betraf sowieso Drachensgrab. Das Silber ist weg, damit kann ich mich leicht abfinden. Ich weiß von einem Freund, der seine Armbrustschützen befördert hat. Ist lange her. Ich kann mir aber kaum vorstellen, dass das nie vorkommt.

Wieso kompliziert? Der Befehl ist simpel und dann muss man ein Parteiattribut merken und - zum Beispiel - jede Runde um 1 an den berechneten Sollwert annähern.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2419 [Eressea] General kleinerer Fehler nicht getestet 2018-02-15 19:13 2018-02-18 11:46
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Wirkung Heiltrank und Wundsalbe vertauscht?
Beschreibung:

Laut https://wiki.eressea.de/index.php/Tr%C3%A4nke macht die Wundsalbe 400 Trefferpunkte Heilung, und kann mit BENUTZE verwendet werden. Der Heiltrank soll für bis zu 4 Personen einen tödlichen Treffer mit 50% abwehren.

BENUTZE 1 Wundsalbe führt dazu, dass die Einheit 400 Punkte geheilt wird, aber das passiert nicht in der dafür vorgesehenen Funktion, sondern in use_healingpotion. Heiltränke hingegen kann man scheinbar nicht benutzen? In use_potion steht nämlich:

if (oldpotiontype[P_HEAL] && itype == oldpotiontype[P_HEAL]) {
    return EUNUSABLE;
}
Schritte zur Reproduktion:

Die beiden Items haben derzeit keine Acceptance-Tests. Da sollten wir mal anfangen.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007814)
Enno   
2018-02-15 19:14   

Ich habe so ein dunkles Gefühl, dass wir dazu mal eine Diskussion of eressea-dev hatten...

(0007815)
Enno   
2018-02-15 19:19   

Jau. 06.06.2016, Betreff: "Wirkung von Heiltränken" mit Bezug auf Bug 0002204

Zitat Enno:

Zweck des Trankes ist, dass eine Einheit mit 0 HP den Kampf trotzdem
überlebt, und man so seine Taktiker und Magier retten kann.

Es gab in der Folge eine Diskussion, an der sich @Solthar und @CTD beteiligt haben, und wir haben wohl auch etwas geändert. Solthar hat damals offenbar einen Pull-Request dafür gemacht.

Erschwerend kommt sicherlich dazu, dass die beiden Tränke intern P_HEILWASSER und P_HEAL heißen. Da kann ich mal gleich anfangen, glaube ich.

(0007816)
Enno   
2018-02-15 21:03   

Okay, ganz so verwirrend ist es dann doch nicht gewesen, das ist alles machbar. Ich habe das lokal in einem Branch halbwegs geordnet, mit Tests für BENUTZE, aber (noch) ohne Test für die Auferstehung im Kampf oder bei Vulkanausbruch.

(0007817)
Enno   
2018-02-16 19:56   

Interessant: Beim Vulkanausbruch gibt der Trank vier Personen eine 50% Chance zum Überleben (und eventuell residuelle Trank-Effekte, durch change_effect). Im Kampf scheint der Trank nur für eine Person zu wirken, dafür mit 100% Wahrscheinlichkeit, und es kann nur ein Trank pro Person wirken, aber mehrere pro Einheit. Das war wohl Absicht der Änderungen in 2016? Ich finde aber keine Ankündigung, und es steht auch anders in der Anleitung, glaube ich.

(0007818)
Enno   
2018-02-16 20:08   

Anleitung muss noch aktualisiert werden. Machen wir dann nach dem Announce zur Einführung?

(0007819)
Enno   
2018-02-17 13:39   

Noch ein Fehler bei Tränken: Es gibt eine alte Regel, dass man Tränke nur einmal pro Woche mit BENUTZE einsetzen darf. Also nicht zwei Befehle "BENUTZE 1 Zaubertrank" in der gleichen Woche, Herr Obelix.

Ich sehe nicht ein, warum das so ist, und es hat ursprünglich wohl auch nur Zauber betroffen, die einen Effekt an der Einheit erzeugen (z.B. Schaffenstrunk). Durch den Umweg über do_potion betrifft es aber auch Tränke wie den Heiltrank, die dort gesondert behandelt werden.

Das ganze ist eigentlich total egal, weil man auch einfach BENUTZE 2 Zaubertrank befehlen könnte. Ich vermute, der Code dazu kann evtl. ganz weg?

(0007820)
Enno   
2018-02-17 14:08   

Xolgrim weist mich gerade darauf hin, dass ich das falsch verstanden habe. Der Code soll verhindern, dass eine Einheit in der selben Woche zwei unterschiedliche Tränke trinkt. Habe ich wohl kaputtgemacht. Ich halte nichts von der Regel, sehe keinen Grund dafür, und werde die löschen.

(0007822)
Enno   
2018-02-18 11:37   

Durch die Umbenennung von p14 -> healing hat es diesen Fehler in der Test-AW gegeben:

ERROR: read_spells: could not find spell 'create_potion_p14'

Der Name des Zaubers ist im Datenfile, da braucht es eine Aliasing-Funktion.

(0007823)
Enno   
2018-02-18 11:38   

static const char sp_alias(const char zname) ist das.

(0007824)
Enno   
2018-02-18 11:43   

Passiert nur in E3 und E4, natürlich.

(0007825)
Enno   
2018-02-18 11:46   

Ansonsten scheint alles zu funktionieren. Prima.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2415 [Eressea] MACHE kleinerer Fehler nicht getestet 2018-01-28 11:21 2018-02-15 18:55
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.16.0  
    Zielversion: 3.16.0  
Partei: turt
Spiel: E2
Report: 1061
Zusammenfassung: Wasser des Lebens wirkt mit Verzögerung
Beschreibung:

Angeblich machte eine Einheit (siehe unten) 320 Holz, diese sind aber nicht zu finden.
Vermutung: BENUTZE Wasser des Lebens hat einen Teil des laut Befehlsreihenfolge später geschlagen Holz verbraucht.

Auch wenn das hier einen Fehler von mir etwas ausgebügelt hat, ist das etwas undurchsichtig.

Schritte zur Reproduktion:

AW 1060:
160 Schößlinge in der Region

Panzerschildkröte (ea3x) hat 100 Holz, steht im aktiven Sägewerk
MACHE Holz
@BENUTZE 33 Wasser~des~Lebens

eine aktive Schmiede in der Region verbraucht ein weiteres Holz, genug WdL ist bei anderen Einheiten vorhanden, Holz aber nicht für diese Menge WdL

AW 1061:
330 Schößlinge in der Region
Panzerschildkröte (ea3x) in Basudod (-1, 2) produziert 320 von 322 Holz.
Panzerschildkröte (ea3x) erschuf einen heiligen Hain von 330 Schößlingen.

Panzerschildkröte (ea3x) hat 89 Holz

Zusätzliche Informationen:

Ene andere Einheit hatte noch 6 Holz und diese weggetragen, an sonsten kann ich keine Holzbewegungen finden und die ganze Partei hat in dieser AW nichts hergestellt was Holz verbraucht.

Angehängte Dateien:
Notiz
(0007792)
Enno   
2018-01-28 14:37   

Die Vermutung glaube ich nicht. BENUTZE passiert vor MACHE, und kann kein Holz aus der Zukunft benutzen. Aber wenn du 320 Holz geschlagen hast, und die nicht anderweitig verschwinden, dann sollten die in der Region sein, ich gucke mir das also an.

(0007794)
Enno   
2018-01-28 16:19   

Im Report 1060 steht:

* Panzerschildkröte (ea3x), 5 Insekten, flieht, Talente: Holzfällen 13,
  hat: 100 Holz, 2 Ringe der flinken Finger, &quot;MACHE Holz&quot;.

In Report 1061:

Panzerschildkröte (ea3x) in Basudod (-1,2) produziert 320 von 322 Holz.

* Panzerschildkröte (ea3x), 5 Insekten, flieht, Talente: Holzfällen 13,
  hat: 89 Holz, 2 Ringe der flinken Finger, &quot;MACHE Holz&quot;.

Ich sehe also auf jeden Fall das selbe wie Du. Wo das Holz hin ist, muss ich noch untersuchen.

(0007800)
Enno   
2018-01-28 19:26   

Hat zu Beginn von MACHE 99 Holz, danach 419. Verliert 330 durch BENUTZE, hahaha. Ich nehme alles zurück. Auch wenn BENUTZE am Anfang der Runde ausgeführt wird, hat WdL eine verzögerte Wirkung (at_potiondelay). Weiß der Geier, warum das so ist, aber deshalb werden 33 Wasser benutzt, und damit 330 Holz. Das war zumindest für mich nicht klar, dass das so ist, oder warum es so ist.

(0007801)
Xolgrim   
2018-01-29 19:00   

An welcher stelle zündet das WdL denn? Man konnte früher zumindest Schösslinge fällen die man in der gleichen Woche durch WdL in den Boden gerammt hat. Vermutlich ist das ein Mechanismuss um dem mobilen Wald entgegen zu wirken? 60 WdL und 600 Holz machen jede Ebene vor Kampfbeginn zu einem Wald und damit den Kavalleriebonus zu nichte. Früher konnte man den Wald in der gleichen Woche abholzen (wenn die Gegner nicht bewacht haben), dann haben die Gegner nichtmal mitbekommen, dass sie keinen Kavalleriebonus hatten, waren schon lustige Zeiten ...

(0007813)
Enno   
2018-02-15 18:30   

Da es nirgends dokumentiert ist, dass Tränke so verzögert wirken können, kommt das weg, unnötige Komplexität. Zuerst einmal beim WdL, das habe ich gerade fertig.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2418 [Eressea] Reportformat schwerer Fehler immer 2018-02-11 09:04 2018-02-15 17:25
Reporter: kon Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.4  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: hsv9
Spiel: E2
Report: 1062
Zusammenfassung: Falsches mail-to im Report
Beschreibung:

Seit Report 1015 steht wieder eressea-server@kn-bremen.de als Mail-To im Report. Das ist insofern echt ärgerlich, als auf diese Mail-Adresse keine Antwort kommt (auch kein gibt es nicht) und die meisten (so wie ich) in magellan die Report-Adresse übersteuern. Das heißt, das Problem bemerkt immer der erste, der ein Magellan-Update macht und nicht ans neu-einrichten der Übersteuerung denkt.

Gibt es eine Chance, neben der Behebung des Problems ein direktes Feedback einzubauen, dass die Adresse nicht mehr existiert?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007806)
Enno   
2018-02-11 10:31   

Das ist die korrekte Adresse, die steht so im CR, und Mails dorthin sollten auch ankommen. Woran machst Du fest, dass dem nicht so ist? Du musst mir da ein bisschen mehr Informationen geben: Von welchem Absender kam die Mail, wann wurde sie versendet, was war der Betreff? Welche Adresse glaubst Du, ist die richtige?

(0007807)
Enno   
2018-02-11 10:32   

Der Bugreport an sich ist falsch, die Adresse ist die richtige. Ohne Feedback vom Spieler kann ich hier nichts tun, und werde den Report als unreproduzierbar schließen.

(0007808)
kon   
2018-02-11 22:33   

Ich habe am 10.2. drei Mails aus Magellan abgeschickt (jeweils mit Absender eressea@detla.de):

  1. 20:59 an "eressea-server@kn-bremen.de" <eressea-server@kn-bremen.de>
  2. 21:01 an "eressea-server@kn-bremen.de" <eressea-server@kn-bremen.de>
  3. 21:30 an "eressea-server@eressea.kn-bremen.de" <eressea-server@eressea.kn-bremen.de>

Alle Mails sind sicher raus (gingen per reply an meine eigene Mail-Adresse

Ich habe nur einen E-Check um 00:00 von eressea-server@kn-bremen.de bekommen. Verarbeitet im Report wurden die Befehle aus 3.

Meine Schlussfolgerung aus den fehlenden E-Checks war, dass 1 & 2 nicht verarbeitet wurden.

(0007809)
Enno   
2018-02-12 13:20   

Vermutung: Die Mail um 21:30 ist nicht verarbeitet worden, denn der ZAT ist 21:00 und die AW war vor 21:30 schon gemacht. Der Echeck-Empfang von 1 und 2 ist nicht bestätigt worden, weil um 20:45 der letzte ECheck vor der Auswertung läuft. Email #3 ist um Mitternacht bestätigt worden, wenn der erste Echeck für die Folgewoche startet.

Kann das so passen?

(0007810)
Enno   
2018-02-12 13:22   

Es sollte evtl. irgendwo offiziell stehen, dass es nach 20:45 Uhr keine Empfangsbestätigung / ECheck-Resultate mehr gibt, dass das aber nicht bedeutet, dass eine noch rechtzeitig eingegangene Email mit korrektem Passwort von der Auswertung ignoriert wird. Viele Spieler verstehen den Zusammenhang zwischen Zugbestätigung und Auswertung nicht.

(0007811)
kon   
2018-02-12 23:27   

Mir war die 20:45 Regel nicht bekannt. Ich habe es eben nochmal probiert und bekomme Bestätigungen an beide Adressen jeweils eine Antwort.

Sorry für die Fehlmeldung,

(0007812)
Enno   
2018-02-15 17:25   

Ich habe das mit 20:45 Uhr ins Wiki eingetragen.

https://wiki.eressea.de/index.php/Befehle_einschicken#Wie_man_Befehle_einschickt.2C_und_was_man_daf.C3.BCr_bekommt


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2411 [Eressea] Mail Blocker immer 2018-01-13 23:49 2018-02-03 14:35
Reporter: Tuor Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: bart
Spiel: E3
Report: 438
Zusammenfassung: E3 Befehle einschicken ohne Wirkung und keine Bestätigung
Beschreibung:

Hallo zusammen,
wie gewohnt schicke ich vorhin um 20:49 Uhr meine E3 Befehle per Mail an "eressea-server@eressea.kn-bremen.de", Betreff "E3 BEFEHLE". Mit Erschrecken stelle ich im danach erhaltenen Report fest, dass meine Befehle nicht verarbeitet wurden. Eine Bestätigung für die Befehlsabgabe habe ich bisher nicht. Nun fällt mir auf, dass das auch für meine Befehle vom 30.12.17 gilt, die ich versucht habe einzuschicken. Am 23.12.17 hat das auf die Art noch funktioniert. Am 6.1.18 habe ich keine Befehle eingeschickt.
Normalerweise suche ich da den Fehler bei mir, kann ihn aber nicht finden. Für schnelle Hilfe wäre ich dankbar.

Schritte zur Reproduktion:

Ich habe die Befehle in die Zwischenablage, dann in die Mail kopiert (wie gewohnt). Habe den Betreff "E3 BEFEHLE" genutzt, zusätzlich auch mit "ERESSEA 3 BEFEHLE" probiert und auch von einer anderen Mailadresse geschickt. Ein anderer Mitspieler hat auch bereits versucht, Befehle für mich einzuschicken. Ohne Erfolg bzw. ohne Bestätigung.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007768)
Tuor   
2018-01-14 00:17   

gerade um 00:00 Uhr alle Bestätigungen der Befehle, welche von den unterschiedlichen Adressen und auch mit unterschiedlichen Betreffzeilen eingeschickt wurden, auf einmal bekommen .

(0007769)
Tuor   
2018-01-14 13:05   

was bleibt ist natürlich, dass meine Befehle nicht rechtzeitig gelesen wurden. Gab es beim Server Probleme? Woran kann das gelegen haben? Worauf müsste ich beim nächsten Mal achten?
Prinzipiell sollte es ja möglich sein, 1 h oder 10 min vor ZAT Befehle erfolgreich einzuschicken.

(0007777)
Enno   
2018-01-23 07:44   

Von welcher Adresse kam die Email, und falls Du das auch noch einfach sagen kannst, was war die genaue Absendezeit (mit Datum)?

(0007778)
Enno   
2018-01-23 07:49   

Am Samstag wird um 21:00 Uhr keine ECheck-Bestätigung verschickt (weil da schon die AW läuft). Vorher alle 15 Minutne, also zuletzt um 20:45. Aber Du sagst, Deine Befehle sind nicht in die Auswertung mit eingeflossen? Woran machst Du das fest?

(0007779)
Tuor   
2018-01-27 20:42   

Danke für deine Rückmeldung, Enno! Ich sehe jetzt schon mal zu, die Befehle nicht ganz so kurzfristig einzusenden, um die Bestätigung zu bekommen.
Bezüglich E-Mailadresse und Absendezeit:
Von: Bartak Vollbart [mailto:vollbaerte@googlemail.com]
Gesendet: Samstag, 30. Dezember 2017 20:50
An: eressea-server@eressea.kn-bremen.de
Betreff: E3 BEFEHLE
und
Von: vollbaerte@googlemail.com [mailto:vollbaerte@googlemail.com]
Gesendet: Samstag, 13. Januar 2018 20:49
An: Eressea Server <eressea-server@eressea.kn-bremen.de>
Betreff: E3 BEFEHLE

Bzgl. woran ich festmache, dass meine Befehle nicht eingeflossen sind: am 13.01.18: In REGION -40,26 wurde der Unterhalt für den Hafen nicht gezahlt, Schiffe konnten nicht anlegen. @BEZAHLEN NICHT habe ich gelöscht. Ansonsten hat auch ein beabsichtigter Silbertransport dorthin nicht funktioniert.

(0007780)
Enno   
2018-01-27 20:48   

Deine Email ist offenbar vollbaerte@googlemail.com

Ich habe mal ein wenig geschuat, was ich zu der Email weiß:

  • Am 23.12. (438) kamen die Befehle bei mir um 14:05 Uhr an, und sollten um 14:15 bestätigt worden sein (ist zu lange her, als dass ich das noch in einem Log verifizieren kann).
  • Am 30.12. (439) kamen sie um 20:50 an, und zwischen 20:45 und 0:00 Uhr schickt ECheck keine Bestätigungen.
  • In Runde 440 hat die Partei keine Befehle erhalten
  • Am 13.01. (441) kamen die Befehle wieder erst nach 20:45 Uhr an.

Frage: In welcher Woche meinst Du wegen der Befehlsverarbeitung einen NMR gehabt zu haben? Du schreibst:

Mit Erschrecken stelle ich im danach erhaltenen Report fest, dass meine Befehle nicht verarbeitet wurden.

Woran machst Du das fest, und auf welchen Report bezieht sich das? Wann wurden die Befehle eingeschickt? Ohne mehr Informationen kann ich hier nichts reproduzieren.

(0007786)
Enno   
2018-01-27 21:55   

Hier gucke ich mir den Fall vom 13. Januar noch einmal an. Das ist aber nicht Report 438 gewesen, die Angabe im Original_report ist also irreführend.

(0007788)
Enno   
2018-01-28 10:58   

Eingetroffene Mail am 13. Januar laut procmail.log:
From vollbaerte@googlemail.com Sat Jan 13 20:50:59 2018
Subject: E3 BEFEHLE
Folder: grep -v '>From' | $HOME/bin/orders-accept 3 de 156530
From vollbaerte@googlemail.com Sat Jan 13 21:31:03 2018
Subject: E3 BEFEHLE
Folder: grep -v '>From' | $HOME/bin/orders-accept 3 de 147111
From vollbaerte@googlemail.com Sat Jan 13 21:41:03 2018
Subject: E3 BEFEHLE
Folder: grep -v '>From' | $HOME/bin/orders-accept 3 de 40970
From vollbaerte@googlemail.com Sat Jan 13 22:01:05 2018
Subject: ERESSEA 3 BEFEHLE
Folder: grep -v '>From' | $HOME/bin/orders-accept 3 de 40978

Eine Mail sollte also vor dem ZAT gekommen sein.

Zeitstempel in orders.dir.440/headers/turn-vollbaerte@googlemail.com\,gruenbaer\,0

Received: Sat, 13 Jan 2018 20:50:59 +0100 (CET)
ERESSEA bart [...]
; TIMESTAMP 1515872861657

Inhalt von orders.440 (mit Zeilennummer)
85400 ERESSEA bart [...]
85402 ; TIMESTAMP 1515872861657

Die Mail ist also vor dem ZAT angekommen, und war in den benutzten Befehlen mit drin.

In den neuen Befehlen für REGION -40,26 ; Vollmoor hat niemand einen BEZAHLE Befehl. Wenn die Partei keine NMR-Warnung im Report hat, ist es wahrscheinlicher, dass etwas mit dem Hafen nicht stimmt, und warum dein Silbertransport nicht klappt, kann ich auch nur erklären, wenn ich seine Nummer kenne.

Ich mache mal eine Testauswertung mit den Daten von der Woche, und schaue mir den Report an.

(0007789)
Enno   
2018-01-28 11:09   

Die Partei hat Befehle bekommen. Hier liegt kein Mailproblem vor. Aber falls es sich um diesen Hafen handelt:

Hafen (d4rn), Größe 25, Hafen.

Dann ist Dein Problem vielleicht folgendes: Da steht niemand drin. So weit ich das sehe, hast Du nur drei Einheiten in der Region, keine davon im Hafen.

Worauf stützt Du die Aussage, dass der Hafen nicht funktioniert?
Was ist das erwartete Verhalten, und was siehst Du stattdessen?
Welcher Silbertransport ist das, der sich nicht in die Region bewegt hat, und welche Fehlermeldung siehst Du?

Diese Fehlermeldung ist so mangelhaft, dass ich drauf und dran bin, sie als unreproduzierbar zu schließen. Vielleicht machst Du einfach noch eine (oder zwei) neue.

(0007803)
Tuor   
2018-02-03 12:24   

Vielen Dank für deine Nachforschungen! Das weiß ich zu schätzen. Entschuldige meine mangelhafte Fehlermeldung.
Ich habe nun gelernt, wann Echeck Bestätigungen verschickt und werde meine Befehle zur Sicherheit früher einschicken, um diese Bestätigung eben auch immer direkt zu erhalten und nicht erst um 00:00 Uhr. Auch, dass der Hafen Insassen haben muss für eine Funktion war mir nicht klar. Ich dachte an eine Analogie zum Leuchtturm, wo der Regionsbesitzer den Unterhalt bezahlt und die Funktion auch ohne Insassen gewährleistet ist.

Du kannst die Fehlermeldung gern schließen. Gerade funktioniert alles reibungslos, wie ich es aus vielen Jahren Eressea gewohnt bin und schätze.

Für den Fall, du willst doch nochmal nachschauen, habe ich für zwei Einheiten in Vollmoor die eingeschickten Befehle zu kopiert und hoffe, dass das nun nachvollziehbar ist. Aber wie gesagt, gern einfach die Fehlermeldung schließen.

In Runde 440, 13.1.18 20:49 habe ich folgende Befehle eingeschickt:
MACHEN TEMP erhf
BENENNEN EINHEIT "Rekruten"
REKRUTIEREN 10 Zwerg
FAHREN vers
ARBEITEN
ENDE
EINHEIT ffs; Feiernde Fest-ungs-baulinge [20,0$]
FAHREN vers
EINHEIT vers; Fleißige Versandlinge [5,0$]
ROUTE so PAUSE o so PAUSE
@TRANSPORTIEREN ffs
RESERVIEREN 3000 Silber
TRANSPORTIEREN TEMP erhf
@GIB 7dsc ALLES Stein
@GIB gwhd ALLES Stein
LERNE Reiten
@GIB ffs ALLES Stein

Ergebnis Runde 441:
Einheit vers hat nicht die angeordnete Route genommen und Einheit ffs nicht transportiert. Die Temp-Einheit erhf wurde nicht erstellt.

(0007804)
Julian   
2018-02-03 13:34   
  1. Einheit vers hat zwei lange Befehle (Route und Lernen). Also gut möglich, dass Route nicht ausgeführt wurde.

  2. Welche Einheit hatte den Befehl die Temp-Einheit zu erzeugen? Einheit ffs jedenfalls nicht, da der "Mache Temp" Befehl über "Einheit ffs" steht. Eine Einheit muss aber den mache Temp Befehl geben.

(0007805)
Enno   
2018-02-03 14:35   

Ich glaube, Julius hat das richtig erkannt. Der Server bearbeitet nur einen langen Befehl pro Einheit.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2398 [Eressea] Reportformat kleinerer Fehler nicht getestet 2017-12-27 23:39 2018-01-28 19:13
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: ufo
Spiel: E2
Report: 1056
Zusammenfassung: Wochenbericht hat keine Deltas mehr?
Beschreibung:

In meinem Wochenbericht steht:
Parteien: 242 (+0)
Zwergenvölker: 41 (+0)
Elfenvölker: 43 (+0)
Goblinvölker: 4 (+0)
Menschenvölker: 27 (+0)
Trollvölker: 17 (+0)
Dämonenvölker: 15 (+0)
Insektenvölker: 12 (+0)
Halblingsvölker: 17 (+0)
Katzenvölker: 13 (+0)
Meermenschenvölker: 39 (+0)
Orkvölker: 13 (+0)

          Zwerge: 2183870 (+9896,+0%)
           Elfen: 1130832 (-3948,0%)
         Goblins: 138734 (+748,+0%)
        Menschen: 6898142 (+8745,+0%)
          Trolle: 573088 (-427,0%)
        Dämonen: 25923 (+133,+0%)
        Insekten: 351775 (+857,+0%)
       Halblinge: 197356 (+1699,+0%)
          Katzen: 595369 (+1567,+0%)
    Meermenschen: 1433687 (+1492,+0%)
            Orks: 315965 (+145,+0%)
         Kröten: 4 (-2,-33%)

Wie kann es sein, dass beinahe alle Deltas hier 0 sind, und wie hilft die abgerundete Prozentzahl bei den Rassen jemandem? Die Deltas können evtl. einfach weg?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007785)
Enno   
2018-01-27 21:15   

Wochenbericht könnte ich mal komplett überarbeiten. Das ist ein doofes Modul.

(0007787)
Enno   
2018-01-28 10:46   

Rassen mit Umlauten im Namen sind doof eingerückt, das wäre auch mal was.

(0007798)
Enno   
2018-01-28 19:13   

Bin zufrieden mit dem neuen Wochenbericht.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2387 [Eressea] General kleinerer Fehler nicht getestet 2017-11-19 12:43 2018-01-27 21:14
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.13.2  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 1wpy
Spiel: E2
Report: 1050
Zusammenfassung: Juju im Meer
Beschreibung:

Ich habe einen Juju-Zombie im Ozean angetroffen:

Ozean (-18,-40), Ozean. Im Nordwesten der Region liegt das Bergland von
...

  • Ninja (p8j5), Monster (ii), 1 Juju-Zombie, hat: Zauberbeutel.

Er stammt vermutlich von einem ausgestorbenen Juju-Volk und ist enstanden, um den Zauberbeutel (notlost="yes") zu retten. Ist es eine akzeptables Verhalten, das solche Einheiten auf Ozeanen entstehen? Vielleicht sollten sie in diesem Fall in der Nähe angespült oder von einer Seeschlange verschluckt werden? Wir brauchen dringen Seeuntote!

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007614)
Enno   
2017-11-19 15:17   

Die gute alte alles zerstörende Kanonenkugel, die auf den unzerstörbaren Turm trifft... Jujus dürfen nicht ins Wasser, sie können nicht (hoffentlich) schwimmen oder fliegen. Andereseits dürfen aber einige Items nicht verschwinden, und erschaffen Untote. Die Frage hier ist also, was eigentlich wichtiger ist. Dass der Beutel erhalten bleibt, oder dass der Zombie nicht entsthet? Warum ist der Zauberbeutel überhaupt so gegen Verluste geschützt? Ich nehme an, dass dabei eher an Kampf gedacht war, dass gewisse Dinge nicht auf dem Schlachtfeld verloren gehen können. Wer auf dem Ozean an Hunger oder Ertrinken stirbt, dessen Zeug kann meinetwegen ruhig verschwinden.

(0007615)
Solthar   
2017-11-19 16:20   

Unabhängig vom konkreten Fall des Beutels gibt es sicher Gegenstände, die unter keinen Umständen verloren gehen sollten. Ganz schlimm finde ich Ghoule auf dem Wasser ja nicht, aber ich würde lieber eine neue Rasse aquatischer Untoter (Lacedon?) erschaffen. Vorbilder gibt es und warum soll es eigentlich nur an Land Untote geben?

Meine ursprüngliche Idee war ja, dass solche Dinge irgendwo an Land treiben, was ich auch sehr cool fände, weil das ein klassisches Erzählelement ist. Aber das wäre mehr Aufwand.

(0007616)
Enno   
2017-11-19 16:37   

Man könnte den Juju auf eine Planke setzen, mit der er herum treibt (neuer Schiffstyp, den man als Spieler nicht bauen kann).

(0007617)
Solthar   
2017-11-19 18:48   

Auch gut, aber was ist, wenn das Boot kaputt geht?

(0007618)
Enno   
2017-11-19 23:17   

Entweder darf das nicht passieren, oder dann ist der Beutel eben doch futsch.

(0007619)
Solthar   
2017-11-19 23:31   

Manche Dinge dürfen eben nicht futsch gehen, zum Beispiel Questgegenstände. Und unzerstörbare Boote. Hmmm... :evilgrin:

Dann erscheint mir die neue Rasse einfacher, weil sie weniger neue Logik braucht.

(0007620)
Enno   
2017-11-20 06:55   

Einfacher schon, aber ein untoter Fisch? Irgendwie schon doof. Vielleicht reicht eine Schildkröte?

(0007621)
Solthar   
2017-11-20 10:45   

Ein weißer Wal wäre klassischer. Aber das geht auch. Die hier finden aber nicht das das doof ist ;)

https://www.qwant.com/?q=undead%20under%20water&amp;t=images

(0007674)
Enno   
2017-12-16 11:45   

Man kann das Ding natürlich auch an eine fliegende Einheit geben, das löst das Problem. Wenn allerdings jeder dumme Ring einen Wyrm erzeugt, wird das schnell als Waffe missbraucht werden. Ich weiß doch, wie die Spieler ticken. Ein Geist vielleicht?

(0007677)
Enno   
2017-12-16 20:27   

Was ich hier vor allem machen möchte, ist zu überleben, ob alle die Gegenstände, die mit notlost markiert sind, das wirklich brauchen? Für Questen-Items macht es ja Sinn, dass die nicht verschwinden, aber durch Zauber erstellte Beutel? Ist der Grund, dass da permanente Aura eingeflossen ist?

Andere Gegenstände dieser Art: Pegasus, Elfenpferd, Delphin, Mistelzweig, Schneeball, Schneemann, Schneekugel, Ring der Levitation, Geburtstagskuchen, Lebkuchenherz, Amulett des Treffens, Items für die Museums-Queste und die Hochzeit von Jadee und Wildente, Gürtel der Heldentaten.

Der Beutel ist also das einzige Item, das ersetzbar ist, alles andere sind limitierte Gegenstände. Ich glaube, ich mache das Atribut weg von dem.

(0007711)
Enno   
2017-12-25 19:16   

Ich werde da in Zukunft einen Geist erstellen (die können fliegen), falls kein anderes Monster in der Region ist. Das kriegt dann den ganzen Krempel, statt dass die verlierende Einheit komplett zu Untoten wird (besonders bei STIRB ändert sich das Verhalten also deutlich).

(0007745)
Enno   
2018-01-01 14:26   

Die Sache mit dem Geist gefällt mir nicht so doll. Es werden dabei im Moment alle Items in der Region bei einer kleinen Einheit zusammengelegt, es gehen die schönen Namen der Spielereinheiten verloren, und das ganze passiert auf Land wie auf Wasser - ist nicht notwendig, so viel Charme zu verlieren. Ich denke mir hier noch etwas anderes aus, wenn die Zeit bleibt.

(0007784)
Enno   
2018-01-27 21:14   

Das Feature ist gut genug für 3.15, evtl. denke ich für die Zukunft aber noch einmal drüber nach.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2412 [Eressea] Schiffe kleinerer Fehler nicht getestet 2018-01-15 18:39 2018-01-22 21:01
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.3  
Produkt-Build: Lösung: doppelt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ufo
Spiel: E2
Report: 1059
Zusammenfassung: Schiff treibt ab, Meldung sagt falsche Richtung.
Beschreibung:

Meine Trireme 8sye ist in Runde 1058 durch Hunger liegen geblieben. Im aktuellen Report steht: Die Maitre du Temps (8sye) treibt nach Nordwesten. Das Schiff ist jedoch in Menel gelandet, was sich im Nordosten des Ozean befindet.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007774)
Enno   
2018-01-22 19:52   

Fehler wurde bereits einmal gemeldet.

(0007776)
Enno   
2018-01-22 21:01   

Wird in 3.15 gefixt sein: commit 35742e8


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2376 [Eressea] NACH/ROUTE Fehler im Text nicht getestet 2017-10-20 22:55 2018-01-22 21:01
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.13.2  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: d08a
Spiel: E2
Report: 1046
Zusammenfassung: Fehlerhafte Meldung beim Abtreiben
Beschreibung:

Diese Woche fand in der Region (6,-10) ein Kampf gegen eine Seeschlange statt. Die Schiffsbesatzung tötete die Seeschlange, aber das Schiff nahm Schaden und trieb dann wegen Überladung ab. Es befindet sich jetzt in Region (6,-11), also südwestlich der Kampfregion.

Die beim Schiff angezeigte Meldung lautet aber:
Die DZS-4048 Enforcer (axer) treibt nach Nordwesten.

Die Richtung in die das Schiff abgetrieben ist, wird also in Nord-Süd-Richtung verkehrt herum angegeben.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Abgetriebenes Schiff: axer
Am Kampf beteiligte Einheiten: Mannschaft der Enforcer (axer) und Seeschlange (7r3c)

Angehängte Dateien:
Notiz
(0007577)
Enno   
2017-10-21 10:01   

Ich glaube sogar, da wird IMMER Nordwesten angezeigt. Lustig.

(0007579)
Enno   
2017-10-21 10:48   

Ich habe einen Fix, derzeit nur in einem separaten Branch lokal bei mir, weil ich das Release 3.14 noch nicht fertig habe.

(0007598)
Enno   
2017-10-30 18:03   

Gefixt in meinem lokalen develop Branch, sollte Sonntag in die Test-AW einfließen.

(0007773)
Enno   
2018-01-22 19:51   

Argh. Ich habe den lokalen Branch gelöscht, statt ihn zu mergen. Der Bug ist jetzt auch mir selber passiert.

(0007775)
Enno   
2018-01-22 21:01   

Falsch, ich hatte das schon gefixt und ein Merge gemacht. Das war commit 35742e8
Dass das in 3.14 immer noch auftritt, liegt daran, dass es da nicht mehr mit rein gekommen ist.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2405 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2018-01-01 14:29 2018-01-21 18:16
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 0
Spiel: E2
Report: 1057
Zusammenfassung: Mistelzweig hat keine Funktion
Beschreibung:

Der Mistelzweig erzeugt ein Attribut, das nicht gespeichert wird. Da BENUTZE erst nach ATTACKIERE kommt, hat er insbesondere keine Auswirkungen auf Kämpfe in der selben Runde, und da das Attribut (at_fleechance) nicht gespeichert wird, ist es in der Folgewoche auch wirkungslos.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Hier hätte der Entwickler einen curse erzeugen sollen, wie das z.B. bei Antimagiekristallen der Fall ist. Statt dessen gibt es attributes/fleechance.c und Sonderbehandlung davon in battle.c, also eine Menge Code, der keine Wirkung hat.

Angehängte Dateien:
Notiz
(0007761)
Enno   
2018-01-10 19:25   

ct_mistletoe ersetzt in Zukunft at_mistletoe. Eventuell muss man dafür eine curseinfo Message implementieren? Aber am besten sollte den curse niemand aufdecken können, ich hoffe, das habe ich richtig gemacht. Der Anwender selbst könnte ihn möglicherweise sehen, glaube ich?

Test gemacht, gibt: ERROR: no curseinfo function for fleechance, using cinfo_simple fallback.
Das sollte ich also noch erledigen.

(0007762)
Enno   
2018-01-10 19:28   

Au weia. cinfo_simple funktioniert nicht, weil statt NULL eine "missing_message" erzeugt wird.

(0007763)
Enno   
2018-01-11 09:21   

Es ist vielleicht einfacher, das über einen potion_effect zu machen, als über einen curse? Dann hat der Effekt lange Auswirkung, und skaliert mit der Anzahl Personen, statt für beliebig viele zu gelten. Das sollte er ja eigentlich nicht, aber tut er in meiner neuen Implementation, glaube ich.

(0007764)
Enno   
2018-01-11 18:03   

Für einen potion_effect müsste der Mistelzweig ein Trank sein. Warum ist das überhaupt eine eigene Klasse von Objekt? Kann nicht einfach jedes item einen Effekt haben?

(0007765)
Enno   
2018-01-11 18:04   

Die Klasse potion_type erweitert item_type nur um einen level. Spielt der eine Rolle für diese Effekte? Nein, nur für die Erschaffung.

(0007766)
defaitist   
2018-01-13 00:34   

Ich kann nur anmerken, dass der Mistelzweig von mir vor ca. 15 Jahren erfolgreich angewendet wurde und wie ein Friedenslied wirkte. Aber meiner Kenntnis nach kommt zwar der Befehle KÄMPFE vor BENUTZE, jedoch erst danach kommt ATTACKIERE und die tatsächlich durchgeführten Kämpfe. Somit entfalten sich Gegenstände immer vor den Kämpfen. Den gleichen Dauereffekt sollte Ponnuki besitzen, zumindest vor den diversen Bugfixes, wo er den Effekt des Dauerschutzes zuerst verlor und du ihn dann rekonstruiert hast.

(0007767)
Enno   
2018-01-13 08:56   

Du hast Recht, das habe ich falsch gelesen. BENUTZE kommt in der Tat vor ATTACKIERE. Trotzdem ist die Implementation des Mistelzweig nicht schön gewesen, so viel zusätzlichen Code für ein kleines Gimmick ist unnötig. Ich sehe hier eine Chance, die Tränke zu verallgemeinern auf Items, die einen lang anhaltenden Effekt haben, das gehe ich jetzt zu Ende.

(0007772)
Enno   
2018-01-21 18:16   

Der Zweig hat wohl doch funktioniert, das war aber schwer zu testen, und zu viel Code für ein kleines Feature. Ich habe das auf einen Effect umgestellt, dabei erlaubt, dass auch nicht-Tränke einen Effekt machen können, dass eine Einheit den Zweig lange vor dem Kampf benutzen kann, und für mehrere Personen auch mehrere Zweige.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2413 [Eressea] General kleinerer Fehler nicht getestet 2018-01-21 10:20 2018-01-21 18:14
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.3  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.14.4  
    Zielversion: 3.14.4  
Partei: so0g
Spiel: E2
Report: 1060
Zusammenfassung: Partei Halima hat Nummer 0
Beschreibung:

Die Partei Halima hat irgendwie die ID 0 bekommen, was dazu führt, dass das Datenfile nicht gelesen werden kann (0 wird intern verwendet für "keine Partei"). Das darf natürlich nicht sein.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Gerade in den Befehlen gefunden:

EINHEIT zn2i;
Nummer Partei [halima]

Das ist syntaktisch natürlich falsch, aber damit muss der Parser klar kommen.

Angehängte Dateien:
Notiz
(0007770)
Enno   
2018-01-21 10:33   

Ich habe den Fehler im Parser gefunden, jetzt muss ich allerdings noch die Daten reparieren. Das wird nicht einfach, aber evtl. leichter dadurch, dass die Partei noch so neu und klein ist?

(0007771)
Enno   
2018-01-21 10:50   

Datenfile ist gerettet, keine Neuauswertung notwendig. Die Partei hat ihre alte Nummer zurück bekommen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2408 [Eressea] General kleinerer Fehler nicht getestet 2018-01-07 17:26 2018-01-10 18:39
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.3  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.15.0  
Partei: ufo
Spiel: E2
Report: 1058
Zusammenfassung: TARNE PARTEI NICHT wirkt nicht
Beschreibung:

Meine Einheit zjoi ist als Assyrians getarnt, und möchte das gerne nicht mehr sein. Sie hat den Befehl TARNE PARTEI NICHT gegeben, der aber scheinbar nur Anonymität aufhebt, nicht Tarnung als eine andere Partei? Das ist so nicht gewünscht, glaube ich.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007758)
Enno   
2018-01-07 18:10   

Angeblich geht das mit TARNE PARTEI NUMMER. Dann ist das aber in der Anleitung nicht gut erklärt.

(0007760)
Enno   
2018-01-10 18:39   

PEBCAK. Ich habe einen Acceptance Test in Lua geschrieben, der das Feature in E2 prüft.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2409 [Eressea] Reportformat kleinerer Fehler nicht getestet 2018-01-08 18:56 2018-01-08 19:46
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Magellan versteht keine unsigned integers
Beschreibung:

Im CR sollten alle Integer 32-bit signed sein, denn Magellan mag das wohl nur so: http://www.pbem-spiele.de/forum/viewtopic.php?f=16&amp;t=4182

Es gibt mindestens eine Stelle in creport.c, wo das nicht so ist: "MESSAGE %u"

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007759)
Enno   
2018-01-08 19:46   

fixed in commit 5587e209


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2401 [Eressea] ATTACKIERE kleinerer Fehler nicht getestet 2017-12-28 13:19 2018-01-07 17:22
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 1wpy
Spiel: E2
Report: 1056
Zusammenfassung: Kaputte Kampfmeldung
Beschreibung:

Im Testreport:
"Der Kampf wurde ausgelöst von und Paladine des Flammenden Schwertes (pdfs)."

Stattdessen sollte da wohl stehen:
"Der Kampf wurde ausgelöst von Monster (ii), Seekoenigtum Gerengko (1wpy) und
Paladine des Flammenden Schwertes (pdfs)."

Kampf war gegen - Seeschlange (qrjz), 1 Seeschlange, aggressiv.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007736)
Enno   
2017-12-31 13:44   

Der Fehler scheint nicht bei allen beteiligten Parteien aufzutreten. Hmm. Gut, dass ich hier ein konkretes Beispiel habe.

(0007737)
Enno   
2017-12-31 13:51   

Der String wird für jede teilnehmende Partei neu erzeugt, weil sie die anderen Beteiligten evtl. nicht sehen kann (TARNUNG). Lästiger Mist ist das.

(0007738)
Enno   
2017-12-31 15:06   

Fehler gefunden. Diese Sorte Code sollte eigentlich in reports.c sein, nicht in battle.c. Ich verschiebe das mal bei dieser Gelegenheit. Siehe auch: battle_report.

(0007741)
Enno   
2018-01-01 07:11   

Umfassende Verbesserungen gemacht.

(0007747)
Solthar   
2018-01-07 13:16   

... und neuen Fehler eingebaut?

Der Kampf wurde ausgelöst von Seekoenigtum Gerengko (1wpy).

statt

Der Kampf wurde ausgelöst von Monster (ii) und Seekoenigtum Gerengko (1wpy).

           In Südwesthochland (115,-259) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Monster (ii) und Seekoenigtum Gerengko (1wpy).

Heer 0: Monster (ii)
Kämpft gegen: Heer 1(1wpy), Heer 2(1wpy)
Hilft: Heer 0(ii)
Attacke gegen: Heer 1(1wpy), Heer 2(1wpy)
... in der 1. Kampflinie:
  - Verdammte der Tiefe (sLij), 16 Ghoule, aggressiv (erschöpft), bewacht die
    Region.

Heer 1: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy)
... in der 4. Kampflinie:
  * Umgucker (692t), 97 Meermenschen, flieht, Talente: Tarnung 1, Unterhaltung
    7, hat: 2625181 Silber.
  * Miliz (8jaj), 281 Meermenschen, flieht, Talente: Tarnung 1, Ausdauer 1.

Heer 2: Seekoenigtum Gerengko (1wpy)
Kämpft gegen: Heer 0(ii)
Hilft: Heer 1(1wpy), Heer 2(1wpy)
Attacke gegen: Heer 0(ii)
... in der 1. Kampflinie:
  * Miliz (nmwk), 100 Meermenschen, vorne, bewacht die Region, Talente: Reiten
    4, Hiebwaffen 15, Tarnung 4, Unterhaltung 2, Steuereintreiben 4, Ausdauer
    7, hat: 400 Pferde, 497000 Silber, 100 Rostige Kettenhemden, 100 Schwerter.
(0007748)
Enno   
2018-01-07 13:42   

Was ist hier der Fehler?

(0007749)
Enno   
2018-01-07 14:01   

Im aktuellen Testreport (1058) sehe ich da etwas anderes:

        In Südwesthochland (115,-259) findet ein Kampf statt.

Der Kampf wurde ausgelöst von Seekoenigtum Gerengko (1wpy).

Heer 0: Monster (ii)
(0007751)
Solthar   
2018-01-07 14:03   

Genau das ist der Fehler. "Monster (ii) und" fehlt.

(0007753)
Enno   
2018-01-07 14:34   

Aha. Es war nicht offensichtlich, dass die Dich attackiert haben.

(0007755)
Enno   
2018-01-07 15:33   

Ah, ja. Man darf halt strcat und strcpy nicht vertauschen.

(0007756)
Enno   
2018-01-07 17:21   

Neuer Test zeigt: Der Kampf wurde ausgelöst von Monster (ii) und Seekoenigtum Gerengko (1wpy).


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2407 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2018-01-07 13:10 2018-01-07 17:21
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 1wpy
Spiel: E2
Report: 1058
Zusammenfassung: Lernkosten für Magie falsch
Beschreibung:

Original:
Seehexe Anjuschka Floisania (awiz) in Vepunkan (-30,-42) verbraucht 23300
Silber für das Studium von Magie.
Spulzeer (xw01) in Vepunkan (-30,-42) verbraucht 6050 Silber für das Studium
von Magie.
Morla (d25f) in Vytbêd (27,-2) verbraucht 40700 Silber für das Studium von
Magie.
Seehexe Simone (wyiy) in Vytbêd (27,-2) verbraucht 56200 Silber für das
Studium von Magie.

... und Fälschung im Testreport:
Seehexe Anjuschka Floisania (awiz) in Vepunkan (-30,-42) verbraucht 24850
Silber für das Studium von Magie.
Spulzeer (xw01) in Vepunkan (-30,-42) verbraucht 24850 Silber für das Studium
von Magie.
Morla (d25f) in Vytbêd (27,-2) verbraucht 49700 Silber für das Studium von
Magie.
Seehexe Simone (wyiy) in Vytbêd (27,-2) verbraucht 49700 Silber für das

Morla und Spulzeer sind Vertraute.

Alle Magier zahlen also für Stufe 31, obwohl sie ganz unterschiedliche Stufen haben.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007750)
Enno   
2018-01-07 14:03   

Ich habe doch tatsächlich an der studycost Funktion etwas geändert. Und Tests geschrieben. Aber scheinbar nicht genug.

(0007752)
Enno   
2018-01-07 14:10   

Morla ist Stufe 27, kosten sollten 20350 sein? Aber in costs[sk] steht schon ein Wert, haha. Das ist natürlich verkehrt, dass der benutzt wird.

(0007754)
Enno   
2018-01-07 15:28   

Ja, doofer Cache ist doof. Für Magie abgeschaltet (eine Optimierung geht da wohl noch).

(0007757)
Enno   
2018-01-07 17:21   

Test zeigt:

Seehexe Anjuschka Floisania (awiz) in Vepunkan (-30,-42) verbraucht 23300
Silber für das Studium von Magie.
Spulzeer (xw01) in Vepunkan (-30,-42) verbraucht 6050 Silber für das Studium
von Magie.
Morla (d25f) in Vytbêd (27,-2) verbraucht 40700 Silber für das Studium von
Magie.
Seehexe Simone (wyiy) in Vytbêd (27,-2) verbraucht 56200 Silber für das
Studium von Magie.

Ist okay, glaube ich.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2403 [Eressea] Reportformat kleinerer Fehler nicht getestet 2017-12-31 16:26 2017-12-31 16:37
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: ii
Spiel: E2
Report: 1057
Zusammenfassung: Reportgenerierung Endlosschleife
Beschreibung:

Die Testauswertung ist in eine Endlosschleife gelaufen, glaube ich. Das Logfile ist 83G groß, und drin steht nur:
WARNING: static buffer too small in /home/eressea/eressea/git/src/report.c:2232
WARNING: static buffer too small in /home/eressea/eressea/git/src/report.c:2237
WARNING: static buffer too small in /home/eressea/eressea/git/src/report.c:2232
WARNING: static buffer too small in /home/eressea/eressea/git/src/report.c:2237

etc.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007739)
Enno   
2017-12-31 16:34   

ZEIGE ALLE Kräuter verursacht das. Ich habe da eine Variable umbenannt.

(0007740)
Enno   
2017-12-31 16:37   

Die ganzen Strings in statischen Buffern könnte ich mal anders lösen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2400 [Eressea] General kleinerer Fehler nicht getestet 2017-12-28 13:15 2017-12-31 13:15
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: 1wpy
Spiel: E2
Report: 1056
Zusammenfassung: Zauberbeutel zerfallen im Astralraum
Beschreibung:

Im Testreport:
"Botschafter Finz (3umk) in Nebel (6,-2): 1 Zauberbeutel zerfallen zu Staub."

Folge der notlost-Änderung? Falsches Flag erwischt? Vergessenes Feature?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007723)
Enno   
2017-12-30 18:24   

Die notlost Änderung ist noch nicht in der Produktion, die habe ich ja diesen Monat erst gemacht.

(0007725)
Xolgrim   
2017-12-30 21:12   

Die Meldung ist auch noch Grammatikalisch falsch

(0007727)
Enno   
2017-12-30 22:15   

Tip: Die Version mit anzugeben hilft mir, gerade wenn es sich um den Testreport handelt. Version steht im CR.

(0007733)
Enno   
2017-12-31 12:44   

Der Code zum zerfallen ist:

        if ((itm->type->flags & ITF_NOTLOST) == 0) {
            if (itm->type->flags & (ITF_BIG | ITF_ANIMAL | ITF_CURSED)) {

Zauberbeutel sind ITF_BIG, aber seit der Änderung nicht mehr ITF_NOTLOST, glaube ich.

(0007734)
Enno   
2017-12-31 12:50   

In gewisser Weise ist das ein (unangekündigter, weil unbewusster) Bugfix. Sinn des Zerfall-Codes war, dass man keine Invasion durch den AR mit massenhaft Material machen kann. Eingeführt wurde das, als ich gesehen habe, das es Leute gab, die massenhaft Pferde und Wagen im AR hatten, um eben das zu tun. Der Zauberbeutel ist da ein mir bisher unbekanntes Schlupfloch gewesen.

Das ist zumindest eine strikte Sichtweise. Die andere ist, dass der Zauberbeutel das Flag hatte, eben damit man mit viel Magie trotzdem Material durch den Astralraum schicken kann. Ich bin nicht sicher, was die Intention war, das ist bestimmt 10 Jahre her.

(0007735)
Enno   
2017-12-31 13:15   

Ich führe mal das notlost Flag für den Beutel wieder ein, das war nicht wirklich nötig, das zu entfernen.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2399 [Eressea] General kleinerer Fehler nicht getestet 2017-12-28 13:08 2017-12-31 11:58
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.15.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: drac
Spiel: E3
Report: 438
Zusammenfassung: Schreibfehler %%
Beschreibung:

Testreport:
"Im Nordwesten befindet sich eine zu 38%% vollendete Straße."

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007722)
Enno   
2017-12-30 18:23   

Daran habe ich neulich noch etwas gemacht, glaube ich. Aber ist das wirklich shcon in Produktion? Mist, wieso?

(0007724)
Xolgrim   
2017-12-30 21:11   

Steht doch im Testreport...

(0007726)
Enno   
2017-12-30 22:12   

Oh, das habe ich nicht gesehen. Es war auch keine Version angegeben.

(0007732)
Enno   
2017-12-31 11:58   

easy


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2197 [Eressea] General kleinerer Fehler immer 2016-03-14 20:18 2017-12-26 16:10
Reporter: Mortox Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: meLf
Spiel: Deveron
Report: 97
Zusammenfassung: Falsche Anzahl Bäume in Beschreibung von Wasser des Lebens
Beschreibung:

Laut Zaubertext soll Wasser des Lebens aus 10 Holz 10 Schösslinge machen. Tatsächlich wird das Holz direkt zu 10 Bäumen umgewandelt.

Schritte zur Reproduktion:

BENUTZE "Wasser des Lebens"

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0006505)
Xolgrim   
2016-03-17 17:50   

Der Zaubertext ist hier (vom Ursprungsdesign her) korrekt. Wir wollten verhindern, dass damit massenhaft Holz produziert wird wie in E2. "Wasser des Lebens wird extrem abgeschwächt." war von daher auch schon einer der ersten Punkt zu Magie und Alchemie.

Das erstezen der Alchemisten durch Magier ist jedoch schon eine drastische Abschwächung die alleine vermutlich schon dafür sorgt, dass hier keiner 1000 WdL herstellt.

Ich spiele E3 nicht mehr und habe Deveron nie gespielt, was ich davon bisher gehört habe ist Holz dort aber ein extrem knapper Rohstoff. Von daher ist zu überlegen, ob man nicht doch lieber die Zauberbeschreibung ändert als die Funktionsweise.

(0006506)
CTD   
2016-03-20 18:28   

Ich denke was Mortox meint, ist das da was von Schösslingen steht, aber es entstehen Bäume. Das ist für die Baumvermehrung nicht gant Unwesentlich, und auch für die Arbeitsplätze. Das und die Tatsache das es in E3 und E4 nur 5 und nicht 10 Bäume aus entsprechend 5 Holz erschaffen werden sollte mal in die Beschreibung.
Auch finde ich nicht das WdL zu schwach ist. Das kann man so lassen.

(0007324)
Enno   
2017-07-08 11:26   

Wenn das ein rein kosmetischer Fix an der Beschreibung ist, sollte das schnell gemacht sein. Ich freue mich da über einen Pull Request, falls jemand anders das tun will.

(0007326)
CTD   
2017-07-08 20:34   
(Zuletzt bearbeitet: 2017-07-30 00:00)

Ja, ist es, aber auch die Meldungen sind falsch, nicht nur die Beschreibung. Wenn man es also richtig macht müsste man für E3 eine andere Meldung auswerfen als für E2.
Oder man ändert in einem der beiden Spiele was erschaffen wird. Das warum ist mir eh nicht klar (also warum es in E3 Bäume und in E2 Schößlinge sein müssen).
Das es in E3 nur 5 statt 10 sind ist OK, und im Bezug auf die Zahl stimmt die Meldung ja auch.

(0007717)
Enno   
2017-12-26 12:50   

Der Zaubertext spricht weder von Schößlingen, noch sagt er, wie viele neue Bäume erzeugt werden. Er macht nur eine Aussage über das verwendete Holz. Es kann allerdings sein, dass in E3 und Co auch weniger Holz verwendet wird. Die Anpassung der Texte an den Magie-Multiplikator ist schwierig...

Zitat:

Das 'Wasser des Lebens' ist in der Lage, aus gefällten Baumstämmen wieder lebende Bäume zu machen. Dazu wird ein knotiger Saugwurz zusammen mit einem Elfenlieb erwärmt, so dass man gerade noch den Finger reinhalten kann. Dies gieße man in ein Gefäß und lasse es langsam abkühlen. Der Extrakt reicht für 10 Holzstämme.

(0007718)
Enno   
2017-12-26 15:51   

Der Test, den ich geschrieben habe, scheint noch nicht 100% zu funktionieren.

https://travis-ci.org/ennorehling/eressea/jobs/321809865

(0007719)
Enno   
2017-12-26 16:00   

Mallorn ist eine Pest. Okay, Test ist in Ordnung, jetzt muss nur der Text in E3+ angepasst werden. Macht 5 Bäume, nicht 10 Schößlinge.

(0007720)
Enno   
2017-12-26 16:10   

So schwierig ist es gar nicht, den Text zu ersetzen, aber man kann ihn halt nicht an die Werte in der config-Datei anpassen, sondern muss beides gemeinsam ändern.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2097 [Eressea] General kleinerer Fehler immer 2015-04-29 10:47 2017-12-26 12:47
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.5  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Ring der Levitation ist kaputt
Beschreibung:

Der Ring der Levitation ist ein Spezialitem auf der Treueschwur, zum Überqueren von Gletscherbarrieren. Der Lua-Code für BENUTZE (use_ring_of_levitation) ist verschwunden, sicher bei einer Umstellung der Skripte. Einen Test gibt es natürlich auch nicht, weil das schwer zu testen ist, und geschrieben wurde bevor ich Tests gebaut habe (das war ein Curse Effekt, tippe ich).

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005840)
Xolgrim   
2015-05-22 08:41   

Laut Alerich2 flog das Schiff in Woche 858 noch:
Kräftige Stürme haben dieses Schiff in die Luft gehoben. (db0u)
Die Treueschwur (4jwt) fliegt von Ozean (-75, 349) nach Ozean (-67, 349).

(0005841)
Enno   
2015-05-22 11:29   

Das ist der Effekt von Luftschiff. Das gibt mir zumindest einen Anhaltspunkt dafür, wie der Code mal funktioniert hat, falls ich ihn neu schreiben muss.

(0007716)
Enno   
2017-12-26 12:47   

Falscher Alarm. Der Ring war so gemacht, dass er nur einmal benutzt werden muss, um das Schiff führt immer flugfähig zu machen. Weil es nur einen solchen Ring gab, und keine weiteren geben wird, ist der Code dafür auch nicht mehr nötig, und gelöscht worden.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2238 [Eressea] NACH/ROUTE kleinerer Fehler nicht getestet 2016-09-19 12:23 2017-12-26 06:28
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.14.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: II
Spiel: E2
Report: 962
Zusammenfassung: Drachengeschwindigkeit
Beschreibung:

Im Code steht:
switch (old_race(u_race(u))) {
case RC_DRAGON:
case RC_WYRM:
case RC_FIREDRAGON:
return BP_DRAGON;

d.h. die drei Monsterdrachen sollen Geschwindigkeit 4 haben, komme was wolle. Das ist eklig fest einprogrammiert, weil es sicher älter ist als races.xml

In res/races/dragon.xml steht aber speed="1.5", also ein Multiplikator, der erst ganz am Ende der Funktion auf die Bewegungspunkte multipliziert wird, also für Drachen gar nicht zum Einsatz kommen kann. Hier ist etwas faul, und einiges schwer verständlich. Ich nominiere das für ein Refactoring und zusätzliche Tests zwecks Dokumentation des erwünschten Verhaltens.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007715)
Enno   
2017-12-26 06:27   

Drachen mit Multiplikator sollten jetzt schneller sein, aber sie benutzen immer noch keine magischen Items oder Zaubereffekte.


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2156 [Eressea] General Unschönheit nicht getestet 2015-11-11 20:30 2017-12-25 23:24
Reporter: Pyanfar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.13.1  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.15.0  
    Zielversion: 3.15.0  
Partei: yuka
Spiel: Deveron
Report: 69
Zusammenfassung: [Deveron] Vulkanopfer in falscher Region gemeldet
Beschreibung:

Der in http://bugs.eressea.de/view.php?id=2139 gemeldete Vulkanausbruch ergab folgende Meldung in meinen NR&CR:
"Beim Vulkanausbruch in Vikotin, Reich der Yuka (6,-5) sterben 1 Personen in Siedler (hwr7).
Der Vulkan in Vikotin, Reich der Yuka (6,-5) bricht aus.
Beim Vulkanausbruch in Vikotin, Reich der Yuka (6,-5) sterben 1 Personen in Siedler (aLm3)."

Letztere Einheit ist allerdings zuvor in die Nachbarregion des Vulkanes (wohin sich die Lava ergoß) geritten:
"Siedler (aLm3) reitet von Cupiges (5,-4) nach Smalland (5,-5)."

Die Opfer des Lavaausflußes in die Nachbarregion werden also als im Vulkan gestorben gemeldet.
Ob sich das Verhalten ändert, wenn ich noch Eeinheiten in den Regionen gehabt hättet, hab ich noch nicht getestet :)

Kein groß störender Fehler, aber ich wollte es einmal zur Kenntnis bringen.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0006422)
Enno   
2015-12-17 20:54   

Die Message hier ist volcano_dead, aber die wird nicht in der Region, sondern an der Partei der Verstorbenen gemeldet. Dass da der Name der Vulkanregion drin ist, ist nicht falsch. Brauchen wir den Namen der Region, in der sie standen, auch? Also "Beim Ausbruch des Vulkanes in <region1> starben in <region2> 3 Personen von <einheit>"? Das wird dann aber sehr wortreich.

(0006423)
Pyanfar   
2015-12-17 22:11   

Hmm, ich meine, das wurde früher anders und trotzdem sparsam an Worten gemeldet. Also die sekundären Vulkanopfer druch den Lavaausfluß. Ich durchforste mal alte Reports und melde mich mit einem Verbesserungsvorschlag :)

(0006607)
Enno   
2016-06-07 17:27   

Warte hier immer noch auf die versprochene Rückmeldung.

(0006750)
Pyanfar   
2016-08-21 19:06   

So nun kann ich mich endlich zurückmelden, da ich das Phänomen jetzt grad (Aw367) nochmal bei E3 hatte.

Da wurden die Opfer des Vulkans in der Nachbarregion gemeldet mit
"Beim Vulkanausbruch in Faratcilrur (-1,-10) sterben 5 Personen in Priester des Nagels (1rrr)."
Faratcilrur (8, -11) (7pLgo9) war nun der Vulkan selber, die Opfer standen aber in der Nachbarregion Sacud, der Hohe Berg (9, -11) (pie4sw).

Ich hätte nun also einen Formulierungsvorschlag - vorausgesetzt, der Server unterscheidet überhaupt zwischen den Opfern im Vulkan und denen nebenan.

Falls ja, wäre mein Vorschlag:
"Durch Lavamassen starben in <region2> 3 Personen von <einheit>"
wobei <region2> die Nachbarregion wäre.

Falls nein, ist es eh egal, dann müssen wir halt zweimal hingucken.
:)

(0006751)
Enno   
2016-08-21 21:02   

Wie üblich rollen die Würfel nicht so wie sie es vorher taten, und eine Neuauswertung auf den gleichen Daten macht bei mir keinen Vulkanausbruch, aber vielleicht kann ich das als Anlass nehmen, den Code mal mit einem Test auszustatten, der die Meldungen testet. Das wird sicherlich kompliziert, weil der Code nicht geschrieben wurde, um einfach zu testen zu sein, aber die dafür nötige Umstrukturierung kann auch Spaß machen. Und gelegentlich findet man bei so einem refactoring ja auch noch andere Fehler (heute war mal wieder so ein Tag).

(0006752)
Enno   
2016-08-23 17:45   

Also, um das noch einmal klar zu stellen: Deine Klage bezieht sich darauf, dass die Einheit nicht im Vulkan ist, aber der Name des Vulkans in der Meldung erscheint? Obwohl sie den Schaden bekommen, weil sie in der Region waren, wo die Lava hin geflossen ist? Es hat mit der Bewegung der Einheit (im Original-Beispiel) nichts zu tun, ja?

(0006753)
Pyanfar   
2016-08-23 18:36   

Ah, sorry, dass ich da zwei Sachen vermische... ich kann aber beides beantworten:

Ja, das Problem ist, dass die Meldung von Lavaopfern ausserhalb der Vulkanregion (also durch Lavafluss) dennoch den Vulkanregions-namen enthält.
Dadurch wird es erschwert herauszufinden, wo denn nun Leute gestorben sind, wenn eine Einheit komplett stirbt (wenn Personen der Einheit überleben, kann ich ja einfach die ID suchen).

Ob die Personen sich bewegt haben, scheint mir dabei irrelevant, würde auch Sinn machen, da ja der tatsächliche Todesort nicht vermerkt wird.

Habe ein paar alte Reports durchforstet, und ein Beispiel gefunden, wo für beide Opfer (einmal rumstehend, einmal in die Lava reingezogen) beides dieselbe Meldung verwendet wird (CR sagt zum message-typ: 109595936;type).

Habe auch ein Beispiel gefunden, wo jemand im Vulkan selber stirbt - der bekommt exakt dieselbe Meldung, ebenfalls "109595936;type".

Insofern scheint mir das Problem eh nicht lösbar ohne Ausdifferenzierung der Meldungen. Ob das den Aufwand wert ist...

(0006754)
Pyanfar   
2016-08-23 18:43   

Ach, und Nachtrag: meine Erinnerung scheint mich getrogen zu haben, eine Textstringsuche in meinem Eressea-Ordner ergibt keinerlei anderen Meldungen. Meine Vermutung aus der ersten Notiz ist damit hinfällig.

(0006766)
Enno   
2016-09-02 09:14   

Ich habe im Urlaub eine Menge refactoring und neue Tests rund um Vulkane geschrieben, aber bin nicht sicher, was ich mit Hinsicht auf die Meldungen eigentlich ändern sollte. Ich glaube, das ist hier kein Bug, sondern eher ein Denkanstoss für ein Projekt, um bessere Benachrichtigungen beim Ausbruch zu geben.

(0007468)
Enno   
2017-09-04 19:58   

Wir haben eine Meldung, die anzeigt, in welche Region die Lava geflossen ist: Der Vulkan in $region1 bricht aus. Die Lavamassen verwüsten $region2. Das sollte reichen, um dem Geschehen zu folgen. Das die Meldung über den Tod der Einheit nicht die Region in der sie (nicht mehr) steht, enthält, sondern den ausgebrochenen Vulkan, ist