Script-KI und pak128.german

[makie]

Oberleitungen sollten den Wortteil catenary enthalten.

Mach ich, neue beta in 1-2 Tagen

Die Kosten spielen eine untergeordnete Rolle beim Ladebahnsteig. Dort kommt es eher auf die Kapazität an. Beim Entladebahnsteig wird dann der billigste genommen, weil dort die Kapazität keine Rolle spielt.

Das ist leider (Pak) historisch gewachsen. Optik und Kapazität passen nicht zusammen.
Steht auf dem Plan das zu überarbeiten. So dass ein simpler Schotterbahnsteig wenig Kapazität und Kosten hat. Ein Bahnsteig mit aufwendigen Dach und Lagerhallen viel Kapazität.

Gibt jetzt eine beta mit diesen Änderungen.
https://pak128-german.de/PAK128.german_2.2_beta.zip
Bei den Bahnsteigen ist noch nicht das letzte Wort gesprochen. Der Schotterbahnsteig gefällt mir die Grafik nicht und ein älterer mit Ziegel Pflaster wäre auch noch nett.

Aber als nächstes, wenn Zeit ist, möchte ich die Signale fertig machen. Braucht dummer Weise leider auch eine Programmänderung, wenn es schön werden soll.
Fußgänger hab ich auch noch halbfertig.

[Andarix]

Die jetzt aktuelle Version sqai_rail v0.8.9 hat einige Änderungen in Bezug auf Straßenverkehr.

Sofern es mal Rückmeldungen gibt bzw. keine Bugmeldungen werde ich diese Version dann wieder bei Simutrans hinzufügen.

[makie]

Bei meinem erster Versuch mit der Sqai_rail v0.8.9 und Nighly10879 ist mir Simutrans kommentarlos abgestürzt.
Ich habe etwas Eisenbahn gebaut. Die beiden AI hatten noch nichts gebaut.
Bin das gar nicht gewohnt, deshalb hatte ich auch noch nicht gespeichert.

[makie]

Zweiter Versuch

Save:  https://makie.de/AI-Error1.sve

[Andarix]

Beim Testen der Script-KI ist es ratsam autosave = 1 zu setzen. Sonst ist es kaum möglich Fehler zu reproduzieren.

In dem Fall geht der Bau einer Ausweichstelle schief. Da kann ein Signal nicht gebaut werden.

Ideal wäre jetzt der Spielstand kurz vor dem Fehler. Aber selbst ein Bild von der betreffenden Stelle würde helfen.

Die Strecke transportiert Fisch von Feld 465,457 zu Feld 416,51.

[Andarix]

Die Änderung sollte das Problem lösen. Konnte es halt nicht testen.

Entweder die komplette Datei astar.nut ersetzen oder eben die Änderung einfügen.

https://github.com/Andarix/simutrans-sce...35455b5dd8

Der Script-Error kommt daher, das versucht wird das Signal auf die Abzweigung zu bauen.

[makie]

Anmerkung:
Die gewählte V 36 ist für den Zug zu schwach. Die Höchstgeschwindigkeit wird zwar in der Ebene auf der Geraden erreicht, aber bei jeder Kurve und Steigung bricht die Geschwindigkeit ein, was den Zug langsam macht. Durch die Fixkosten kostet das zumindest auf langen komplizierten Strecken mehr als die stärkere Lok kosten würde. Das bezieht sich natürlich auf Pak128.german in anderen Paks kann das anders sein. Ich hätte eher die G8 genommen obwohl 3x teurer.

Des weiteren: die Kühlwägen laufen 80 km/h. Auch bei den Wägen hängen die Fixkosten an der Geschwindigkeit. Die beste Wahl aus meiner Sicht wäre die BR 50. Dann reicht ein Zug zur Versorgung der Gastwirtschaft.
 
*Hm* nein, es kommen zu wenig Gäste in das abgeschiedene Waldlokal. Die essen nicht einen Güterzug voll Fisch im Monat. Nur 40% der Gäste essen Fisch. Das Lager wird überfüllt und dann wird für viele Monate nicht mehr bestellt. Wenn die BR 50 das halbe Jahr nur rum steht ist sie doch zu teuer.

Ok neuer Versuch. V 36 lassen und nur drei Wagen. Das läuft, ist aber unterm Strich inklusive Instandhaltung nicht profitabel. Das hängt auch an den langen teuren Brücken. Es fährt ja nur ein Zug auf der langen Strecke.

Noch ein Versuch: Das Script stellt auf Oberleitung um und setzt die E71 ein. Das ist eigentlich keine schlechte Wahl, aber zu viel Fisch für die Gastwirtschaft ohne Gäste, weil abseits des Nahverkehrs. Das ist inklusive Instandhaltung nicht profitabel. Das Script baut zusätzlich zum V 36 Zug noch 3 Züge mit E71. Ein E71 Zug würde reichen.  Nach einem halben Jahr reißt das Script das ganze wieder ab.

Als Spieler hätte ich nur für Fisch, nicht die lange Strecke um den See gebaut, sondern Schiffe genommen.
Wenn ich die Stecke für den Personenverkehr gebaut hätte, um die Städte zu erschließen, dann hätte der eine Zug mit Fisch diese Strecke natürlich mit benutzen können und wäre rentabel, selbst mit BR 50.

[Andarix]

pak128.german hat das gleiche Problem wie auch pak128 bei den Zügen. Zu niedrige Produktionsraten im Verhältnis zu den Zugkosten.

