View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003048EresseaMagiepublic2024-10-03 16:372025-02-09 12:03
ReporterSolthar Assigned ToEnno  
PrioritylowSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version29.3.1 
Target Version30.1Fixed in Version30.1 
Summary0003048: Gesang der Versklavung doppelt gezaubert führt zu Problemen
Description

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!

Steps To Reproduce

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
TagsNo tags attached.
Faction1wpy
GameE2
Report1372

Activities

Enno

Enno

2024-10-04 17: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 10:46

administrator   ~0010345

Was ist denn set_debug? Die Funktion kenne ich nicht.
Enno

Enno

2025-01-25 10:47

administrator   ~0010346

Last edited: 2025-01-25 10: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 10:51

administrator   ~0010347

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

Enno

2025-01-25 10: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 17: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 17:11

administrator   ~0010351

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

Enno

2025-01-25 17: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 15:21

developer   ~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.
Enno

Enno

2025-02-09 12:03

administrator   ~0010364

https://github.com/eressea/server/pull/1110

Issue History

Date Modified Username Field Change
2024-10-03 16:37 Solthar New Issue
2024-10-03 19:48 Solthar Product Version 29.4 => 29.3.1
2024-10-03 19:54 Solthar Description Updated
2024-10-04 17:47 Enno Assigned To => Enno
2024-10-04 17:47 Enno Status new => assigned
2024-10-04 17:50 Enno Note Added: 0010245
2024-10-04 18:51 Solthar Steps to Reproduce Updated
2024-10-16 07:13 Enno Priority normal => low
2025-01-25 10:46 Enno Note Added: 0010345
2025-01-25 10:47 Enno Note Added: 0010346
2025-01-25 10:47 Enno Note Edited: 0010346
2025-01-25 10:51 Enno Note Added: 0010347
2025-01-25 10:52 Enno Status assigned => feedback
2025-01-25 10:52 Enno Note Added: 0010348
2025-01-25 17:05 Enno Note Added: 0010350
2025-01-25 17:11 Enno Status feedback => assigned
2025-01-25 17:11 Enno Note Added: 0010351
2025-01-25 17:28 Enno Note Added: 0010352
2025-01-26 15:21 Solthar Note Added: 0010354
2025-02-09 12:03 Enno Status assigned => resolved
2025-02-09 12:03 Enno Resolution open => fixed
2025-02-09 12:03 Enno Fixed in Version => 30.1
2025-02-09 12:03 Enno Note Added: 0010364
2025-02-09 12:03 Enno Target Version => 30.1