Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2621 [Eressea] GIB kleinerer Fehler nicht getestet 2019-11-25 00:31 2019-12-10 19:36
Reporter: Fiete Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: zugewiesen Produktversion: 3.22.1  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: atnf
Spiel: E2
Report: 1146
Zusammenfassung: Test-AW: Fehlermeldung bei fehlender Anzahl bei Schiffsübergaben unkorrekt
Beschreibung:

Matrosen (c8v3) in Sudibabis (-2,5): 'GIB yw18 SCHIFF ' - Nichts angegeben,
was wir übergeben sollen.

Die Fehlermeldung sollte richtig lauten: Die Anzahl der Schiffe fehlt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008630)
Enno   
2019-11-30 19:20   

Wenn man GIB abcd PERSON befiehlt, gibt es da analog auch eine "Anzahl fehlt" Meldung?



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2620 [Eressea] GIB kleinerer Fehler nicht getestet 2019-11-25 00:28 2019-12-10 19:36
Reporter: Fiete Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: neu Produktversion: 3.21.0  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: atnf
Spiel: E2
Report: 1146
Zusammenfassung: Test-AW: Übergabe von Schiffen erzeugt keine Nachricht
Beschreibung:

Weder bei der Ziel-Einheit (Matrosen (yw18)) noch beim Schiff Eichenblatt (cqij) und nicht bei der Geber-Einheit (Mannen (asqa)) wird eine Meldung/Nachricht erzeugt, welche die Übergabe des Schiffes dokumentiert.
Oder ich habe sie nicht gefunden, weder in nr noch in cr.

Test-Report der Partei atnf Runde 1146.

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:
2619 [Eressea] BEWACHE schwerer Fehler nicht getestet 2019-11-24 01:23 2019-11-25 15:16
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: d08a
Spiel: E2
Report: 1147
Zusammenfassung: Unbewaffnete und weggezogene fremde Einheit verhindert Ressourcenabbau
Beschreibung:

Ich habe diese Woche die folgende Meldung in meinem NR:
--- snip ---
Sjorrim Eisenfinder (smor) in Südmorgan (-149,285): 'MACHE 200 Eisen' - Die
Region wird von Besucher (a9zv), einer nichtalliierten Einheit, bewacht.
--- snap ---

Besucher (a9zv) ist eine unbewaffnete Einheit, die diese Runde aus der Region weggezogen ist. Wie kann diese Einheit den Abbau von Ressourcen verhindern.

Meine Bergarbeiter (smor) haben in der Tat kein Eisen abgebaut. Der Bestand in der Vorwoche ist der gleiche wie in dieser Woche: 5408 Eisen, d.h. es handelt sich nicht um einen kosmetischen Fehler.

In Runde 1146 wurde die Region nur von mir bewacht:
--- snip (1146-d08a.nr) ---
Die Region wird von Thorans Axtträger (d08a) bewacht.
--- snap ---

Allerdings ist eine der bewachenden Einheiten eben genau diejenige, die hier auch Eisen abbauen sollte. Ich vermute deshalb, dass das mit dem Fix für Bug 2614 zusammenhängen könnte. Allerdings bewacht meine abbauende Einheit die Region schon seit Urzeiten (also mit Sicherheit mehrere hundert Wochen) und dieser Fehler ist noch nie gemeldet worden.

Ich habe die Partei der Einheit a9zv über Discord kontaktiert und sie gebeten ,mir die genauen Befehle dieser Einheit zu schicken. Sollte ich diese erhalten, trage ich die als Notiz nach.

Ich habe den Fehler mal als "schweren Fehler" eingestuft, weil man mit einer solchen Aktion - wenn man sie denn irgendwie bewusst herbeiführen kann - schon einiges an Schaden anrichten kann.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Abbauende Einheit: smor
Fremde, weggezogene Einheit: a9zv
Regions-ID: 1162143512

Angehängte Dateien:
Notiz
(0008626)
Xolgrim   
2019-11-24 09:53   

Du beziehst nicht zufällig die Test-AW? 2614 ist nämlich in der live Version noch nicht integriert und behebt den Fehler ja ggf. schon.

(0008627)
Enno   
2019-11-24 14:30   

Das sieht mir auch aus, als könnte es Bug 0002614 sein.

(0008628)
Enno   
2019-11-24 14:31   

In Testreport 1147: Sjorrim Eisenfinder (smor) in Südmorgan (-149,285) produziert 200 Eisen.

(0008629)
Thoran   
2019-11-25 00:46   

Mein Fehler: Ich hatte in der Tat nicht berücksichtigt, dass 2614 noch nicht live ist.

Kann also geschlossen werden. Sorry!



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2614 [Eressea] BEWACHE schwerer Fehler nicht getestet 2019-10-18 19:21 2019-11-24 09:52
Reporter: Waldgoettin Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: am
Spiel: E2
Report: 1142
Zusammenfassung: Fremde Einheit ohne Waffen bewacht laut Meldung - allerdings kann ich mit einer Einheit Ressourcen abbauen, mit der anderen nich
Beschreibung:

Partei Clanlose Gesellen (am) hat in einem Berg einen Steinbauer (zf5z) und einen Bergbauer (a6na). Die Region wird vom Bergbauer bewacht.

Der Steinbauer konnte in Runde 1142 Steine abbauen, der Bergbauer erhält die Fehlermeldung "Eisensucher (a6na) in Fuchsstein (-24, 59): 'MACHE 114 Eisen ' - Die Region wird von Bergbauer aus Tytgefabit (cj7w), einer nichtalliierten Einheit, bewacht."

Die genannte Einheit ist NICHT bewaffnet.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008590)
Xolgrim   
2019-10-19 10:06   

Wer bewacht laut NR die Region? also das: "Die Region wird von Nachtschatten (oLm) bewacht."
und das:
" + Gebirgsjäger (iu2s), Nachtschatten (oLm), 100 Dunkelzwerge, bewacht die Region, hat: 100 Bihänder ..."

Ich nehme an deine beiden Einheiten befinden sich in Gebäuden?

(0008591)
Waldgoettin   
2019-10-19 14:11   

Ich schlaf ja nicht auf dem Baum, ich hab mir das vorher schon genau angeschaut. Ich bin in meinen eigenen Gebäuden, ich bewache selbst die Region und Alerich bewacht sie nicht (und hat wie gesagt ja nichtmal Waffen). Ausserdem ist es extrem unlogisch, dass eine meiner Einheiten abbauen kann, die andere aber nicht.

Eisensucher (a6na) in Fuchsstein (108,-41): 'MACHE 114 Eisen ' - Die Region
wird von Bergbauer aus Tytgefabit (cj7w), einer nichtalliierten Einheit,
bewacht.

Die Region wird von Sirianische Schattengarde (cm) und Clanlose Gesellen (am)
bewacht.

Bergwerk (tpbk), Größe 4, Bergwerk.

- Bergbauer aus Tytgefabit (cj7w), Die Walgenorianer (L12a), 4 Menschen,
  hat: 10 Pferde, Silberkassette.

Stollen (qxw2), Größe 5, Bergwerk.

* Eisensucher (a6na), 4 Talzwerge, kämpft nicht, bewacht die Region,
  Talente: Bergbau 28, Burgenbau 5, Hiebwaffen 2, Tarnung 5, hat: 1580
  Silber, 4 Plattenpanzer, 4 Schilde, 4 Schwerter, "MACHE 114 Eisen ".

Steinbruch (vL7a), Größe 10, Steinbruch.

* Steinsucher (zf5z), 10 Talzwerge, flieht, Talente: Steinbau 21, hat: 950
  Silber, 220 Steine, "MACHE 220 Stein ".
(0008592)
Waldgoettin   
2019-10-19 14:37   

Nachtrag: ich stehe im zweiten (jüngeren) Bergwerk der Region. Daran sollte es doch aber nicht liegen?

(0008593)
Enno   
2019-10-20 17:08   

Sieht nach einem wirklcihcne Fehler aus. Der Code checkt da nicht, ob cj7w bewacht, sondern prüft Deine eigene Einheit. Oops.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2523 [Eressea] General kleinerer Fehler nicht getestet 2018-11-25 15:12 2019-11-16 16:26
Reporter: Solthar Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: zugewiesen 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?

(0008624)
Enno   
2019-11-16 09:25   

Die Parametrisierung von Meldungen ist eher Glücksache. Ob ein Parameter im CR ist, hängt davon ab ob er zum Erzeugen der Meldung benötigt wurde. Eine Meldung wie "Frank Oz (f9oz) stirbt" wird von einem String "$unit($dead) stirbt" erzeugt, und würde einen Parameter 712403;dead bekommen, und keine Region, weil keine Region in der Meldung steht. Der Parameter heißt dann auch "dead" und nicht "unit". Ein Client, der darauf hofft, das jede Meldung einer Region zugeordnet werden kann, wird da bei einigen Probleme kriegen. Ebenso, wenn er die Einheit, auf die die Meldung sich bezieht, aus einem "unit" Argument ermitteln will, weil die eben nicht immer so heißen, sondern auch schonmal "mage", "giver" oder "target".

Ich bin zunehmend unzufrieden damit, wie die Messages gelöst sind, und suche immer noch nach einer besseren Lösung. Da wäre es mal an der Zeit zu fragen, was denn die Clients erwarten.

(0008625)
Solthar   
2019-11-16 16:26   

In erster Näherung würde ich mir wünschen, dass alles so bleibt wie es ist, denn dann muss ich nix ändern. ;)
Es gibt im Moment ungefähr drei Dutzend Stellen im Magellancode, wo auf Message.getAttributes zugegriffen wird. Der Großteil davon in BattelInfo, wo versucht wird, den Kampfreport aufzubereiten. Das reicht von konkreten Zugriffen auf bestimmte Attribute bestimmter MESSAGETYPEs, bis zum Vergleich auf gut Glück, ob ein Attribut mit einer UnitID übereinstimmt.

Als Mindestanforderung würde ich mir im Moment einen "Besitzer" mit einem "Typ" pro Meldung wünschen. Besitzer könnte leer (global, blöd), eine Partei, eine Region, ein Schiff, ein Gebäude, eine Einheit sein. Typ wäre eben "leer", "Partei", "Region", "Einheit" usw. Weitere Parameter wären dann nice to have, sollte aber ebenso einen Typ haben.

Das ist jetzt gerade so dahergesagt, im Ernstfall müsste darüber noch mal weiter nachdenken.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2617 [Eressea] Schiffe schwerer Fehler nicht getestet 2019-10-27 15:13 2019-11-02 19:20
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion:  
Partei: 777
Spiel: E2
Report: 1144
Zusammenfassung: Fusion von Schiffen auf dem Ozean funktioniert nicht
Beschreibung:

Ich habe diese WOche 74 Schiffe auf dem Ozean fusioniert (GIB k29 1 Schiff). Nun stehen sämtliche kapitäne und passagiere der Schiffe auf der Karavelle von Kapitän k29. Soweit alles gut. Das Problem ist, dass die Schiffe alle weg sind. Es gibt nur noch eine Karavelle in der Region. Das Schiff ist hoffnungslos überladen und dadurch massiv beschädigt worden

Karavelle (2seh), Karavelle, 61% beschädigt.

Erwartet hätte ich eine Flotte aus 74 Karas (73, sehe gerade das ich einer kara wohl vergessen habe den fusionsbefehl zu geben)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008616)
Xolgrim   
2019-10-28 11:22   

War natürlich in der Test AW

(0008618)
Enno   
2019-10-28 20:56   

Neu ausgewertet, und ich sehe folgendes:

Die Karavelle (2seh) ist zu stark überladen und wird stark beschädigt.

Karavelle (2seh), 73 Karavellen, (12776/85410), 61% beschädigt.

* Kapitän (k29), 2 Erzzwerge, kämpft nicht, Talente: Schiffbau 15,
  Segeln 17, Ausdauer 7, "ROUTE Ost Ost Ost Ost Ost Ost Ost NO NO NO NO NO
  NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO Ost NO NO NO NO NO NO NO NO
  NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
  NO NO NO NO NW NW NW NW NW NW NW NO NO NO NO NO NO NO NO NO NO NO NO NO
  NO NO NO NW NW NW NW NW NW NW NW NW NW NW PAUSE PAUSE Ost NO NO Ost Ost".

[ ... alle anderen Einheiten ... ]

Felsspalter K (spaL), Karavelle, 0% beschädigt; h9u9.

+ Kapitän (mn8q), Iøniger (ioen), 2 Nebelmeermenschen.
(0008619)
Enno   
2019-11-02 18:38   

Das Schiff nimmt Schaden, weil es nur 2 Kapitäne hat, und 73 braucht.

(0008620)
Enno   
2019-11-02 18:39   

Dazu kommt, die Überladung berechnet sich basierend auf sh->type->cargo, was nicht multipliziertwird mit der Anzahl Schiffe!

(0008621)
Enno   
2019-11-02 18:55   

Ich sehe übrigens auch in deinem Testreport (den ich noch habe), dass das 73 Karavellen sind:

Karavelle (2seh), 73 Karavellen, (12776/85410), 61% beschädigt.

Warum Du da nur eine siehst, verstehe ich also immer noch nicht. Das kommt nicht von mir. Sicher, dass du in den NR schaust, und nicht in eine Ausgabe von Vorlage?

(0008622)
Enno   
2019-11-02 18:58   

Mit dem Fix für die Kapazität errechnet ich nur noch eine Überladung von 6%, nicht mehr als 400% wie zuvor. Damit gibt es nicht den starken Schaden, sondern nur die "normalen" 2% für das Abtreiben, und das Schiff sollte ca. 30% beschädigt sein. Mal neuen Report erzeugen und gucken.

(0008623)
Enno   
2019-11-02 19:08   

Neue Ausgabe:

Die Karavelle (2seh) treibt nach Südwesten.

Karavelle (2seh), 73 Karavellen, (12776/148920), 32% beschädigt.