Nur das es im pak128.german durch das sehr hohe Startkapital besser kaschiert wird. Weil dadurch geht man nicht so schnell Pleite

Durch den Bau der Ausweichstellen (hatte das Save gefunden unter dem Bild, Zeile Abstand wäre da besser gewesen) ist auch ein zweiter Zug gebaut. Hier halt nicht durch den Scriptfehler.

Wie schon mal gesagt, so viel Weitsicht wie Du gerne hättest hat die Script-KI nicht. Und ich bin auch nicht sicher, ob die Fixkosten überhaupt berücksichtigt werden. Das kann nur Dwachs sagen. Ich geh aber eher von nein aus, weil die glaube nicht bei den Fahrzeugen gelistet sind sondern bei der Instandhaltung. Ich bin noch nicht mal sicher ob die scriptseitig überhaupt abgefragt werden können. Hab da noch nicht nachgesehen.

Möglicherweise schalte ich auch im pak128.german die Eisenbahn ab wie im pak128. Ggf mit Zeitbezug oder halt komplett.

[makie]

pak128.german hat das gleiche Problem wie auch pak128 bei den Zügen. Zu niedrige Produktionsraten im Verhältnis zu den Zugkosten.

Ich denke, ein Spieler kommt schnell auf die Idee, Leute zum Essen zur Gastwirtschaft zu fahren. Da sind dann 200% Steigerung drin.
Für das Script derzeit natürlich nicht machbar.

 

Nur das es im pak128.german durch das sehr hohe Startkapital besser kaschiert wird. Weil dadurch geht man nicht so schnell Pleite.

Wäre nicht Pleite gegangen, die beiden LKW Linien decken die Verluste der Schiene.
Das Startkapital ist hoch, weil zumindest der Personenverkehr erst ab einer gewissen Kartenabdeckung rentabel wird.
Es muss genug Geld da sein um 2-3 Städte mit Nahverkehr abzudecken und mit Fernverkehr zu verbinden.

Wie schon mal gesagt, so viel Weitsicht wie Du gerne hättest hat die Script-KI nicht

Was ich mir vom Script wünschen würde:
Dass das Script die Produktion des Verbrauchers sowie den % Wert des Verbrauchs kalkuliert und die Tranportkapazität überschlägig aus Entfernung und Geschwindigkeit berechnet und dann nicht wesentlich mehr Züge bzw. Transportkapazität aufs Gleis stellt, als der Verbraucher auch tatsächlich verbraucht.
 
Das Script hat etwas zu wenig Geduld.
Es passt die Transportkapazität zu schnell und auch viel zu stark an.
Wo ich in 10% Schritten rauf oder runter gehen würde, sind wir plötzlich bei 400% über Verbrauch.
Nach ein paar Monaten Stillstand dann Komplettabriss.

Wir haben in Pak große Eingangslager um die Zeitverzögerung zwischen Bestellung und Lieferung auszugleichen. Damit dann nicht gleich die Produktion steht.

Das Script weitet die Transportkapazität erst stark aus und befüllt das Eingangslager sehr schnell. Es ist viel unterwegs. Dann ist heillos überfüllt. Die Bestellungen stoppen, da nur langsam verbraucht wird. Der Transport setzt aus. Das Script erkennt, die Linie macht drastisch Verlust und reißt das ganze ab. Ein paar Monate später hätte sich das ganze eingeschaukelt.

Ich werde das noch mit Just_in_Time=2 testen, da treten die Probleme möglicherweise nicht so krass auf.

Und ich bin auch nicht sicher, ob die Fixkosten überhaupt berücksichtigt werden

Unnötig, müssen nicht berücksichtigt werden, die Fixkosten korrelieren mit den Betriebskosten.
Im Pak192.comic sind die meines Wissen deutlich höher und relevant. Im Pak128.german nicht.

weil die glaube nicht bei den Fahrzeugen gelistet sind sondern bei der Instandhaltung.

Nein, sind letztlich auch Betriebskosten. Nur nicht von der Wegstrecke abhängig. Sondern werden am Anfang des Monats gebucht.

Möglicherweise schalte ich auch im pak128.german die Eisenbahn ab wie im pak128. Ggf mit Zeitbezug oder halt komplett.

Es tut eigentlich.
Im konkreten Fall oben kommt das Script nur nicht mit dem langsamen Fahrzeug auf dieser weiten Strecke klar und baut zu viele Züge. Einer würde ausreichen.
Bei der niedrigen Produktionsmenge wäre vielleicht ein (oder wenige) LKW besser gewesen.

Bei Pak128.german bleibt es allerdings nicht bei den niedrigen Produktionsmengen.
Alles was gut versorgt wird wächst. Die Gastwirtschaft wie die Märkte. Ganz krass das Oktoberfest.
Die Wachstumsraten sind so kalkuliert, dass die Verbrauchsraten mit den leistungsfähigeren moderneren Transportmitteln mitwachsen.
Ein Markt der um 1800 noch mit Pferdekarren versorgt werden kann, ist bis 1950 so gewachsen, dass moderne Güterzüge notwendig sind.

Im Fall oben würde also im Laufe der Zeit die Eisenbahnstrecke ausgelastet werden.

[Zugfahrer]

Das pak128.german ist sehr stark auf Lkw Transporte ausgelegt, Züge sind fast unbrauchbar.
Ein Grund, warum ich es nicht mehr benutze. Ich möchte soviel wie möglich rentabel mit dem Zug versorgen, und das geht nicht.