Im CR wird auch nur die wahre Partei angezeigt, also 1348834;Partei statt 1348834;Partei 573869;Anderepartei

Erste Debug-Ergebnisse:

1. Der Reportcode scheint nicht zu verstehen, dass die Partei getarnt sein soll.
2. Die Einheit hat dem Betrachter kein HELFE PARTEITARNUNG gesetzt, das sieht der Code auch so (alliedunit ist korrekt)
3. visible_faction findet kein at_otherfaction bei der Einheit
4. Die Einheit hat kein at_otherfaction, nur ein at_group

Neue Untersuchung: Wurde das at_otherfaction aus dem Datenfile geladen, oder hat es da schon gefehlt?

Zweiter Versuch:

Es gibt die Attribute im Datenfile, aber read_of checkt rule_stealth_faction & 2, und da es 1 ist, kommt AT_READ_FAIL zurück, weshalb keine at_otherfaction eingelesen werden. Hat sich die Regel geändert? Evtl. bei Verlegung in die JSON Config?

Oha, in der Konfiguration ist rules.stealth.faction ein Boolean, kein Integer. Wenn es ein Integer sein sollte, was sind dann die verschiedenen Ausprägungen? Evtl. nur 2 oder nicht-2 ? Der Code kann da klarer sein.

Ich sehe gerade, der default war früher 0xFF, und ist jetzt 1. Es scheint, das war ein Boolean, und die &2 Bit-Pfuscherei ist ein roter Hering.

Oh nein, Missverständnis. Es gibt scheinbar zwei Formen der Parteitarnung: TARNE PARTEI, und TARNE PARTEI . In E2 gibt es beide, in E3 und E4 nur die anonyme Tarnung?

Die anonyme Tarnung ist UFL_ANON_FACTION, die andere ist atotherfaction. Das sollte im Code durch defines erklärt werden, oder separate rule*() funktionen nicht durch Bitmagie.

Fehler gefunden, lag an einer Änderung im Lesen der Konfigurationsdaten. Das sollte allerdings schon vorige Woche falsch gewesen sein. Merke: Der QA Prozess ist nicht idiotensicher.

PR: https://github.com/eressea/server/pull/377