Beiträge von eis_os

Es kann an Geforce Experience liegen, aber wenn der seit Feb. nicht angerührt wurde, dann weiß ich auch gerade nicht weiter...

Also im Fenstermodus geht das schon ewig, zwar TPF1, aber acht mal FullHD (1920x1080) Da kann auch ne Karte voll raus zoomen. Von den FPS reden wir lieber nicht, das System war dafür nicht gemacht...

Der Overlay Vulkan Render kann eine Synchronisation Objekt nicht mehr herstellen.

-3 wäre VK_ERROR_INITIALIZATION_FAILED

Warum es das auf einmal nicht mehr machen kann, keine Ahnung. Der Code läuft mindestens ein halbes so ohne Änderungen hier.

- Kann es sein das du einen neuen Grafiktreiber hast? (Windows Update macht das gerne auch mal im Hintergrund)

- Läuft im Hintergrund irgendwelche Shader, Overlay oder Aufzeichnungssoftware?

Man kann CommonAPI2 veranlassen die Renderpipeline nicht anzutasten, das wäre in den CommonAPI2 Einstellungen Rendermode auf 2 setzen,

dann verliert man aber das Overlay. Via API Knopf im Spiel ggf. wieder zurückschalten. (Speichern der Einstellung nicht vergessen und Spiel neu starten)

Es wäre gut zu wissen welche Grafikkarte, Treiber genutzt wird

Nein, das geht nicht.

Ein TownBuilding und eine Construction (via Asset/Industrie) sind zwei verschiedene Sachen.

Ein ecs::component::TownBuilding hat eine Verbindung zu einer Stadt (Town) und darüber hinaus auch noch zu Parcels.

Über das Parcel System gibt es ne ganze Menge Verbindungen von einer Stadt zu einem Stadthaus, dies kann man mit einer Konstruktion oder Asset nicht nachbilden. Sprich man bekommt immer eine Art Industrie

Seit dem letzten großen Update werden Straßeninformationen mit ins Savegame gespeichert und sollten daher nicht mehr zu einem Crash führen.

Während der Entwicklung (ohne Release) meines Straßenpakets hab ich die lua Namen geändert und drei Savegames funktionieren ohne Crash auch weiterhin, die Straßen waren aber während des Speicherns natürlich in Ordnung.

Besser ist natürlich keine Fehler bezüglich Meshes, Materialen und co zu haben...

1.6 ist nun online:

eis_os Strassenpaket - Strassen mit Rasengleis & Mitteltram -

Bitte beachtet, manchmal kann der Umbau etwas zickig sein:

- Haltestellentyp stimmt nicht -> abreißen und neu bauen (Beispiel: Bushalt an nur Tramgleis)

- Haltestellen steht verkehrt herum -> abreißen und neu bauen

- Zum Ändern der Fahrtrichtung die rechte Maustaste nutzen beim "Straßenupgrade".

Sonst sind alle Straßen so konzipiert, das die Einbahn Tram/Busspur in Baurichtung gebaut wird, d.h. von Start nach Zielpunkt führt.

Für die einfache Straße oder mit Busspur nicht vergessen beim Bau ggf. die Schienen mit zubauen.

Linux Nutzer: Ich bin immer noch am testen bezüglich isBusLane Problemen, ggf. vor dem Umbau einer Straße Busspur abschalten.

-edit-

PS: Und natürlich dürft Ihr Screenshots veröffentlichen und unter das Volk bringen. Videos ebenso...

Mir gehen die Ideen für Straßentypen nicht aus:

Mal ein Test mit außen liegenden Tram Gleisen, da überholt gerade ein Bus die Straßenbahn :o)

Wird noch besser, einseitige Tramgleise (auf öffentlicher Strasse), einseitige ÖPNV Spur mit Tramgleis einschaltbar. Damit dann LKWs keine Haltestellen blockieren
Das wird ne ganze Menge an UI Bildchen und Tests benötigen...

Ausblick auf meine weiteren Strassen, ein schönes Failback ohne CommonAPI2 wird es aber dafür nicht geben:

Ich würde sagen, die Vorteile überwiegen hier und werde das weiter verfolgen... (als Rasengleis geht es leider nicht)

Und bevor Fragen aufkommen, die Tramgleise haben eine Richtung, die durch die Straße definiert ist. (mit rechts klick wählbar).

Also es werden sich keine Bahnen begegnen oder durcheinander fahren...

