Beiträge von Freahk

Zum ausladen müsstest du eigentlich sogar nur den lanes den typen "TRUCK" hinzufügen. Das dürfte schon genügen.

Nach wie vor als offene beta in der Testversion.
Wie gesagt letzte Woche hat sich nicht viel getan aber seit Gestern bin ich wieder dran.

sehr unwahrscheinlich.
Die taucht zwar in der stdout auf aber hat sehr wharscheinlich nichts damit zu tun.

Nutzt ihr beide die neuste Version der Unterführung?

Zitat von eis_os

Lade Dateien, Nutzer klickt ein Konstruktion auf.

Du kannst dir über einen modifier einen "onload hack" basteln, indem du eine ~ready.lua multiple unit definierst. Dein modifier weiß dann ziemlich sicher, dass alle anderen modifier durch sind, wenn diese geladen wird.
An den namen des saves kommt man, falls es denn ein savegame und kein neues Spiel ist, ebenfalls recht hacky über die stdout.txt ran.

Nun, ich hatte gehofft du hättest da eine etwas schönere Lösung gefunden^^

Zitat von eis_os

Ich hab dazu noch eine Idee über einen Cache d.h. man muss ggf. sein Savegame nochmalig laden.

jap, das funktioniert.
Den cache müsste es aber pro savegame geben und an den namen vom save kommt man nur über Umwege und es macht Stress wenn man das save mal unter einem anderen Namen speichern möchte...
Vielleicht hast du da aber noch einen anderen Hack im Ärmel, ich bin gespannt.

Der Stand sieht sinnvoll aus und wird bei mir dann wohl sehr bald objdata ablösen, da es im Endeffekt das Selbe mit einer etwas schöneren API macht. Objdata war eh nur so eine schnelle und einfache Lösung mit ein paar wenigen Zeilen code, weil ich gefragt wurde, ob ich in die Depots denn auch Schmalspurgleise legen kann.

p.s. das Objekt gedöns für die UI parameter klingt auch sinnvoll.
Wäre cool, wenn du davon mal einen Link zum sorce geben könntest, damit ich mir überlegen kann ob ich das irgendwie sinnvoll mit meinem param script, welches ich in der unterführung erstmalig veröffentlicht habe, verdreht bekomme.
Darauf werden vermutlich demnächst viele meiner mods aufbauen, da es mir und ggf. Nutzern die die mod etwas an anpassen wollen das Verbinden von config, UI und construction Modulen ziemlich leicht macht, also bin ich auch sehr an einer vernünftigen Anbindung an die repo API interessiert.

Wie? Wir modder sind nicht normal?
Das finde ich jetzt aber echt beleidigend

Und warum eigentlich nur eine Peitsche?

Zitat von FlBra

habe festgestellt, dass die Bahnsteigbreite nicht dieselbe ist

Ja das ist bekannt. Mit der nächsten Version wird es auch eine Variante geben die für Güterbahnhöfe passt, dauert aber noch ein wenig, letzte Woche ist wegen Klausuren und ähnlichem nicht viel passiert.

Ich konnte den Fehler mit build 13505 Linux und der grimes_unterfuehrung_1.1 nicht rekonstruieren.
Es gibt einen Fall, der aber eigentlich nie eintreten dürfte in dem das Feld nicht initialisiert ist.
Ich sehe mir das nochmal im detail an.

Ich würde die Straße wohl etwas kurviger, also ohne diese harte Ecke an der schmalen Straße verbinden.
Ansonsten sieht das aber schon ziemlich gut aus.
Bei der Einmündung bin ich gespannt wie du das mit den lanes regelst. Du müsstest da auf die Schnittpunkte achten.

Wie stellst du dir das vor? in Konstruktionen könnte man was die Oberleitung angeht noch etwas mogeln und diese als model über das Gleis hängen. In Depots könntest du auch bei der Geschwindigkeit weiter mogeln und eine lane parallel zum Gleis legen aber auf freier Strecke kannst du das vergessen. Da brauchst du dann wirklich für jeden Gleistypen eine eigene Datei.
Ich sehe in deinem Menü alleine 18 unterschiedliche Geschwindigkeiten, 2 Gleistypen und 3 Oberleitungstypen...
Macht also schlappe 18*2*3=108 permutationen für die du jeweils einen Gleistypen definieren müsstest...

Gleise und Oberleitungen gehören so wie es aktuell in TpF umgesetzt ist fest zusammen. Da lässt sich auch nichts scripten.

Aus Gründen der Abwärtskompatibilität würde ich einfach wie gewohnt die params speichern und zusätzlich in einer anderen table die data.
Man muss die data table nicht nutzen, aber sie kann hilfreich sein. Die params muss man so oder so mit speichern, ansonsten müsste man aus data den Zustand der UI rekonstruieren.

