Die beste Antwort auf deine letzte Frage wird dir vermutlich TpF geben können
Probier es aus!
Die Reichweite des Bahnhofs könntest du "manuell" erweitern, indem du einen weiteren Straßenanschluss an die entsprechende Stelle moddest.
Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
Die beste Antwort auf deine letzte Frage wird dir vermutlich TpF geben können
Probier es aus!
Die Reichweite des Bahnhofs könntest du "manuell" erweitern, indem du einen weiteren Straßenanschluss an die entsprechende Stelle moddest.
Hi Community,
Da ich die Möglichkeiten der Construction UI als deutlich verbesserungswürdig ansehe, habe ich mich mal dran gesetzt und im Rahmen des bisher möglichen ein paar Scripts zusammengebastelt die ein umfangreichere grafisches Nutzer Schnittstelle bieten sollen.
Aktuell befindet sich das ganze noch in einer frühen Beta und ist, um wirklich nutzerfreundlich zu funktionieren darauf angewiesen, dass UG uns etwas mehr Möglicheiten gibt das UI zu modden.
Aktuell gibt es folgende UI Elemente:
Jetzt kommt das große Aber:
-Es gibt bisher keine (mir bekannte) Möglichkeit die internen Werte über das speichern/neu laden des Spiels hinweg zu sichern.
-Es ist bisher nur Möglich den Status des Interfaces für alle Stationen eines Typs zu verwalten. Anders ausgedrückt heißt das, wenn ich eine Station umbaue und danach eine andere Station des Selben Typs veränder, übernimmt diese die Einstellungen der vorherigen als "default" Werte und nicht seine eigene Einstellung.
-Bei sehr vielen gleisen kommt es mit dem Standardscript dazu, dass (angeblich) nicht alle Terminals verbunden sind. Ich konnte aber keine Verbindung finden die tatsächlich nicht verbunden war.
-Bevor man die buttons nutzt, muss man erstmal den buildMode ändern, denn sobald die engine feststellt, dass die buttons wieder im Ursprungszustand sind, wird die updateFn nicht aufgerufen und stattdessen die unveränderte Construction dargestellt.
-Es ist aktuell noch recht Nutzer unfreundlich, da man nicht mehrere Buttons eines Elements gleichzeitig anwählen kann und man immer jeweils ein "neutrales" Element anklicken muss, da sich shließlich der Index nicht ändert, wenn man einen bereits angewählen Button anklickt.
Auf dem Plan steht noch ein gruppiertes UI Element mit dem man einen Status auswählt und zu jedem Status mehrere Werte mit den anderen Elementen angeben kann. Das wäre dann nützlich um z.B. Gleisbezogene Einstellungen setzen zu können.
@tomdotio @mikael @weberba
Damit das ganze aus der experimentellen Phase heraus kommt und nutzerfreundlich wird müsste UG allerdings das UI modbarer gestalten.
Man müsste die Möglichkeit haben aus der updateFn heraus explizit die ausgewählen Buttons zu setzen und explizit angeben zu können, ob die Construction verändert wurde oder nicht und man bräuchte eine Möglichkeit an eine konkrete gebaute Construction Werte anzuhängen, die man dann mit der updateFn zusätzlich zu den gewählten Indizes übergeben bekommt und die vor allem auch beim Speichern/laden nicht verloren gehen.
Weiter wäre es sinnvoll Ui Elemente grafisch gestalten zu können, um die Gruppen und checkboxen auch optisch direkt vom Rest unterscheiden zu können. Es würde ja schon reichen wenn man auf die Buttons eine Farbe oder Textur legen könnte und Rahmen definieren zu können.
Nice-to-have wären noch wenn man Einträge im User interface explizit hinzufügen und entfernen könnte.
So ich habe mir dann für dieses Jahr genug gewünscht ![]()
Moin @Tom,
Bei der ersten Version vom Script habe ich noch durchgeblickt. Ich bräuchte da mal ein paar Tipps wie ich am einfachsten mit dem aktuellen Script umgehen kann ohne mir erstmal das Script im Detail anzusehen. Dabei geht es direkt an die Grenzen des Userinterfaces aber das möchte ich erst mal außen vor lassen. Ich gehe einfach davon aus, dass es im UI irgendwie umsetzbar ist.
Und zwar möchte ich deinen Standard Bahnhof plus so abändern, dass man
Und wie gesagt mich interessiert erstmal nur an welchen Schrauben vom Script ich da schrauben muss und nicht wie ich das am Ende ins UI bringen kann.
Einfach nur großartig was du in letzter Zeit bastelst. Nach deiner Haltebucht wollte ich dich direkt nach so etwas ähnlichem fragen und jetzt hast du schon angefangen ohne, dass ich gefragt habe.
Wobei ich eher an einen versetzen Halt, wie es bei den Straßenbahnen im Ruhrgebiet häufig der Fall ist bzw. einen Mittelbahnsteig, wie es bei den Stadtbahnen, manchmal auch bei den Straßenbahnen im Ruhrgebiet häufig vorkommt, gedacht habe.
So sieht so ein Mittelbahnsteig dann in der Realität aus: https://de.wikipedia.org/wiki/…ohnhauser_Stra%C3%9Fe.jpg
Die Variante mit den versetzen Außenbahnsteigen findet man aber deutlich häufiger. Nur leider findet man dazu nicht so einfach gute Bilder. Bei Bedarf suche ich aber mal Bilder raus.
Die Ldoc Seiten sind quasi ein Nebeneffekt von den lua documentor Seiten die eclipse zur Autovervollstänigung nutzen kann.
Man kann natürlich auch Wiki Seiten draus machen wenn man möchte.
de:
Ich habe die letzten Tage mal damit angefangen das was ich über die von UrbanGames gebotenen Modding Schnittstellen weiß aufzuschreiben.
Bisher beschränkt sich das ganze nur auf Constructions, wird aber, wenn ich nicht der Einzige bin der etwas damit anfangen kann, demnächst auch models, Straßen, Gleise und mit der Zeit bestimmt auch weitere umfassen.
In erster Linie geht es darum die Schnittstelle zur Engine zu beschreiben, also welche Attribute die engine kennt und wie diese damit umgeht.
Es ist nicht geplant die Scripts von UG zu dokumentieren.
Der aktuelle Link ist: http://dome.xileks.de/tpf/doc/de
Wenn du mir dabei helfen möchstest die Dokumentation zu vervollständigen, schreibe mir gerne eine PN.
Der Link könnte sich in Zukunft ändern. Ich werde diesen dann hier schnellstmöglich aktualisieren.
Das ganze ist noch WIP aber ich denke man kann damit schonmal etwas anfangen.
---------------------------------------------
en:
A few days ago I started documenting the modding interface provided by UrbanGames.
Up to now this documentation only describes the interface on Constructions but it will also include models, streets, tracks and more in the future.
This documentation is about describing the interface to the engine, which means describing the attributes accepted by the engine and how it uses these.
I won't document the Scripts of urban games.
The current link to the english documnetation pages is http://dome.xileks.de/tpf/doc/en.
Notice that the german documnentation is more recent since I decided to continue this documentation in german and I won't update the english version until I consider the german documentation as final.
If you want to help me translating the documentation, or help me completing the documentation, feel free to contact me.
The link could change in the future. I will update this post as soon as possible when it changed.
Currently the documentation is still WIP but I think it could already be useful.
Schaut gut aus ![]()
Eine Kleinigkeit ist mir aber dennoch direkt aufgefallen: Die Ecke die man im Teaser in etwa bei 0:28 sieht wirkt ziemlich unschön.Die Höhe und die Textur passen nicht zum Rest.
Ähnliches gilt für die Ecke die man bei 1:10 am Rande sieht.
Ansonsten ist der Busbahnhof gut gelungen und ich bin gespannt was du da noch an updates planst ![]()
Ja das ist das alt bekannte Problem. Beim neu Bauen ist die Breite des Fensters fest, beim Upgrade ist die Höhe des Fensters fest.
Mit Build 12763 wurde das laut patchnotes behoben. Ob das jetzt aber nur für die Feste Höhe des Upgrade Fensters oder für beide gilt weiß ich nicht.
@andy2612 Die Wegsuche ist nicht modbar. Man kann sie höchstens indirekt beeinflussen.
@majus_gaming wozu dind die Treppen überhaupt da? Nur als Unterführung oder kommt da noch ein ggf. optionaler U-Bahn oder S-Bahn Halt drunter?
Der Busbahnhof gefällt mir unabhängig davon jetzt schon gut.
dir (und @Tom , wenn er will)
Oder der gesamten Community?
Ahrg! Was hast du getan! Der Bussteig schwebt ja, muss eine Hexe sein, verbrennt ihn!
Auf dem ersten Bild habe ich das völlig übersehen. Magst du mir den code schicken den du für die Treppen in der construction hinzugefügt hast?
Ich bin jetzt nicht unbedingt der Experte für modelle aber so weit ich weiß kann man Landanpassungen nur in der construction machen. Du musst da also irgendwo das Loch definiert haben.
Ich glaube ich verstehe die Frage nicht so recht.Was gräbt sich da wo ein und was meinst du mit "bitte platziere die neue .mdl, offset auf die bestehende groundFaces"?
Möchtest du an der Stelle wo du das neue Modell platzierst keine groundFaces haben? Dann darfst du die an der Stelle garnicht erst definieren. Eine Möglichkeit Löcher in ground faces zu schneiden gibt es so weit ich weiß nicht.
"=" ist in Lua eine Zuweisung, "==" hingegen ein Vergleich.
Wenn du also etwas wie if a=true then ... schreibst, wird der Variablen a der Wahrheitswert true zugewiesen und, da eine zuweisung dem zurückgegebenen Wert zurückgibt sieht die Bedingung effektiv if true then ..., springt also hinein.
if a==true then ... hingegen vergleicht den Wert der Variablen a mit true und springt in die Bedingung, wenn die Aussage wahr war.
Naja wenn z.B. params.morecon=0, ist dieser Wert offensichtlich nicht größer als 0,1 oder 2, also geht es in kein if rein und du bekommst wie erwartet keinen Straßenanschluss.
Wenn params.morecon=1 oder params.morecon=2 oder params.morecon=3, ist der Wert offensichtlich in allen 3 Fällen größer als 0, also wird immer direkt ins erste if gesprungen ![]()
So wie du das bastelst müsstest du auf >2, >1, >0 prüfen. Lesbarer ist aber wohl ==1, ==2, ==3 bzw. noch besser, da du ansonsten bei ==3 den Code von ==1 und ==2 wiederholen würdest, was allgemein als "nach Möglichkeit zu vermeiden" gilt, folgendes:
Das Beispiel ist nicht unbedingt gut gewählt oder verstehe ich den Sinn der DKW in dem Fall nicht?
Das Prinzip wird anhand des Beispiels aber klar. Als Anleitung taucht dat also wohl wat.
Brainfuck Quellcode ![]()
Ernsthaft? Warum hat die Foren Software hightlighting für Brainfuck aber keines für Lua ![]()
Bisher habe ich für lua immer kwrite bzw. unter Windows notepad++ genommen. Da ich aber meine projekte grundsätzlich über svn verwalte, ich eclipse bereits gewohnt bin und es mir irgendwie auf den Nerv ging ständig nachschlagen zu müssen wie jetzt nochmal die erwartete Struktur eines bestimmten Attributs war oder wie ein bestimmter Wert für diese ganzen type Attribute hieß, habe ich einfach mal ldt ausprobiert.
aber welche Variable jetzt welchen Typ haben muss ... Dass kann doch keine IDE leisten
genau mein Problem^^ Und doch, das kann eine IDE leisten, wenn man ihr erzählt welche Typen die engine da erwartet und ihr auch erklärt wie dieser Typ aufgebaut ist. Muss man nur halt machen... ldt bietet dazu eine Dokumentationssprache. So ähnlcih wie javadoc.
ug wird vermutlich selbst keine Dokumentation dazu schreiben aber man könnte sowas ja als Community machen. Dann müsste man nur einmal herausfinden wie es funktioniert und könnte das dann mit allen anderen teilen und wenn man Spaß daran hat das ganze nutzen um der IDE ebenfalls mitzuteilen welcher type wie aussieht.
Mit den debugging tools kann man schon ein bisschen was anfangen, wenn man größere Scripts schreibt. Alles was irgendwie mit parametrisierbaren Constructions zu tun hat wird zwangsläufig größer. Ich gehe dann so vor, dass ich mir das ganze zusammen baue und als erstes in der updateFn den parameter den ich übergeben bekomme in die stdout ausgebe. Wenn etwas unerwartetes passiert oder es gar einen crash gibt, nehme ich dieses Objekt als argument für meine updateFn und starte das script im debug mode.
Kann dein atom das Objekt was von der updateFn einer construction zurückgegeben wird vervollständigen, also kennt es die Struktur dieses Objekts? Wenn ja wäre ich doch sehr an der Datei interessiert die dem editor diese Struktur erklärt.
Ich TpF kommt man bekanntlich nicht um lua herum, wenn man modden möchte. Es gibt viele .lua Dateien an unterschiedlichen Stellen, aber auch .mdl, .con und einige andere sind nichts anderes als lua Dateien die ein Objekt mit einer bestimmten vordefinierten Struktur zurückgeben.
Aus anderen Sprachen bin ich es gewohnt, dass meine IDE (meistens eclipse) mir eine Autovervollständigung anbietet und auch so eine Übersicht über erwartete Datentypen gibt.
Da lua schwach typisiert ist, kann eclipse (mit ldt) von sich aus nur bis zu einem gewissen Grad diesen Luxus bieten.
Wie macht ihr das also mit dem lua scripting bei TpF? Nutzt ihr überhaupt IDEs?
Woher nehmt ihr die Informationen über die erwartete Struktur eines bestimmten Objekts? Schaut ihr immer bei Beispieldateien ab wie die Struktur sein muss?
Woher nehmt ihr die Informationen welche Werte für die überall verstreuten enum artigen strings wie z.B. dem type Attribut einer Construction gültig sind? Ebenfalls indem ihr DAteien durchsucht und ggf. mal ug fragt?
Nutzt außer mir noch jemand eclipse mit ldt oder eine andere IDE die eine kompatible Syntax zur Dokumentation von typen nutzt?
Würde mich besonders bei den Vielscriptern interessieren @Tom @tomdotio @eis_os @Enzojz und bestimmt noch einige andere die ich vergessen habe.
Das ist natürlich auch eine möglichkeit wie man es lösen kann. Ist das eine alte schmale Straße?
Nein tut es nicht^^
Dein Script muss sich schon selbst merken was bereits geladen wurde.
Du kannst dann selbst sowas schreiben wie "schau mal nach, ob dieses Teil geladen wurde, wenn nicht schau mal nach ob jenes Teil geladen wurde, wenn nicht nimm halt ein standard objekt von UG".