Soweit ich mich erinnere:

Für Zauber mit expliziten Zielen (Einheiten) im Befehl ist verify_targets immer die richtige Lösung, und es sollte kein weiterer Test nötig sein. Wenn ein Zauber alle Einheiten in einer angegebenen Region betrifft, muss er die Einheiten selber testen (verify_targets testet dann nur gegen die Resistenz der Region an sich).

Ich gucke mir die genannten Zauber mal an, und schaue, ob es evtl. noch mehr gibt.

Du hast hier als Beispiel die Einheit einh der Partei ii in Runde 1372 genannt. Das ist, soweit mir bekannt, nicht deine PArtei, und die Einheitennummer erscheint mir auch unwahrscheinlich. Gehe ich Recht in der Annahme, dass das kein Fall ist, den ich reproduzieren kann, sondern aus purer Lektüre des Codes gefolgert wurde?

Lua-Testfall, Debugging und Lektüre, ja.

Hier ist es diskutierbar, weil sp_charmingsong wie gesagt eigene Regeln festlegt. Ob diese Ausnahme gerechtfertigt ist, ist die Frage.

Bei sp_enterastral (Astraler Weg), sp_babbler, sp_readmind trifft es zu, da tut es der allgemeine Aufruf (es sei denn, man wollte hier eine höhere Chance auf Widerstand.

Es gibt andere Fälle, wo es sinnvoll ist, dass target_resists_magic oder magic_resistance oder is_magic_resistant direkt aufgerufen werden. Zum Beispiel sp_earthquake oder sp_petrify und andere Kampfzauber, weil die keine Parameter haben.

Ich finde den Unterschied zwischen sp_enterastral und sp_treewalkenter spannend. enterastral macht bei jedem Ziel einen Test auf is_magic_resistant, treewalk tut das nicht. Du hast sicher Recht, dass das im Zauber selbst nicht gemacht werden muss, es sei denn, man will besondere Regeln für einen Bonus oder Malus implementieren. Dann sollte man allerdings nicht doppelt testen. Das ist soweit ich sehe, nur bei sp_charmingsong so. Ob das wirklich nötig ist, oder man einfach die Anzahl Personen direkt an die Spruchstärke (force) koppeln sollte, weiß ich nicht. Einfacher wäre es. Klingt mir nach einer nicht sehr gut überlegten Sonderregel, die von jemandem ersonnen wurde, ohne das Framework zu verstehen.

Noch eine Bemerkung:

Es gibt Zauber, die im Falle dass ihr Ziel wegen Magieresistenz verfehlt wird, trotzdem Kosten verursachen (sp_sparkle, sp_destroy_magic, uvm) und solche, die das nicht tun (sp_readmind, sp_babbler, sp_eternizewall usw). Die machen meist sowas:

    /* wenn Ziel gefunden, dieses aber Magieresistent war, Zauber
     * abbrechen aber kosten lassen */
    if (params[0].flag == TARGET_RESISTS)
        return cast_level;
    /* wenn kein Ziel gefunden, Zauber abbrechen */
    if (params[0].flag)
        return 0;

Ich glaube, das sollten alle Zauber tun. Unterschied scheint zu sein, dass ich für die Zauber mit dem TARGET_RESISTS Check vor einem Jahr (Version 28.3: "Zauberkosten sind abhängig von der Zauberstufe") Tests geschrieben habe. Ich hatte das wohl schon einmal in Bearbeitung, bin aber nicht dazu gekommen, das für alle Zauber zu machen, weil es so viel Aufwand ist, Tests für jeden einzelnen zu schreiben, und ich das bei der Gelegenheit gleich auch tun wollte.

Dann gibt es noch Zauber, die bei einem Ziel mit Resistenz nicht fehlschlagen, sondern nur reduzierte Wirkung haben. sp_babbler ist so einer. Oder sie geben dem Ziel eine Warnung, wie sp_readmind das tut.

Die sollten stattdessen einfach auf TARGET_RESISTS checken, glaube ich? Statt direkt mit if (param->flag) return 0; abzubrechen.

sp_treewalk_exit ist komisch: Hier wird TARGET_RESIST geprüft, aber auch, ob die Einheit kontaktiert.

Verstehe ich nicht, was da falsch sein soll. Da wird erst geprüft, ob die Magieresistenz gewirkt hat. Wenn nicht, dann wird geguckt, ob die Einheit kontaktiert. Wer nicht kontaktiert, den kann der Zauber nicht teleportieren. Um zu teleportieren (im letzten else), muss die Einheit:

1. Nicht magieresistent sein,
2. kontaktiert haben, und
3. nicht zu schwer sein. Wenn eine Einheit wegen Magieresistenz ausscheidet, wird der Zauber trotzdem bezahlt, in den anderen beiden Fällen wird für sie eine entsprechende Fehlermeldung erzeugt. sp_treewalkenter macht das ähnlich, aber da wird nicht gezahlt, wenn eine Einheit widersteht der nicht gefunden wurde.

Wenn man das einheitlich machen wollte, sollte man in treewalkenter bei TARGET_RESISTS die Kosten setzen, und getrennt auf TARGET_NOTFOUND prüfen.

Update: Ich sehe, dass beide Zauber einen Test haben, und das mit dem Preis bei Resistenz da auch uneinheitlich geregelt ist. Ich repariere.

Was ich nicht so recht verstehe, ist warum TARGET_NOTFOUND und TARGET_RESISTS als bitfield gelöst sind, und nicht als enum. Hmm.

Ich habe mit Änderungen begonnen, siehe https://github.com/eressea/server/pull/1089

Wer kontaktiert ist automatisch nicht magieresistent. Es ist also unsinnig, beides vorauszusetzen.

https://github.com/eressea/server/blob/996ab208d96faa6fa9bb16333d8084defd9287b5/src/magic.c#L1094

Aber nicht umgekehrt. Wenn ich ein Ziel angebe, das mich nicht kontaktiert hat, und das nicht genug Magieresistenz hat, soll das nicht teleportiert werden. Sonst könnte man damit Feinde gegen ihren Willen in den Astralraum schubsen.

Ja das stimmt. Aber was ich sage ist, dass der Test auf Magieresistenz dann überflüssig ist, wenn ich sowieso kontaktiere voraussetze. Nicht unbedingt falsch, aber überflüssig. Und bei treewalk_enter fehlt der Test auf Magieresistenz (deshalb?) auch richtigerweise.

Der Test auf Magieresistenz ist nicht überflüssig, weil er darüber entscheidet, ob der Zauber etwas kosten soll.

Wer resistent ist, wird nicht verzaubert, kostet aber den Zauberer Aura. Wer nicht resistent ist, hat entweder kontaktiert oder nicht. Aus "wer kontaktiert ist nicht resistent" folgt nicht die Umkehrung "wer nicht resistent ist, hat kontaktiert". Im Falle eines Kontaktes wird die Einheit transportiert, andernfalls gibt es eine Fehlermeldung, und der Zauber kostet nichts.

Ja, aber wer resistent ist, hat nicht kontaktiert, also offensichtlich vergessen, zu kontaktieren. Welchen spielerischen Sinn ergibt es, die zaubernde Einheit zusätzlich dafür zu bestrafen? Es ist schlimm genug, dass der Zauber nicht funktioniert.

Dies unterscheidet sich von der Situation, in der ich einen schädlichen Zauber wirke, der vielleicht funktioniert oder nicht, aber in beiden Fällen Aura kosten soll.

Aber mal zu dem eigentlichen Problem: sp_charmingsong möchte die Resistenz gerne selber prüfen, mit eigenen Modifikatoren. Das ist dann doppelt gemoppelt, weil es schon in verify_targets gemacht wird. Am liebsten möchte man verify_targets für den Zauber selektiv abschalten können. Und wenn man mal guckt, gibt es da einen Check if (((sp->sptyp & NORESISTANCE) == 0) der genau das tut. Ich sehe nur noch nicht, wie das gesetzt wird.

Ah, gefunden. Man muss dafür in spells.xml noresist="true" an den Zauber schreiben. Das ist aktuell nur bei Aushorchen und Auratransfer und zwei Astralraumzaubern gesetzt.

Oh, ich sehe. Du willst argumentieren, dass der Zauber im Fall von Resistenz nichts kosten soll. Das Argument halte ich auch für vertretbar. Weil man ihn ja nur auf befreundete, also kontaktierende Einheiten spricht, sollte Resistenz nicht vorkommen, es sei denn man macht einen Fehler beim kontaktieren. Stimmt, glaube ich.

Alternative Lösung für sp_charamingsong:

Wenn eine Einheit einen Bonus P_bonus auf die Resistenz kriegt (zu groß oder teure Talente), dann machen wir einen neuen Würfelwurf. Und zwar so, dass die Resistenzchance P_unmodifiziert * P_neu = P_modifiziert ist. P_unmodifiziert ist der Test, den wir schon gemacht haben, P_modifiziert ist P_unmodifiziert + P_bonus, dann ist P_neu = (P_unmodifiziert + P_bonus) / P_unmodifiziert.

Schwere Geburt, aber ich glaube, damit stimmt die Magieresistenz vom Gesang der Versklavung jetzt: https://github.com/eressea/server/blob/fffa33497361d7222c7bf65da20de2302e76d000/src/spells.c#L3502

Nächster Zauber: sp_pump (Aushorchen) testet das Ziel auch doppelt aus Resistenz. Aber ohne Bonus, das kann man also sicher einfach löschen.

Check. Nächster Fall ist dann sp_enterastral (Astraler Weg). Da kann man sicher auch einfach das is_magic_resistant löschen, aber der Test für den Zauber ist komplizierter zu schreiben (und ich habe mir vorgenommen, das alle Zauber an denen ich ändere bei der Gelegenheit auch Tests kriegen). Das wird heute nicht mehr fertig.

Ich glaube, jetzt habe ich sie alle erwischt. Es wird nur noch an zwei Stellen in spells.c target_resists_magic aufgerufen (in sp_earthquake auf alle Gebäude der Region, und in dc_age für alle Regionen, die unter einem Fluch stehen)

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