Die Möglichkeit für Teilbereiche einer Konstruktion eine eigene UI zu definieren wäre natürlich noch viel besser, das stimmt wohl. Vermutlich aber auch noch viel aufwändiger.
Ein UI flag für die models wäre mit Sicherheit auch eine einfache und effektive Lösung.

Der Typ der Oberleitung ist fest mit dem Gleistypen Verbunden.
Das heißt für den Vorschlag Oben müsste man 21 unterschiedliche Gleisetypen definieren, wäre aber technisch machbar.
Den Bahnhof könntest du mit einem modifier anpassen der die params entsprechend anpasst, also (hässlich aber relativ einfach) die values des trackType params um deine 21 Gleistypen ergänzt oder die trakTypes um die 7 Grundtypen ergänzt und einen zusätzlichen param catenaryType hinzufügt.

So weit zum einfachen part.
Jetzt musst du noch (ebenfalls mit dem modifier) die updateFn so wrappen, dass die Indizes der Gleistypen in dem Bereich liegen die vom urpsrünglichen params Eintrag stammen und dann nachträglich selbst die Werte handlen die außerhalb dieses Bereichs liegen.

Außerdem: Egal wie du es implementierst, es kann theoretisch immer mods geben bei denen das zu unerwünschten Ergebnissen führt. Du solltest also zumindest eine blacklist anbieten.

@lange Das stimmt aber von denen wird man dann wohl nicht mehr all zu viele in Rhein-Ruhr fahren sehen. knapp über 80 422er gibt es, 48 werden übernommen und 41 neue Flirts werden für die Sbahn angeschafft.
Da ist man dann bei mehr als den knapp über 80 bisherigen Zügen. Ein paar bleiben bestimmt noch als Reserve hier aber im Alltag wird man wohl eher grün-weiß als Verkehrsrot sehen.
Vielleicht gehen die anderen ja dann für ein paar Jahre nach Berlin die dürften zu dem Zeitpunkt noch Züge gebrauchen die funktionieren

Ich würde ganz gerne z.B. über eine Option einen Bahnsteig auswählen, damit man diesen bearbeiten kann.
Damit man auch direkt sieht um welchen Bahnsteig es sich handelt, würde ich den markieren wollen, indem ich einfach ein mesh mit ner halbtransparenten Textur drüber lege oder sowas.
Wenn das Fenster dann geschlossen wird (mit ausführen des Umbaus oder ohne ist hier egal) müsste ich die Markierungen wieder raus nehmen und das geht eben nur, wenn ich weiß "warum" die updateFn aufgerufen wurde.
Den Aufruf beim schließen des Fensters durch Abbruch kann man auch weg lassen. In diesem Fall wird ohnehin nichts gebaut, aber TpF müsste sich dann auch darum kümmern, dass ggf. in der data table gemachte Änderungen wieder verworfen werden und das könnte schwierig werden.
Deshalb meine Idee einfach mitzuteilen "hey! Das was eben verändert wurde muss wieder verworfen werden, kümmer dich drum."
Das wäre dann natürlich der Vorteil der Variante ohne data table in der man alles als hidden uiValue verpacken muss. Da wäre es für TpF eine Leichtigkeit eine Kopie der params anzulegen und beim abbruch entsprechend zurückzusetzen.

Nicht ganz, zumindest wenn man da der Information aus dem endlich wieder erreichbaren VRR mediacenter glauben schenken darf, fehlen noch die Symbole aus der Region.
http://mediencenter.vrr.de/ass…rke_fahrzeuge_ab_2019.pdf

Aber von der Grundfarbe her passt das schon.

Ja die Sache mit der Kompatibilität ist klar.
Ich sehe nur im Moment nicht den Punkt an dem eine alte construction die kein solches data Objekt mit sich führt inkompatibel zu einer neueren construction die dieses Objekt erwartet ist.

Alte nicht angepasste constructions würden eine leere data table übergeben bekommen, diese ignorieren und wie gewohnt die construction anhand der params zusammenkleben, an denen sich nichts geändert hat und keine zusätzlichen Informationen in der data table ablegen.

Neue oder auf die data table angepasste constructions würden feststellen, dass die data table leer ist, diese initialisieren und anschließend anhand der params die data table füllen. Hier könnte es sein, dass beim upgrade einmalig gewisse Informationen verloren gehen, die man dann im worst case kurz neu einstellen müsste.

