In der NR-Parteienliste fehlt die Partei auch!

Ich habe einen ähnlichen Fall und auch hier ist es eine Partei aus einer Durchreiseregion. (Runde 396, Partei drac, gesichtete Einheit: - Bärtiger Heiopei (er49), Heiopei (qit), 1 Zwerg.

Das war im Testreport von E3.

@Solthar: War das nur im Testreport? Diskrepanzen zwischen Testreport und offizieller Version bitte immer sofort melden, die sind mir fast wichtiger als "normale" Bugreports.

Ja, das betraf in dem Fall nur den Testreport.

Muss ich mir also unbedingt vor dem Wochenende noch ansehen. Seufz.

Region ist 900467642 Man würde erwarten, dass cb_add_address in der Region aufgerufen wird, wenn mein Report erzeugt wird, das passiert aber wohl nicht. Entweder ist die Durchreise also nicht registriert worden, oder die Region ist nicht im Report-Interval?

travelthru_add wird in der Region nie aufgerufen. Warum?

In meinem Report steht an der Region "Die Region wurde durchquert von Zeitreisender (vnzi)." Das passt zu der Beobachtung ja mal gar nicht.

Kann es sein, dass die Einheit bei einer Neu-AW vor NACH verschwunden ist? Im Kampf gestorben?

Oh, shit, ja. Die dummen Skelette in Bisur greifen ihn an.

Wenn ich die Monsterattacke blockiere, wird die Durchreise in travelthru_add registriert. Prima. OMG! Das ist gar keine andere Partei. Das sind Kleine Mannen, die sich als Tiamats Kinder parteigetarnt haben. Warum führt das im CR dazu, das keine Partei gezeigt wird? Evtl. ist die Durchreise die ganze Zeit ein roter Hering gewesen.

Was geht hier vor? Die KM haben mir kein HELFE PARTEITARNUNG gesetzt, also:

sf = visible_faction(f, u); // liefet TK (die Tarnung)

Dann wird das kurz darauf noch einmal berechnet (Warum?):

const faction *otherfaction =
    a_otherfaction ? get_otherfaction(a_otherfaction) : NULL;

Das ist natürlich wieder Tiamat. Es wird dann ein ;Partei Attribut in den CR geschrieben mit sf->no (Tiamat), aber da ich die Partei anderswo nicht im CR habe, ist sie nicht in der Adressliste.

Das Problem ist hier also, dass die Partei nicht in der Adressliste steht, weil ich sie nicht sehe. Ich sehe aber eine Einheit, die als Tiamat getarnt ist, deren Tarnung ich nicht erkennen kann (aber die natürlich dadurch jetzt aufgeflogen ist).

Hm, meine Beobachtung stammt aber aus dem Testreport E3 und da gibt es diese Art von Parteitarnung gar nicht. Ist das demnach ein eigener Bug?

Das kann natürlich sein, dass das ein anderes Problem ist. Ich habe das gestern nicht mehr reproduziert, nachdem ich zwei Stunden an der Parteitarnungs-Sache gesessen habe, bis ich die auf ihre Ursache reduziert hatte. Werde ich dann wohl heute Abend machen.

Wir haben uns entschieden, dass ich die Partei in der Adressliste haben sollte. Ich habe das Problem gerade eben auf einen roten Unit-Test reduziert.

Hier liegt der Hund begraben:

bool ballied = sf && sf != ctx->f && sf != lastf
    && !fval(u, UFL_ANON_FACTION) && cansee(ctx->f, r, u, stealthmod);
if (ballied || is_allied(ctx->f, sf)) {
    add_seen_faction_i(&flist, sf);

ballied ist false (weil sf==lastf), und is_allied ist auch false (Allianzen sind eh nur ein E3-Feature). Was soll der Code? Speziell das mit lastf ist komisch.

Oh, lastf!=sf heisst einfach, das die Partei, die wir für die vorherige Einheit registriert haben, nicht die gleiche ist, wie diese hier. Weil, wenn es die gleiche ist, kann man sich den teuren call nach add_seen_faction_i sparen.

Hier ist das aber so: Die Einheit ist getarnt als die Partei der Einheit vor ihr.

Oh, ich sehe gerade, der Test denn ich eben geschrieben habe ist eh verkehrt, weil selist_find anders funktioniert, als ich gedacht hatte.

Jetzt ist mein Test nicht mehr rot, muss mir was neues überlegen. Da ist eine Einheit der Partei, als die sich getarnt wird, in der Region. Das darf ja für unseren Bug nicht sein.

Oh, lauter falsche Fehler. Der Code-Path ist ein anderer für Durchreiseregionen (add_travelthru_addresses), und mein Test hat das nicht richtig reproduziert. Da wird am Ende cb_add_address aufgerufen, was für eine Durchreise-Region die Parteien allee Einheiten einträgt, wenn man diese sehen kann. Dabei wird in cansee_unit ein Parameter stealthmod übergeben, der -1 ist, weil das vorher von stealth_modifier(r->seen.mode) so bestimmt wurde. Der Adress-Code glaube also, die Einheit sei nicht sichtbar! Das glaubt aber der Rest des Report-Codes nicht?

Der Code, der die Einheit ausgibt, sieht so aus:

        if (u->building || u->ship || (stealthmod > INT_MIN
            && cansee(f, r, u, stealthmod))) {

Der ruft also cansee auf, und nicht cansee_unit. Testet aber dafür auf Schiffe und Gebäude (was cansee_unit auch tut). Das ist offenbar so, weil cansee alle Einheiten in der Region nach einem Wahrnehmer durchsuchen muss.

Die von mir gesehene Einheit steht auf einem Schiff, deshalb sollte sie auch für Durchreisende immer sichtbar sein. Mein Test bildet das nicht ab.

Oh, ich glaube, der Aufruf von cansee_unit() hat die Einheiten in der falschen Reihenfolge! Das ist es. Heureka!

fixed in commit 7f03417

fixed, awaiting merge into eressea/server

Die Version 3.11 ist historisch, alle gefixten Bugs scheinen keine Probleme zu haben.