Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0003048EresseaMagieöffentlich2025-01-26 16:21
ReporterSolthar Bearbeitung durchEnno  
PrioritätniedrigSchweregradkleinerer FehlerReproduzierbarnicht getestet
Status zugewiesenLösungoffen 
Produktversion29.3.1 
Zusammenfassung0003048: Gesang der Versklavung doppelt gezaubert führt zu Problemen
Beschreibung

Im Test gibt es Probleme, wenn eine versklavte Einheit erneut verzaubert wird:

Runde 0

Einheit a; Partei A
ZAUBERE "Gesang der Versklavung" b

Runde 1: --> Einheit b gehört nun zu Partei A.

Einheit c; Partei B
ZAUBERE "Gesang der Versklavung" b

Runde 2: Einheit b gehört wieder zu b. Es gibt zwei Meldungen (die bei beiden Parteien erscheinen):

  * Einheit b6gv (b), anonym, 10 Menschen, aggressiv.
   Einheit b (b) wird noch 1 Woche unter unserem Bann stehen. (yvLd)
   Einheit b (b) wird noch 2 Wochen unter unserem Bann stehen. (3pLn)

Runde 3: Einheit b gehört immer noch zu b.

 * Einheit ddhk (b), anonym, 2 Menschen, aggressiv.
    Einheit ddhk (b) wird noch 1 Woche unter unserem Bann stehen. (3pLn)

Runde 4: Einheit b gehört nun dauerhaft zu a! Ein mindestens überraschendes Ergebnis. Ich denke, die zweite Versklavung sollte entweder automatisch fehlschlagen oder den ersten Zauber aufheben (oder die Einheit sollte dauerhaft zum Schlumpf werden).

Es gibt noch einen weiteren Bug im Code

/* Auf eigene Einheiten versucht zu zaubern? Garantiert Tippfehler */
    if (target->faction == mage->faction) {
        /* Die Einheit ist eine der unsrigen */
        cmistake(mage, co->order, 45, MSG_MAGIC);
    }

Hier fehlt ein return 0; Das führt sonst zu noch seltsamerem Verhalten!

Schritte zur Reproduktion

Aufgrund von Patzern wird der Test leider nicht immer dasselbe Ergebnis bringen...

function test_charming()
    local r1 = region.create(0, 0, 'plain')
    local f = faction.create('human', "charmer@eressea.de", "de")
    local f2 = faction.create('human', "charmee@eressea.de", "de")
    local u1 = unit.create(f, r1, 1)
    local u2 = unit.create(f2, r1, 2)
    local u3 = unit.create(f2, r1, 1)
    u1.id = 10
    u2.id = 11
    u3.id = 12
    f.id = 10
    f2.id = 11

    u1.magic = 'cerddor'
    u1:set_skill('magic', 24)
    u1.aura = 1000
    u1:add_spell('song_of_slavery')

    u1:add_order("ZAUBERE 'Gesang der Versklavung' b")
    u3.magic = 'cerddor'
    u3:set_skill('magic', 24)
    u3.aura = 1000
    u3:add_spell('song_of_slavery')

    set_debug(1)
    process_orders()
    set_debug(0)
    -- write_reports()

    u1:clear_orders()
    u3:add_order("ZAUBERE 'Gesang der Versklavung' b")
    process_orders()
    -- write_reports()

    for i = 1,10 do
        u1:clear_orders()
        u3:clear_orders()
        process_orders()
        -- write_reports()
    end

    assert_equal(f2, u2.faction)
end
TagsKeine Tags zugeordnet.
Partei1wpy
SpielE2
Report1372

Notizen / Dateien

Enno

Enno

2024-10-04 19:50

Administrator   ~0010245

