Überflüssige Einträge in der model.cfg

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.

    Sind die folgenden Einträge nicht eigentlich überflüssig in einer model.cfg? Und wenn ja warum nicht?

    Oder verpeile ich das grad wieder? Da bin ich eben in einigen Bussen drüber gestolpert.

    Code
    1. [viewpoint] <-- Ist eh immer sichtbar, ob es nun dabei steht oder nicht
    2. 0
    4. [matl_alpha] <-- Ist eh nicht durchsichtig, ob es nun dabei steht oder nicht
    5. 0
    7. origin_rot_z <-- Da wird ja auch um nix gedreht
    8. 0

    Danke für eure Unterstützung!

    Naja, wenn ich Fahrzeuge und Sceneryobjekte erstelle möchte ich da keine unnötigen Einträge rein hauen.

    Da geht es eher ums Prinzip, ob die anderen Objektbauer das falsch gemacht haben oder ob ich es einfach nur nicht raffe.

    If [viewpoint] is left out, it gets inherited from the previous [mesh]e's [viewpoint], so resetting it (to 0) might make sense, if the previous one was too restrictive. (Edit: No, that's not how it works -- 0 is indeed the default). I have no good example on what purpose the other two flags, directives -- whatever the proper term is --, might serve under their default values.


    I think your intuition in general is right though: There is a lot of clutter, sometimes even plain duplication, both in configuration files and scripts. Predominantly I believe this is due to too many modders, having, over too many years, engaged in too much "quick & dirty" copy/pasting. For example, consider the cockpit.osc of the freeware Citaro and SU: There are tens of unnecessary variables that are being processed in tens of superfluous triggers and macros, implementing functionality that is simply no longer relevant to modern vehicles (think e.g. the triggers for the standalone electrics/lights key, engine ignition, and engine shutdown functions, all of which are obsolete, yet miraculously survive to this day).


    I can only identify one sound reason why a modder would choose to retain such clutter (being lazy doesn't count :) ) : Diffing & patching. If I make a large number of changes to a long text file, like a model.cfg, I want to be able to easily tell what I changed, and revert the changes, in case I hit a bug, for example. The standard diff/patch utilities that exist out there for that exact purpose, however, will no longer be able to make my life much easier, if, in the middle of development, I suddenly decide to compulsively clean up all the extraneous bits of the long file. Thus, in a complex project involving lots of editing of text files, the sole practical chance one gets to clean up the foundation, is right at the beginning, before yet having undertaken any big, functional changes. Unfortunately, in the initial phase of excitement that usually accompanies every new project's beginning, that's precisely the last thing a typical modder, myself included, has the foresight to do.

    Okay, thats an interesting point. I will test this later that day.


    Code
    1. [mesh]
    2. model1.o3d
    4. [viewpoint]
    5. 1
    7. +++++++
    9. [mesh]
    10. model2.o3d

    Also hat Model 2 trotzdem den Videwpoint 1 ja? -> Nein wird auf Viewpoint 0 zurückgesetzt

    Yes, that's how I believe it works. To be fair, I haven't tested whether it applies to every viewpoint-value. Nor do I know of a passage in the SDK reference, or the wiki, that verifies my claim. But for viewpoint 2 specifically used in vehicle model.cfgs, I know, for example from looking at alTerr's Citaros, that just the first dashboard switch sets the viewpoint, yet all other switches/buttons/levers that come after it appear to inherit it, given that they too are only rendered when an interior vehicle perspective is used. Hence, logically, one would assume that it behaves consistently for other viewpoint-values -- and hopefully also in the case of scenery objects -- as well.


    Edit: Sorry, modellbusse ;) , I just tested, and my claim regarding viewpoint-inheritance is totally incorrect. Indeed, 0 seems to be the default. I don't know why I was so firmly convinced that my hypothesis works... maybe I was thinking of [illumination_interior] instead... or the caffeine simply hadn't kicked in yet. :/

    Zitat von Unorthodox Paradox

    I was thinking of [illumination_interior] instead

    When you say [illumination_interior]: The Money and Tickets on the Cashdesc use the illumination of the last mesh from the modell.cfg. Maybe you thought about that?

    Weil du grade von der [illumination_interior] anfängst: Geld und Tickets am Zahltisch nehmen die Beleuchtung vom letzten mesh in der Modell.cfg. Vielleicht dachtest du grade da dran?

    Ich habe mir tatsächlich eingebildet, alle Dashboard-Schalter des Citaros, außer dem ersten, würden keinen Viewpoint deklarieren. Diese Vorstellung kombinierte ich dann wohl mit dem Wissen dass...

    Zitat von Marcel Kuhnt

    Wenn kein weiterer "[illumination_interior]"-Befehl folgt, dann werden die Lichtquellen vom vorherigen Mesh genutzt.

    ...um schließlich zu folgern dass "[viewpoint] wie [illumination_interior] funktioniert",


    Äußerst peinlich! Zumindest erfolgte in diesem Fall Bildung durch Einbildung. :)