Beiträge von eis_os

I am not sure what you mean with arc. Do you mean that you have two small pieces at the end flat and then a curve down? And you calc some sample points every x length and build a list of triangles for the terrain modification list?

Hmm, with previous Beta Patch it didn't worked well. Maybe I have an error but as soon the snappoint at groundlevel was connected TPF tries to do some terraforming. Did you use slopeLow, slopeHigh?

Die Gruppe sollte man so erreichen, man muss Mitglied sein, sonst kommt man nicht in die jeweiligen Foren (Gruppe Beitreten)
http://steamcommunity.com/groups/transport_fever_beta_test/

Ja, ich hab in meine Mods auch ein kompletten Modifer der mir alle Gleistypen und Strassentypen lädt mit den bekannten Problemen.
Außerdem kann es ja sein, das ein späterer Modifer die Werte ändert und soll ich nochmals alle LUA Werte zwischenspeichern für jedes Mod, das ist doch dämlich? Außerdem UGs UI könnte das ja auch nutzen...

UG hat schon intern ein Repository für die Typen. Ein Entity kann auch schon serialisiert werden nach Lua, zum Beispiel per game.interface.getEntity, warum also nicht auch nicht die Typen aus dem Repository?
Und Auflistungen gibt es per game.interface.getEntities, ich verlange ja nicht das man es dynamisch ändern kann.

Textanalyse von TPF:
StreetTypeRep, TrackTypeRep, BridgeTypeRep, TunnelTypeRep, cargoTypeRep, m_railroadCrossingTypeRep

Und es gibt auch bestimmte Funktionen für die Repos:

TrackTypeRep->Find(standardTrackName) Das bedeutet das es eine Funktion zum Auffinden eines Types gibt
trackTypeRep->GetNumTypes()
oder auch cargoTypeRep->GetNumTypes()

--
Xanos ModManager kann die Listen nicht erstellen, ich hab eine Liste von Modgleisen für die UI, diese gilt aber Modgrenzen hinweg.
Nun ist die Frage wo ich das Zentral speichere für alle Mods. Der richtige Platz wäre für jeden Steam User / User separat, also da wo die settings.lua ist.

