scenario script - abfrage von station_coverage

[ny911]

Wie kann man den Wert "station_coverage" aus den Einstellungen mit einem Scenario-Script-Befehl auslesen oder diesen anderweitig bestimmen?

Ebenso für ( max_transfers, passenger_factor, way_max_bridge_len, ... )

[Dwachs]

zur Zeit noch nicht. Kannst du eine Liste machen, welche Eigenschaften interessant waeren? Wozu brauchst du denn max_transfers, passenger_factor??

[ny911]

Bei der Erstellung der ersten allgemeingültigen Szenario Klassen die ein gemeinsames gewichtetes Ergebnis für ein Szenario ausgeben kam der Gedanke an die Abfrage von Verbindungen und Linien. Eine Klasse kann nun (naja, fast) prüfen ob zwischen zwei beliebigen Punkten, die keine Haltestelle sein müssen, eine Verbindung mit min und max Anzahl an Umsteigen, Unglücklichen Haltestellenbesuchern, Beföderngsmittel und Frachttyp bestimmen. Also eine erweitere "function is_connected()".

Um die Rekursion trotz Vorgabe des Scripts nicht länger laufen lasse zu müssen als unbedingt möglich braucht man max_transfers. Momentan ist die Benutzerausgabe (muss ja verständlich sein) und eine kleine Beschleunigung der internen Such-Schleifen in der Entwicklung/Verbesserung. Sollte alles im nächsten bald erscheinenden und hoffentlich spielbaren Szenario auftauchen.

Zur Liste. So aus dem Bauch mit hoffentlich mehr Kopf als Bauchverstand glaube ich sind folgende Eigenschaften interessant:

station_coverage
max_transfers
passenger_factor
way_max_bridge_len
factory_worker_radius
factory_worker_minimum_towns
factory_worker_maximum_towns
no_routing_over_overcrowded
avoid_overcrowding
separate_halt_capacities
maintenance_building
[ alle cost_XXX ]

Dabei wären für spätere Scripte sicherlich auch die cost_XXX Eigenschaft als lese und schreib Option (soweit überhaupt möglich) interessant.

Viel mehr liegt mir aber das Problem mit der Rotation und der Benutzerangabe der Koordinaten (nur Text kein Link) und edit/new/delete Funktionen für Markierungen auf dem Magen.

[Dwachs]

Du hast tatsaechlich eine Routensuche programiert? Da es exakt diese Funktion intern gibt, kann man die leicht verfuegbar machen. Das Problem ist nur, dass man mit einem entsprechend schlecht programmierten Skript Simutrans komplett lahmlegen kann.

