Zu Patricks Rock:
Bei
station_coverage = 2 und
max_transfers = 7
und nicht so grossem Netz werden Passagiere, die zu dieser Attraktion fahren wollen, nur an einer Haltestelle abgeladen, die andere erhält nie Passagiere oder Post. Sind die Abdeckungen Start/Ziel asymmetrisch?
Ist das beabsichtigt, dass Schiffe nicht mehr auf einem Feld neben, sondern unter dem Dock halten, und bleibt dies auch so? Die shiptools.txt wäre eines meiner nächsten "Opfer".
Nein, das mit den Schiffen ist als ein Unfall zu betrachten und funktioniert bei mir schon wie früher ...
Zu den Attraktionen: Die Touristen werden für jedes Feld einzeln erzeugt, allerdings mag da in der 86.00.3 noch ein Fehler sein. Ich bin gerade am grundreinemachen in diesen Routinen. Vielleicht schlägt da noch ein Rest des Merge-Fehlers zu. Übrigens, wie wäre es, wenn jeden Monat nur soviele Touristen zurückfahren, wie ankamen (+- 10%)?
"ED-Bereich:
Da kann man nicht machen, die Zeichenroutinen werden nur pro Kachel aufgerufen. Eine Kachel weiß nichts von der nächsten, wegen Objektorientierung"
In Ordnung, das lasse ich für Punkt 2 gelten. Aber was ist mit dem ersten? Hier muß die Kachel doch nichts von der nächsten wissen, sondern nur, ob ein Gebäude gebaut wurde - wenn ja, dann gleiche Markierungshöhe wie beim Standard.
Oder hab ich schon wieder 'nen Denkfehler?
"Übrigens, wie wäre es, wenn jeden Monat nur soviele Touristen zurückfahren, wie ankamen (+- 10%)?"
Meinen Segen hast du.
Zählt auch hier ein Passagier schon als "angekommen", wenn er nur in seiner Heimatstadt gerade eine Zielverbindung gefunden hat? Oder muß er den Zielort auch tatsächlich erreicht haben, bevor die Attraktion ihn wieder auf die Rücktour schicken darf?
Wegen Einzugsbereich: Eventuell könnte man auch farbige Linien um eine Kachel rum machen. Das das Verhältnis Breite zu Höhe immer 2:1 ist, sollte das auch ganz zu gehen. ICh werde mal mit rumexperimentieren.
Mit der Gebäude verstehe ich nicht ganz. Male ich das Kästchen über das Geäude, sieht es doch aus, als läge es auf der Kachel dahinter.
Ich denke, dein Vorschlag zur Passagierzählung ist sehr sinnvoll, weil es das Henne-Ei Problem löst: Ich habe einen Bus, der wartet bei der Attraktion auf 10% Beladung, aber da kann noch niemand warten, weill noch keiner Hinfuhr => aber wenn wir nur Passagiere nehmen, die eine Route gefunden haben, ist das Problem vom Tisch.
Mir scheint eine Lösung realistischer, in der nur Touristen zurückkehren, die wirklich physisch an der Attraktion angekommen sind. Wie wäre es mit einer Lösung, dass die Attraktion intern eine Industrie ist, die Passagiere zu Passagieren verarbeitet, also so eine Art Aufenthaltsdauer bekommt, und die Post produziert, aber keine annimmt? Gibt das ein furchtbares Durcheinander?
@martinalex
Post und Passagiere werden sicherlich gleichbehandelt. Das geht gar nicht anders.
Ansonsten ist programmtechnisch die Idee, dass jeder Passagier, der generiert wird, auch zurückfährt, sehr schön (Variante A). So würde z.B. ein Passagier von einem Touristenziel praktisch keine Rechnzeit mehr verbrauchen. Damit würde das Passagieraufkommen auch steigen, wenn zwar eine Zubringerstrecke überlastet ist.
Meine erste Idee war, die Passagiere nach dem Ankommen eine Zufallszeit warten lassen und dann zurückfahren lassen (Variante B). Das hat aber ein großes Problem. Lässt man z.B. eine Bus an einer Attraktion auf x% Beladung warten, dann kann es passieren, dass diese nie erreicht wird, wenn alles abtransportiert wurde. (Bzw. am Anfang gar nicht erreicht werden kann, da ja noch nichts transportiert wurde).
Die Sache, Passagiere als Ware, die Post produziert, geht natürlich prinzipell (Variante C). Allerdings dürfen dann keine Passagier Produziert werden, sonst gibt es eine Art Kurzschluss.
Was ist noch anbieten könnte, ist ein Postaufkommen auf 1/7 der ankommenden Post (für Variante A und B).
Realistischer ist natürlich die Variante mit der Rückfahrt; unter dem obigen Aspekt ist allerdings die Variante A, die vom Spieler einfacher zu verwaltende Variante. Da A auch recht fix zu programmieren sein dürfte, wird das zum Testen mal in der nächsten Version drin sein. Mit der Post, mal sehen ...
"Mit der Gebäude verstehe ich nicht ganz. Male ich das Kästchen über das Geäude, sieht es doch aus, als läge es auf der Kachel dahinter."
Ich hab dir mal, zum besseren Verständnis, eine Grafik angehangen, damit sollte jetzt klar sein, worauf ich hinaus will.
Dort wo der Pfeil ist, sollte die Markierung eigentlich sein, wenn ein Gebäude am Hang gebaut wird. Damit ist es dann optisch einheitlicher und viel besser zu sehen.
Das mit den farbigen Linien um die Kachel kann ich grad nicht so richtig nachvollziehen, lasse mich da aber mal gern von dir überraschen.
Zu der Passagierzählung bliebe mir ersteinmal nur noch zu sagen, daß ich die realistische Variante ebenfalls bevorzugen würde. Allerdings ist das Argument "weniger Rechenzeit" bei der anderen Variante durchaus überzeugend. Rechenzeit werden wir in der Zukunft schließlich noch für genügend andere Sachen brauchen, von daher könnte ich mich, an dieser Steller hier, dann auch mit der "unrealistischeren" Variante anfreunden.
In dem konkreten Fall ist die Basishöhe eines ansteigenden Hanges die tiefste Stelle, also das Nulllevel. Man kann natürlich auf Hang in eine bestimmte Richtung testen, bevor man das Kästchen malt.