---
Wie kannst Du nach Dateien in LUA suchen (cross platform ohne exec)? Ich möchte alle Dateien in einen Verzeichnis aller Mods auflisten, also /mod_1/meindir/*.data, /mod_2/meindir/*.data

Hallo

Für die Weiterführung der Diskussion in Gameplay-Patch angekündigt

Hier also mal meine Ideen & Anregungen zur Modding Schnittstelle

Die einzelnen Punkte werde ich dann noch mit Inhalt füllen,sobald mir die Zeit es zulässt.

Zusammenfassung:

• Dokumentation zu Parametern
• Fehlerbehandlung
• bessere API für das Laden von neuen Ressourcen (Gleise, Straßen, Tunnel)
• Kontrolle über das Konstruktionsfenster per LUA. Ich möchte alle Internen UI Elemente (Knöpfe usw.) selber festlegen
  Daraus erstellt meine LUA Funktion eine Parameter Liste die in der Entity Konstruktion abgelegt werden kann.
• Möglichkeit im Virtuellen Res Ordner nach Dateien zu suchen.
• Pfad Auslesen/Speichern von Mod spezifischen Einstellungen.
• Snappoints für Konstruktionen
• Bessere Kontrolle über die Bodentätigkeiten eines Gleis. (Und auch keine Änderung Textur bei alignTerrain = false)
• Abschalten von Tunnelwänden (Ich will nicht jedes Modgleis duplizieren um die Wände zu ändern)

Dokumentation zu Parametern
Damit wir beim erstellen von Mods keine bösen Überraschungen erleben wäre eine Übersicht der Grenzen von Parametern hilfreich:
Beispiele: Max Min werte von slopeLow, slopeHigh

Wie kurz darf ein Straßenstück sein das Snappoints hat? (wenn man ein größere Strasse anbaut, und die Verengung nicht mehr passt crasht das Spiel.)

Fehlerbehandlung

Die LUA Stack Traces sollten wenn möglich die Dateiname mit kompletten Pfadnamen des Modordners zeigen.

Allgemein wäre es gut nicht nur den Mod ID sondern auch die Bezeichnung aus der mod.lua im stdout zu zeigen (Gerade für SteamWorkshop Mods)

API für bessere Ressourcenmanagement

Zurzeit hat TPF keine Möglichkeit die Mod Gleise, Strassen usw. Zentral per Code abzufragen.

Daher Schlage ich eine API Schnittstelle vor, die internen Repositories für Gleise, Strassen, Brücken und so weiter zur Verfügung stellt.
Leisten soll Sie: Die Anzahl der Typen auszugeben, die Daten per ID bzw. Namen zu erhalten, zwischen ID und Namen zu konvertieren.

Als Beispiel:
game.repositories.tracks / roads / bridges
getCount()
getById()
getByName()
convertIdtoName()
convertNameToId()

Damit wäre es Möglich die Gleisauswahl der parameterutils komplett dynamisch zu erstellen.
Auch sind Fragen wie die Gleis oder Straßenbreite so zu erhalten. Ein Depot bauen mit Schmalspurgleis, dafür bräuchte man nur noch ein Depot.

Objekte (Gleise, Strassen, Brücken) erhalten darüber hinaus noch einen shortUIName, und hideInUI Flag.
(Keine Hacks mehr per Erscheinungsjahr um etwas zu verbergen)
Die Filterung hierbei übernimmt ein LUA Script, damit kann dann auch nach anderen Kriterien gefiltert werden.
Die starre paramsutil.makeTrackTypeParam Funktion wird durch eine neue ergänzt. shortUIName wird als Namen der (Gleis)typen genutzt

Probleme / Änderungen am Spiel:

Hierfür muss das Laden von Mods geändert werden, Gleise oder ähnliches müssen früher als Konstruktionen geladen werden oder das Konstruktionsfenster muss man updaten können.
Die UI kann zurzeit nur komplette Parameter per Zeit ausblenden.

Konstruktionen UI

Neue API für UI Konstruktionen, da es eine Zweideutigkeit gibt zwischen param und param der updateFn, hier eine Unterscheidung:

uilist = eine Liste mit der UI Beschreibung (params der Konstruktionsbeschreibung)
settings = eine Liste der gewählten Einstellungen des Users, bzw. die vorhandenen oder neuen Einstellungen der Konstruktion. (also der UI Parameter Teil von updateFn, { param1 = 1, param2 = 2, ... })

Es gibt keine Änderungen in den Namen der vorhanden Daten bzw. in der Funktion.

Neue UI Elemente für die Uilist

Es gibt einen neuen UI Type für jedes Element, sollte dieser nicht vorhanden sein wird type = "VALUELIST" angenommen (zwingend)
Es muss immer auch eine values = {} angeben werden, dies soll verhindern das "alte" Mods zu viele Probleme bekommen, ist aber nicht zwingend.

Hierbei ist zu beachten, damit nicht alles intern verändert werden muss das UI Elemente weiterhin auf uint32 begrenzt sind.
Desweiteren gibt es die Möglichkeit mit hidden = true ein Element auszublenden,
für kompaktere Layouts kann die Überschrift weggelassen werden. name = ""

Einzelne Werte in values Listen sollten auch die Möglichkeiten habe per yearFrom yearTo Zeitabhängig ausgeblendet werden.
Um auch hier die Kompatibilität zu erreichen, schlage ich eine Liste yearFromValues und yearToValues vor, die Liste hat für jeden Eintrag in values einen Wert.

Die verschiedenen Typen:

Wenn Values gefüllt ist, können diese Werte ausgewählt werden, anstatt einen Wert zwischen minValue, maxValue inklusive
Für größere Wertelisten wäre eine Schnellwahl schön, vielleicht kann man da die Linienauswahl Fenster wiederverwenden.

updateUIFn(uilist, settings)
Erstellt eine neue UI für diese Konstruktion und ersetzt die uilist Definition,
gibt als Rückgabewerte eine Tabelle wieder, analog der updateFn.
Mögliche Rückgabewerte sind eine veränderte uilist und/oder eine neue settings Liste

return {
uilist = uilist,
settings = settings
}

updateUIFn wird aufgerufen bevor eine Konstruktionsfenster erstellt wird, nachdem ein UI Element bedient wurde und nachdem die updateFn ausgeführt wurde.
Die updateFn kann per result.uisettings die Einstellungen der UI ändern!:

Weitere Punkte folgen...
Ihr seit eingeladen eure Kritik / Fehler / API Wünsche zu äußern. Vielleicht hab ich ja noch irgendwo einen Denkfehler oder es gäbe eine bessere Alternative.

Wie schon früher gesagt, wünsche ich mir nur bessere APIs zum Spiel hin gesehen und auch mehr Kontrolle für die Nutzererfahrung.
Well, as said earlier I only wish better APIs and better control over the UI experience.

Zusammengefasst:
- bessere API für das Laden von neuen Ressourcen (Gleise, Straßen, Tunnel) und Fehlerbehandlung *
- Kontrolle über das Konstruktionsfenster per LUA. Ich möchte alle Internen UI Elemente (Knöpfe usw. selber Festlegen)
Daraus erstellt meine LUA Funktion eine Parameter Liste die in der Entity Konstruktion abgelegt werden kann.
- Möglichkeit im Virtuellen Res Ordner nach Dateien zu suchen.
- Pfad Auslesen/Speichern von Mod spezifischen Einstellungen.
- Snappoints für Konstruktionen
- Bessere Kontrolle über die Bodentätigkeiten eines Gleis. (Und auch keine Änderung Textur bei alignTerrain = false)
- Abschalten von Tunnelwänden (Ich will nicht jedes Modgleis duplizieren um die Wände zu ändern)

Ich werde die API Diskussion jetzt aber mal Auslagern und einen neuen Thread erstellen:
-edit-

Mod API Diskussion (weiterführung aus dem Beta News Beitrag)

Nunja, wenn ich wissen möchte schaue ich mir im Zweifel die EXE Datei an ob UG das überhaupt einliest oder das Enum überhaupt existiert. Wobei wenn etwas eingelesen wird hat sagt das ja nicht unbedingt etwas über die Funktion aus. UG lädt ja die Datei und konvertiert den ganzen lua Kram dann in C++ Objekte, dann ist mein Assembler Fu aber auch nicht mehr genug um den C++ Code nachzufolgen oder ich hab da eher keine Lust zu.

Optimierter C++ Code ist da überhaupt nicht lustig. Die Lua Values werden dann per template c++ in den richtigen Typ konvertiert, dort gibt es dann Verzweigungen die Aussagen, dass etwas nicht konvertiert werden kann.
Damit hat man dann eine möglich herauszufinden ob da TPF zum Beispiel einen String mag oder es doch ein Boolean ist.

Des weiteren gibt es auch Code der zwar bestimmte Sachen akzeptiert (die params können auch eine Funktion sein) die aber das Spiel später mit einem Crash quittiert. Der C++ Code für Lua spricht auch zum Beispiel keine LUA Metatables an.
Im Endeffekt bis auf wenige Ausnahmen ist weiterhin die LUA Welt immer nur ein statischer Datenlieferant, dieser wird dann erst mal ausgelesen und dann in UG kompatible Objekte bzw. Bauanweisungen konvertiert. Diese Konvertierung kann auch für das Spiel recht unsinnige Werte annehmen, das sehen wir dann meistens als Crash beim Laden oder Bauen.

Ausnahme: game.interface dort kann man wirklich Einfluss auf die Map nehmen. Da darf man sogar die Werte der Parameter einer gebauten Konstruktion ändern, aber in einer Update Funktion einer Konstruktion können wir keinen Einfluss nehmen. Das Ärgert mich schon ...

Besser wäre es wenn UG das mal dokumentieren würde, was da hinein darf/soll. Oder eben eine Funktion für Mods damit man sagen kann man möchte eine gerade Wand haben

Would be better UG would document what values are valid. Or better directly a function so we can say we want a wall.

Ehm, die MsgBox hat einen Stacktrace, siehe hier:
Gameplay-Patch angekündigt

Der Stacktrace ist natürlich sehr kurz, da ja TPF gerade aus dem C++ Code von UG die Lua Datei lädt und der Lua Loader kennt nun mal eben nur das Virtuelle Dateisystem was UG da hat.

Die Fehlermeldungen die man bekommt sind meistens ein paar im Code verteilte Assets und geben nicht wirklich einen Grund wieder da der Code da schon weiter ist.
(Sprich der Fehler wird erst an ein ganz anderen Stelle sichtbar) Das wird aber langsam zu sehr technisch und geht zu weit hier...

-edit-
Du erwartest von LUA (was eher einfach gestaltet ist) das es für jede Funktionsaufruf einer Tabelle die Herkunft der Tabelle kennt. (Funktion hilft ja hier nicht, da die Fn ja nicht mehr definiert ist)
Um es besser noch mal zu erwähnen um Missverständnisse auszuschließen, die Collider Datei ist eine neue UG Datei aus der Beta und gehört zu keinem Mod.

@tomdotio:

Technisch gesehen kann man für den Fall nur sehr schwer eine richtige Fehlermeldung herstellen, da das aufrufende Modell/Konstruktion ja annehmen muss das die Funktion vorhanden ist.
Man könnte theoretisch nachverfolgen welche Datei im virtuellen Dateisystem von welchen Mod überschrieben wird und dieses auch noch Ausgeben. Wobei ein Steam Mod auch nicht aussagekräftig ist.

Nur so als Anregung: Es wäre schön beim Fehlersuchen wenn Ihr zu der Mod Liste in der stdout auch noch die Bezeichnung der Mod ausgeben würdet.
Gerade bei Steam Mods sind die IDs doch etwas kryptisch und das wäre dann soweit nutzerfreundlicher wenn der Spieler dann anstatt nur modid_1 auch dann ("Bahnhof Bla Bla") herauskommt.

Vielleicht sollte ich aber mal ein paar Seiten Verbesserungsvorschläge in eine E-Mail packen und euch direkt schicken.

Build 13451

/res/config/base_config.lua
In game.config.terrain.

initialTownMinSize
initialTownMaxSize
initialTownSizeExponent
allowTownsInRoughTerrain

/res/scripts/constructionutil.lua
constructionutil.extrudePoints

ausgelagert in die neue Datei:
/res/scripts/colliderutil.lua als colliderutil.extrudePoints

Neue Dateien
/res/textures/ui/b_arrow_left.tga
/res/textures/ui/b_arrow_right.tga

Das liegt aber zum Beispiel an den sehr verkorksten APIs dieser Dateien.

Beispiel wir haben die Möglichkeit von UG neue Gleistypen einzubauen. Soweit ok.
Aber keiner bei UG hat sich da Gedanken gemacht wie man es dann auch anständig im Spiel nutzen kann.

makeTrackTypeParam gibt zwar die Gleisnamen für die Params, aber die Gleistypen werden in den Konstruktionen definiert.

Eine anständige API hat nicht nur die Parameter Generierung in einer Funktion sondern auch eine Funktion die ID aus dem jeweiligen Parameter in eine gleistyp.lua umwandelt:
getTrackTypeFromParam

Noch besser es gäbe dazu eine game.repositories.tracks.getTrackById und byName. Diese würden dann Intern von der paramsutil.lua genutzt um die Gleistypenliste dynamisch zu erstellen.

Weitere Funktion dafür wären die Daten zu einen Typen abzufragen, damit Daten wie Gleisbreite oder ähnliches zu erhalten. (Dann brauch man das der UpdateFunktion nicht zu übergeben)

Und jetzt kommt vielleicht noch das Argument, zu dieser Zeit ist das Repository nicht vollständig.
Ja genau, wenn man die API designt sieht man schon die Probleme, dass entweder Konstruktionen später geladen werden müssen oder eben die UI das später nochmals updaten muss.

Ich finde das sollte doch jeder der schon mal Programmiert hat einsehen oder?

PS: Und das gilt natürlich nicht nur für das interne Repository für Gleise, sondern für alle internen ECS Repository Typen. Bridge, Tunnel ...

@tomdotio
Ich würde da nicht so viel Nörgeln wenn mir das Spiel nicht so sehr am Herzen liegen würde.

Meine Meinung nach ist das der falsche Weg, sobald die Datei wegen eines Bugfix geändert werden muss hat man dann subtil anderes Verhalten weil ein Mod eine alte Version mitbringt... hmpf.

Mal schauen was die Version noch so für eine Wundertüte ist...

-edit-
Nunja, versteht mich nicht falsch, ich bin froh das so Sachen wie feste ID Zuordnung seit der Beta nun endlich drin sind und auch das am Terrainalgorithmus gearbeitet wird.

Aber ich lag UG schon seit Train Fever Release bei den IDs in den Ohren. Gut endlich gelöst.
Sehe eben die Zeit sinnvoller ausgeben wenn Problem mit unflexiblen Konstruktions UI endlich behoben werden und damit man eine vernünftige Modgleiswahl einbauen kann als in die UI ein Vorschaubild für Mods einzubauen.

Nein, man könnte Transport Fever auch als Train Fever 2.0 bezeichnen.
Ja es gibt dann Flugzeuge und Schiffe, aber es wird keiner gezwungen diese zu nutzen (Abgesehen von der Kampagne, Train Fever hatte keine).

Und gerade neue/andere Bahnhöfe und verschiedene Schienenarten sind ja auch zum Beispiel neue Funktionen aus Transport Fever...

Das ist eine Funktion in /res/scripts/construnctionutil.lua, die geändert wurde. (Eine Datei von UG)
Vielleicht ein Mod das eine eigene construnctionutil mitbringt oder es gab beim Update von Steam ein Problem...

-edit-
Freakh war schneller.

Ich verweise auch mal wieder auf Inoffizielle Änderungsliste (Beta Build 12718,12663, 13251, 13422)

Build 13422

Neue Funktionen für Modelle (mdl)

• terrainAlignmentProvider
  In metadata kann mit terrainAlignmentProvider eine terrainAlignmentLists erstellt werden.
• Neuer collider type POINT_CLOUD
  siehe dazu /res/models/model/asset/station/diag*_collider.mdl
  und die extrudePoints Funktion in /res/scripts/constructionutil.lua

/res/config/base_config.lua
In game.config.terrain.

• generator
  noiseScale* und ridge* Einstellungen
• Neuer Key: river
  Fluss Einstellungen für die Karten Erstellungen?
• Neuer Key: valley
  Einstellungen für den Generator für Täler?

/res/scripts/constructionutil.lua

• Neue Funktion:
  constructionutil.extrudePoints(points, offset1, offset2)

/res/construction/industry/food_processing_plant.con

• Änderungen in den Strassen Edges

/res/construction/station/air/airport_*.con

• Neu: Es werden Collider Modelle gebaut

/res/construction/station/street/station_diag_dual.con
/res/construction/station/street/station_diag_dual_new.con

• Neu: Es werden Collider Modelle gebaut

/res/models/model/station/train/*/*.mdl