Noch eine Sache zur updateFn:
Ein weiteres Feld sollte ein updateEvent enthalten, welches folgendes enthält:
Den Grund des updateFn Aufrufs:
- öffnen des upgrade Fensters
- öffnen des "neue Construction" Fensters
- betätigen eines buttons (gerne auch welches buttons)
- schließen des Fensters (durch Abbruch)
- schließen des Fensters (mit ausführen des Umbaus)

Beim betätigen eines buttons sollte zusätzlich der Button (key/index Paar) mit angegeben werden.

Sag Mal dein Bruder kann nicht Zufällig mal Bilder von dem 422 machen der schon im VRR design umlackiert wurde? Angeblich soll es da schon einen geben, ich habe von dem aber noch kein Bild gefunden.

yeah that's what I said above it seems they use it to perform the track and road terrain alignment internally, but they should also provide this feature to the lua api so we can also align the terrain along splines without approximating the splines to polygons by ourselfs.

@Enzojz as you said it's fine when it simply works, however when they should change the API that way so the modder has to care about proper alignment, they will have to provide a way to align terrain directly by splines or to transform a spline to an alignment polygon, since they can't expect everyone to implement this conversion on his own or use some community code for this.

Zitat von eis_os

Einzelne Werte in values Listen sollten auch die Möglichkeiten habe per yearFrom yearTo Zeitabhängig ausgeblendet werden.

ist ein wenig redundant zur updateUiFn. Hier könnte man auch einfach den Eintrag entfernen, müsste dann aber gut aufpassen, da sich dadurch ggf. die indizes verschieben.
Ich sehe also den Grund der Idee aber warum sollte man das invisible feature künstlich auf einen Bereich der timeline einschränken?
Ich würde da eher über eine eine visibility Liste vorschlagen, die für jeden Eintrag in den values einen Eintrag hat der angibt, ob dieser Button sichtbar ist oder, ob es sich um einen Geist handelt.

Zitat von eis_os

Verstecktes Element:
type = "HIDDEN"
value = <uint>
Dient dazu weitere Daten für eine Konstruktion zu speichern

Notfalls auch so...
Ich würde aber einfach eine data table bevorzugen die an das constructionInstance Objekt angehängt wird. (mit constructionInstance bezeichne ich das was die updateFn zurückgibt)
Dieses Objekt wird dann entweder als eigener Parameter oder als Element dieses mysteriösen Objekt, welches immer in den params mitgegeben wird und das statndardgleis und alle möglichen Bäume enthält, an die updateFn übergeben.
Das hätte den Vorteil, dass man nicht wieder alle Werte auf indizes mappen muss, um sie zu speichern. Das hätte den Vorteil, dass man z.B. Einstellungen die man pro Gleis vornehmen kann einfacher speichern kann. Ansonsten bräuchte jedes Gleis für jede Eigenschaft ein eigenes HIDDEN Element.
Man muss halt nur aufpassen das Teil beim ersten Aufruf der updateFn zu initialisieren. Alernativ könnte man noch eine initFn an die construction kleben die dann beim beim auswählen einer construction im Menü dieses data Objekt initialisiert.

Bei der Überschrift fehlt vermutlich das value Attribut.
Bei der checkbox für jeden Eintrag eine eigene Zeile zu machen ist vermutlich nicht so eine tolle Idee.
Eine visibility table wäre bestimmt auch für die checkbox und die bitsetting sinnvoll.
beim spinner würde ich statt des formatString eine toString Funktion bevorzugen. Ist flexibler und formatstrings sind für Leute die damit noch nichts zu tun hatten ziemlich unhandlich.

Ansonsten passt das so würde ich sagen.

Zitat von eis_os

Ich frage mich ob ich meine API als shared mod veröffentlichen soll

Ich bitte doch drum!
Ansonsten würde ich demnächst meine mini lib objdata freigeben die dies wirklich minimalistisch löst:
API:

init(String[] types)
listObjects(objType:String):String[]
getObjectData(objType:String, objectName:String):table
ObjectTypes = {
  MODEL
  MULTIPLE_UNIT,
  STREET,
  TRACK,
  BRIDGE,
  TUNNEL,
  RAIL_CROSSING,
  CONSTRUCTION,
  SOUND_SET
}

Init teilt man einfach mit von welchen Typen man später die genauen Werte haben möchte,
listObjects gibt die Liste der Namen aller Objekte des bestimmten Typens wieder,
getObjectData gibt dann die Daten des bestimmten Objekts aus und
ObjectTypes ist einfach nur eine Auflistung aller gültigen Typen, damit ich nicht immer nachschlagen muss und Tippfehler schneller auffallen.

Ich müsste objdata dann nur noch schnell fit für neue Versionen machen und in die doku bringen, aber das ist ja bei den paar Funktionen schnell getan..