Verteilung der Konvois

[partyschreck]

Ich glaube, dom700 beschreibt hier eher den Fall, wo die Verteilung der Fahrzeuge allein über Signale nicht ausreicht, so dass sie sich in der einen Streckenhälfte sammeln.
Du hast dann drei Möglichkeiten:

1. Richte die Blöcke so groß ein, dass deren Anzahl der der Fahrzeuge entspricht.

2. Auch hier funktioniert die Anpassung der Umsteigewerte so, dass es nicht zu diesem Fall kommt (ich arbeite hier aber auch gerne mit Signalen).
Bei Strassenbahnen muss mit sehr hohen Prozentwerten gearbeitet werden (70-100%)

3. Ignorieren. Die Strassenbahnen sind so schnell, dass das nicht unbedingt schlimm ist. (wenn das Netz nicht zu groß ist)

Nachtrag: Bei Streckenüberlastung kann es sogar dazu kommen, dass sich die Fahrzeuge wieder entzerren, weil das davorfahrende Fahrzeuge die Passagiere aufnimmt die schneller wieder aussteigen.
Allerdings hat man nicht viel davon.

[dom700]

Tatsächlich ist die Lösung meistens do-nothing Auch, weil das oftmals nur in einer kurzen Zeit des Städtewachstums passiert

[renke]

Danke für die ganzen Hinweise - ich spiele damit mal rum.

Bisher war mir dieses Verhalten so nie aufgefallen, weil die anderen von mir verwendetem paks (German, pak64, Britain) deutlich höhere Margen haben: Am Anfang eine Kohlenstrecke einrichten und mit dem eingefahrenen massigen Gewinn den ganzen Personen- und Mailtransport finanzieren.

pak128 ist, ähm, anders.

Die fixen Kosten für die Infrastruktur sind im Verhältnis so hoch, dass sich 1930 (Standard-Startjahr) eine simple p2p Mine-zu-Kraftwerkstrecke irgendwie nicht lohnt; die eingefahrenen Gewinne werden von den monatlichen Kosten sofort aufgefressen. Nachdem mir das zwei mal passierte habe ich eben mit dem Startkapital einen Personen- und Postverkehr hochgezogen, vollständig straßenbasiert und nur unter Nutzung der vorhandenen Strecken (Fixkosten waren damit nur die Haltestellen). Das geht finanziell so gerade eben, aber sobald die Fahrzeuge auf der Linie sich stauen war das _deutlich_ am Ergebnis zu merken.

Im neuen Versuch habe ich jetzt die Post weggelassen und generiere eine zufriedenstellende Marge (wenn auch weit weg von den >50% bei German mit der Kette Bauernhof->Brauerei->Gaststätte), aber eben wieder nur mit Bussen - an den Bahnverkehr (sowie Fabrikketten) traue ich mich nicht ran, ich wüßte nicht wie ich die Strecken so vollstopfe, dass die Kosten für den Unterhalt wieder reinkommen...

Mal abwarten, solange ich die ultimative pak128-Lieferkette nicht finde ist das Spiel wenigstens spannend - eine falsche Streckenplanung kann tatsächlich den Untergang bedeuten, nicht nur das Sinken des Gewinns von 57% auf 49%

[Norman]

Hi,

ich habe das 128er recht ausgiebig gespielt. Die Industriegewinne sind sehr gering, aber ausreichend. Die Frage nach der Fahrzeugwahl (billiger + langsamer meist besser) und nich zweigleisig dafür Ausweichstellen hast du sicher schon gelesen, aber ich frage trotzdem.

[renke]

So, der Thread wäre dann gekapert für "wie funktioniert pak128"

Mit dem geringeren Profit ist eben eine Umstellung verbunden, Sachen wie "hier werde ich mal einen großen Verkehrsknoten brauchen, baue ich doch gleich den Bahnhof mal auf 6x6 aus" sind einfach nicht mehr finanzierbar. Wie oben erwähnt ein prinzipiell spannenderes Spiel, Linien- und Bauplanung werden dann deutlich wichtiger.

Mal sehen ob ich mich damit anfreunden kann, oder ob mir dann die nicht vorhandenen Auswertungen* doch den Spaß zu sehr vermiesen und ich wieder auf fehlertolerantere paks zurückwechsel.

*) beispielsweise eine "Hotspot-Übersicht", also Streckenabschnitte, auf denen sich der Verkehr ständig staut. Die Zielübersicht der Haltestellen ist mir da zu unflexibel, es ist zu kompliziert bei einer überfüllten Station zu erkennen, an welcher Stelle jetzt das Nadelöhr ist. Genial fände ich es, wenn jeweils bei den wartenden Gütern/Personen noch dabeistehen würde, über welche Linien das Ziel erreicht wird. Also noch den Punkt "via (Route)" bei dem dann etwas steht wie:

23 Passagiere nach Kassel 1 (Linie 1 über Freiburg 2, Linie 3 über Kassel Land 1)

[erneut "umgekapert", diesmal zu Change Requests für das Programm selbst]