• collider type nun "BOX", ehemals MESH
• boundingInfo für die main_building_size*.mdl

/res/models/model/station/bus/*.mdl
/res/models/model/station/tram/*.mdl
/res/models/model/depot/*.mdl

• boundingInfo Änderung. bbMin von -2 auf 0 für z Koordinate
• Neu: terrainAlignmentProvider

/res/config/bridge/road_wood_old.lua

• Neu: sidewalkHeight = 0.0
• Änderungen von street/transparent.mtl auf bridge/road/road_wood_old_crossing.mtl

/res/models/model/bridge/road/wood/old_railling_rep.mdl
/res/models/model/bridge/road/old_railling_side.mdl

• Änderung transf

Neue Dateien:
road_wood_old_crossing.mtl airport_1920_collider1.mdl airport_1920_collider2.mdl airport_1950_runway_collider.mdl airport_1950_terminal1_collider.mdl airport_1950_terminal2_collider.mdl airport_1950_terminal3_collider.mdl airport_1980_runway_collider.mdl airport_1980_terminal1_collider.mdl airport_1980_terminal2_collider.mdl airport_1980_terminal3_collider.mdl diag1_collider.mdl diag2_collider.mdl diag3_collider.mdl road_wood_old_cross_albedo.dds road_wood_old_cross_metal_gloss_ao.dds road_wood_old_cross_normal.dds

EXE Änderungen:

Savegame Version nun 83
deltaMin, deltaMax vielleicht für boundingInfo oder Collider?

OT: Der Bridge Ramp Designer ist ja auch nicht für Unterführungen.
Ich hab mein Tunnelrampen Designer auch in die Ecke geworfen, da sich der Aufwand für mich einfach nicht mehr lohnt. Grimes hat so schöne Modelle. Ich hab natürlich an eine früheres Erscheinen des Mods gehofft, also gebt mal Gas

Gute alte Zeit ist relativ.

Für eine CPU und Speicherbedarf so einer Simulation wie Transport Fever waren mal ganze Serverracks nötig, damit resultiert natürlich auch eine höhere Komplexität.

Und wenn ich mir an die ersten Grafikbeschleuniger denke, 10Base-T, OS/2, DOS läuft es doch alles doch recht rund.
Update für ein Spiel? Per Modem und BBS besorgt, nein das möchte ich nicht mehr.

Mich mit inkompetenten Herstellern herumschlagen, das muss ich heute immer noch, wenn aber alle Stricke reißen kann ich dem desjenigen ein Bild oder Video schicken und zu Not auch die Spezifikation in Asien herunterladen.
Stimmt die dann? Nicht immer, aber ich habe nicht mit 10 Leuten telefoniert die mir das Blaue vom Himmel beschrieben haben.

Geändert hat sich aber die Marge an der ganzen Sache.
Natürlich ist es heute eben nicht mehr möglich sich X Stunden um einen Kunden zu kümmern und die halbgaren Sachen können auch nicht mehr so gut von Händlern abgefangen werden.

Früher konnte ich einem Kunden auch noch etwas erklären, dieser hat dieses aufgenommen, versucht zu verstehen und umzusetzen.
Heute? "Ich will das nicht wissen, muss nur laufen, sonst werfe ich es weg". Das geht mir mittlerweile ganz gehörig auf den Zeiger...

Neue Version = wieder neu Herunterladen oder man kann einen Patch herunterladen. (Kommt darauf an). Es gibt eigentlich immer die neueste Version als Komplettpaket

Für Windows, sind es 3 Dateien (eine exe Datei und weitere bin Dateien) und für Linux Nutzer gibt es eine riesige Datei.
Man sollte um die 6GB einplanen für Transport Fever, Einfach auf dem Zielsystem alles in ein Verzeichnis kopieren und dann die Installationsdatei ausführen.

UG benutzt es um die Strassenart USA in den Einstellungen umzusetzen.
Da wird effektiv mit game.config.townMajorStreetAngleRange = .0 dann dem Spiel gesagt, er soll die Strassen ohne Winkel bauen... (siehe dazu base_mod.lua)