1.4/1.5

Visuelle Änderungen, viel Spaß damit.

Download unter:

eis_os Strassenpaket - Strassen mit Rasengleis & Mitteltram -

Changelog:

- removing crossing arrows on lawn only tram streets

- removing crossingCrosswalk on lawn only tram streets

- replace the double line with curbs on medium lawn tram track streets

- always use streetTram background texture, so tram tracks always fit together

- edit-

1.5 - Version mismatch hotfix, wer 1.4 hat bitte auf 1.5 updaten...

Technical information about the inner workings of Transport Fever entity component system (ecs).

Note: This pretty much my limited view on it, and even may change in the future!

For curious people like me, a lot of technical infos, please simple ignore this post if you don't want to look into game internals.

Entities

All game relevant stuff in TPF2 are handled in entities.

Each Entity has an numeric id. Since the api update, you have access to entity components via api.engine.getComponent.

ecs::components are structs, not classes. However they need to be copy able, so pretty much the act class like.

ecs::components are mostly PODs, so they don’t have actually code.

TPF(2) has relevant Systems to manipulate the necessary data.

If a tram moves around, there is a Move System handling that kind of entity. A line system for stop management and so on.

You can ask a lot of Systems to give information. See api.engine.*System

ecs::Engine and ecs::ComponentManager

The ecs::Engine and ecs::ComponentManager hold the game data,

if TPF2 changes something or need data it looks into the components of Entity, this is handled by these.

Most code assumes that the necessary data to be present, if not a it != it->components.end exception is a result.

When loading or saving, your game save data is handled by the component manager and it does game version difference handling. Upgrade savegames when loading.

As the structure needs to be known it's not easy to write an external savegame editor.

Flow of Savegame System is as this:

For each ecs::component:

SaveComponentData<struct ecs::component>Write()
Write each component data field via std io functions to savegame. There is no header, only the count of data in vectors are written.
The load functions my transform the data or link entity components in ways the game needs.

After loading, there are some fixups done, if a earlier game did something bad, or a savegame version fundamental changed something.

Game States

Each Game has at least two currently active GameStates with a own copy of the entity data. An own instance of ecs::Engine,

GameRes is shared across states, and shouldn't actively change. (That's a reason you can't write to api.res from UGs point of view)

There is a time frame where each System may actively allow to change the data.

Each entity component will be flagged if changed.

Every game state flip changes are copied, or you do a savegame as example, you simply use a GameState for saving, the game can continue running.

You can actively follow this, as game_scripts get there relevant load and save events.

If you mess with the lua state of you game script, you get an error, because TPF2 can't transfer your lua variable state from one GameState to the next.

If copying takes to long, or a gamestate is still is used by an industry developer or street expansion, you get micro stops in the game.

This system was actively changed in the performance updates and got several changes.

Technical you can't write to entities via lua api. You are allow to send api.cmds or influence decision by commands, if the command does a gamescript callback.

ecs::Engine internal workings:

Internally each component data is hold into an vector<struct ecs::component::something)

and the ecs::Engine, ecs::ComponentManager is responsible to manage lifetime.

