Modelling questions

It is an OMSI problem. The rue of thumb ist that OMSI renders at last that what's placed at last. You can try this oute by moving objects in the model-file (*.cfg) more to the beginning to give them a lover prority or to the end to give them higher priority. There is also an option called [rendertype] only for sceneryobjects. But In the main game, between busses ect. you can do nothing to fix this your self.

So you removed it from glass and repaint texture entry and now it works?

that would require a real mirror like the rear mirror, what could heavily decrease your performance ingame.

Maybe you can rip off the roof in blender, photo your interior in a orthogonal top view and try this as reflection.

Zitat von PaulIP

Does OMSI recognise "inside" objects (like roof panels) from "outer" ones (like the body)

When you have different objects or textures, it should be possible to make different envmaps or shiny strength. If you look at other busses, the interior is mostly or always seperated o3d's from the outer body.

Zitat von PaulIP

What is the "secret" to get rid of what is here and to make the sun visors "invisible" when not dragged?

you need a complete transparent box around them. The secret is the correct order in the cfg, that you can still see all of your bus, but the box hides yoursun visor. For further information, take a look at for example the Mercedes O303, Setra S313UL or other busses without a big matrix box to hide it.

I'm afraid there can only be a single [visible] directive per [mesh]. But the variable tested in a [visible] can itself be derived from an arbitrary number of other variables and relationships between them, via scripts.

So, assuming I've understood you correctly, you want the [visible] constraint to be satisfied, i.e., the object to be displayed, when a) some .cti-variable has a certain value, at initial spawn time, or b) the user has subsequently "clicked-activated" something in-game. Here's a template on achieving that:

And some clarification on the above:

• The script where you add these fragments doesn't really matter; just pick the one that seems most relevant to the nature of your object, or create and integrate (with the *.bus-file and main script) a new one. This means that the cockpit_init fragment could reside e.g. in gearbox_init of gearbox.osc instead, or generally speaking, in the xxx_init macro of the script named xxx.osc. The same applies to the cockpit_frame fragment, which can be appended to any xxx_frame macro really. Pay attention though that the trigger block must be pasted verbatim (including its start and end tag, and retaining the same name) to the top of the file, whichever it is, before any macro occurrences.
• Principle of operation: OMSI reads the .cti-file [setvar] entries briefly after a vehicle gets spawned. There are two problems with this: First, it not exactly known when that happens. It could be during exactly the first frame after spawn, or it could be the second, or, for that matter, the thirteenth frame. The only thing known is that it doesn't occur during the init phase (which is usually the time at which you see a "preview" of the vehicle in the vehicle selection GUI). Second, once OMSI reads the .cti and assigns its specified values to the corresponding variables, the variables can no longer be reassigned by scripts. Both these reasons explain why this complex setup is needed. First we assign (in the "init" block) a value known to be invalid (-1) to the .cti-variable (my_mesh_visibility_cti). Then, once each frame, we test whether that variable has changed. If it has, then we copy it, just once, to another variable, my_mesh_visibility_effective, which is the variable coupled to the [visible] directive, and which OMSI doesn't control. Lastly, when the user clicks, we simply invert (boolean "NOT") the previous state of my_mesh_visibility_effective.

Regarding the latter half of your question: Yes, you can have arbitrarily complex relationships between .cti variables, as long as you follow the scheme presented above, i.e., a) assign initially invalid values everywhere, then b) wait for OMSI to process [setvar]s, by testing whether those initial invalid values have changed, then c) copy those variables to other variables, under your direct control, and lastly d) apply any post-processing to them instead, as often as needed (in the trivial example given above, "post-processing" simply means taking subsequent user input into account).

Zitat von PaulIP

Just to clarify my intentions:
I have 2 steering wheel types, which I want to switch between by clicking on them, but I also want to make them invisible just like in any other bus. The other instance is 2 cab wall types. Until a certain fleet number, type 1 was mounted. From that number onwards, type 2 was mounted, but also the older ones had their type 1 replaced with type 2. I want to make the up-to-X number buses with the 2 types of walls changeable by clicking on them. Since this was the only difference, I wouldn't want to make 2 different .bus and model.cfg files.

I see. The template given above suffices for simple boolean ("yes-no", "true/false", "one-or-the-other") cases of configuration. So that would address the second case, where there are only two possible states, i.e., either wall type 1 visible, or wall type 2 visible. In the model.cfg that would look as follows (trigger and "effective" config variable renamed):

For the purpose of switching between steering wheels, on the other hand, three states are needed: { wheel type 1 visible, wheel type 2 visible, none visible ("hidden") }. That requires slightly different code to support (only trigger changed; whole sample attached, with renamed variables, for clarity's sake):

So, in summary, you need:

• The same variable coupled to the [visible] constraint of all alternative [mesh]es, with a distinct constraint value for each.
• The same [mouseevent] coupled to all alternative [mesh]es.
• A trigger that handles the [mouseevent] by cycling the [visible]-coupled variable through all permissible states.

Edit: No, better disregard what I wrote about the shared [mouseevent]. Since you would also want it to work in the case where the steering wheel is hidden (steering_wheel_type_effective = 2), you would be better off attaching it to a separate object that is always visible (e.g. the steering wheel base), so as to allow the user to "recover" from the hidden state.