Script-KI - Industrieplanung

[Andarix]

Der industry_connection_planner_t haut ein paar Debug-Ausgaben raus, gain_per_m(onth) ist der vorhergesagte Gewinn pro Monat.

Auf Grund der Wegkosten von 0 über offenes Wasser und der hohen Schiffskapazitäten gewinnt dann immer der Schiffsverkehr. Sofern halt eine direkte Verbindung möglich ist.

[Andarix]

Was soll mit dem folgenden Code in plan_simple_connection() ( industry_connection_planner.nut ) erreicht werden?

Code:

   cnv_valuator.distance = distance
   // compute correct distance
   if (distance == 0) {
     foreach(i in ["x", "y"]) {
       cnv_valuator.distance += abs( (start ? start[i] : fsrc[i]) - (target ? target[i] : fdest[i]))
     }
   }

Weil der wird nie ausgeführt, da am Anfang die distance gleich auf 1 gesetzt wird, wenn diese 0 ist beim Funktionsaufruf.

[Dwachs2]

Ich vermute mal, dass der Code, der distance auf 1 setzt, Murks ist.

Edit: Fix ist auf github

[Andarix]

Was gibt veh.get_power() als Wert zurück?

Die pr G3 hat 400 kW ohne gear.
veh.get_power() liefert 25.600.

[Dwachs2]

das gibt power*gear zurueck.

[Andarix]

das gibt power*gear zurueck.

und multipliziert mit 64

[Dwachs2]

ja. Mit dem Wert rechnet dann die Methode convoy_x.calc_max_speed .

[Andarix]

Es ist irritierend, wenn intern mit anderen Zahlen gearbeitet wird als in den Dats und in der Anzeige im Spiel stehen.

[Dwachs2]

Da bist du jetzt der erste, der das sagt. - Liegt vermutlich daran, dass du der erste bist, der sich das ueberhaupt anschaut

Ich werde mal die Dokumentation auf
http://dwachs.github.io/simutrans-sqapi-...4a0bb7d284
dahingehend anpassen.

[Andarix]

Da ich bei der im Moment auf 3 Felder begrenzten Zuglänge die starken Loks ausfiltern will ( wegen dann zu hoher Betriebskosten ) hab ich die Leistung abgefragt.

Nur standen dann eben in der Ausgabe unerwartete Zahlen.

Und wo wir gerade dabei sind, warum wird die max_speed so extrem hoch angegeben in class cnv_proto_t.

Code:

max_speed = 1000000000 //1000000000000

Mit der größeren Zahl ( original ) gibt es scheinbar einen Überlauf.

siehe hier

---

Bei kurzen Tests ist es aufgefallen, je später das Startjahr ist um so länger dauert die Planung und der Bau von Verbindungen.

Nach wie vor ist mir auch nicht ganz klar wie die Wahl des Verkehrsträgers passiert. Allein an gain_per_m kann das nicht hängen.

---

Da bist du jetzt der erste, der das sagt. - Liegt vermutlich daran, dass du der erste bist, der sich das ueberhaupt anschaut
...

Ob es jemand anderes benutzen wird was ich hier bastel ist auch eher fraglich. Andererseits frisst das viel Zeit, die ich aktuell gerade zu Verfügung habe. Wie das in Zukunft aussehen wird ist fraglich.

Hat sich halt nicht weit rumgesprochen, das KI-Entwicklung inzwischen auch von außen möglich ist.

Aber beim Thema KI-Spieler sind die Spieler im laufe der Jahre blind geworden, weil die alte/bisherige C-KI nicht sehr logisch agiert.

Auch die Script-KI hat da noch schwächen. Zum einen welche Verbindungen gebaut werden. Da plane ich ua eine Prüfung ob schon eine Verbindung zwischen 2 Industrien mit der Ware existiert um die dann nicht zwangsläufig zu bauen. Sondern nur, wenn ein Warenmangel beim Empfänger besteht. Auch die Wahl des Stationsplatzes ist nicht immer gut. Besonders wenn es um Bahnstationen geht.

Zum anderen hat der Wegbauer noch Probleme. Eine Brücke die mit Rampe auf einem flachen Feld endet und das nächste Feld den Hang wieder rauf geht ist unpraktisch. Analog, wenn es einen Hang runter geht und dann in gerader kurzer Entfernung wieder hoch geht. Da Blicke ich aber noch nicht so richtig durch.

Solche Sachen sind aber eher wieder was für Streckenverbesserungen im späteren Verlauf. Wird das eigentlich aktuell gemacht oder bleiben die Strecken wie gebaut bestehen?

Und ich teste vorwiegend mit pak64.german. Kurze Tests mit pak64 mache ich. Aber wie es mit anderen Sets aussieht weis ich aktuell nicht. Gerade was pak128 mit dessen Höhendefinition betrifft hab ich keine Ahnung was passiert.