A basic c++ code (that doesn't support high level revision system) straight from CommonAPI.

The typeidptr is actually a c++ std::type_index of a ecs::component::something

    struct typeindexid2index {
        int typeindexid;
        int dataindex;
    };


// This is actually a kind of vector struct, however the size changes between game compilation 
    struct Engine_m_entityComponents_entry {
        ecs::typeindexid2index *components_start;
        ecs::typeindexid2index *components_end;
        __int64 dataIndex;
    };


template<typename T> T* getComponentFromEntity(ecs::Engine* engine, int entityid, void* typeidptr) {
    void* mytypeid = typeidptr;
    int typeIndex = ecs::ComponentManagerFn::GetComponentTypeIndex(&engine->ComponentManager, &mytypeid);
    auto components2typeindex = engine->m_entityComponents[entityid];
    auto end = components2typeindex.components_end;
    auto ptr = components2typeindex.components_start;

    if (ptr == end) {
        return 0;
    }
    while ( ptr->typeindexid != typeIndex) {
// Technical TPF2 does an iteration here, if it fails you get it != it->components.end exception,
// my code simply returns null without crashing.
        ++ptr;
        if (ptr == end) {
            return 0;
        }
    }

    std::vector<T>* ptrdata = (std::vector<T>*)&engine->ComponentManager.m_componentDatas[typeIndex]->data;
    return &(*ptrdata)[ptr->dataindex];
}

Depending on compiler decision the entity iterator code is inlined. Means the compiler thinks for performance reasons it's worth to not call a function but use a copy of the code in place.

UI::CSelector

UI::CSelector is the execution root of UI user input, if something in the deeps of the game crashes, a catch Exception block will print the error to stdout.txt

You can think about the actually flow of the game like this:

UI::CSelector -> UI and GameScript running -> LUA -> your function maybe -> LUA -> api.* function -> c++ function throws exception,

Explizit möchte euch auf Punkt 1 hier hinweisen, bezüglich Politik.

Forenregeln

Daher ohne irgendwas zu bewerten oder auch durchzulesen mache ich nun zu.

Yes, changing post release street names won't work. It is an advise for new mods.

And I only want to emphasize that seeing the string error it != it->components.end is a clear indicator for Entity related problems. It is simply possible that non related code (non ecs entity code) throw an error and you see UI::CSelector as well.

-edit-

For the technical inner workings I opened a thread here: https://www.transportfever.net/index.php?thread/18395

Not an array. it's an broken Entity. TPF2 searches an Entity Component, if something is missing it is a fatal error Exception. Technical it's a c++ macro and a such each and every code piece in TPF2 may produce this. The UI:CSelector has a catch block for Exceptions.

If it is a regular result of a mod, then this mod creates or changes an Entity in a way it shouldn't.

A general note to all mod creators:
Please add a clear marker who changes something.
So instead adding only some internal postfix, add the modname to the auto generated modified streets.

1.7.20220223

Neues Jahr, neue Version, noch schnell bevor UG irgendwann mit der Beta loslegt.

Linux Nutzer wird dringend empfohlen auf diese Version zu updaten. Es beseitigt Fehler beim Umschalten zwischen OpenGL und Vulkan Renderer

Für Windows Nutzer, die Track Toolbox sollte wieder funktionieren.

Im Inspektor werden nun große Entity Komponenten versteckt und können via checkbox angezeigt werden.

Leider haben es neue Funktionen für Ampeln noch nicht in die Version geschafft. Ich versuche da schon seit geraumer Zeit Ampeln für Staßenbahnen einzubauen (BOStrab Fahrsignale auf Sicht, also "Lichtbalken")

CommonAPI2 Download:

CommonAPI2 (via Downloads)

1.7.20220223 funktioniert mit Build 34983 direkt.

1.7.20220223 works directly with Build 34983.

CommonAPI2 Download:

CommonAPI2 (via Downloads)

Linux Nutzer wird dringend empfohlen auf diese Version zu updaten. Es beseitigt Fehler beim Umschalten zwischen OpenGL und Vulkan Renderer.

Für Windows Nutzer, die Track Toolbox sollte wieder funktionieren.

Linux users should use this version, it reduces crashes between OpenGL & Vulkan render changes.

Windows users, the track toolbox should work again.

Dafür hab ich den Reset Knopf drin. Drauf klicken und man hat wieder den Installationszustand.

Außerdem hab ich Trunky verständigt und so wie ich es sehe ist der Fehler behoben...

My road pack doesn't have such names, all streets use my name as prefix, and additional have a base folder of eis_os_streetpackage in config.

Please look into a mod eis_os_streetpackage_1/res/config/street/eis_os_streetpackage/ before making wild guesses, thanks.

[ ] Checkbox "Repositories" drücken, die Liste geht auf.

Links unter "name.repo" gibt es einen "Reset" Knopf

-edit-

Zurzeit gibt die Modwerkstatt aber kaputtes JSON raus, siehe hier, Firefox kann das auch nicht parsen...

https://modwerkstatt.com/tpfmm/

-edit2-

Ich hab es mal Weitergegeben an meine Kontakt(e)

Bus, LKW Spuren werden ggf. von Anlieger - Fahrzeugen genutzt.

Alternativ gibt es ein CTD wenn ein Bewohner sein "Taschenpkw" nicht auspacken darf.

Ich kann nicht behaupten das UGs System nicht funktioniert.

Also auf nur Tramgleisen der CommonAPI2 sind mir noch nie andere Fahrzeuge aufgetaucht. Und hab auch separate ÖPNV Spuren ohne LKW Verkehr. Aber ich pfusche da ordentlich am Code herum, die Ergebnisse könnten daher abweichen