neue Szenario Script Funktionen

[ny911]

Dwachs:
Bitte Bug-Reports und Wuensche fuer die Script-Funktionen bitte in eigene Threads schreiben ! ... sonst verliere ich den Ueberblick

Mach ich doch gerne. Soll ich für jede einzelne Funktion/Klasse einen eigenen Thread aufmachen?

Im Thread: Produktion - produktivty geht es um Berechnungen für die Produktionsketten. Um die Szenarienscripte auch als Hilfe für das Erstellen von Karten zu nutzen wären folgende Funktionen hilfreich:

- GET_STANDARD_PRODUCTION (Ausgangswert für Produktion)
- GET_MAX_BOOST jeweils für power/pax/mail
- GET_FACTOR_GOOD (der Prozentwert je Gut in der Fabrik)
- GET_FACTORY_NAME (für die bessere Anzeige)
- CLASS FACTORY_LIST_X (parallel zu der Stadtliste)

aus den anderen Threads im Forum habe ich mal folgendes zusammengeschrieben:

Wichtiger als die Gebäude oder Tabellen wären aber wohl:
- settings.get_start_time (edit: DONE in r6228 )
- book_cash als integer Wert (edit: DONE in r6228 )
- book_cash auf 64-bit Wert
- Anzahl Linien des Spielers
- traffic rate (edit: DONE in r6235 )
- Meldungsfenster (edit: DONE in r6249 )
- Textfeld für Übersetzer im Copyright
- Länderkodierung Zahlen/tausender punkt/komma
- Länder kodierte Angaben Monat (dann muss man das nicht nochmal extra in die ttext Dateien schreiben
- Verlinkung / Kartensprung (x,y) aus Missionsanzeige (edit: DONE in r6255 )
- evtl Link innerhalb der Missionsanzeige, inkl. Reiterwechsel (edit: DONE in r6255 )
- Eine Benutzerauswahl radio-buttom oder check-list, damit man beim Start Einfluss auf die Schwierigkeit nehmen kann
- Tabellenanzeige Texte
- Gebäude bauen und Spieler zuordnen
- ein Kartenfeld auf allen Ebenen löschen

Auf jeden Fall schon einmal Danke für die vielen Ergänzungen und Erweiterungen für die Szenarien-Scripte!!

[ny911]

habe eben nightly r6261 and pak128 2.2.0 r1135 getestet.

Wunderbar. Besonders schön: das Script Fenster benötigt nun viel weniger
CPU Zeit. Ich kann nun (im leeren NY Szenario) ca. 40% schnelleren Vorlauf nutzen!!!

- Textfeld für Übersetzer im Copyright

Habe get_about_text(pl) Funktion entdeckt und nutze diese. Ist also gelöst. Halte es aber immer noch für besser in der "scenario_base.nut" auch für Übersetzer ein Feld vor zuhalten (das ist schließlich auch Arbeit).

- Tabellenanzeige Texte

im englischen Forum habe ich einen Thread gelesen, wo die Schrift ausgetauscht wurde. Um die Programmierarbeit für Tabellen in grenzen zu halten:
Mit einem Befehl "font" (via HTML) auf eine Schrift mit fester Breite umstellen, dann ließe sich relativ einfach im Script selber eine Tabellenausgabe erzeugen.

[Dwachs]

Danke!

Allgemein: bitte Wuensche und Bugs alles in einzelne Threads schreiben, dann kann man die einfacher als 'erledigt' verschieben. Die koennen auch gerne in dem Szenario-Unterforum rumfliegen.

Uebersetzer ins Copyright mit rein: Kann man machen, muss man aber nicht. Bei den ganzen Programmtexten wird da jedenfalls nciht Buch gefuehrt.

Tabellenanzeige - feste Schriftbreite: funktioniert nicht, weil man in Simutrans immer nur einen Font nutzen kann. Den normalen Font auf feste Breite zwingen sieht wahrscheinlich merkwuerdig aus.

Performance: du hast im NY-Skript ganz viele lokale Variablen im globalen Bereich/Scope, also

Code:

local bla = null

Ich gebe zu, dass ich damit angefangen habe... Ich vermute nur, dass der Zugriff auf diese Variablen langsamer ist als auf Tabellenelemente (Intern nutzt Squirrel eine Liste fuer lokale Variablen, eine Hash-Tabelle fuer Tabellen-Elemente). Probiere mal aus, ob es etwas bringt, alle lokalen Variablen im globalen Scope (also ausserhalb von Funktionen, Klassen etc) in globale Variablen umzuwandeln:

Code:

// aus
local bla
// wird
bla <- null

Fuer den Rest des Skriptes ists dann wieder egal, nur bei der Definition der Variablen machts einen Unterschied.

Es kann auch sein, dass bei einer Aenderung, die ich in der Pipeline habe, dann solche lokalen Variablen im globalen Scope gar nicht mehr erlaubt sind (weil sie Fehler verursachen wuerden)

[ny911]

Wenn ich es richtig verfolgt habe ist der momentane Performance Zuwachs (bei unverändertem Script) der Tatsache geschuldet, das nicht mehr andauernd auf aktuellere ttextfile(file) geprüft und geladen wird.

Habe schon bei dem letzten nightly angefangen locale variablen im globalen Bereich zu ersetzen, oft gegen Konstanten.

Es kann auch sein, dass bei einer Aenderung, die ich in der Pipeline habe, dann solche lokalen Variablen im globalen Scope gar nicht mehr erlaubt sind (weil sie Fehler verursachen wuerden)

Ich Versuch es gleich mal umzusetzen ....
Edit: zur Info hat circa 12% schnelleren Vorlauf gebracht.

[Dwachs]

Länder kodierte Angaben Monat (dann muss man das nicht nochmal extra in die ttext Dateien schreiben

Wuerde da eine Funktion get_month_name(integer month) reichen?

[ny911]

Wuerde da eine Funktion get_month_name(integer month) reichen?

Ja. Glaube kaum, das jemand kurze (drei Buchstaben) Schreibweise der Monate benötigt.

[Dwachs]

- Länderkodierung Zahlen/tausender punkt/komma

siehe r6282.

http://dwachs.github.com/simutrans-sqapi...gelog.html

[ny911]

Funktioniert. Danke.

[Dwachs]

- GET_FACTORY_NAME (für die bessere Anzeige)
- CLASS FACTORY_LIST_X (parallel zu der Stadtliste)
- Länder kodierte Angaben Monat (dann muss man das nicht nochmal extra in die ttext Dateien schreiben

in r6286 drin. Der Fabrikname muss noch durch die translate-Funktion, ist der Objektname aus der pak-Datei.

http://dwachs.github.com/simutrans-sqapi...gelog.html

[ny911]

in r6286 drin. Der Fabrikname muss noch durch die translate-Funktion, ist der Objektname aus der pak-Datei.

Klappt.