Dieser Settings-Kram geht sicherlich zu exportieren (Edit: siehe r7398 oder http://dwachs.github.io/simutrans-sqapi-...tings.html )

Fuer die Koordinaten gibts im Prinzip zwei Moeglichkeiten:
-- Methoden coord_to_string(x,y) und coord_to_string(x,y,z) erstellen
-- Die koordinaten in squirrel als Klassen neu zu implementieren (inkl + und - operatoren etc), sowie typecast zu string.

Markierungen: Die willst Markierungen setzen/aendern/loeschen ?

[ny911]

Dieser Settings-Kram geht sicherlich zu exportieren (Edit: siehe r7398 oder http://dwachs.github.io/simutrans-sqapi-...tings.html )

mit r7399 (pak64) und "settngs.get_station_coverage()" getestet, funktioniert, Danke

Du hast tatsaechlich eine Routensuche programiert? Da es exakt diese Funktion intern gibt, kann man die leicht verfuegbar machen. Das Problem ist nur, dass man mit einem entsprechend schlecht programmierten Skript Simutrans komplett lahmlegen kann.

Ja. Siehe Szenario "Great Abbey" Verzeichnis class_group Datei target_connected.nut
Habe aber die Funktion, da ich sie noch nicht ausgiebig getestet habe, nur mit der Rekursionstiefe = 0 (also Direktverbindung) im script eingebunden. Bin mit dem Script noch nicht so wirklich glücklich, da es bei komplexen Netzwerken einen riesigen Baum (max Tiefe begrenzt durch festen wert = 10) aufbaut. Hat aber bisher bei meinen kleinen Testläufen immer die richtigen Ergebnisse zurückgegeben.

Wenn ich die interne Suchroutine von Simutrans richtig verstanden habe, dann gibt diese ein anderes Ergebnis zurück. Die Script Routine hingegen soll alle möglichen Verbindungen die innerhalb der Parameter (min und max Transfers) liegen finden. Des weiteren wird ggf. nicht nur ein Überfüllter Bahnhof, sondern auch noch das/die Verkehrsmittel berücksichtigt. Letztlich dient das ganze dazu später mal eine Klasse entwickeln zu können mit der man ein kleines "Kursbuch" mit verschiedenen Verkehrsmitteln als Szenario Ziel abfragen kann.

Fuer die Koordinaten gibts im Prinzip zwei Moeglichkeiten:
-- Methoden coord_to_string(x,y) und coord_to_string(x,y,z) erstellen
-- Die koordinaten in squirrel als Klassen neu zu implementieren (inkl + und - operatoren etc), sowie typecast zu string.

Da mir keine weitergehenden sinnvollen Nutzungen einer Koordinaten Klasse (to output string) einfallen, halte ich die Methoden Lösung für sinnvoller. Sofern ich es aber richtig verstanden habe, reicht die Methode coord_to_string(x,y) vollkommen aus. Ein Z Wert ändert sich beim rotieren nicht.

Markierungen: Die willst Markierungen setzen/aendern/loeschen ?

Markierung (deutsch) = "place a sign" (englisch) = "mo_label" (script) = "Marker" (c_english)

Code:

local obj = square_x( pos.x, pos.y ).get_ground_tile().find_object( mo_label )
gui.add_message( "Name:" + obj.get_name() )

Momentan kann man den Namen des Objekts (hier "Ding" ) abfragen, nicht aber den Inhaltstext einer Markierung. Wenn man nun noch die Möglichkeit hätte diesen Text zu ändern, wäre dies schon sehr gut und erlaubt weitergehende Hinweise direkt auf der Spielkarte. Ein setzen und löschen von Markierungen seitens des Scripts würden folglich ein ändern der object_list_x Liste erfordern und wäre der Idealfall.

[Dwachs]

In r7403 ist dann coord_to_string dabei.

Mit den Markern wirds etwas komplizierter.

[ny911]

Mit r7403 (pak64) getestet, funktioniert, aber:

Beim testen ist mir aufgefallen, das für einen "normalen" Satzbau bei den Übersetzungsdateien eventuell auch die Kartenausrichtung für eine korrekte Beschreibung (norden, osten, süden, westen) notwendig ist. z.B. "das nördlich der Stadt liegende Gebiet (pos_a bis bis_b) darf nur ...." ergibt keinen Sinn bei einer Kartenrotation und bedarf einer anderen Formulierung oder einer Abfrage der Kartenausrichtung. Eine Methode für die Abfrage der Kartenausrichtung ist also, anders als ich dachte, doch sehr wichtig.

Dann noch eine Frage zur einheitlichen Darstellung von Koordinaten für den Spieler: Soll auch bei gedrehter Karte immer erst die Position (aus Sicht des Spielers) "NW to SE" bei cubes angegeben werden?

Vielleicht sollte in der Beschreibung http://dwachs.github.io/simutrans-sqapi-...ord3d.html noch ein deutlicher Hinweis rein, das die "href Verlinkung" (ist ja auch ein string) nicht über diese Ausgabe generiert werden darf, sondern nur der Text in der href Anweisung. Schließlich wird die Verlinkung schon so umgerechnet.

Falls das mit den Markern zu kompliziert ist, hier drei vermutlich sehr einfache Änderungen/Ergänzungen:

Szenario Fenstergröße:
Scenario - Fenstergröße

Szenario base.nut
Wunsch - Erweiterung in scenario_base.nut "scenario.translation"

Fenster - Reiter Debug:
scenario - Missionsfenster Reiter "Debug"

[Dwachs]

Beim testen ist mir aufgefallen, das für einen "normalen" Satzbau bei den Übersetzungsdateien eventuell auch die Kartenausrichtung für eine korrekte Beschreibung (norden, osten, süden, westen) notwendig ist. z.B. "das nördlich der Stadt liegende Gebiet (pos_a bis bis_b) darf nur ...." ergibt keinen Sinn bei einer Kartenrotation und bedarf einer anderen Formulierung oder einer Abfrage der Kartenausrichtung. Eine Methode für die Abfrage der Kartenausrichtung ist also, anders als ich dachte, doch sehr wichtig.

Ist das wirklich ein Problem? Wenn die Anfangsstellung der Karte die Himmelsrichtungen vorgibt, dann sollte das doch keine Verwirrung geben. Berlin ist immer noerdlich von Muenchen, egal wierum man die Landkarte haelt.

Dann noch eine Frage zur einheitlichen Darstellung von Koordinaten für den Spieler: Soll auch bei gedrehter Karte immer erst die Position (aus Sicht des Spielers) "NW to SE" bei cubes angegeben werden?

Hm, das geht mit den vorhandenen Befehlen jetzt nicht so recht. Wie waere es mit einer Methode, die zwei Koordinaten nimmt und zwei Strings zurueckliefert, die dann jeweils die anzeigbaren Koordinaten der NW- und SE-Ecken sind?

Bei den Befehlen forbid_tool_sowieso ist es egal, welche Ecke des Cubes angegeben wird. Hauptsache es sind zwei gegenueberliegende.

Vielleicht sollte in der Beschreibung http://dwachs.github.io/simutrans-sqapi-...ord3d.html noch ein deutlicher Hinweis rein, das die "href Verlinkung" (ist ja auch ein string) nicht über diese Ausgabe generiert werden darf, sondern nur der Text in der href Anweisung. Schließlich wird die Verlinkung schon so umgerechnet.

Da habe ich nicht dran gedacht. Ich werde einfach noch ein methode coord::href und coord3d::href spendieren, die das dann mit abfaengt.

Marker setzen und bearbeiten habe ich lokal schon implementiert. Das direkte Loeschen ist noch nciht drin.

[ny911]

Ist das wirklich ein Problem? Wenn die Anfangsstellung der Karte die Himmelsrichtungen vorgibt, dann sollte das doch keine Verwirrung geben. Berlin ist immer noerdlich von Muenchen, egal wierum man die Landkarte haelt.

So wirklich ist es kein Problem, nur lässt sich die Scriptausgabe nicht an die Kartendrehung anpassen, da das script keine Ahnung hat wie /wie weit die Karte gedreht ist.

Hm, das geht mit den vorhandenen Befehlen jetzt nicht so recht. Wie waere es mit einer Methode, die zwei Koordinaten nimmt und zwei Strings zurueckliefert, die dann jeweils die anzeigbaren Koordinaten der NW- und SE-Ecken sind?

Bei den Befehlen forbid_tool_sowieso ist es egal, welche Ecke des Cubes angegeben wird. Hauptsache es sind zwei gegenueberliegende.

Es geht nur um die Benutzerausgabe, nicht die forbid_tool_ Parameter. Es lässt sich doch prima im script durch zerlegen des strings nach integer vergleichen und dann in gewechselter Reihenfolge darstellen. Meine Frage ging mehr in die Richtung, ob es da eine einheitliche Vorgabe für eine solche Benutzerausgabe (cube / area) gibt.

[Dwachs]

Setzen und Loeschen von Markern geht jetzt (r7416).