@trostlos: Danke für das Staubild! Das sagt mehr als 1000 Worte.
Interessant ist die Stelle, wo 2 Siedler hin und her "zittern"; das ist regelmässig die Stau-Ursache. Zittern sieht man in einem Standbild nicht , daher muss folgende Hilfsbetrachtung reichen:
Wo stehen 2 Siedler Gesicht in Gesicht blickend? Alle anderen stehen nämlich brav in geplanter Gehrichtung!
Hier gibt es 2 Stellen, wo das geschieht - die Lupe zeigen die Orte in der Edi-Ansicht. Man sollte daher das Bild von Trostzlos nebenbei sehen können.
An solchen solchen Uferlinien hat der S3-Wegegenerator für Träger Probleme. Solis haben vermutlich einen besseren Algorithmus, der i.d.R. (fast) keine Staus erzeugt.
Leider kann man als Mapper nur bedingt was dagegen tun.
Entscheidend ist der Weg von A nach B: bei A steht ein arbeitsloser Träger, der bei B was erledigen soll.
Beide Punkte A und B bestimmt der Spieler, weil er Werkstätten/Baustellen/Lager usw. setzt, die dann Waren brauchen oder Waren liefern. Wenn dann die gedachte Gerade A-B durch eine Uferlinie unterbrochen wird, erhöht das die Staugefahr.
Der LV-Turm ist zu weit weg und kann eigentlich nicht die Ursache sein.
Wenn man den Steg bei der LV setzt (=LV mit Land verbunden), dann bekommen die Gegner ein Angriffszeil und marschieren los; der Grüne geht unten rum, weil das der kürzere Weg ist.
Entfernt man den Steg wieder, bleiben erst mal alle Solis kurz stehen. Danach wollen einige wieder zurück und stehen dann Gesicht gegen Gesicht gegen diejenigen, die immer noch zur LV laufen wollen.
Der Bug ist eigentlich ein Programmfehler. Folgende Überlegung möchte das zeigen: Ein Siedler kann nur auf ein leeres Pixel laufen (ohne Gebäude, Stein, Begrenzungsstein). Bevor ein Siedler zu laufen beginnt, muss also überprüft werden, ob das Pixel frei ist. Das muss geschehen, bevor ein Siedler losläuft.
Wenn 2 Siedler auf der Stelle "zittern", kann das nur bedeuten: beide Siedler wissen nicht, dass ihr nächstes Pixel schon besetzt ist. Sie laufen beide los, bemerken dann aber das besetzte Pixel, also Schritt zurück und das immer.
Wichtig ist daher für Programmierer, dass ein Ergebnis im Spiel erst festgezurrt sein muss und dann erst das Ereignis startet.
Man kann das gut beobachten, wenn Schwerti z.B. Pios bekämpfen: Der Pio verwolkt schon vor dem letzen Treffer.
Ein Bild zur Situation gibt es unter S3-Screenshots