Das klingt mir absolut richtig.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2618 [Eressea] Schiffe Absturz nicht getestet 2019-10-27 19:57 2019-10-28 20:25
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.22  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion: 3.22  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Assertion `fval(r->terrain, SEA_REGION)' failed.
Beschreibung:

Manchmal versuchten wir eine Küste zu setzen, ohne dass das Schiff an Land ist? Passiert während der E2 Lua Tests, run-tests-e2.lua

https://travis-ci.org/eressea/server/jobs/603472966?utm_medium=notification&utm_source=email

Schritte zur Reproduktion:

Ich habe einen Callstack extrahiert bekommen:

Program received signal SIGABRT, Aborted.
GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt 10
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff654542a in
GI_abort () at abort.c:89
0000002 0x00007ffff653ce67 in assert_fail_base (fmt=<optimized out>,
assertion=assertion@entry=0x55555566704c "fval(r->terrain, SEA_REGION)",
file=file@entry=0x555555666ed0 "/home/eressea/eressea/git/src/move.c",
line=line@entry=706,
function=function@entry=0x555555667668 <__PRETTY_FUNCTION
.8704> "set_coast") at assert.c:92
#3 0x00007ffff653cf12 in GI_assert_fail (
assertion=0x55555566704c "fval(r->terrain, SEA_REGION)",
file=0x555555666ed0 "/home/eressea/eressea/git/src/move.c", line=706,
function=0x555555667668 <
PRETTY_FUNCTION
.8704> "set_coast")
at assert.c:101
0000004 0x00005555555c5794 in set_coast (sh=0x555557046a50, r=0x5555570418c0,
rnext=0x5555570418c0) at /home/eressea/eressea/git/src/move.c:706
#5 0x00005555555c97e9 in sail (u=0x55555702f160, ord=0x555556f97910,
routep=0x7fffffffdb80, drifting=true)
at /home/eressea/eressea/git/src/move.c:1927
#6 0x00005555555ca5b5 in move_cmd (u=0x55555702f160, ord=0x555556f97910)
at /home/eressea/eressea/git/src/move.c:2179
#7 0x00005555555cb0b0 in movement ()
at /home/eressea/eressea/git/src/move.c:2447
0000008 0x00005555555b789c in process ()
#9 0x00005555555b8920 in turn_process ()
at /home/eressea/eressea/git/src/laws.c:4057
#10 0x000055555558562a in tolua_turn_process (L=0x555556d21920)
at /home/eressea/eressea/git/src/bindings.c:416
#11 0x000055555558566d in tolua_process_orders (L=0x555556d21920)
at /home/eressea/eressea/git/src/bindings.c

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008610)
Enno   
2019-10-27 19:59   

Die Region ist 0,0, ein Ozean. Einzige Einheit ist ein Mensch auf einem Langboot. Die Partei hat die Adresse "elf@eressea.de"

(0008611)
Enno   
2019-10-27 20:00   

Der Befehl der Einheit ist "NACH o"

(0008612)
Enno   
2019-10-27 20:02   

Aus den Indizien zu folgern ist das test_piracy.

(0008613)
Enno   
2019-10-27 20:06   

In move,c:1927 steht set_coast(sh, last_point, current_point); Beide Regionen sind Ebene (0, 0) - wie das? Oh, Korrektur: 0,0 war gar kein Ozean.

(0008614)
Enno   
2019-10-27 20:07   

Kann das an der Änderung neulich liegen, wo FOLGE zu weit fuhr?

(0008615)
Enno   
2019-10-27 20:10   

Die Tests haben Stürme nicht deaktiviert.

(0008617)
Enno   
2019-10-28 20:25   

Das lag sicher an Stürmen, jedenfalls kann ich mir das vorstellen. Ich habe die Tests erweitert, Stürme abgeschaltet, und set_coast verbessert.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2616 [Eressea] Schiffe kleinerer Fehler nicht getestet 2019-10-21 10:44 2019-10-22 21:31
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: d08a
Spiel: E2
Report: 1143
Zusammenfassung: FOLGEnde Schiffe enden in anderer Region als das Schiff, dem sie folgen
Beschreibung:

Ich habe eine Flotte, bestehend aus ca. 3 Dutzend Karavellen und fünf Drachenschiffen. Alle Schiffe haben den Befehl einer Karavelle zu folgen (FOLGE SCHIFF 90mt). Das hat bislang auch immer geklappt, d.h. die Flotte ist beieinander geblieben. Diese Woche jedoch habe habe ich als Endresultat, dass die Flotte sich aufgeteilt hat, was so nicht passieren sollte. ALLE Drachenschiffe stehen in einer Ozeanregion und ALLE Karavellen in einer anderen Ozeanregion (darunter auch das "Führungsschiff"). Die Reichweite der Drachenschiffe liegt - bedingt durch das Segeltalent der Schiffskapitäne - bei 6, die der Karavellen bei 5.

Schritte zur Reproduktion:

Befehle Runde 1141:
Alle Schiffe befinden sich in der Region 32,-8 (yh6jLu) und werden magisch beschleunigt.
Die Befehle des Führungsschiffs in Runde 1141 lauteten:
NACH W W W W W W W W W W
Alle anderen Kapitäne hatten die Befehle:
FOLGE SCHIFF 90mt
NACH W W W W W W W W W W

Auswertung 1142:
Alle Schiffe befinden sich in der Region 23,-8 (8n6dh6) - eigentlich sollten sie bis 22,-8 (rjri25) gesegelt sein! Warum sie nicht dorthin gesegelt sind, ist mir unklar. Im NR findet sich keine Meldung darüber, dass das Führungsschiff abgetrieben ist.
Die Befehle des Führungsschiffes in Runde 1142 lauteten:
NACH O O O O O
Alle anderen Kapitäne hatten die Befehle:
FOLGE SCHIFF 90mt
NACH O O O O O

Auswertung 1143:
Alle Karavellen befinden sich jetzt in Region 28,-8 (m9kevo), wie es auch zu erwarten war. Alle Drachenschifffe befinden sich jedoch in Region 27,-8 (nyqvLa). In Region 28,-8 (m9kevo) finden sich Durchreisemeldungen für alle Drachenschiffe.

Ich vermute aufgrund der Durchreisemeldungen in Region 28,-8 (m9kevo) und der um eins höheren Reichweite der Drachenschiffe, dass diese der Führungskaravelle gefolgt und dann (da noch ein Feld Reichweite übrig war) wieder um ein Feld zurück gesegelt sind (denn durch die Region ist das Führungsschiff ja ebenfalls gesegelt). Das ist aber nur eine Vermutung. Dagegen spricht, dass dieser Fall vorher bislang nie aufgetreten ist.

Zusätzliche Informationen:

Führungsschiff: 90mt
Kapitän Führungsschiff: 90mt
Drachenschiff: y69w
Kapitän Drachenschiff: y69w

Angehängte Dateien:
Notiz
(0008600)
Enno   
2019-10-22 19:06   

Auch bei einer neuen Auswertung sind in Report 1142 alle Schiffe in 23,-8:
Die DZS-4064 Sturmwoge (90mt) segelt von Ozean (32,-8) nach Ozean (23,-8).

(0008601)
Enno   
2019-10-22 19:59   
(Zuletzt bearbeitet: 2019-10-22 20:06)

Interessante Fakten, die ich im Bugreport nicht gefunden hatte: Auf der Karavelle liegt Sturmwind, und sie ist beschädigt, weshalb ihre Reichweite 9 Felder sein sollte, obwohl sie laut Befehlen 10 x NACH W segelt.

(0008602)
Enno   
2019-10-22 20:07   

Von Ozean (32,-8) nach Ozean (23,-8) sind es doch 9 Felder, das stimmt also?

(0008603)
Enno   
2019-10-22 20:10   

Zur ersten Aussage:

Alle Schiffe befinden sich in der Region 23,-8 (8n6dh6) - eigentlich sollten sie bis 22,-8 (rjri25) gesegelt sein! Warum sie nicht dorthin gesegelt sind, ist mir unklar.

Das ist, weil die führende Karavelle 12% beschädigt ist, und nur einer Reichweite von 9 Feldern hat. Es bleibt also nur die Frage, warum die Drachenschiffe in der Folgewoche in einer anderen Region ankommen, als die Karavelle? Dafür muss ich auf ein anderes Backup zurückgreifen.

(0008604)
Enno   
2019-10-22 20:22   

Oho, lustig. Das folgende Schiff hat Reichweite 6, und kalkuliert aus der Spur, die das Leitschiff gelegt hat, diese Route: NACH Osten Osten Osten Osten Osten Westen. Ich fürchte fast, da rächt sich, dass die Durchreise-Informationen keine Richtung haben. Wenn das Drachenschiff die Karavelle (Reichweite 5) eingeholt hat, segelt es in die nächste Region, in der das Schiff diese Woche war (also zurück), weil es noch Reichweite hat. Man sollte vielleicht anhalten, wenn man das Leitschiff erreicht hat.

(0008605)
Enno   
2019-10-22 20:58   

Doch, Quatsch. Das ist (zumindest intern) ein gerichteter Graph. Das sollte nicht stimmen, was ich eben gesagt habe. Hmm. Bin jedenfalls nahe dran.

(0008606)
Enno   
2019-10-22 21:05   

In der Region 1346324820, wo die Sturmwoge landet, steht ein at_shiptrail mit Richtung WEST. Wie kommt die da hin?

(0008607)
Enno   
2019-10-22 21:20   

Oh, die Dinger altern mit der Zeit, und das liegt da noch aus der Vorwoche, dmait Piraten es finden können. In der Vorwoshce ist das Schiff ja in die genau entgegengesetzte Richtung gefahren. Hui.

(0008608)
Enno   
2019-10-22 21:29   

Mit dem Kniff, dass man einfach nicht weiter fährt, wenn man das Schiff erreicht hat, klappt es offenbar. Das war ja einfach, auch wenn die Gründe kompliziert waren.

(0008609)
Enno   
2019-10-22 21:31   

So ganz wohl ist mir nicht dabei, dass es da Spuren aus zwei verschiedenen Wochen gleichzeitig gibt, und Tests habe ich auch nicht geschrieben, aber für diesen einen bekannten Sonderfall, in dem das nicht funktionert hat, klappt es jetzt jedenfalls.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2263 [Eressea] General kleinerer Fehler immer 2016-12-05 13:01 2019-10-22 18:57
Reporter: K 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.22  
    Zielversion:  
Partei: ovis
Spiel: E3
Report: 385
Zusammenfassung: Untoteneinheit können nicht bewachen
Beschreibung:

Von Spielern erschaffene Untoteneinheiten können (ohne Waffe) nicht bewachen. Da Monstereinheiten dies können und die Untoten auch ohne Waffen eine gewisse Gefährlichkeit beweisen halte ich dies für einen Bug.

Schritte zur Reproduktion:

Skelette der Ruhelosen (7uda) in Tal des Nagels (45, 10): 'BEWACHE' - Die Einheit ist nicht bewaffnet und kampffähig.

Kreaturen des Bösen (207z) in Pasa Dur (44, 10): 'BEWACHE' - Die Einheit ist nicht bewaffnet und kampffähig.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0006849)
Enno   
2016-12-11 11:39   

Das könnte an commit 5bb2dbfd oder (eher) 754ad78d liegen. Ich sehe es mir an.

(0006850)
Enno   
2016-12-11 11:54   

Es kann sein, dass nur Monster (also angehörige der Partei Monster) das dürfen. Untote sind zwar furchterregend, aber so ein Skelett alleine ist eigentlich ein Weichei. Ich werde mir aber die Details noch einmal anschauen, ehe ich da eine solide Behauptung aufstelle.

(0006851)
Enno   
2016-12-11 11:58   

Korrekt! Hier ist der Code, in can_start_guarding:

if (is_monsters(u->faction) || fval(u_race(u), RCF_UNARMEDGUARD))
    return E_GUARD_OK;
if (!armedmen(u, true))
    return E_GUARD_UNARMED;

Wenn die Partei die der Monster ist, oder die Rasse unbewaffnet bewachen kann (Drachen und so Zeug), dann kann man bewachen. Ansonsten braucht man eine bewaffnete Einheit (und das Talent für die Waffe).

Diese beiden Skelette haben keine Waffen.

(0006860)
Enno   
2016-12-11 15:35   

Es ist vom Spiel nicht gewünscht, dass unbewaffnete Skelette bewachen können. Monster haben, wie Du selbst beobachtet hast, eine Sonderregel.

(0006874)
K   
2016-12-17 23:11   

Leider kann man den Unbewaffnetstatus auch nicht einfach ändern, sie nehmen nichts an.

(0006875)
Enno   
2016-12-18 10:44   

Ich glaube, ein Waffentalent lernen tun sie auch nicht. Das klingt mir alles nicht mehr nach einem Bugreport, sondern nach einem Featurewunsch.

(0006876)
Enno   
2016-12-18 12:29   

Ich hatte eigentlich im Gefühl, dass beschworene Skelette nach einer Weile verschwinden, kann das Feature dazu aber nicht orten. Billig beschworene Kämpfer, die ohne Unterhalt zu verbrauchen ewig leben, das geht nun wirklich nicht. Ich werde also erst einmal schauen müssen, wieso die das ewige Leben besitzen.

(0006877)
Enno   
2016-12-18 12:31   

Zeit, das ich mir den Lebenszyklus von Spieler-Untoten mal genauer ansehe. Ob sie danach bewachen dürfen, kann ich noch nicht sagen.

(0006878)
K   
2016-12-18 13:20   

Nach meiner Erfahrung haben sie fixe (nicht allzu hohe) Talentwerte, lernen nichts (fallen also hinter normalen Spielereinheiten schnell zurück), geben nichts, nehmen nichts, vertreiben Bauern ... kein Unterhalt ist, in meinen Augen, das Einzige was sie rechtfertigt.

(0006880)
Enno   
2016-12-18 17:31   

https://github.com/eressea/server/blob/develop/src/randenc.c#L827
Monster-Rassen desertieren jede Runde mit 5% Wahrscheinlichkeit.

(0006881)
Enno   
2016-12-18 17:33   

NEIN!

Nicht alle Monster desertieren. Nur die, bei denen desert="yes" an der Rasse steht, also nur Schattenmeister und Schattendämonen. Skelette und andere Untote halten also für ewig.

(0008599)
Enno   
2019-10-22 18:57   

Ich habe mich entschieden: Skelette und Untote können unbewaffnet bewachen, aber sie desertieren dafür jetzt über die Zeit, wie stärkere Spieler-Monster es schon immer tun.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2613 [Eressea] Monster kleinerer Fehler nicht getestet 2019-10-04 10:09 2019-10-22 18:47
Reporter: Enno 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: 3.22  
    Zielversion: 3.22  
Partei: 0
Spiel: E2
Report: 1140
Zusammenfassung: Keine Vulkane in neuen Welten generieren
Beschreibung:

Der Inselgenerator im Editor sollte keine Vulkane erzeugen, wenn Inseln für neue Parteien gemacht werden, das macht die Startpositionen zu ungleich. Vulkane nur vom Spielleiter über explizites Terraforming erzeugen.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008598)
Enno   
2019-10-22 18:47   

Das scheint schon jetzt nicht so zu sein. Nichts zu machen.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2615 [Eressea] Schiffe schwerer Fehler nicht getestet 2019-10-20 12:52 2019-10-21 20:07
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.22  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion:  
Partei: ioen
Spiel: E2
Report: 1143
Zusammenfassung: Fusion von Schiffen funktioniert nicht korrekt (Schiffe sind nach übergabe im Bau)
Beschreibung:

Fusion von unbeschädigten fertiggestellten Schiffen mit dem neuen Flottenbefehl führt zu Flotten die im Bau sind, vermutlich weil die sollgröße (200) ungleich der ist größe (600) ist.
Erst die 3 beteiligten Schiffe und die befehle und unten das neue großschiff aus dieser Test AW

; - - - - - - - - - - - -
; An Bord von Trireme 'Weihnachtsbaum K' (xmas) Kap: 1688GE/2000GE(0%):
EINHEIT xmas; Weihnachtsmann [1,0$,Sxmas] hinten
LERNE AUTO Segeln
; - - - - - - - - - - - -
; An Bord von Trireme 'Silberflotte Loge' (eqtv) Kap: 103GE/2000GE(0%):
EINHEIT x0r3; Kapitän [10,179650$,Seqtv] kämpft nicht
Gib xmas 1 schiff
; - - - - - - - - - - - -
; An Bord von Trireme 'Silberflotte Loge' (h0Lz) Kap: 103GE/2000GE(0%):
EINHEIT i51k; Kapitän [10,179700$,Sh0Lz] kämpft nicht
; Gew: 1897.00GE Gehen: -1743.00GE/54.00GE
Gib xmas 1 schiff

Ergibt:
; - - - - - - - - - - - -
; An Bord von Trireme 'Weihnachtsbaum K' (xmas) im Bau (600/200):
EINHEIT xmas; Weihnachtsmann [1,0$,Sxmas] bewacht, hinten

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008594)
Enno   
2019-10-20 18:05   

Fehler gefunden und repariert. Dabei ist mir aufgefallen, dass shi->type->maxsize noch an anderen Stellen im Code statt ship_maxsize benutzt wird, z.B. bei MACHE, das muss ich mir mal genauer ansehen.

(0008595)
Enno   
2019-10-20 19:43   

Ja, MACHE hat auch noch Macken. Ich habe einen Test, der das zeigt, aber die Lösung ist noch nicht fertig.

(0008596)
Enno   
2019-10-21 19:48   

Ja, Schiffe bauen ist gut, aber Schaden reparieren überhaupt nicht, Die Schadensformel verstehe ich schon mal gar nicht.

(0008597)
Enno   
2019-10-21 20:07   

Damit habe ich es jetzt aber hoffentlich.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2096 [Eressea] General Feature-Wunsch nicht getestet 2015-04-28 17:56 2019-10-04 12:26
Reporter: K Rechnertyp:  
Bearbeitung durch: Xolgrim Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ovis
Spiel: E3
Report: 303
Zusammenfassung: erlaube GIB Person zwischen Parteien
Beschreibung:

Das Spiel ist hinreichend fortgeschritten das dieser Befehl allein der Konsolidierung von Allianzen diehnt. Eigentlich tote Mitglieder werden nichtmehr unnötig mitgeschleppt weil ihre Kapitäne, Bergarbeiter etc. zu wertvoll sind.

  • möglichst unlimitiert pro Runde
  • evtl. rassenübergreifend (Migranten oder Rasse der neuen Partei)
Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005795)
Enno   
2015-04-29 12:12   

Ist das ein FEaturewunsch für E3? Weil das für E2 schon geplant ist.

(0005796)
Xolgrim   
2015-04-29 13:53   

Spiel: E3
Report: 303
Ja Enno das deutet für mich schon arg nach einem Wunsch für E3 hin ;)

(0005797)
Kitaktus   
2015-04-29 17:54   

Bei rassenübergreifenden Übergaben müsste man sich ein paar Gedanken machen über Talente und Rekrutierungskosten, damit da kein Mißbrauch betrieben wird.

Rassen bei der Übergabe beizubehalten zerstört sehr viel Flair. Wozu habe ich Zwerge, wenn sich jeder irgendwo Zwergenbergleute besorgen kann.
Rassen zu konvertieren ist nicht ganz trivial (Rekrutierungskosten, Talentboni, Dämonen). Besonders wenn man Hin- und Herübergaben einbezieht kann man da viel Unfug anstellen. Ich wandle meine Trollarmee für den Transport in kleine Zwerge um. Wenn sie wieder an Land sind, verwandle ich sie zurück. Der Taktiker ist mal Zwerg, mal Elf, je nachdem ob er im Gebirge oder im Wald kämpfen soll. Dämonen sind nur in der Kampfwoche hungrige Bauernfresser, ansonsten sind sie Elfen und fördern das Baumwachstum...

(0005799)
K   
2015-04-30 11:45   

Gute Punkte, ein einfacher Workaround wäre vieleicht nicht einzelne Personen/Einheiten zu übergeben, sondern eine Übergabe aller Einheiten inkl. Löschung der Ursprungspartei?
So bleiben die Personen/Einheiten für die Allianz erhalten ohne Missbraucht mit hin und her treiben zu können.

(0005801)
Xolgrim   
2015-04-30 12:01   

Könnte man eventuell auch über einen verlust von Personen und oder Talentstufen bei der Übergabe (und umwandlung in die Zielrasse) regeln. Wobei das schon eine komplexere Aufgabenstellung wird.

(0008589)
Xolgrim   
2019-10-04 12:26   

Nach dem ende von E3 nicht mehr von Belang.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2062 [Eressea] General kleinerer Fehler nicht getestet 2015-01-04 12:08 2019-10-03 21:55
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: [E2] engl. Modus // Ring of Power - Ring der Macht
Beschreibung:

Kann es sein das der Ring (nicht) funktioniert?

Die Frage stellt sich mir nach folgendem Gedankengang:

Ein Zauberer zaubert ohne Level. Er hat nicht genügend Zauberkomponenten und produziert folgende Fehlermeldung:

Unit (ycxy) has insufficient components to cast Create Iron Golems on level [ x ].

Soweit Ok.
Laut Beschreibung des Ring's wird das Level/Stufe erhöht ohne das sich die Kosten erhöhen. In der Fehlermeldung wird darauf aber nicht hingewiesen. Das wäre ja eigentlich auch ok...
Aber wie will/kann ich das als Spieler überprüfen... Es gibt eine Handvoll Zauber an derem Ergebnis ich erkennen kann ob der Ring funktioniert.

Kann/Müsste es da nicht auch einen Hinweis auf den Ring geben?! Alleine schon um überprüfen zu können ob er funktioniert hat...

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005625)
CTD   
2015-01-05 09:41   

Wäre sicher nett, aber das würde bei der Fehlermeldung wieder zu Verwirrung wegen den Materialien führen, denn man braucht für den zusätzlichen Level aus dem Ring keine zusätzlichen Materialien. Von daher ist die Stufe ohne Ring bei der Fehlermeldung schon OK. Möglicherweise kann man die effektive Zauberstufe (die sich ja je nach Spiel auch noch unterscheidet) auch noch angeben.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2610 [Eressea] General kleinerer Fehler nicht getestet 2019-09-21 22:50 2019-10-03 21:55
Reporter: K Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: wird nicht behoben  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: turt
Spiel: E2
Report: 1139
Zusammenfassung: Mikromanagement von TREIBE verringern
Beschreibung:

Mit TREIBEN kann man, im Gegensatz zu UNTERHALTEN, den Bauern alles Silber wegnehmen. Dies ist allerdings nicht immer gewünscht, z.B. möchte man sie evtl. nicht verhungern lassen. Dies erfordert regelmäßige Kontrolle des Regionssilbers (Mikromanagement).

Wünschenswert wäre ein Befehlszusatz der das Verhungern der Bauern verhindert ("TREIBEN gnädig").

Oder vielleicht eine Gesamtmengenangabe ("TREIBE 1000000") die Runde für Runde aufsummiert/absubtrahiert wird wie es schon beim Burgenbau möflich ist ('MACHE 50 Burg' baut immer nur einen Turm egal ob mehr Steine da sind oder ob es mehrere Runden dauert).

Schritte zur Reproduktion:
Zusätzliche Informationen:

TREIBEN ist für einige Völker die grundlegende Silberquelle und sollte nicht noch unnötig unhandlich gemacht werden. Die Notwendigkeit von Waffe, Waffentalent und das Nichtlernen durch Anwendung macht es ohnehin schon 'sperriger' als den gedankenlosen Selbstläufer UNTERHALTEN.

Angehängte Dateien:
Notiz
(0008578)
Bruck   
2019-09-24 21:33   

TREIBE [betrag] geht laut wiki schon: https://wiki.eressea.de/index.php/TREIBE Selber aber noch nicht probiert.

So ein TREIBE gnädig fände ich aber auch toll. (TREIBE Überschuss??) Könnte aber spannend werden wenn man alle Interaktionen abdecken will. (Ich nenne mal: Bauernwanderung, Vermehrung, Rekrutieren (Siehe auch den Bug den ich eigentlich aufmachen wollte und warum ich eigentlich hier bin) , Magie, Handel, Unterhalten und andere TREIBE ohne Gnade...

(0008579)
Xolgrim   
2019-09-25 19:30   

Treibe 100000 Silber teibt aber 100.000 Silber pro Runde ein, genau wie Unterhalte 100000. Das ist analog zu Mache 100 Schwert. Ich mache BIS ZU XXX K wollte es analog zu Mache 5000 Burg XYZ bei dem die Festung zur Zitadelle ausgebaut wird, auch wenn das mehrere WOchen dauert. Dort wird die angegebene Zahl jede Woche um den gebauten betrag reduziert. Das was ihr beide wollt lässt sich auf zwei verschiedene weisen mit Vorlage mit einem einzeiler regeln. ff2 tools hat da ganz sicher auch schon Dinge eingearbeitet.

  1. Variante:
    //#after 5 { MACHE WAS ANDERES }
    TREIBE 20000

Hier werden 5x20.000 Silber eingetrieben und dann was anderes gemacht, das ist dem Mache von Burgen schon sehr ähnlich. Ich persönlich finde variante 2 entspannter

2.Version:
// #if region.Silber>200000 { TREIBE 44000 Silber } else { LERNE Steuereintreiben }
Hier geht ganz sicher nichts kaputt, auch dann nicht wenn die Bauernzahlen sinken oder jemand anderes massiv in das Regionssilber eingreift.

(0008580)
Enno   
2019-09-29 17:14   

Ich sehe da auch keine große Notwendigkeit, das bestehende System zu verändern, noch dazu für E2, wo sich die Spieler seit Jahren damit abgefunden und darauf eingestellt haben.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2590 [Eressea] General kleinerer Fehler nicht getestet 2019-06-09 17:26 2019-10-03 21:55
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:
2574 [Eressea] General kleinerer Fehler nicht getestet 2019-04-03 18:29 2019-10-03 21:55
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:
2542 [Eressea] General Feature-Wunsch nicht getestet 2019-01-05 15:24 2019-10-03 21:55
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.21  
    Zielversion: 3.21  
Partei: 0
Spiel: E2
Report: 1105
Zusammenfassung: Neues Schiff "Galeone"
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.

(0008534)
Enno   
2019-08-17 22:47   

Ich habe mal eine Galleone implementiert, mehr dazu wenn das Release klar ist.

(0008538)
Enno   
2019-08-21 18:22   

Statt einer Arhce ist es eine Galeone gworden. Die Ankündigung spricht noch von einer "Galleone", mit zwei L, das war aber offenbar verkehrt.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2541 [Eressea] General kleinerer Fehler nicht getestet 2019-01-05 15:16 2019-10-03 21:55
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:
2512 [Eressea] General kleinerer Fehler nicht getestet 2018-11-04 18:11 2019-10-03 21:55
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:
2483 [Eressea] General Unschönheit immer 2018-09-03 17:11 2019-10-03 21:55
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:
2471 [Eressea] General kleinerer Fehler N/A 2018-08-05 06:57 2019-10-03 21:55
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:
2422 [Eressea] General kleinerer Fehler nicht getestet 2018-02-24 09:21 2019-10-03 21:55
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:
2316 [Eressea] General Feature-Wunsch nicht getestet 2017-03-31 20:29 2019-10-03 21:55
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: bestätigt Produktversion: 3.11.2  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ufo
Spiel: E2
Report: 1018
Zusammenfassung: DEFAULT Befehl Syntax
Beschreibung:

Meine Einheit tjcu hat in Runde 1017 diesen Befehl gegeben:
DEFAULT LERNE Bergbau

Im Report 1018 hat sie nun den Befehl LERNE (ohne Talent). DEFAULT sollte alle folgenden token verarbeiten, nicht nur das erste, sonst kommt man bei etwas wie DEFAULT "MAKE "lunar sword"" in Fisimatenten mit doppelten Anführungszeichen.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007199)
meer   
2017-05-14 17:00   

In den Regel wird erklärt, wie man mit den doppelten Anführungszeichen umgehen kann: Siehe https://wiki.eressea.de/index.php/DEFAULT
Allerdings benutze ich DEFAULT auch viel und fände das gewünschte Feature auch nett.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2081 [Eressea] General Feature-Wunsch N/A 2015-03-01 09:26 2019-10-03 21:55
Reporter: K Rechnertyp:  
Bearbeitung durch: CTD Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: bestätigt Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: qy7x
Spiel: E3
Report: 295
Zusammenfassung: Gebäudeunterhalt wahlweise von Regions- oder Gebäudebesitzer bezahlbar machen
Beschreibung:

Mit der letzten Änderungen bezahlen nun Regionsbesitzer für leere Gebäude.

Es wäre schön wenn man erreichen könnte das sie optional auch zahlen wenn die Gebäude (durch eine andere Partei) besetzt ist.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005693)
CTD   
2015-03-02 09:12   

Die Idee ist nicht schlecht, aber wer bestimmt das? Besitzer ist ja derjenig im Gebäude, der müsste dann mit einem Befehl die Kontrolle abtreten. Vom logischen und sicher auch vom Verhalten her wäre es aber besser wenn all Gebäude immer dem Regionsbesitzer gehören, und er es anderen erlaubt sie zu nutzen. Dann könnten wir auch gleich das @Bezahle nicht xyz oder @Gib xyz kommando dafür nutzen können, wenn der Besitzer nicht will wird geschaut ob es jemandem in dem Gebäude gibt der dann zahlen muss. Das würde aber bedeuten das der Regionsbesitzer alle Gebäude erstmal besitz, auch wenn jemand anderes drin ist und die gebaut hat. Das dürfte vieleicht auch nicht im Interesse aller sein. Aber ja, gerade für Leuchttürme wäre das schon schön wenn es so was gäbe. Zumal man das dann auf alle Gebäude ausweiten kann, da es dann auch für Bergwerke und so Sinn macht.

(0005695)
K   
2015-03-02 11:34   
(Zuletzt bearbeitet: 2015-03-02 11:36)

Oder das erst der Gebäudeinsasse zu Kasse gebeten wird und sollte dieser nicht zahlen können (oder wollen per BEZAHLE NICHT) der Regionsbesitzer die Rechnung bekommt (hoffentlich rechtzeitig)?

(0005702)
Thoran   
2015-03-16 10:09   

Sollte der Gebäudebesitzer ein BEZAHLE NICHT befohlen haben, dann sollte der Regionsbesitzer für dieses Gebäude allerdings auf keinen Fall zur Kasse gebeten werden, denn das würde BEZAHLE NICHT ja hinfällig machen.

BeispieL: Man hat nicht genügend Silber in der Region, um die Gebäude zu bezahlen, wohl aber genügend, um alle Bewohner zu ernähren und das Silber liegt beim Regionsbesitzer. Dann will ich doch als Gebäudebesitzer z.B. eines Steinbruchs explizit nicht bezahlen, damit der Regionsbesitzer nur das Silber für den Unterhalt der Bewohner übernimmt.

(0005705)
CTD   
2015-03-19 23:23   

Ich habe noch mal darüber nachgedacht, und der einzig sinnvoll Weg ist das alle Gebäude einer Region immer dem Regionsbesitzer gehören, und er auch den Unterhalt zahlt, ausser er schaltet es mit @BEZAHLE NICHT XYZ aus, oder er übergibt für diese Runde das Kommando an eine Einheit (ABC) in dem Gebäude, sinnvollerweise dann via @GIB ABC KOMMANDO XYZ, was jedoch einigen Imlementierungsaufwand darstellt (wenn auch nicht so groß) und nach Aktivierung dafür sorgt das der Regionsbesitzer erstmal alle anderen Gebäude besitzt (und auch Zerstören / Abschalten kann). Hier wäre dann noch mal eine Aktion der Spieler nötig.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2063 [Eressea] General kleinerer Fehler nicht getestet 2015-01-04 12:24 2019-10-03 21:55
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:
2044 [Eressea] General kleinerer Fehler immer 2014-11-17 11:50 2019-10-03 21:55
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: bestätigt Produktversion: 685  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: cbc
Spiel: Deveron
Report: 30
Zusammenfassung: "Hohe Kunst der Gaukelei" sinnlos in Deveron?
Beschreibung:

Ich habe die vergangenen Woche mal den Zauber "Hohe Kunst der Gaukelei" getestet. Dieser scheint keinerlei erkennbare Auswirkungen zu haben: weder verdient der zaubernde Magier Silber, noch erhöht sich die Silbermenge der Region noch verändert sich die Bauernzahl. Einzig und allein ein Regionseffekt wird angezeigt ("Es herrscht eine fröhliche und ausgelassene Stimmung.").

In E2 hat der Spruch das Unterhaltungslimit in einer Region verdoppelt. In Deveron hingegen ist das Unterhaltungslimit einer Region sinnlos, denn es gibt ja keine Möglichkeit mehr, durch Unterhaltung Silber zu verdienen. Das ist ja durch die Steuereinnahmen des Regionsbesitzers ersetzt worden. Diese haben sich aber in der verzauberten Region nicht erhöht.

Schritte zur Reproduktion:
Zusätzliche Informationen:

AW 29: Hohes Lied der Gaukelei durch Einheit nx89 in Setutvul (id: v99kzc) gezaubert
AW 30: Regionseffekt wird angezeigt, sonst keine Effekte

Angehängte Dateien:
Notiz
(0005497)
CTD   
2014-12-09 14:48   

Sinnvoll für E3/E4 wäre wenn der Zauber dort z.B die Moral der Region erhöht, wenn das von seiten der Burg noch möglich ist. Dazu sollte er vieleicht etwas teurer werden, denn das wäre schon ein großer Vorteil, aber sicher recht stimmig.

(0005498)
Enno   
2014-12-09 14:52   

Keine schlechte Idee, das.

(0005499)
Thoran   
2014-12-09 15:06   

Klingt auch für mich recht stimmig - allerdings weiss ich nicht, wovon genau der Anstieg der Moral abhängt (die Berechnung der Obergrenze ist klar).

Bisher ist mir bekannt, dass die Moral bei von Halblingen regierten Regionen schneller ansteigen soll (kann ich, obwohl selber Halbling, aufgrund der begrenzten Datenlage, nicht beurteilen), dass die Moral aber generell zufällig steigt.

Unklar ist mir auch noch, warum man dann den Zauber verwenden sollte, denn die Moral eilt (zumindest bisher) dem Ausbau der Burgen voraus - oder wenigstens nicht lange hinterher. Wenn ich mich recht erinnere, dann waren meine Einkünfte bisher eher durch die Burgengrösse beschränkt als durch den hälftigen Moralwert (Ausnahme war glaube ich ganz zu Anfang bei der Errichtung eines Wachturms - aber da hat man sowieso weder Silber zur Magierausbildung noch Zauber auf höherer Stufe).

So bliebe dann als einzige sinnvolle Anwendung das "Aufpäppeln" von durch Krieg oder Besitzerwechsel demoralisierten Regionen. Aber OK: für diesen Einsatzzweck ist der Zauber dann wirklich gut und wohl tatsächlich zu günstig (zumindest dann, wenn er die Moral direkt erhöht und nicht die Wahrscheinlichkeit auf einen Anstieg erhöht).

(0005500)
CTD   
2014-12-10 10:58   

Ich habe mal in den Code geschaut, und der Spruch erhöt bereits die Chance das die Moral in einer Runde aufsteigt um 20%. Das ist nicht viel und durch die Wahrscheinlichkeiten durch den Spieler kaum wahrnehmbar. Vorschlag: Erhöhung auf 25% und Reduziereung der Moralcooldownzeit um eine Runde.

Die Moral sollte auch ein wenig angepasst werden, so das es keine "vorauseilende" Maoralsteigerung mehr gibt. Sobald der Turm zur Burg wird steigt die Moral um 1 Punkt von 4 auf 5, und ca. 10 Runden später dann auf 6 (wenn der Turm schon 12 Ruden alt ist) Das ist gerade für neue Spieler verständlicher, auch wenn es die Übergabe von Regionen etwas nachteiliger gestaltet. Hier könnte man das Moral-minus auf eine Stufe reduzieren, statt auf 2. Das würde dem Spruch dann auch gleich viel wichtiger machen, und er wäre nicht nur für den eher selteten Fall das man Regionen (zurück)erobert.

(0005501)
Enno   
2014-12-10 12:59   

Danke für's nachgucken, damit habe ich es jetzt auch gefunden. Was du mit der vorauseilenden Moralsteigerung meinst, weiss ich nciht recht, aber ich habe die Moralregeln auch nicht mehr im Kopf, und müßte die selber aus dem Code zurückverfolgen. Eine Steigerung des Zauber-Effektes halte ich für in Ordnung, gerne auch noch drastischer. Also 50%, oder gleich die Moral um eine Stufe heben. Zauberwirkungen, die man nicht deutlich sehen kann, sind regelmäßig Grund für Bugreports die keine sind, und viel Arbeit beim Nachprüfen kosten (Magieresistenz ist ein ganz blöder Fall von so etwas).

Implementationstechnisch wäre es toll, die Moral-Regeln in ein eigenes Modul zu packen (morale.c), und mit Unit-Tests zu covern. Das sollte ich evtl. selber machen, um dabei die Regeln neu zu entdecken.

(0005502)
CTD   
2014-12-10 16:53   
(Zuletzt bearbeitet: 2014-12-10 16:57)

Man bekommt pro Moaralpunkt (0-10) je 0,5% des Regionssilbers.
Pro Burgenstufe kann man 2 Punkte Moral "nutzen" Bei einem Turm also 4, macht 2%.
Nur das die Moral eben nicht bis auf 4 steigt, sondern bis auf 6. Damit habe ich zwar sofort die 3% Einnahmen wenn ich eine Burg baue, aber die Moral steigt weiter auf 8, das ist nicht sehr konsistent. Zumal die Moral bei eine Festung und Zitadelle dann gleich ist, (je 10, weil 10 halt max.) aber ich je nach Burg unterschiedlich viel Silber verdiene. Wachtürme sind noch mal anders, da steigt die Moral nur eine Stufe weiter (also auf 3 bei einem 10er Wachturm, statt auf 4 wie bei einer 10er Steinburg) bei beiden gibt es aber die selben Einnahmen.
Viel sinnvoller wäre da die einfach Regel Silber=0,5% pro Moralpunk, unabhänig von der Burg, und Moralmax = Burgengröße mal 2. Das ist einfach und verständlich ohne irgendwelche Ausnahmen.

Ach ja, beim Aufstieg gibt es noch den Cooldown von 2 Runden, das heist es kann frühestens 3 Runden nach dem Moralaufstieg wieder einen weiteren geben.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1986 [Eressea] General schwerer Fehler nicht getestet 2014-01-05 21:03 2019-10-03 21:55
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:
1944 [Eressea] General Feature-Wunsch N/A 2012-09-24 10:27 2019-10-03 21:55
Reporter: Zod Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: bestätigt Produktversion: 3.6  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: 0
Spiel: E2
Report: 944
Zusammenfassung: "STOP" in ROUTE-Befehl
Beschreibung:

Der Befehl ROUTE wird ja gerne nicht nur für Kreisrouten und ähnliches benutzt, sondern auch für längere Wege.
Es wäre evtl. sinnvoll, eine STOP-Option zu haben, analog zu PAUSE aber dass die zurückgelegten Wegabschnitte hinter STOP nicht wieder angefügt werden, sondern wegfallen. Wird STOP erreicht, sollte der DEFAULT-Befehl wieder eingesetzt werden.
Bzw. alternative Variante: STOP funktioniert wie PAUSE, aber wird beim erreichen nicht automatisch an das Ende gesetzt sondern die Abarbeitung der ROUTE bleibt unterbrochen bis der Spieler eingreift(hat den Nachteil, dass bei nicht bemerktem STOP kein langer Befehl ausgeführt wird, die Einheit wartet einfach und tut nichts).

Um diesen Effekt zu erreichen behelfe ich mir derzeit mit folgendem Workaround:
ROUTE SW SW SW SW PAUSE PAUSE NO NO NO
Bei erreichen von PAUSE setzt der Eressea-Server zwar ein PAUSE an das ende, das andere bleibt aber am Anfang stehen, und Magellan quittiert das mit "Fehler in Bewegungsbefehl" ... damit sieht man dass ein Eingreifen erforderlich ist.
Aber das ist eigentlich nur ein ausnutzen nicht dokumentierter Features, damit nicht ganz sauber.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0004996)
argelas   
2012-09-30 14:28   

Das mit dem Defaultbefehl könnte schwierig werden, ist der nicht bei ner Route auch Route? Ansonten wäre das sicher ne gute Sache für diejenigen die keine Skripte nutzen.

(0005003)
Enno   
2012-10-22 01:14   

Fuer Wuensche bleibt mir momentan nicht genug Zeit, glaube ich...

(0005882)
Bruck   
2015-06-20 12:26   

Das Defaultproblem könnte man vieleicht umgehen wenn der STOP Befehl die DEFAULT "" Befehl Routine verwendet? Mit der Syntax:

ROUTE .... STOP "Defaultbefehl"

(nur falls der Zeit bug irgendwann mal behoben sein sollte ;) )

(0005883)
Enno   
2015-06-21 14:44   

Ich schlage vor wir nennen das HALT, weil es dann eine einbuchstabige Abkürzung gibt die nicht mit SÜDEN kollidiert.

(0006116)
Enno   
2015-09-06 21:06   

Vielleicht ein gutes Feature für Version 3.7?



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1658 [Eressea] General Feature-Wunsch immer 2009-11-04 23:55 2019-10-03 21:55
Reporter: Ompfjaeger Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: bestätigt Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ompf
Spiel: E3
Report: 22
Zusammenfassung: Keine Meldungen bei Alianzaustritten Eintritten
Beschreibung:

Ich Vermisse eine Meldung, wenn es in der eigenen Alianz zu Ein und Austritten kommt.
Es wäre schön, wenn dies im NR möglichst übersichtlich vor den Ereignissen geschehen könnte.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0007481)
Enno   
2017-09-04 22:24   

Das betrifft alle Aufrufe von setalliance() in alliance.c, denke ich.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2612 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2019-09-29 17:17 2019-09-29 18:30
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.22  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: 0
Spiel: E2
Report: 0
Zusammenfassung: Störe astrale Integrität funktioniert nicht wie beschrieben
Beschreibung:

Beschreibung: Dieser Zauber bewirkt eine schwere Störung des Astralraums. Innerhalb eines astralen Radius von Stufe/5 Regionen werden alle Astralwesen, die dem Zauber nicht wiederstehen können, aus der astralen Ebene geschleudert. Der astrale Kontakt mit allen betroffenen Regionen ist für Stufe/3 Wochen gestört.

Entweder verstehe ich das falsch, oder da wird nie jemand aus den Regionen geworfen. (Im Code ist trl immer NULL). Nur das mit dem Kontakt stören, das sollte klappen.

Schritte zur Reproduktion:

Das ist eventuell so ein "Hirntöter in die Realwelt schicken" Zauber, die sind gefährlich. Traue ich mich, das zu reparieren?

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008581)
Enno   
2019-09-29 17:41   

Oh, noch besser. Es gibt da einen Crash. Sicher seit meienr letzten Änderung im Zaubercode :-(

(0008582)
Enno   
2019-09-29 17:46   

Ist wohl nur im Entwicklungsbranch kaputt, nicht in der aktuellen Version.

(0008583)
Enno   
2019-09-29 18:30   

ok



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2611 [Eressea] (Keine Kategorie) kleinerer Fehler nicht getestet 2019-09-22 14:22 2019-09-22 16:31
Reporter: Tokahe 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.22  
    Zielversion:  
Partei: kr51
Spiel: E2
Report: 1139
Zusammenfassung: Passwort mit Sonderzeichen funktioniert nicht
Beschreibung:

Meldung per Email erhalten von Michael Lenssen (@Tokahe):

NMR trotz verarbeiteter Befehle

Guten Morgen,

diese Woche hatte ich den seltsamen Effekt, daß meine eingeschickten Befehle zwar verarbeitet wurden. Unter Fehlern und Hinweisen stand dennoch, daß ich keinen Zug abgegeben habe. Ich bin mir nicht sicher, ob das Auswirkungen hat, aber bevor dadurch der Zähler für die NMRs gestartet wird, wäre mir recht, wenn einer von euch darüber gucken könntest.

Danke,

Tokahe

Schritte zur Reproduktion:
Zusätzliche Informationen:

Ob das der Grund ist, weiß ich nicht. Als Besonderheit wäre zu erwähnen,
daß ich vorletzte Woche in Urlaub war und Fiete, mein Vertreter, bei der
Rückgabe ein neues Passwort eingegeben hat. Das Passwort war komisch, es
bestand nur aus für mich nicht einzugebenden Sonderzeichen. Ohne die
Autoübernahme des Passworts durch Magellan hätte ich wahrscheinlich auch
Probleme gehabt. Auf jeden Fall ändere ich diese Woche das Passwort wieder.

Angehängte Dateien:
Notiz
(0008573)
Enno   
2019-09-22 14:25   

Was mich noch interessieren wird: In welcher Woche (Reportnummer) hat Fiete das Passwort geändert, und wie lautete es ursprünglich? (Kommentar mit Passwort am besten als Privat markieren).

(0008574)
Enno   
2019-09-22 14:30   
(Zuletzt bearbeitet: 2019-09-22 14:31)

Also, erst einmal sieht es so aus, als wenn das Müllpasswort vom Server in der Tat akzeptiert wird. Wieso hat die Partei dann einen NMR?

Update: Oh, weil ich zum schnelleren debuggen den Passwort-Check überbrückt hatte, und jedes Passwort akzeptiert wurde. 8-)

(0008575)
Enno   
2019-09-22 14:39   

Wir kommen wohl nicht drum herum, dass ich das altes Passwort wiederherstelle.

(0008576)
Enno   
2019-09-22 15:26   

Oh. Ich sehe da etwas: In Runde 1138 hat die Partei den PASSWORT Befehl ohne Argumente gegeben. Da sollte sie iein zufälliges Passwort kriegen, keinen Schrott.

(0008577)
Enno   
2019-09-22 16:31   

Bug ist gefunden und repariert.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2607 [Eressea] Reportformat Fehler im Text nicht getestet 2019-09-11 18:40 2019-09-21 22:22
Reporter: Thoran Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: d08a
Spiel: E2
Report: 1137
Zusammenfassung: Leerzeichen fehlt im NR bei Auflistung der Schemen
Beschreibung:

Mir fällt gerade durch Zufall auf, dass in der Auflistung der Schemen einer Astralraumregion im NR Leerzeichen fehlen, nämlich hinter dem Teilstring "Schemen der Regionen" sowie vor dem Teilstring "sind erkennbar".

---snip---
Schemen der RegionenPigifal (12,-17), Burgogúpês (12,-18), Setsacilfan
(11,-16), Rattir (11,-17), Howards End (10,-15), Dandat (10,-16), Giber
(10,-17), Luhn (9,-15), Vyrur (9,-16), Dutevetil (9,-17), Düsterland (8,-15),
Schwertelfelder (8,-16)sind erkennbar.
---snap---

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008569)
Enno   
2019-09-20 18:33   

Formatieren von Listen ist immer schon ein Problem gewesen, da gibt es in jeder Sprache andere Regeln, was Kommas und andere Trenner (wie "und") angeht. Ich bräuchte da so etwas wie http://icu-project.org/apiref/icu4j/com/ibm/icu/text/ListFormatter.html - vielleciht löse ich das also aus diesem Anlass mal grundsätzlich.

(0008570)
Enno   
2019-09-20 19:47   

Lösung auf Stack Overflow gepostet, wo jemand vor Jahren die gleiche Frage hatte:
https://stackoverflow.com/questions/43081112/localization-of-lists/58033018#58033018

(0008571)
Enno   
2019-09-21 20:47   
(Zuletzt bearbeitet: 2019-09-21 20:47)

Meine Implementation in C schient auch zu funktionieren:

Schemen der Regionen Pigifal (12,-17), Burgogúpês (12,-18), Setsacilfan
(11,-16), Rattir (11,-17), Howards End (10,-15), Dandat (10,-16), Giber
(10,-17), Luhn (9,-15), Vyrur (9,-16), Dutevetil (9,-17), Düsterland (8,-15)
und Schwertelfelder (8,-16) sind erkennbar.
(0008572)
Enno   
2019-09-21 22:22   

Mein neuer Code funktioniert ganz prima, den werde ich noch an anderen Stellen benutzen.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2605 [Eressea] NACH/ROUTE kleinerer Fehler immer 2019-09-03 08:36 2019-09-15 20:33
Reporter: EON Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: gLod
Spiel: N/A
Report: 1136
Zusammenfassung: Pro 2 Pferden sollte ein Wagen genutzt werden können, egal ob die Einheit mit den Pferden reiten kann
Beschreibung:

Eine Einheit ohne Reittalent kann pro Person ein Pferd führen, aber keine Wagen anhängen auch wenn 2 oder mehr Pferde geführt werden.
Eine Einheit mit Reittalent kann 2*Reittalent*Personen Pferde reiten, halbsoviel Wagen wie Pferde anhängen und sich zwei Felder bewegen.
Die gleiche Einheit mit Reittalent kann 4*Reittalent*Personen+Personen Pferde führen und sich ein Feld weit bewegen, dann aber nicht halbsoviel Wagen wie Pferde nutzen.

Aus meiner Sicht wäre es schöner, wenn man immer Anzahl Pferde/2 Wagen anhängen könnte, egal ob man reitet oder die Pferde führt und egal ob man reiten kann oder nicht.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008556)
Enno   
2019-09-10 18:47   

Ich verstehe die Frage nicht, und brauche mal ein Beispiel für ein Szenario, das momentan nicht geht, aber in Zukunft gehen soll.

(0008557)
Xolgrim   
2019-09-11 22:42   
(Zuletzt bearbeitet: 2019-09-12 19:21)

2 Personen T1 Reiten können mit 4 Pferden (und 2 Wagen) 2 Regionen reiten (2 Personen x 2 Pferde)
2 Personen T1 Reiten können 8 Pferde und 4 Wagen 1 Region weit führen (2 Personen x 4 Pferd)
2 Personen T1 Reiten können 10 Pferde 1 Region weit führen (2 Personen x 4 Pferd und JEDE Person kann, egal ob sie reiten kann oder nicht, 1 Pferd 1 Region weit führen) und dabei maximal 4 Wagen mit sich führen.

Wagen benötigen das Talent reiten. Das eine Pferd, welches JEDE Person mit sich führen kann, benötigt das Talent Reiten nicht. Daher kann man aktuell mit obigem Beispiel eben nicht 10 Pferde und 5 Wagen 1 Region weit führen.

(0008558)
Enno   
2019-09-12 22:39   

Ich finde wie EON, dass es einfacher ist, wenn man pro zwei Pferde, dei man dabei hat, einen Wagen mitführen darf, ob man nun ein Talent hat oder nicht, und werde das so umsetzen.

(0008562)
Enno   
2019-09-15 20:33   

Ich habe mal reichlich Tests geschrieben, auch für Trolle, und das Verhalten passt jetzt.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2608 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-09-14 21:29 2019-09-15 14:26
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21.1  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21.1  
    Zielversion: 3.22  
Partei: wiki
Spiel: E2
Report: 1138
Zusammenfassung: Fehler bei Partei, die an NMR stirbt
Beschreibung:

Diese Woche ist die Partei cwz aus dem Spiel ausgeschieden. In meinem Report steht:

Achtung: Clan wagemuter Zwerge (cwz) hat seit 5 Wochen keine Züge
  eingeschickt und könnte dadurch in Kürze aus dem Spiel ausscheiden.

Das sollte diese Woche vielleicht dann nciht da stehen, sondern eine "ist ausgeschieden" Meldung.

Außerdem taucht er noch in der Statusmeldung auf:

Wir helfen Clan wagemuter Zwerge (cwz) (ALLES)

In den Adressen ist er aber nicht mehr, und seine Einheiten sind auch alle verschwunden. Allerdings ohne dass sie ihren Verbündeten die restlichen Gegenstände übergeben haben! Betrug!

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008560)
Enno   
2019-09-15 09:06   

Eine Neuauswertung kommt für die zwei Parteien, die diese Woche gestorben sind, nicht in Frage. Aber eine manuelle Reparatur könnte Spaß machen, wenn ich sie komplett als one-off Skript in Lua schreiben kann.

Die Idee sieht so aus: Altes Datenfile vom Backup laden, und für die beiden Parteien eine Liste machen, welche Gegenstände sie in welcher Region haben. Dann aktuelles Datenfile laden, eine "neue" Partei mit den selben HELFE-Stati machen, ihr in jeder Region aus der Liste eine Einheit schaffen, und der alle Gegenstände geben. Partei stirbt in der Folgewoche, Gegenstände werden verteilt (vorausgesetzt, der ursprüngliche Bug ist repariert).
Das kann ich hoffentlich alles in einem Einmal-Skript machen, ohne am Code vom Server ändern zu müssen. Nur Allianzen kann man evtl. noch nicht im Skript abfragen. Die neue Partei muss ja die selben wie die alte haben.

(0008561)
Enno   
2019-09-15 14:26   

Fehler ist repariert, und ich werde einen Eingriff in die Daten machen, um den Schaden zu mitigieren.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2393 [Eressea] NACH/ROUTE kleinerer Fehler nicht getestet 2017-12-10 15:55 2019-09-10 22:01
Reporter: Falathar Rechnertyp:  
Bearbeitung durch: Solthar 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: j6rm
Spiel: E2
Report: 1054
Zusammenfassung: Transport mit Wagen benötigt das Talent Reiten
Beschreibung:

Einheit mit:
2 x Personen
2 x Pferden
1 x Wagen
2 x Steinen
ohne Reittalent ist nicht bewegungsfähig.
Fehlermeldung:
"MESSAGE 486693152 1115140909;type "Gaukler (9msf) in Kucobis (0,0): 'NACH sw' - Die Einheit hat nicht genug Wagenlenker oder zuviel andere Fracht, um die Wagen aufzuladen.";rendered 449439;unit 0 0 0;region "NACH sw";command"
In den Regeln hatte ich folgendes Beispiel gefunden:
"Eine Einheit mit 5 Zwergen ohne Reitentalent kann 5 Pferde eine Region (mit Straßen zwei Regionen) weit führen und dabei 127GE transportieren (5,4GE pro Zwerg und 20GE pro Pferd). Zusätzlich könnte diese Einheit auch noch 2 Wagen mitführen, was die Kapazität auf 327 erhöhen würde."

Schritte zur Reproduktion:
Zusätzliche Informationen:

Befehle:
EINHEIT 9msf; Gaukler [2,40$]
;bestaetigt
NACH sw
GIB 9msg 10 Silber
GIB Lsdj 10 Silber
GIB 9msh 10 Silber
GIB 9msa 10 Silber
DEFAULT "GIB ebdi 2 Stein"

Aus Report 0001054
EINHEIT 449439
"Gaukler";Name
"Ein lustiges Grüppchen von Elfen das den Tag mit Musik und viel Schabernak verbringt. Stets freundlich lächelnd und immer sehr gesprächig sind sie gut gelaunte Zeitgenossen.";Beschr
895234;Partei
2;Anzahl
"Elfen";Typ
5;Kampfstatus
28000;weight
COMMANDS
TALENTE
60 1;Unterhaltung
GEGENSTAENDE
1;Wagen
2;Pferd
2;Stein

Angehängte Dateien:
Notiz
(0007640)
Xolgrim   
2017-12-11 17:27   

@Enno: Laut Solthar kann man keine Wagen ohne Reiten bewegen (sagt der Code)
http://www.pbem-spiele.de/forum/viewtopic.php?f=16&amp;t=4173&amp;p=34344&amp;sid=e0537a0cd664cc4c3165cbf9f465d603#p34344
Wenn Du das nicht rein programmieren willst, kann ich auch einfach die Anleitung anpassen.

(0007644)
Enno   
2017-12-11 19:56   

Das ist dann wohl schon immer "kaputt" gewesen, bzw. in der Anleitung falsch. Ich fände es gut, wenn man ein Wagengespann auch führen dürfte, ohne ein Talent zu haben. Transportkapazität aufzubauen dauert am Anfang des Spieles extrem lange.

(0007645)
Enno   
2017-12-11 20:29   

Oh, ich sehe das. Im Code steht: maxwagen = effsk u->number 2, also "Eine Einheit kann pro Stufe Reiten 2 Wagen bewegen". Es scheitert also an denen, nicht an der Menge Pferde (2 sind in der Tat erlaubt).

Gibt es einen spieltechnischen Grund, dass hier die Menge der Wagen an das Talent gekoppelt ist, wenn es doch die Menge der Pferde schon limitiert? Mehr als Pferde/2 Wagen kann man ja eh nicht bewegen.

(0007646)
Falathar   
2017-12-11 20:52   

Realistischer wäre es auf jeden Fall mit 2 Personen und Pferden auch nen Wagen mitnehmen zu können und hilfreich hätte ich es auch gefunden, wenn es funktionoert hätte ;)
Pro Talent Reiten sind ja eh 4 Pferde erlaubt, wenn ich das richtig sehe. Män könnte so also 0,5 Wagen mehr transportieren. Ohne Talent geht ja auch ein Pferd. Wie ist das denn bei Trollen, ohne Reitentalent müssten die doch auch Wagen bewegen können!?

Sehe ich das richtig, dass Zielversion 3.15 bedeutet eine mögliche Änderung dauert noch und ich lerne jetzt erstmal reiten um meine Steine zu bewegen?
So oder so schon mal vielen Dank fürs drum Kümmern!

(0007647)
Enno   
2017-12-11 21:19   

Ja, vor Anfang März passiert da nichts im laufenden Spiel.

(0007648)
Solthar   
2017-12-12 11:48   
(Zuletzt bearbeitet: 2017-12-12 11:49)

Ich sehe keinen Grund die Anzahl der Wagen durch die Zahl der Pferde und das Reittalent zu begrenzen. Ist es vielleicht möglich, dass es mal Zentauren gab, wo das eine Rolle gespielt hätte?

Einheiten ohne Reiten Wagen zu erlauben, hat natürlich Einfluss auf die Spielbalance (Rassen mit Malus). Ich behaupte aber, dass das Erlauben vertretbar ist. Das Beispiel in der Anleitung mit den Zwergen kam allerdings erst 2014 durch CTD hinzu. Bis dahin stand da auch explizit:

"Wagen haben eine Kapazität von 140GE. Man kann sie nur mit dem Talent Reiten bedienen - außer Trolle, die können jeweils zu viert einen Wagen ziehen, aber auch nur eine Region weit bewegen. Ansonsten müssen vor einen Wagen immer zwei Pferde gespannt werden, diese können mit nichts anderem mehr beladen werden."

P.S. Markup-Editing ohne Vorschau-Modus ist echt bescheuert.

(0007649)
Xolgrim   
2017-12-12 19:51   

Das erklärt, warum mir die Regel so neu war ...

(0007650)
Solthar   
2017-12-12 23:19   

War wohl in Zusammenhang mit Bug 0001576.

(0007651)
Solthar   
2017-12-13 17:59   

Aktuelles Verhalten:
Eine Einheit mit 2 Personen, 2 Pferden und 1 Wagen ohne Reiten hat 10,8 GE frei (2*5.4 + 2*20 - 40), da sie die Wagen nicht bedienen kann.

Somit war das ein Anleitungsbug. Ich habe die Anleitung entsprechend korrigiert. Ich sehe hier inzwischen auch keinen Handlungsbedarf mehr. OT: Allenfalls sollte man überlegen, ob -3 auf Reiten für Insekten wirklich angemessen ist.

https://wiki.eressea.de/index.php/Pferd_und_Wagen

PR mit Tests: 746

(0007652)
Enno   
2017-12-13 19:34   

Ich sehe gerade, @Solthar hat einen PR gemacht, in dem nur die Tests geändert werden, nicht der Code. Wir streichen das Beispiel mit den Zwergen, lassen alles wie es ist, so dass man als nicht-Troll ein Reiten-Talent braucht, um Wagen zu bewegen? Na, meinetwegen. War ja wohl auch früher schon so.

(0007653)
Enno   
2017-12-13 19:47   

Finale Entscheidung: Kein Bug, wir weisen in der Anleitung darauf hin, dass man das Talent Reiten braucht, um einen Wagen zu bewegen. Insekten sind keine einfach zu spielende Rasse, das steht aber glaube ich schon irgendwo.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2598 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2019-07-18 18:15 2019-09-08 16:39
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Betriebssystem:  
Priorität: normal BS-Version:  
Status: neu Produktversion: 3.20.3  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: ioen
Spiel: E2
Report: 1131
Zusammenfassung: Kröten haben Magietalent und Zauber aber keine Aura
Beschreibung:

Zauber -> Patzer -> Kröte. Das ist soweit nichts neues. Ich hab schon lange keine Kröte mehr gehabt und hab mich gewundert, dass die Kröten noch Magie als Talent hat. Also habe ich mal im Code nachgeschaut. Da findet sich erstmal dei Beschreibung (Auszug):

msgstr "Die Kröte ist eine der seltensten Rassen Eresseas ... Vieleicht deswegen ist die Kröte auch gegen Zauber weitaus widerstandsfähiger als die normalen Rassen Eresseas, leider aber auch weitaus unmagischer als diese. Die Kröte kann schon aufgrund ihrer Größe und der fehlenden Hände nur unter Schwierigkeiten normale Tätigkeiten ausüben. Der einzige Vorteil ihrer geringen Größe ist, dass sie sich leichter verstecken kann."

Und bei weiterem suchen, dann was das in Werten heisst. Fast alle Talente werden mit einem Malus von 10 belegt, Tarnung gibt nen Bonus von 2

... <skill name="magic" modifier="-10"/> ... <skill name="stealth" modifier="2"/> ...

Das passt soweit mit dem Magier überein, er hat 8 Ausdauer und 10 Magiestufen verloren.
Der Magier kann aber eben noch Magie auf T6 und hat auch noch diverse Zauber aufgelistet, nur Aura hat er keine mehr, warum?

* Phygon (phyg), 1 Nebelkröte, kämpft nicht (sehr stark), Talente: Magie
  Cerddor 6, Ausdauer 0, hat: 941740 Silber. Aura 0/0, Zauber: Lied der
  Heilung, Gesang der Verwirrung, Gesang der Furcht, Gesang des
  Auratransfers, Friedenslied, Lied der Verführung, Monster friedlich
  stimmen, Heldengesang, Gesang des Werbens, Hohes Lied der Gaukelei,
  Gesang des Lebens analysieren, Bannlied, Regentanz, Erschaffe einen Ring
  der Unsichtbarkeit, Gaukeleien, Erschaffe ein Amulett des wahren Sehens,
  Plappermaul, Kampfzauber:

Wenn Kröten nicht zaubern können sollen, sollte die Beschreibung angepasst werden (übernehme ich gerne) und der Talentbonus auf -99 gesetzt werden. Magietalent, angezeigte Zauber und 0 Aura ist verwirrend.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008518)
Bruck   
2019-08-04 04:36   

Also meine Kröten hatten immer Aura. Du hast nicht zufällig soviel Permanetaura als Magier verbrauch das dadurch die 36 (oder so) Aura die Du als T6 haben solltest weg sind?

(0008520)
Xolgrim   
2019-08-04 08:19   

Mit Sicherheit hat der Magier schon mehr als 36 permanente Aura verbraten in seinem Leben. Ist eine Erklärung, wenn auch nicht wirklich intiutiv.

(0008555)
Bruck   
2019-09-08 16:39   

Wie sollte denn intuitiv anders gehen? max_Aura = Talent^2 - verbrauchte_permanent_Aura ist doch intuitiv.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2606 [Eressea] KAUFE/VERKAUFE kleinerer Fehler nicht getestet 2019-09-08 10:02 2019-09-08 13:30
Reporter: Dnalor Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.21.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.22  
    Zielversion: 3.22  
Partei: drei
Spiel: E2
Report: 1137
Zusammenfassung: Handel ohne Burg
Beschreibung:

Ich kann in einem Hochland Waren kaufen, ohne dass dort eine Burg steht. Klappt seit 2 Runden.

Einheit: Gilda Prigge RHaU (udjq) kauft 17 Öl.

Rahmenbedingungen:
Die Insel ist ja recht neu, von uns hat da wohl noch keiner was gebaut. Keine Burg in CR oder NR.
Rasse: Halbling
Es ist sind Trolle in der Region anwesend.
Es ist mal ein Insekt durchgereist.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Theorie:
Dnalor Today at 22:27
Undokomentiertes Feature: Trolle können in Hochländern und Bergen ohne Burg handeln. Bug: Es reicht, wenn ein Troll daneben steht
Dnalor Today at 22:27
Wie ich Software kenne, ist die das die richtige Erklärung. Fehler ist im Code seit Runde 1

Angehängte Dateien:
Notiz
(0008553)
Enno   
2019-09-08 12:57   
(Zuletzt bearbeitet: 2019-09-08 12:57)

Ich sehe gerade, dass KAUFE und VERKAUFE nicht den selben Code benutzen. Das gehrt geändert, DRY.

(0008554)
Enno   
2019-09-08 13:30   

Ich habe da einen Fix für die Zukunft geschrieben.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2603 [Eressea] ZAUBER kleinerer Fehler nicht getestet 2019-08-30 20:27 2019-08-31 12:20
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: enno
Spiel: E2
Report: 1135
Zusammenfassung: Nach Zauberpatzer wird noch ein Zauber gezaubert?
Beschreibung:

Meine Magierin hatte die Befehle:

EINHEIT iq03;    Jyn'Leeviyah the Red [1,1220$]
    ZAUBERE STUFE 8 &quot;Erschaffe Eisengolems&quot;

Dabei hat sie wohl gepatzt. Im Report steht:

Jyn'Leeviyah the Red (iq03) unterläuft in Pedun (1,-1) beim Zaubern von Erschaffe Eisengolems ein Patzer.
Jyn'Leeviyah the Red (iq03) in Pedun (1,-1): 'ZAUBERE STUFE 8 &quot;Erschaffe Eisengolems&quot;' - Jyn'Leeviyah the Red (iq03) erschafft 23 Eisengolems.
Als Jyn'Leeviyah the Red (iq03) in Pedun (1,-1) versucht, Erschaffe Eisengolems zu zaubern erhebt sich plötzlich ein dunkler Wind. Bizarre geisterhafte Gestalten kreisen um den Magier und scheinen sich von den magischen Energien des Zaubers zu ernähren. Mit letzter Kraft gelingt es Jyn'Leeviyah the Red (iq03) dennoch den Spruch zu zaubern.

Der Patzer führt dazu, dass man keine Aura mehr hat, was aber egal sein sollte, weil ich ja nur einmal gezeubert habe. Oder habe ich? Im Report steht dann auch noch:

Jyn'Leeviyah the Red (iq03) in Pedun (1,-1): 'ZAUBERE Stufe 1 Viehheilung' - Für diesen Zauber fehlen noch 4 Aura.

Was ist hier los?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008545)
EON   
2019-08-30 21:10   

Normalerweise wäre meine Vermutung, dass aus Versehen doch zwei Zauberbefehle gesetzt wurden, durch mergen etc. Kannst Du überprüfen, wie der Stand im Server vor der AW war?

(0008546)
Enno   
2019-08-31 10:18   

Ach, verflixt. Da ist die Fehlermeldung schuld. Ich habe einen vertrauten, der Viehheilung zaubert, mit der Aura des Magiers, die aber jetzt leer ist. Meldung anpassen, dann passt das.

(0008547)
Enno   
2019-08-31 12:20   

In allen Zauber-Meldungen darauf geachtet, dass die korrekte Einheit (co_get_caster) angezeigt wird.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2602 [Eressea] General kleinerer Fehler immer 2019-08-25 20:05 2019-08-27 22:18
Reporter: Waldgoettin Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: ntc
Spiel: E2
Report: 1135
Zusammenfassung: Der Befehl "Benenne fremde Burg" geht nicht
Beschreibung:

Ich habe auf der Insel Mindariel versucht Burgen umzubenennen, die ich gebaut hatte, aber dann andere vor mir rein sind (weil der Burgenbauer schon weg war, aber ich keine Einheit reingestellt hatte ....).
Leider hat das nicht geklappt.

Beispiel: Region Weldhelm, Einheit 79q8

Befehl letzte Runde "Benenne fremde Burg bdnz "Diebeshöhle"

Nachricht diese Runde:
Seaman Reisch (79q8) in Weldhelm (251,-476): 'BENENNE FREMDE BURG bdnz
"Diebeshöhle"' - Die Einheit ist nicht der Burgherr.

Schritte zur Reproduktion:

Versuchen fremde unbenannte Burgen zu benennen

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008542)
Enno   
2019-08-25 22:22   

Kann es sein, dass das nur klappt, wenn man vom Besitzer dabei nicht gesehen wird?

(0008543)
Enno   
2019-08-25 22:23   

Oh, nein. Daran sollte es nicht liegen. Eventuell ist das wirklich kaputt?

(0008544)
Enno   
2019-08-27 22:18   

Das war in der Tat kaputt gegangen. So ein wichtiges Feature, und keiner hat es gemerkt!



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2601 [Eressea] REKRUTIERE schwerer Fehler nicht getestet 2019-08-20 22:13 2019-08-25 17:44
Reporter: Waldgoettin Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion:  
Partei: onyx
Spiel: E2
Report: 1134
Zusammenfassung: Meldung das Insekten nur noch dieses Mal rekrutieren können, kommt bereits für die 1. Woche Sturmmond
Beschreibung:

Laut Anleitung können Insekten nur im Winter nicht rekrutieren, also in den Monaten Herdfeuer, Eiswind und Schneebann.

Die aktuelle Auswertung 1134 bezieht sich auf die 3. Woche Nebeltage, es folgt also noch ein ganzer Monat Herbst. Vielleicht ist bei der "Behebung" einer der vorher gemeldeten Bugs (es fehlte eine Woche zum Rekrutieren) irgendwie die Richtung des Fix schief gelaufen?

Damit kann man laut aktueller Meldung im Monat Sturmmond nur in der 1. Woche rekrutieren, aber nicht mehr in der 2. + 3.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Report für Eressea, Saturday, 17. August 2019, 21:09
Wir schreiben die letzte Woche des Monats Nebeltage im Jahre 36 des zweiten
Zeitalters. Es ist Herbst.

Es ist Spätherbst, und die kommende Woche ist die letzte vor dem Winter, in
der Insekten rekrutieren können.

Angehängte Dateien:
Notiz
(0008541)
Enno   
2019-08-25 17:44   

Ich hatte bereits den Bug 2458 noch einmal geöffnet, und habe die Sache dort gefixt, das sollte zum nächsten Winter funktionieren.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2458 [Eressea] REKRUTIERE schwerer Fehler nicht getestet 2018-07-07 22:10 2019-08-25 15:15
Reporter: Julian Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: dringend BS-Version:  
Status: erledigt Produktversion: 3.16.4  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    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.

(0008539)
Enno   
2019-08-25 11:09   

Im Report 1134 der Partei moor kam die Meldung "Es ist Spätherbst, und die kommende Woche ist die letzte vor dem Winter, in der Insekten rekrutieren können." - das ist verfrüht, der Code ist also noch immer verwirrt.

(0008540)
Enno   
2019-08-25 15:15   

Noch einmal gefixt, diesmal aber richtig.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2596 [Eressea] General kleinerer Fehler nicht getestet 2019-07-14 00:16 2019-08-20 21:34
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.4  
    Zielversion: 3.20.3  
Partei: 0
Spiel: E2
Report: 1131
Zusammenfassung: BANNER (ohne Text) crasht
Beschreibung:

Der Server crasht, wenn eine PArtei den BANNER BEfehl gibt, ohne ein Banner zu setzen.

Schritte zur Reproduktion:
Zusätzliche Informationen:

So geschehen bei Partei pvn5 (ich habe den Befehl aus der eingegangenen Mail gelöscht).

Angehängte Dateien:
Notiz
(0008488)
Xolgrim   
2019-07-15 08:14   

Bei anderen beschreibe Befehlen löscht der Befehl ohne Angabe einer Beschreibung schlicht die vorhandene. Falls das hier auch möglich ist, wäre das Verhalten wenigstens konsistent. Wobei ich bisher nie nur Beschreibe getestet habe, ich schreibe immer BESCHREIBE &quot;&quot; aber das sollte für den Server kein Unterschied sein?

(0008489)
Xolgrim   
2019-07-15 08:14   

Blöde Steuerzeichen.... Beschreibe ""

(0008490)
Enno   
2019-07-15 08:21   

Das mit dem quot ist ein Bug in Mantis, wo ich schon lange auf den Fix warte.

Ja, man könnte das Banner einfach löschen, aber das kann man mit "" glaube ich schon, und zumindest in diesem Fall war das nicht gewollt.

Eine andere Sache, die ich gerne machen würde, ist dass man Befehle nur auf minimal 4 oder 5 Buchstaben abkürzen darf. Also ein einzelnes b, w, p, oder n nicht mehr als Befehle interpretiert.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2543 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-01-06 12:41 2019-08-20 21:33
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.22  
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
&quot;Onema&quot;;Name
&quot;Ebene&quot;;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:
2490 [Eressea] Gebäude kleinerer Fehler nicht getestet 2018-09-10 02:04 2019-08-20 20:28
Reporter: Thoran 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.21  
    Zielversion: 3.21  
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: Leuchtturm.png (332,779 Bytes) 2019-08-13 19:29
https://bugs.eressea.de/file_download.php?file_id=97&amp;type=bug
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.

(0008532)
Xolgrim   
2019-08-13 19:29   

Zur erklärung was Thoran meint:
Früher hat man vom Leuchtturm aus jede Region gesehen, von Ozeanregionen hat man durchreise infos zu Schiffen etc. bekommen, von Landregionen hat man nur den Regionstyp und den Namen gesehen. Dann wurde etwas geändert und man hat Gebäude und durchreisemeldungen von Landregionen erhalten wenn man in einem leuchtturm stand, das war natürlich falsch. Das hast du dann etwas zu gründlich entfern, da man nun Landregionen überhaupt nicht mehr sieht, nichtmal Regionstyp und name. Weiter dahinterliegende Ozeanregionen sieht man jedoch wieder, was zu einer etwas seltsamen Sicht, gerade bei grossen Leuchttürmen, führen kann. Ich hänge mal ein Bild anbei. Das Schöne Hexfeld ist das Verhalten welches gute 1000 Wochen lang funktionierte. Das andere Bild ist nach dem etwas zu gründlichen Bugfix.

(0008533)
Xolgrim   
2019-08-13 19:52   

Nachtrag: Man sieht natürlich trotzdem einige Landregionen, das liegt aber daran, dass man die Nachbarregion einer Ozeanregion die man von einem Leuchtturm aus sieht auch sieht.

(0008535)
Enno   
2019-08-18 06:46   

Ich glaube, meien Änderung wirkt sich nur auf den CR aus, nicht auf den NR. Grundregel Eressea ist aber, dass in NR und CR immer die selbe Information steht.

Für so eine Anzeige von Landregionen ohne Infos hat der Server nämlich keinen Code, glaube ich. Die werden immer nur indirekt angezeigt als "Im Norden befindet sich der Wald von Huttiheita", wenn sie neben einer bewohnten Region liegen.

Wie soll so eine aufgedeckte Landregion im NR angezeigt werden? Hast Du ein Beispiel aus der Zeit, wo das noch nicht "kaputt" war?

(0008536)
Xolgrim   
2019-08-18 14:28   

Geiermoor (-6,4) (vom Turm erblickt), Sumpf, 347/20 Bäume, 76 Bauern. Im
Nordwesten der Region liegt der Gletscher von Falkenstein (-7,5), im Nordosten
das Hochland von Rabenberg (-6,5), im Osten der Sumpf von Schwanensee (-5,4),
im Südosten das Hochland von Brachten (-5,3), im Südwesten der Gletscher von
Eiszinne (-6,3) und im Westen der Gletscher von Habichtsfels (-7,4)

Wenn man da noch die Baum und Bauern Infors raus löscht wäre doch alles fein oder?



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2554 [Eressea] ZAUBER kleinerer Fehler immer 2019-02-08 16:02 2019-08-13 18:57
Reporter: Fiete Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: niedrig BS-Version:  
Status: erledigt Produktversion: 3.18.5  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
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.

(0008531)
Enno   
2019-08-13 18:57   

Okay.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2587 [Eressea] Reportformat Trivial immer 2019-06-02 14:14 2019-08-13 17:43
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
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, &quot;UNTERHALTE&quot;.

                           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:
Notiz
(0008528)
Enno   
2019-08-13 17:43   

Macht Sinn.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2592 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-06-25 05:05 2019-08-11 14:05
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: wiedereröffnet  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: wiki
Spiel: E2
Report: 1128
Zusammenfassung: Seltsames Zeichen im Namen
Beschreibung:

Im Testreport 1128 für wiki steht:

Ingeborg Refling Hagen<U+200E> (puma) baut für 1 an Burg (aLvg) weiter.
Thorbjørn Egner<U+200E> (theg) verdient in Gawet (1,-4) 40 Silber durch
Unterhaltung.
Bjørnstjerne Bjørnson<U+200E> (bjbj) verdient in Fyrid (2,-2) 20 Silber durch
Unterhaltung.

Das <U+200E> gehört dort nicht hin, woher kommt das?

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008478)
Enno   
2019-06-25 05:12   

Im Datenfile steht scheinbar "Ingeborg Refling Hagen‎" (erstes krankes Zeichen ist -30).

(0008479)
Enno   
2019-06-25 05:14   

Das ist ein Left-To-Right Mark? Warum hier?
https://www.fileformat.info/info/unicode/char/200e/index.htm

(0008480)
Enno   
2019-06-25 05:23   

Es ist ein gültiges 3-byte UTF8 Zeichen. Obwohl das ganz am Ende des Strings steht, und kein lesbares Zeichen, entfernt unicode_utf8_trim es nicht. Sollte es das? Viel wichtiger: Wie ist das überhaupt hier hin gekommen?

(0008481)
Enno   
2019-06-25 05:28   

Das Zeichen war in den Befehlen für Runde 1120 drin, wie auch immer ich das geschafft habe.

Kommt das nur in meinen Einheiten vor, oder ist ds aucha ein Problem für andere Parteien, dass ich lösen sollte?

(0008483)
Enno   
2019-06-25 05:37   

Das betrifft offenbar wirklich nur meine Einheiten. Seltsam.

(0008501)
Enno   
2019-08-01 19:04   

Gefixt für Einheiten puma und bjbj, aber jetzt werden die Namen von iakc und rum angemeckert?

(0008502)
Enno   
2019-08-01 22:55   
(Zuletzt bearbeitet: 2019-08-01 22:56)

Anscheinend endet rum's Beschreibung in zwei RTL Zeichen, die da auch weg können? Dito für iakc.

(0008503)
Enno   
2019-08-01 23:02   

unicode.c überarbeitet, vor allem die trim() Funktion besser gemacht.

(0008504)
Enno   
2019-08-01 23:13   

Zu früh gefreut, die Änderung macht Probleme unter Linux. Wahrscheinlich wegen unterschiedlicher Defnition von wint_t oder etwas der Art?

(0008505)
Enno   
2019-08-02 12:35   

Jetzt klappt es doch.

(0008526)
Enno   
2019-08-07 22:07   

Die Änderung löscht Emoji iaus Einheitennamen, ich muss da noch einmal dran.

(0008527)
Enno   
2019-08-11 14:05   

Ich habe das Interval mit den ungewollten Zeichen jetzt einfach hartkodiert.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2079 [Eressea] NACH/ROUTE kleinerer Fehler immer 2015-02-28 14:52 2019-08-04 18:54
Reporter: Holder Rechnertyp:  
Bearbeitung durch: CTD Betriebssystem:  
Priorität: normal BS-Version:  
Status: bestätigt Produktversion:  
Produkt-Build: Lösung: offen  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: souL
Spiel: E2
Report: 915
Zusammenfassung: Ein Magier mit Elfenpferd bewegt sich nur ein Feld weit.
Beschreibung:

Ein Magier mit Elfenpferd bewegt sich nur ein Feld weit.
Ist das gewollt?
Der Magier hat auch noch ein normales Pferd bei sich.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005691)
Xolgrim   
2015-02-28 19:51   
(Zuletzt bearbeitet: 2015-02-28 19:52)

Ein bischeln mehr Information wär schon gut. Einheitennummer, Talent Reiten, bewegungsbefehl, meldung aus dem Report etc.
Wenn ich das jedoch noch recht im Kopf habe reicht für Elfenpferde T1 Reiten nicht aus so brauchst T7 (oder so um den dreh, kann auch t3 gewesen sein) um mit denen reiten zu können. Vermutlich ist dein Magier nicht gut genug um auf dem Pferd zu reiten und ist daher abgestiegen und hat es an der Leine geführt. ggf. bringt zeige Elfenpferd genauere informationen zum benötigten Talent.

(0005692)
Holder   
2015-03-01 20:59   

Ich hab mir gerade die Beschreibung für Elfenpferde aus den Meldungen durchgelesen. Da steht das zumindest nicht drin. Woher soll man das dann wissen?
Der Magier hat Reiten tatsächlich nur auf 1. Vielleicht ist das das Problem.

(0005696)
CTD   
2015-03-02 13:18   

Elfenpferde brauchen mindestens Reiten 5 (Reiten 10 für 2 und so weiter)
genau zwischen T7 und T3, gut graten ;-) Sonst muss man sie führen, und das geht nur wenn man selbst nicht reitet.

Das sollte in die Beschreibung.

ToDo in move.c :
if (!(u_race(u)->flags & RCF_HORSE)
&& ((horses == 0 && unicorns == 0)
|| horses > maxhorses || unicorns > maxunicorns)) {
return 0;
}

muss heißen horses > (maxhorses - (unicorns * 10)) || unicorns > maxunicorns

(0005901)
Enno   
2015-07-02 09:07   

Selbst wenn der Bug hier keiner ist (Elfenpferde brauchen T5), ist mir der letzte Satz von CTD noch unklar: Was ist (unicorns * 10) ?

(0005933)
CTD   
2015-07-02 19:43   

Beispiel:
Ein Reiter mit T10 Reiten hat 1 Elfenpferde und 20 normale.
Nach obiger Formel dürfte er Reiten. Da aber ein Elfenpferd 5 "Talentpunkte" verbraucht sollte er nur noch 5 für die Pferde haben. Da ein Pferd zum Reiten nur 1/2 Talentpunkt braucht also 10. Die Elfenpferde haben in dem Vorschlag Vorrang, und deshalb - Elfenpferde mal 10 von maxhorses abziehen.

(0008524)
Enno   
2019-08-04 18:54   

Aha! Das ist ein Alias. unicorn = elvenhorse. Weil der Eressea-Code ja diese undeutlichen Namen so liebt ...



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2016 [Eressea] General schwerer Fehler nicht getestet 2014-07-17 21:47 2019-08-04 18:51
Reporter: Lorsch Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: wird nicht behoben  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: bu
Spiel: E2
Report: 884
Zusammenfassung: VORAUSBEFEHLE funktionierten nicht
Beschreibung:

Am 26.06. hatte ich ERESSEA 2 BEFEHLE, ERESSEA 2 VORAUSBEFEHLE + 1 und ERESSEA 2 VORAUSBEFEHLE + 2 für die Auswertung 884, 885 bzw. 886 eingesandt. Alle drei Befehlssätze hat der Server bestätigt.

Die ERESSEA 2 BEFEHLE und die ERESSEA 2 VORAUSBEFEHLE + 1 hat der Server ignoriert, stattdessen wurden die ERESSEA 2 VORAUSBEFEHLE + 2 für die Auswertung 884 verwendet. Ich weiß nicht, welche Befehle für die Auswertungen 885 und 886 verwendet wurden, vermutlich einfach die Defaultbefehle.

Wäre schön, wenn das repariert würde.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0005237)
Enno   
2014-07-18 03:32   

Das kann wegen der Neuauswertung passiert sein? Vorausbefehle sind eine furchtbar ätzende Sache, ein Krampf aus bash-skripten.

(0005252)
Thoran   
2014-07-18 14:27   

Hai!

Ein Verbündeter von mir probiert das zur Zeit auch in E4 (aka Deveron) aus. Hat aber auf "E4 VORAUSBEFEHLE + 1" keine Antwort vom Server bekommen. Mit "ERESSEA 4 VORAUSBEFEHLE + 1" ist zwar eine Antwort vom Server gekommen, aber eben eine, die darauf hindeutet, dass das nicht bearbeitet worden ist (Partei nicht bekannt oder Passwort falsch). Die Partei in E4, die das probiert, ist tok

Wäre schön, wenn das auch für Deveron behoben werden könnte. Aber notfalls lösen wir das intern in unserer Allianz.

Gruß,
Thorsten

(0005255)
Lorsch   
2014-07-19 14:48   

Hallo, ich war während der Neuauswertung in Urlaub, aber die war für Runde 885, richtig? Da der Fehler ja schon für Runde 884 auftrat, glaube ich nicht, dass es allein mit der Neuauswertung zusammenhängt.

(0005296)
Enno   
2014-08-05 10:28   

Das ist mit der Umstellung auf den neuen Server passiert: Die aktuellen procmail-Regeln verarbeiten keine Vorausbefehle mehr. Mit der Umstellung auf E4 und die ERESSEA <n> BEFEHLE Syntax ist es dann so gekommen, dass die nicht abgelehnt, sondern für die aktuelle Woche akzeptiert wurden, wegen schlechter regexp für die abwertskompatiblen Regeln. Es schicken immer noch knapp ein drittel der Spieler die Befehle mit ERESSEA BEFEHLE statt ERESSEA 2 BEFEHLE ein, für die musste ich einen Hack bauen...

(0005336)
Thoran   
2014-08-14 09:45   

Das betrifft nicht nur E2 (weil ich gerade Deine Zuweisung zu "Spiel" -> "2" sehe), sondern mindestens auch E4.

(0006430)
Solthar   
2015-12-23 15:32   

Ich habe die entsprechende Passage aus der Anleitung genommen. Sollten die Vorausbefehle wieder aktiviert werden, sollte das hier vermerkt werden:

https://wiki.eressea.de/index.php?title=Befehle_einschicken

Ich habe das hier zufällig gelesen: Ist die bevorzugte Syntax für das Subject ERESSEA 3 BEFEHLE? In den Reports steht immer noch
"E3 BEFEHLE";mailcmd

(0006431)
Enno   
2015-12-25 11:39   

Das ist dann wohl im Report falsch. Danke.

(0008523)
Enno   
2019-08-04 18:51   

Das Feature VORAUSBEFEHLE war zu kompliziert, und ist inzwischen offiziell eingestellt worden. Hier wird also nichts getan werden.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2578 [Eressea] KAUFE/VERKAUFE Unschönheit nicht getestet 2019-04-14 11:35 2019-08-04 04:44
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

(0008519)
Bruck   
2019-08-04 04:44   

Das ist mehr oder weniger ein Duplikate von "0001683: Befehlsreihenfolge Kaufen", den Du Dir gerade angeschaut hast Enno.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1935 [Eressea] General schwerer Fehler immer 2012-07-19 22:39 2019-08-03 20:49
Reporter: Broxbart Rechnertyp:  
Bearbeitung durch: CTD Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion:  
Produkt-Build: Lösung: wird nicht behoben  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei:
Spiel: E2
Report:
Zusammenfassung: [E2] Number-command abuse?
Beschreibung:

Units using the renumbering-command 'Nummer' seem to be immune to targeted attacks, e.g. STEHLE/STEAL and spells targeting specific units.

This is currenty done on a huge scale (hundereds of units each and every turn) by opposing factions.
In my (admittedly biased) opinion, this looks like an abuse / bug exploit.

Example unit in turn 781/782: hjpy

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0004983)
Solthar   
2012-07-26 12:29   

NUMBER shouldn't be the problem. But MAKE TEMP (with GIVE ALL/GIVE ALL PERSONS) might be. It doesn't fool STEAL (at least not in the current round, but having to adjust your STEAL command every round because the unit number changed can be a nuisance). However, both FOLLOW UNIT and CAST can be vulnerable to this kind of strategy.
TEMP units are the root of much evil.

(0004988)
argelas   
2012-09-02 14:19   

TEMP-units are certainly not intended for such use, but there is not much one can do about that. You can tell your enemies that you think this is an unfair strategy but if they think of it as a clever strategy inside the rules they will not stop it.

The only remedy would be if such use of TEMP-units would be officially prohibited. But since this could not be enforced by rules and would have to be controlled manually by Enno or some moderators in every case, I do not know if it is practicable.

(0004995)
Broxbart   
2012-09-21 15:08   

Thanks for your feedback, Solthar and argelas.

(0005004)
Enno   
2012-10-22 01:16   

Ihr koennt gerne Deutsch reden. Ich habe es noch nicht verlernt :-)

(0005288)
CTD   
2014-07-30 14:04   

Sowohl BEKLAUE als auch FOLGE EINHEIT geht trotz NUMMER ohne Probleme.
Das Problem mit TEMP Einheiten besteht wie schon erwähnt nicht bei BEKLAUE, mal sehen ob es für die anderen Fälle eine praktikable Lösung gibt. Erster Gedanke: Bei jedem GIB 123 x Personen Kommando wird die Zieleinheit zusammen mit der Gebenden Einheit in einer Tabelle gespeichert, wenn gib erfolgreich ist.
Sollte dann später eine Einheit nicht gefunden werden, wird nachgeschaut ob die Einheit Personen abgegeben hat. Wenn ja wird (zufällig?) eine dieser Einheiten genommen.

(0005291)
Enno   
2014-07-30 16:59   

Das ist potenziell eine große lookup-struktur, da Frage ich mich ob es das Wert ist. Auf jeden Fall dann nur für TEMP Zieleinheiten pflegen.

(0005292)
argelas   
2014-07-30 19:54   

Wenn ich das richtig verstehe ist vom ursprünglichen Problem nur noch das Zaubern übrig. Beklaue wird zwar im Bugtext genannt, funktioniert aber anscheinend sowohl mit NUMMER, als auch mit MACHE TEMP. Ob sich der Aufwand nur für die handvoll Zauber lohnt ist fraglich.

Man könnte ggf. auch alle gezielten Zauber durchgehen und die betroffenen Einheiten markieren, so dass sie den Effekt bei GIB PERSONEN mitnehmen. Da fallen nicht ganz so viele Daten an, aber ich weiß nicht ob das so leicht zu machen ist wenn ZAUBERE eigentlich erst später in der Befehlsreihenfolge ist.

(0005293)
CTD   
2014-07-31 00:49   

Und Folge Einheit. Das wäre schon gut wenn man das nicht so einfach aushebeln könnte.
Bleiben die 0 Personen Einheit bis zum Cleanup nach dem Bewegen vorhanden?
Dann wäre es vieleicht sinnvoller alle Gib Personen Kommandos an der jeweiligen Einheit (temporär) nachzuhalten. Ich weiß bei Betrete wir die Order gelöscht, aber bei Gib bleibt die doch? Dann wären die Information sogar schon da, man müsste nur mal in den Befehlen der Orginal-Ziel-Einheit suchen gehen.

(0005829)
Xolgrim   
2015-05-17 10:01   

Das ganze wird dann sehr frickelig wenn ich mehrere Temp Einheiten erschaffe und die Personen aufteile... Folge ich dann der Einheit mit den Meisten Personen? Keiner? Einer zufälligen?

(0008517)
Enno   
2019-08-03 20:49   

Ich glaube nicht, dass uns hier etwas gutes einfallen wird. MACHE TEMP ist ein grundsätzliches Problem von Eressea, das kann man nicht so einfach abschaffen.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1874 [Eressea] General schwerer Fehler nicht getestet 2011-10-10 14:21 2019-08-03 20:45
Reporter: Thoran 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: d08a
Spiel: E2
Report: 743
Zusammenfassung: Almosen deckt wahre Partei auf
Beschreibung:

Eine meiner Einheiten hat diese Woche Almosen erhalten und dabei natürlich auch erfahren, welche Partei ihr das Almosen gegegeben hat. So weit, so gut, aber: Der Geber tarnt sich eigentlich als eine andere Partei (es gibt diverse Parteien der 13. (?) Welt, die sich alle als United Folks Organization (UFO) ausgeben).

Ich erhielt folgende Meldung:
---snip---
gundabar of angmar clan (4dob) gibt ein Almosen von 2 Silber an Thorans
Axtträger (d08a).
---snap---

In der Region sehe ich nur noch Einheiten der Partei UFO. Entweder gibt es da noch eine weitere Einheit der Partei gundabar of angmar clan, die mir im Notfall Silber gibt (was aber seltsam wäre, weil ich dieser Partei explizit noch nie begegnet bin) oder aber eine der UFO-Einheiten gehört in Wirklichkeit dieser Partei an (was ich für wahrscheinlicher erachte).

Schritte zur Reproduktion:
Zusätzliche Informationen:

Region: ° Tempa ° (ID: y90cpt)
Empfängereinheit: Temporäre Regionsüberwacher (dd2g)

Angehängte Dateien:
Notiz
(0004765)
argelas   
2011-10-12 23:27   

Das Problem ist doch unabhängig davon, ob sie in der Region unsichtbar getarnt oder als UFO getarnt ist oder? Wenn du der Partei noch nie begegnet bist, wieso hat sie dann helfe silber für dich? Eben wegen diesem Helfestatus finde ich es aber auch nicht so schlimm dass sie sich zu erkennen gibt, ein bischen vertraut sie dir ja anscheinend. Und von welcher Einheit es genau kommt kann man nie wissen.

(0004766)
Thoran   
2011-10-13 00:09   

UFO ist sowohl eine Partei als auch eine Allianz aus mehreren (keine Ahnung wie vielen) Parteien, die sich alle (!) nach außen hin als Partei UFO tarnen. Ich arbeite mit dieser Partei/Allianz im Rahmen des Untotenfeldzuges in den alten Welten zusammen, weshalb eine, mehrere oder alle Parteien dieser Allianz ein HELFE SILBER zu mir haben. Ich weiß aber definitiv nicht, welche Einheit zu welcher tatsächlichen Partei gehört als auch bi ich der genannten Partei "gundabar of angmar clan" bisher jemals vorher begegnet (zumindestens nicht unter ihrer wahren Parteizugehörigkeit - wenn dann habe ich diese Partei nur als UFO zu Gesicht bekommen).

Das "Problem" meiner Meinung nach ist hier, daß ich über die Almosennachricht von Parteien erfahre, von denen ich vorher überhaupt nichts gewußt habe.

(0004767)
Enno   
2011-10-18 03:41   

Ich bin mir nicht sicher, was man da stattdessen anzeigen könnte. Den Namen einer Einheit der Partei, die das Almosen gibt? Das ginge, aber was dann, wenn zwei verscheidene Parteien in der Region Almosen verteilen, die sich als die gleiche Partei getarnt haben?

(0004768)
Thoran   
2011-10-18 07:17   

Den Namen der Partei, als die sich die almosengebende Partei getarnt hat (in diesem Fall also UFO) anzuzigen, halte ich für die beste Lösung, den das sind ja auch genau die Parteien, die man in der entsprechenden Region sieht.

Sollten da zwei Parteien sich als die gleiche, dritte, Partei tarnen und auch beide Almosen geben, so halte ich es für unkritisch, das zwei "Almosenmeldungen" im Report auftreten. Das wäre dann halt analog zu Kämpfen, wo die beiden Parteien ja auch als getrennte Kombattanten auftreten.

Gut, wenn man absolut genau sein will, dann müßte man Almosen auch nach Gruppen innerhalb der jeweiligen Geberparteien aufschlüsseln, aber ist das dann nicht übertrieben?

(0004769)
argelas   
2011-10-18 20:22   

Was machst du wenn der Geber mehrere Einheiten hat die sich als unterschiedliche Parteien tarnen? Zufällig auswählen? Das geht vielleicht noch. Aber was wenn eine Einheit getarnt aber nicht parteigetarnt und eine parteigetarnt und sichtbar ist? Die richtige oder die falsche Partei angeben? Warum sollte eine Art der Tarnung durchsichtiger sein als die andere?

Oder generell wenn keine unparteigetarnte sichtbare Einheit vorhanden ist "Eine anonyme Partei" schreiben? Dann könnte sich ein parteigetarnter Spion verraten der beim Spenden seine zugehörigkeit verschleiert. Das tut er allerdings jetzt schon. Sonst fällt mir erstmal kein Problem ein, außer dass man dann für alle Eineheiten checken muss ob wenigstens eine sichtbare und unparteigetarnte Einheit vorhanden ist und das für Verbündete die den eigenen Tarner mit Geld für die Region nicht sehen verwirrend ist.

Ich würde es einfach so lassen, dann verrät sich die Einheit eben bei der Geldübergabe.

(0004770)
Thoran   
2011-10-18 21:25   

Wäre es nicht am einfachsten, man gibt beim Almosen die Partei an, als die sich die erste Silber abgebende Einheit des Gebers ausgibt.

Wenn man Almosen von mehreren Einheiten einer Partei empfängt, die sich alle als unterschiedliche Parteien tarnen, dann erhält man hier halt eine falsche Aussage, die man aber ja nicht nachprüfen kann, weil ja keiner weiß, wieviel Silber die abgebende Einheit denn nun tatsächlich hatte (von solchen Fällen wie dem gleichzeitigen Ausspionieren aller entsprechenden Einheiten mal abgesehen). Auffällig wäre es nur dann, wenn man mehr als 500 bzw. 5000 Silber erhält und die abgebende Partei in meinem Report nur mit einer Einheit auftaucht, die aber gar keinen Silberbeutel/-kassette dabei hat - aber das ist dann halt so.

Wenn ich Almosen von einer Partei erhalte, die in der Region zwei Einheiten hat, von denen eine parteigetarnt, aber nicht getarnt, und die die andere getarnt aber nicht parteigetarnt ist, dann würde ich als Spenderangabe entweder "eine anonyme Partei" (wenn die parteigetarnte zuerst im Report auftaucht) oder die entsprechende Partei (entweder die wahre Partei des Spenders oder die als die er sich ausgibt) erhalten. Das ist ja meines Wissens nach jetzt auch so, oder?

(0004771)
argelas   
2011-10-18 21:43   

Wie es jetzt mit gatarnten ist weiß ich gar nicht mit Sicherheit. Wenn das jetzt schon "anonym" ist würde ich eher das für parteigetarnte nehmen als die angebliche Partei. Ist aber Ansichtssache. Parteitarnung ist als Spionagewerkzeug eh nicht tauglich weil mit etwas Aufwand durchschaubar (zumindest wenn sich der Feind als ein Freund von dir oder als Neutraler tarnt, falls nicht ist es aber ein schlechter Spion). Für Zwecke des Ausgebens unter einer gemeinsamen Allianzfahne ist es praktisch, aber dann ist das mit der Almosenmeldung nicht ganz so wichtig.

(0004843)
Enno   
2012-05-10 19:19   

Ich denke, der richtige Weg ist hier, die Tarnung beizubehalten, wenn man kann. Folgender Vorschlag:

  1. Wenn der Empfänger eine ungetarnte Einheit der Geberpartei in der Region sieht, dann diese Partei auflisten.
  2. Wenn der Empfänger nur getarnte sieht, dann eine getarnte auswählen, und die Tarn-Partei angeben
  3. Wenn mehrere Parteien als die gleiche erscheinen (oder sind), ihre Spenden in einer Nachricht vereinigen.

Das ist ein bischen viel Komplexität für ein eigentlich simples Feature :-)

(0005567)
Enno   
2014-12-14 19:36   

Alternativer Vorschlag: Wer sich nicht durch Spenden enttarnen möchte, kann doch einfach den HELFE-Status aufheben?

(0005676)
Kitaktus   
2015-02-18 16:27   
(Zuletzt bearbeitet: 2015-02-18 16:32)

Wenn bei der Spende die Originalpartei genannt wird, dann wird man unter Umständen so oder so enttarnt. Entweder man setzt HELFE SILBER und offenbart beim Spenden die wahre Partei, oder man setzt es nicht und fällt dann auf, weil man nicht gespendet hat.

Der Einfachheit halber würde ich die erste Einheit der spendenden Partei nehmen (eventuell die erste mit Silber) und deren nach außen gezeigte Zugehörigkeit als Quelle angeben.
Das Zusammenfassen von mehreren Quellen, die sich als gleiche Partei ausgeben, ist nett, aber nicht unbedingt den Aufwand wert.

Zur Info: gundabar of angmar clan ist in den alten Welten durchaus unter diesem Namen unterwegs.
Ein Helfe Silber auf Parteien, denen ich nie begegnet bin, halte ich nicht für ungewöhnlich. Ich habe da auch ein paar auf meiner Liste, bei denen mich mal ein Dritter gebeten hat, sie im Fall der Fälle zu unterstützen.

PS: Ich sehe gerade, dass der Fehlerbericht schon älter ist. Wenn es seit 3 Jahren keinen stört, dann muss das Thema wegen mir nicht wiederbelebt werden.

(0008516)
Enno   
2019-08-03 20:45   

Ich glaube, hier ist der Konsens, dass da nichts geändert werden muss.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1683 [Eressea] General kleinerer Fehler nicht getestet 2009-12-12 22:22 2019-08-03 15:32
Reporter: Bruck 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: fano
Spiel: E2
Report: 648
Zusammenfassung: Befehlsreihenfolge Kaufen
Beschreibung:

(Eigentlich sollte das ein Bugreport zur Silberversorgung werden, aber nach 3 Stunden Suche habe ich dann doch herausgefunden, dass es nicht notwendigerweise ein richtiger Bug ist.)

KAUFE scheint in der Befehlshaberische nicht wie bisher von mir gedacht gleichzeitig mit den anderen produzierenden Befehlen (MACHE, ARBEITE, UNTERHALTE) sondern wie im Punkt 21 der Befehlsreihenfolge komplett nach UNTERHALTE, ARBEITE u.s.w. zu kommen (Punkt 21.5.)

Von meinem generellen Verständnis, dass man direkt erzeugtes in der gleichen Runde noch nicht verbrauchen kann (hier Silber) ist das ungewollt. (deswegen auch Bug Report) So hatte ich auch die Punkt 25 Unterpunkte immer verstanden, dass das alles gleichzeitig geschieht.

Ebenfalls ist es extrem unschön, dass man auf diese Weise durch einen Fehler bei Kaufe sein gesamtes Silber verlieren kann, und dadurch wie bei mir gerade geschehen sogar Leute verhungern, wenn in der gleichen Runde genug Silber durch ARBEITE und UNTERHALTE erzeugt wird.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0004192)
Enno   
2009-12-14 08:42   

Ich bin mir nicht sicher, ob ich das wirklich reparieren will. Ich könnte KAUFE/VERKAUFE natürlich vor alle Silber-produzierenden Befehle ziehen, wenn das keine Seiteneffekte hat...

(0004195)
Solthar   
2009-12-16 23:09   

Ich sehe keinen Bug. Auch wenn die Punkt-21-Unterpunkte gleichzeitig geschehen, kann man das eingenommene Silber gleich wieder ausgeben. Es gibt auch andere Stellen, wo verdientes Geld gleich wieder ausgegeben wird (Gebäudeunterhalt, Beförderung), wenngleich das nicht zum Verhungern führen kann.

Ich wäre hier eher für "Bestandsschutz", aber wenn man VERKAUFE vorziehen sehe ich keine Seiteneffekte, außer

  • SPIONIERE (völlig unwichtig, aber warum ist das eigentlich in der gleichen Gruppe mit MACHE & Co?)
  • MACHE (kann man eigentlich jetzt schon in der gleichen Runde handeln, in der ein Handelsposten gebaut wird?)
  • und eben den Silberbefehlen, weil man den "Bug" nicht mehr als Feature nutzen kann.
    Evtl. verhungern Bauern jetzt leichter, weil man ihnen das erhandelte Geld dann gleich wieder über Steuern aus der Tasche ziehen kann (finde ich sehr stylisch).
(0008515)
Enno   
2019-08-03 15:32   

Ich glaube noch immer, hier muss man nichts machen.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
1606 [Eressea] General kleinerer Fehler nicht getestet 2009-09-05 20:11 2019-08-03 15:30
Reporter: Bruck Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.4  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: fano
Spiel: E2
Report: 634
Zusammenfassung: Bauernwanderung
Beschreibung:

Durch den Baumvermehrungsbug 1600 sind bei mir diese Woche sehr viele Bauern aus überwaldeten Regionen abgezogen. Dabei sind mir 3 Dinge aufgefallen, wobei ich mir nicht ganz sicher bin ob da Bugs dabei sind.

  1. Es fehlen Bauern (nicht viel, abgezogen sind 1300, angekommen nur 1230). Verhungert ist niemand, da war überall Silber.
  2. 350 der Bauern sind in eine ebenfalls überwaldete Region (Südosten) gezogen.
  3. Niemand ist nach Nordwesten abgewandert, und das obwohl die dortige Wüste fast identische Werte hat wie eine Wüste im Nordosten, in welche 300 Bauern gewandert sind.

Könnte 2+3 zusammenhängen? Also dass die 350 nicht nach SO sondern NW wollten?

Schritte zur Reproduktion:
Zusätzliche Informationen:

Die verlassene Region ist (ID:s64mc8).

Angehängte Dateien:
Notiz
(0003985)
Bruck   
2009-09-06 22:52   

In Dieser Runde (635) hat sich 2. und 3. erledigt, aus beiden Wäldern sind Bauern verschwunden und auch welche nach NW gewandert.

Der erste Teil ist aber immer noch ein Problem, es fehlen (Summe aller Wanderungen) wieder etwa 100 Bauern.

Das ist aber nun wirklich nicht mehr gravierend (in E2), kann also von mir aus geschlossen werden wenn kein höheres Interesse daran bestehen.

(0008506)
Enno   
2019-08-02 13:43   

Hilfreich für mich: Die Region heisst Vodas, und in ihr befindet sich eine Einheit mit Nummer q9a3

(0008507)
Enno   
2019-08-02 14:04   
(Zuletzt bearbeitet: 2019-08-02 14:05)

Hmm. In calculate_emigration wird MAX_EMIGRATION immer negativ, weshalb niemand aus der Region wandert? Das scheint mir falsch, Bauern laufen offenbar nur in überbevölkerte Regionen.

(0008508)
Xolgrim   
2019-08-02 14:51   

Wie besprochen ein Fall, in welchem die Bauern aus überwaldeten Regionen gewandert sind, wenn auch schon etwas älter.

Region Dunkelwald (1086980931;id)
Runde 1039: Dunkelwald (1,0), Wald, 86/1285 Bäume, 4102 Bauern, 4406101 Silber
Runde 1040: Dunkelwald (1,0), Wald, 176/2370 Bäume, 2305 Bauern, 4279020 Silber
Runde 1041: Dunkelwald (1,0), Wald, 195/3332 Bäume, 960 Bauern, 4134395 Silber
Runde 1042: Dunkelwald (1,0), Wald, 36/3129 Bäume, 563 Bauern, 4005910 Silber

Beispielhafte Nachbarregion: Ritus (224049591;id)
Runde 1039: Ritus (2,-1), Hochland, 2623 Bauern, 350905 Silber
Runde 1040: Ritus (2,-1), Hochland, 3276 Bauern, 345133 Silber
Runde 1041: Ritus (2,-1), Hochland, 0/1 Bäume, 3572 Bauern, 343189 Silber
Runde 1042: Ritus (2,-1), Hochland, 0/2 Bäume, 3588 Bauern, 342477 Silber

(0008509)
Enno   
2019-08-02 17:03   

Nach aktuellen Regeln wandern in 1040 keine Buaern von Dunkelwald nach Ritus, weil in Dunkelwald weniger Arbeitsplätze vorhanden sind als dort Bauern leben. Das ist verrückt, finde ich - es soll bestimmt umgekehrt sein. Die Codezeile ist allerdings von 2011. Wann war 1040?

(0008510)
Xolgrim   
2019-08-02 17:21   
(Zuletzt bearbeitet: 2019-08-02 17:24)

@enno: Vor 92 Auswertungen also rund 2 Jahren

Hochland hat 4000 Arbeitsplätze, da war in 1040 also noch etwas frei.

(0008511)
Enno   
2019-08-02 22:00   

Runde 1040 war: "3.13.1";Build - Ich muss wohl mal in den Code von damals gucken, ob der anders war.

(0008512)
Enno   
2019-08-03 10:29   

Mit dem aktuellen Code kann ich reproduzieren, AW 1040:

Dunkelwald (1,0), Wald, 148/2447 Bäume, 2284 Bauern, 4376972 Silber, 588 Pferde.
Ritus (2,-1), Hochland, 3276 Bauern, 345133 Silber, 587 Pferde.

Das ist also die erwartete Wanderung. Passt nicht zu dem, was ich im Code lese, aber das schaue ich mir als nächstes an, jetzt wo es reproduzierbar ist.

(0008513)
Enno   
2019-08-03 14:25   

Aha! Mein Mißverständnis klärt sich auf: Bauern fliehen nicht vor Platzmangel, sondern sie gehen hin zum Arbeitsplatzangebot.

(0008514)
Enno   
2019-08-03 15:30   

Hier lag kein Bug vor, aber der Code war schwer zu verstehen. Ich habe ein paar fehlende Tests ergänzt, und eine Möglichkeit gefunden, etwas Speicher zu sparen.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2586 [Eressea] NACH/ROUTE schwerer Fehler nicht getestet 2019-05-19 11:33 2019-07-31 17:34
Reporter: xenomorph Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.19.7  
Produkt-Build: Lösung: keine Änderung notwendig  
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?

(0008500)
Enno   
2019-07-31 17:34   

Die Zwischenregion hatte in der Tat einen magischen Pfad. Auch sonst sieht der Code aus, als wenn er die Bewegung richtig berechnet. Kein Bug.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2594 [Eressea] General kleinerer Fehler nicht getestet 2019-07-05 21:37 2019-07-31 08:35
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: 0
Spiel: E2
Report: 1130
Zusammenfassung: STIRB PARTEI funktioniert nicht
Beschreibung:

Das Problem ist die Befehlsreihenfolge. STIRB wird vor KONTAKTIERE asugeführt. Es wird dabei nur ein Flag FFL_QUIT gesetzt, das eigentliche Sterben passiert erst später. Man kann aber an dieser Stelle nicht die Partei auflösen, weil noch nicht kontaktiert wurde, und weil das vor GIB EINHEIT passieren qürde, was bestimmt irgendwelche Probleme und Schlupflöcher nach sich zieht?

Schritte zur Reproduktion:

Wir haben das mit den Parteien waan und atas probiert, in einem Test für Runde 1130, aber inzwischen habe ich auch einen Test.

Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008499)
Enno   
2019-07-31 08:34   
(Zuletzt bearbeitet: 2019-07-31 08:35)

Befehlsreihenfolge, neu:

  1. neue Default-Befehle werden gesetzt
  2. GRUPPE, MACHE TEMP
  3. BENENNE, BESCHREIBE, BEWACHE NICHT, HELFE, KÄMPFE, KAMPFZAUBER, TARNE, URSPRUNG, ZEIGE
  4. BANNER, EMAIL, OPTION, PASSWORT
  5. KONTAKTIERE
  6. BOTSCHAFT
  7. BETRETE ; 1. Versuch
  8. BENUTZE
  9. GIB KOMMANDO
  10. VERLASSE
  11. BETRETE; 2. Versuch
  12. Kontakte werden gelöscht, dann ATTACKIERE
  13. RESERVIERE, BEANSPRUCHE
  14. FOLGE wird gesetzt
  15. GIB, VERGISS
  16. ZERSTÖRE
  17. REKRUTIERE wird erst gemerkt, dann personenweise ausgeführt
  18. STIRB
  19. BEFÖRDERE
  20. BEZAHLE NICHT
  21. ZAUBERE


Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2591 [Eressea] Reportformat kleinerer Fehler nicht getestet 2019-06-11 20:11 2019-07-30 15:26
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.4  
    Zielversion: 3.20.4  
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:
Notiz
(0008497)
Enno   
2019-07-30 15:24   

write_reports() setzt das Passwort, und muss vor write_game() und vor allem (bisher nicht) vor write_database() aufgerufen werden.

(0008498)
Enno   
2019-07-30 15:26   

Release geplant zum kommenden ZAT.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2599 [Eressea] General kleinerer Fehler nicht getestet 2019-07-29 11:39 2019-07-30 12:38
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.4  
    Zielversion: 3.20.4  
Partei: 0
Spiel: E2
Report: 1132
Zusammenfassung: KONTAKTIERE ohne Parameter crasht den Server
Beschreibung:

Auswertung abgestürzt. Braucht eine ordentliche Reparatur mit Tests, atoi36 braucht ein assert, etc.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Warum kann die statische Analyse das nicht finden?

Angehängte Dateien:
Notiz
(0008496)
Enno   
2019-07-30 12:38   

Bug auf die Schnelle gefixt, dann nach dem ZAT noch Tests nachgetragen für ein eventuelles weiteres Release.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2597 [Eressea] Gebäude kleinerer Fehler immer 2019-07-15 09:16 2019-07-30 12:37
Reporter: Xolgrim Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.4  
    Zielversion: 3.20.4  
Partei: 777
Spiel: E2
Report: 1131
Zusammenfassung: Wurmlöcher können nur eine Person transportieren
Beschreibung:

Ich habe letzte Woche in zwei Regionen Wurmlöcher gehabt. Da ich von mehreren Personen gehört habe, dass diese nur eine Person aufnehmen, laut dir aber eigentlich vier Personen durch passen sollten, habe ich einen Test mit 5 1er Einheiten durchgeführt.

Resultat: Wurmlochkundschafter (wurm) reist durch ein Wurmloch nach Nurdquapsch (147,306). [1856344745;id]

Die anderen Einheiten stehen noch in Satranan. Das Verhalten ist im Testreport identisch.
Wird vermutlich nicht helfen, wenn ich das andere Wurmloch auch noch raus suche, sag bescheid wenn du es doch brauchst

Hier die Meldungen und Befehle:
In Satranan (1,-31) erscheint ein Wurmloch. [360943784;id]
Wurmloch (5dn3), Größe 4, Wurmloch.

EINHEIT y0s2; Kater
UNTERHALTE
Gib Temp wurm 200000 Silber
Gib Temp W1 500 Silber
Gib Temp W2 500 Silber
Gib Temp W3 500 Silber
Gib Temp W4 500 Silber

Mache Temp wurm "Wurmlochkundschafter"
rek 1
LERNE TARNUNG
kämpfe flieh
Betrete Burg 5dn3
Ende

Mache Temp w1 "Wurmloch Tester 1"
rek 1
LERNE TARNUNG
kämpfe flieh
Betrete Burg 5dn3
Ende

Mache Temp w2 "Wurmloch Tester 2"
rek 1
LERNE TARNUNG
kämpfe flieh
Betrete Burg 5dn3
Ende

Mache Temp w3 "Wurmloch Tester 3"
rek 1
LERNE TARNUNG
kämpfe flieh
Betrete Burg 5dn3
Ende

Mache Temp w4 "Wurmloch Tester 4"
rek 1
LERNE TARNUNG
kämpfe flieh
Betrete Burg 5dn3
Ende

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008491)
Xolgrim   
2019-07-17 17:55   

Nachtrag 2. Wurmloch:

Das Rekrutierungsmaximum war zu gering, daher hab ich nur einen durch gesendet, hab also nur das eine Beispiel.

(0008492)
Enno   
2019-07-28 22:17   

Das Problem: Wenn die erste Einheit durch das Wurmloch ist, werden alle weiteren Einheiten aus der Zielregion betrachtet, weil die verkettete Liste geändert wurde. Oops.

(0008493)
Enno   
2019-07-28 22:32   

bugfix gefunden.

(0008495)
Enno   
2019-07-30 12:37   

Hier mache ich vielleicht ein Release zum nächsten ZAT.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2600 [Eressea] UNTERHALTE kleinerer Fehler nicht getestet 2019-07-29 11:53 2019-07-30 12:35
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.2  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.20.3  
    Zielversion: 3.20.4  
Partei: bLum
Spiel: E2
Report: 1132
Zusammenfassung: Mehr als 512 Arbeiter pro Region
Beschreibung:

Es gab in der vergangenen Auswertung ein Problem, weil mehr als MAX_WORKERS Einheiten in einer Region gearbeitet haben. Das Limit ist derzeit 512, und eine Partei macht das kaputt.

Schritte zur Reproduktion:
Zusätzliche Informationen:

Es gibt offenbar ein ähnliches Limit bei UNTERHALTE, dort wird aber das Limit nicht getestet, was ganz gefährlicher Scheiss ist.

Angehängte Dateien:
Notiz
(0008494)
Enno   
2019-07-30 12:35   

Ich habe am Sonntag einen Workaround gemacht, und dann noch eine ordentliche Version für 3.21



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2595 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2019-07-07 10:51 2019-07-12 20:39
Reporter: EON Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: keine Änderung notwendig  
Projektion: keine      
Aufwand: keine Behoben in Version:  
    Zielversion:  
Partei: haLb
Spiel: E2
Report: 1130
Zusammenfassung: Hungernde Einheit lernt nicht
Beschreibung:

1128 habe ich einen neu rekrutierten Halbling versehentlich ohne Proviant losgeschickt, wodurch er in 1129 gehungert hat. Aufgrund des neuen Features:

"2574: Die freundlicheren Hungerregeln von E3 gelten jetzt auch in E2: Es gibt weniger Schaden, und Hunger verhindert den langen Befehl nicht."

habe ich ihn lernen lassen, Almosen wurden eingerichten. 1130 hat er zwar scheinbar gelernt (es gab keine Fehlermeldung), aber auch weiterhin keine Talente. Das Almosen wurde gezahlt, er hat also nicht wieder gehungert.
Einheit Pfefferio Pfefferkuchen (phba), Region Pefokapor (be73h)

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008486)
Xolgrim   
2019-07-07 18:47   

@Enno "... und sie lernen deutlich langsamer als normalerweise." das wird vermutlich die Stelle sein, die hier für verwirrung sorgt. Die Frage ist wie genau das implementiert ist, lernen mit normaler Geschwindigkeit, aber mit einer wahrscheinlichkein überhaupt nicht? Oder lernen die immer, aber nicht für 30 'Lerntage'? Sollte dann nicht T0 beim talent stehen, wenn lernzeit vorhanden ist, aber nicht genug für T1?

(0008487)
Enno   
2019-07-12 20:39   

Xolgrim hat es richtig gewusst: Bei Hunger halbiert sich die Lernchance:

if (fval(u, UFL_HUNGER)) {
    days /= 2;
}

Das ist also kein Bug, es fehlt nur eventuell ein Hinweis darauf in der Anleitung.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2581 [Eressea] General kleinerer Fehler nicht getestet 2019-04-27 21:21 2019-06-26 22:00
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.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:

&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?>
&lt;d:error xmlns:d=&quot;DAV:&quot; xmlns:s=&quot;http://sabredav.org/ns&quot;>
  &lt;s:exception>Sabre_DAV_Exception_Forbidden&lt;/s:exception>
  &lt;s:message>Permission denied to overwrite node&lt;/s:message>
&lt;/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

(0008485)
Enno   
2019-06-26 22:00   

Die Leute von box haben sich meinen Support-Case angeguckt, und bei sich etwas repariert. Klappt wieder (bis sie das abschalten, muss ich mir trotzdem etwas neues ausdenken). Augen aufhalten nach anderen Startups oder Google Drive Lösungen?



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2593 [Eressea] LERNE/LEHRE kleinerer Fehler nicht getestet 2019-06-25 05:33 2019-06-26 21:57
Reporter: Enno Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: erledigt Produktversion: 3.20.0  
Produkt-Build: Lösung: erledigt  
Projektion: keine      
Aufwand: keine Behoben in Version: 3.21  
    Zielversion: 3.21  
Partei: 0
Spiel: E2
Report: 1128
Zusammenfassung: LERNE AUTO kann nur begrenzt viele Schüler verarbeiten (MAXSCHOLARS)
Beschreibung:

Die Auswertung 1128 ist mit einer Meldung über zu viele Schüler abgebrochen, weil die Partei Blumenkinder 623 Hiebwaffen-Schüler in der gleichen Region hatte. Da ist ein festes Array mit 512 Einträgen geplatzt.

Schritte zur Reproduktion:
Zusätzliche Informationen:
Angehängte Dateien:
Notiz
(0008482)
Enno   
2019-06-25 05:35   
(Zuletzt bearbeitet: 2019-06-25 05:35)

Lösung: In Zukunft werden bis zu 128 Schüler in einem Batch verarbeitet, die nächsten 128 werden dann behandelt, als wenn sie zu einer anderen Partei gehören.

Evtl. könnte man noch eine smartere Zuteilung machen, indem jeder Batch nur ein Talent betrachtet? Dann kann man sich auch scholar.skill sparen.

(0008484)
Enno   
2019-06-26 21:57   

LERNE AUTO macht jetzt nur noch bis zu 128 Einheiten mit gleichem Talent. Wenn man mehr als 128 Lernende hat, werden die in Blöcken au maximal 128 Einheiten verarbeitet.
Beispiel: Wenn ich 129 Leute habe mit LERNE AUTO Hiebwaffen, lehren sich die ersten 128 untereinander, die letzte ist alleine und wird nicht gelehrt.
Das ist natürlich dann suboptimal, aber man kann das auch einfach lassen, und weniger Einheiten haben.



Eintragsdetails ansehen
ID: Kategorie: Schweregrad: Reproduzierbar: Meldungsdatum: Zuletzt aktualisiert:
2503 [Eressea] Monster Unschönheit nicht getestet 2018-10-21 09:05 2019-06-23 21:13
Reporter: Caranthir Rechnertyp:  
Bearbeitung durch: Enno Betriebssystem:  
Priorität: normal BS-Version:  
Status: Rückmeldung Produktversion: 3.17.0  
Produkt-Build: Lösung: wiedereröffnet  
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.

(0008476)
Caranthir   
2019-06-23 09:05   

Nach meinem Gefühl entstehen Untote immer noch häufiger als vor dem Jungdrachenevent. Gerade sind auf meiner Hauptinsel in zwei Regionen 16 Zombies und 25 Ghoule auferstanden. Ich frage mich, wo die herkommen – gerade erst haben wir auf der Insel die langjährige Untotenvernichtungskampagne beendet und die Insel war monsterfrei. Es gibt auch keine Überbevölkerung.
Auch auf anderen Inseln entstehen immer wieder kleine Untotengruppen. Ich finde das blöd, weil es nicht nachvollziehbar ist. Als Feature für "eine kleine Schlacht zwischendurch" brauche ich das nicht, und irgendwie realistisch oder absehbar ist es auch nicht.

(0008477)
Xolgrim   
2019-06-23 21:12   

Es gibt einen Zauber der Potentielle Untote zur ewigen Ruhe verhilft, schon bevor sie aufstehen und einen der deren Aufstehen ganz verhindert. Ich hab letzteren fleissig gezaubert um meine Ruhe zu haben, kann dir aber auch nicht sagen wo die kleinen Gruppen her kommen. Nur das die Bauernzahl und die der Arbeitsplätze nichts mit den Untoten zu tun haben sollte, zumindest nicht direkt. Wenn die Pest ausbricht (für deren ausbrechen beide Werte hingegen relevant sind) stehen die gestorbenen Bauern halt wieder als Untote auf irgendwann.



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, &quot;LERNE Ausdauer&quot;.

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

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:
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 &quot;Beschwöre einen
  Sturmelementar&quot; 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:
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:
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:
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:
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:
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:
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:
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:
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:
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
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:
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:
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:
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:
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