Kleiner Tipp: Mit eressea.settings.set("magic.fumble.enable", "0") kann man in Lua-Tests die Patzer abstellen (und in C Tests entsprechend mit config_set("magic.fumble.enable", "0");

Ähnliche Variablen gibt es für Magieresistenz: (magic.resist.enable), Bauernwachstum (rules.peasants.growth.factor), Auraregeneration (magic.regeneration.enable) und vieles mehr.

Enno

Enno

2025-01-25 11:46

Administrator   ~0010345

Was ist denn set_debug? Die Funktion kenne ich nicht.

Enno

Enno

2025-01-25 11:47

Administrator   ~0010346

Zuletzt bearbeitet: 2025-01-25 11:47

Tipp zu der Sache mit den Patzern und der Reproduzierbarkeit von Zaubern in Tests:

    eressea.settings.set("magic.resist.enable", "0")
    eressea.settings.set("magic.fumble.enable", "0")
    eressea.settings.set("magic.regeneration.enable", "0")
Enno

Enno

2025-01-25 11:51

Administrator   ~0010347

Ich kann das Problem nicht reproduzieren, der beigefügte Test schlägt nicht fehl.

Enno

Enno

2025-01-25 11:52

Administrator   ~0010348

@Solthar erinnerst Du dich noch an diesen Bug? ISt das eventuell inzwischen anderweitig gefixt worden? Das mit dem return 0; sehe ich, das ändert aber auch nichts.

Enno

Enno

2025-01-25 18:05

Administrator   ~0010350

Oho, ich sehe gerade, dass das mit "magic.resist.enable" nur target_resists_magic betrifft, nicht Zauber, die eigene Magieresistenz-Regeln haben (wie sp_charmingsong). Das macht für das Spiel keinen Unterschied, ist aber natürlich Mist für verlässliche Tests.

Enno

Enno

2025-01-25 18:11

Administrator   ~0010351

Mit der Änderung an der Magieresistenz schlägt der Test jetzt jedesmal fehl.

Enno

Enno

2025-01-25 18:28

Administrator   ~0010352

Das hier ist eine Katastrophe:

    {
        trigger *trestore = trigger_changefaction(target, target->faction);
        /* laeuft die Dauer ab, setze Partei zurueck */
        add_trigger(&target->attribs, "timer", trigger_timeout(duration, trestore));
        /* wird die alte Partei von Target aufgeloest, dann auch diese Einheit */
        add_trigger(&target->faction->attribs, "destroy", trigger_killunit(target));
        /* wird die neue Partei von Target aufgeloest, dann auch diese Einheit */
        add_trigger(&mage->faction->attribs, "destroy", trigger_killunit(target));
    }
    /* sperre ATTACKIERE, GIB PERSON und ueberspringe Migranten */
    create_curse(mage, &target->attribs, &ct_slavery, force, duration, zero_effect, 0);

Weil das alles einzelne, unzusammenhängende Attribute sind, kann man die nicht einfach auflösen oder ersetzten, wenn die Einheit erneut verzaubert wird.

Aber dazu kommt: Selbst wenn die Einheit zu ihrer alten Partei zurückkehren würde, dann würde der Tod der Partei des Zauberers sie immer noch auslöschen! Wegen dem zweiten trigger_killunit lebt die extrem gefährlich.

Solthar

Solthar

2025-01-26 16:21

Entwickler   ~0010354

set_debug ist mir rein gerutscht. Ist ein Schalter, der bei mir Debug-Ausgaben scharf schaltet. Ich habe keinen C-Debugger.

Trigger sind generell sehr zerbrechlich, scheint mir. Da werden immer irgendwelche Edge-Cases vergessen. Das könnte man natürlich über Magie im Allgemeinen auch sagen.

Ich frage mich, wie viele Einheiten mit Selbstzerstörungsknopf in Eressea herumlaufen ...

Ja, der Bug existiert noch.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2024-10-03 18:37 Solthar Neuer Eintrag
2024-10-03 21:48 Solthar Produktversion 29.4 => 29.3.1
2024-10-03 21:54 Solthar Beschreibung aktualisiert
2024-10-04 19:47 Enno Bearbeitung durch => Enno
2024-10-04 19:47 Enno Status neu => zugewiesen
2024-10-04 19:50 Enno Notiz hinzugefügt: 0010245
2024-10-04 20:51 Solthar Schritte zur Reproduzierung aktualisiert
2024-10-16 09:13 Enno Priorität normal => niedrig
2025-01-25 11:46 Enno Notiz hinzugefügt: 0010345
2025-01-25 11:47 Enno Notiz hinzugefügt: 0010346
2025-01-25 11:47 Enno Notiz bearbeitet: 0010346
2025-01-25 11:51 Enno Notiz hinzugefügt: 0010347
2025-01-25 11:52 Enno Status zugewiesen => Rückmeldung
2025-01-25 11:52 Enno Notiz hinzugefügt: 0010348
2025-01-25 18:05 Enno Notiz hinzugefügt: 0010350
2025-01-25 18:11 Enno Status Rückmeldung => zugewiesen
2025-01-25 18:11 Enno Notiz hinzugefügt: 0010351
2025-01-25 18:28 Enno Notiz hinzugefügt: 0010352
2025-01-26 16:21 Solthar Notiz hinzugefügt: 0010354