Auch das klingt mir sehr nach einem Featurewunsch. Den Regeln entspricht es auf jeden Fall (was ein unangekündigter bzw. ungewollter Bugfix sein könnte): https://wiki.eressea.de/index.php/Andere_Geb%C3%A4ude#Leuchtturm sagt Kapazität: 4 Personen.

Es gibt offenbar keine Partei ct0d in E3. Kann die Sache daher gerade nicht nachvollziehen.

Aha! Ruhmsucher (xuhw) gehört zur Partei 6t0d. Tippfelher.

In reports.c:1444 steht:

                if (u->building && u->building->type == bt_lighthouse && inside_building(u)) {

Der Ausdruck inside_building(u) ist false, weil die Kapazität 4 ist, und eine 12-Personen Einheit den ganzen Platz beansprucht, deshalb bekommen beide Einheiten den Effekt des Leuchtturmes nicht. Soweit ist das alles im Rahmen der Regeln. Ergo: Featurewunsch.

Generell finde ich es nicht verkehrt, wenn die ersten vier EINHEITEN statt der ersten vier PERSONEN den Effekt des Leuchtturmes bekommen würden, aber da ich selber keine Leuchttürme besitze, in denen mehr als eine Person steht, würde ich da erst die Spieler befragen wollen. Selbst dann fehlt mir die Zeit für Features, die nicht jemand anderes implementiert, da ich mich demnächst primär um Bugs kümmern möchte. Davon haben wir gerade wieder genug.

Verstehe ich alles, aber 2 Anmerkungen habe ich da doch noch:

1. Die 12er Einheit sieht die Regionen. Wäre auch echt bescheiden wenn man den Unterhalt bezahlt und dann nix sieht weil die Eineheiten aus zu vielen Personen besteht. Das ganze ist auch unlogisch.
2. Es ging die letzen 7 Jahre. Die Anleitung als Master heranzuziehen halte ich nicht für den besten Weg. Da steht genug falsches drin. Daher sehe ich das durchaus als Bug.

Und was spricht gegen die Änderung das Größenlimit einfach ganz zu entfernen? Das ist in 5 min gemacht, und ich sehe da kein unfairen Vorteil oder Nachteil im Spiel. Man kann halt Einheiten mit anderen Aufgeben auch mit in den Leuchtturm stellen.

Du unterschätzt glaube ich, wie kompliziert die Erstellung des Reports (und Liste der anzuzeigenden Regionen) ist, und die Anzahl Tests, die davon betroffen sind. Aber ich glaube auch, das Limit hier nicht einzubeziehen ist die beste Lösung, und kann mir das als Feature für das nächste Release vorstellen. Priorität haben aber trotzdem die Untoten, mit denen ich immer noch nicht fertig bin.

Heute habe ich mir das mal wieder ansehen wollen: Der Code im develop Branch hat sich seit meiner ersten Untersuchung stark geändert, die Zeile reports.c:1444 sieht jetzt komplett anders aus. Aber das Verhalten ist noch immer das selbe. Ich bleibe dran.

Starting a new feature branch: feature/2337-lighthouse-capacity

Aha. Der neue Code ruft nicht inside_building auf, weil das O(n^2) war. Der zählt mit, während er durch die Einheiten scannt:

                if (u->building && b != u->building) {
                    b = u->building;
                    c = buildingcapacity(b);
                    br = 0;
                }
                c -= u->number;
                if (u->faction == f && c >= 0) {

Das muss dann alles anders, wenn es die Kapazität ignorieren soll.

Wenn ich den Code ändere, gibt es einen Test, der das anmeckert, den sollte ich also wohl als erstes Mal anpassen: 1) test_prepare_lighthouse_capacity: C:\Users\Enno\Documents\Eressea\git\src\reports.test.c:496: expected <1> but was <2>

Die korrekte Vorgehensweise ist hier bestimmt, buildingcapacity() für einen Leuchtturm irgendwie unendlich groß zu machen (INT_MAX sollte reichen). Das kann man aber, soweit ich es sehe, derzeit (noch) nicht über die XML config machen.

buildingcapacity hat keine Tests, also habe ich die erst einmal nachgeliefert.

Blöderweise haben wir sowohl eine maxsize als auch eine maxcapacity für Gebäude. Wenn das Gebäude eine size >= maxsize hat, gilt maxcapacity sonst size * capacity. Oft (aber wohl nicht immer) ist maxsize == maxcapacity, aber für evtl. existierende Ausnahmen ist der Code extra verkompliziert. Wenn ich daran aber bastele, um diese Änderung zu vereinfachen, dann mache ich evtl. ein anderes Gebäude kaputt. Das wäre natürlich Mist, deshalb muss ich hier mit extra Vorsicht vorgehen, und das nicht im Halbschlaf machen.

Kann man die Sache reduzieren auf 1. Gebäude, die eine Kapazität haben, die von ihrere Größe abhängt (size * capacity), und solcher, die bei Vollendung eine Kapazität haben (if (size>=maxsize) maxcapacity)? Es lohnt sich bestimmt, die existierenden Gebäude erst einmal in solchen Gruppen zu klassifizieren, und dann Tests für jede Sorte zu schreiben.

Ich habe das jetzt glaube ich entwirrt, und so gelöst, dass die Kapazität von Leuchttürmen sich auf die Anzahl der Einheiten, nicht Personen, bezieht. Als Resultat erscheint in 411-6t0d.nr:

Capygilbos (14,-3) (vom Turm erblickt), Hochland, 134/40 Bäume, 609 treue Bauern, 33 Pferde.

So war das wohl gewünscht.

Änderung ist in PR https://github.com/eressea/server/pull/710