Posts by Chrizzly92

wouldn't help in your case anyway. hiding with an alphaplane wont work in your case because you cant define the active player bus as "more important" then an AI vehicle. both are rendered the same way.
you could however "simply" cut your meshes where needed and use the "visible" flag in the model.cfg of your vehicle. this way, you hide the meshes before they even get rendered which is a way cleaner approach.

Check your Changelog.txt in the Urbino_II folder. make sure its updated to Version 1.1.

Quote from IREgio612

A dynamic text isn't possible in OMSI.

thats not true. you can easily develop a scrolling text in OMSI. even a pixel-perfect one.

JCLeung215

I've checked your script and there are a few issues i found. Without checking the complete script, i can only evaluate the segment you posted. first of all, a value in OMSI isn't exactly zero or one at any time because OMSI is using floating point numbers. you should always use bigger > or smaller < operations instead of "=" while dealing with changing values, unless you put them in yourself. So you can do a 1 (S.L.YourVariable) and it will work just fine if you check the variable later with e.g. (L.L.YourVariable) 1 =. Everything thats a floating value like Timegap or your wheels roation or stuff like that will most likely never be zero or one. Also, try to rethink your script and check for logic errors. as an example, the following script wont work due to a few reasons:

(L.L.rtime) 0 >

(L.L.rtime) 2 < &&

{if}

(L.L.rtime) 0 =

(L.L.rlocation) 1000 >

{if}

0 (S.L.rlocation)

first of all, if you check if rtime is bigger than zero and smaller than two, the next statement (L.L.rtime) 0 = will never be true because this scriptpart is only calculated if rtime is bigger than zero. Also, you forgot an && or || behind (L.L.rlocation) 1000 >, so (L.L.rtime) 0 = is ignored.

after that it seems like you try to step over the text by one space 100 times; so the text will scroll once every frame. this will technically work just fine. however, there are a few issues. lets say you only have 20 frames per second, this code is only executed 20 times a second; so for your two second counter, you can only step over the text 40 times. to get this to work, you need to call the macro every frame and you also need to set Refresh_Strings to 1 every frame. besides that, you never set your rtime counter back to zero; so the script would only work once and the counter would count up to infinity if you haven't set this variable back to zero somewhere else in the script.

I've modified your code in a way that it should scroll permanently exactly 100 times, so it will add 100 spaces behind the text and then it will start from the beginning as long as its called every frame. It will take 100 frames to do so.

To make this work more realistic, a few more steps would be needed. first, check the font settings in your model.cfg. there are settings to automatically center the font and stuff like that, make sure your settings fit your needs. Also,you have to compensate for the framerate using a timegap, not only for the counter itself. lets say the string moves over by 10 characters a second, you cant simply say "yeah, from 0 to 1 second, step over 10 times"; you would need to get the current frametime and check how far it should move over every frame. on a fast computer with like 200fps on grundorf, the script would take only half a second to complete. on a slower machine with 100 fps, it would take a second. for 50 fps, it would take two seconds and for 10 fps it would take 10 seconds. so on a slow machine with only 10 fps, the steps to move over would need to be bigger and you would need to add more spaces every frame.
so, in theory, you can make this work without any issues if you fix some problems here and there.

HOWEVER:

You should never use a string modification for scrolling a text. this will result in massive lags and it may cause other issues like blinking or invisible text, especially while using scripttextures. A much better solution - at least from a performance point of view - is to just animate the textbox itself horizontally. you could cut it in different pieces and hide/unhide them using scripts or you can hide the textbox with a transparent face and a bit of cheating using the rendering order.

those arent lighting issues caused by OMSI - those are dirty meshes that cause those lighting artifacts. show us a non-textured model in blender.

if edges aren't properly aligned or the geometry has badly placed vertices, the shading will be wrong. lets say you have a raised edge on a flat panel and the angle between two faces is too mellow to be shaded as a "hard" edge, the lighting will "bleed" into other faces. you can set an edge as "mark sharp" in combination with an edge split modifier to fix those issues.

i have the same workflow and it works just fine. please upload your settings image into the webdisk so we can take a look.

i guess the material settings aren't properly exported and imported by the software you are using. after exporting to obj, use the "normal" way to convert back to the OMSI o3d format. get blender 2.79, activate the directX exporter in the blender settings and export the wheel to *.x then you download the official OMSI SDK Tools from here and convert the x back to o3d.

imho, converting o3d files isn't prohibited in any shape or form as long as the files aren't encrypted. i can easily convert a *.bmp file to *.jpg and back - so why shouldn't i be able to convert from o3d to obj and back?

a fix for that is already developed and implemented in other busses that use the same script. a patch for the solaris is already in development.

as a temporary fix, you can disable the drivers head movement in the settings - this way you wont see and feel that issue.

the scripts for my last projects were completely developed from scratch and are way faster to calculate (no air simulation as an example), thats why the issue only occurs on the urbino series. it will happen in other busses too - the MAN NL standard bus has the same issues but it will take an even lower framerate to get the same issue.

they shouldn't be visible in normal gameplay though. you should repair your omsi installation through steam.

set the transparency of the window areas to 0% or in other words to 100% visibility. everything else can stay at 0% visibility.

as an example, lets take a look on the standard DVB Repaint.

As you can see, there are stickers on the windows and the doors. to get them visible, the alpha-channel of the texture needs to be 100% visible in those areas. In photoshop, they are masked by white (100% visibility) or black (0% visibility).

the alpha channel for the texture should look like this:

using a different software, the black areas are completely transparent and the visible stuff will be shown. you have to create your repaints accordingly.

mirrors are rendered in a way that is optimized for performance. every mirror is basically a second image that needs to be rendered, now imagine that you have like 4 or 5 mirrors on a bus. if they get updated every frame, you would loose a lot of performance. so, every mirror that you place in a bus gets updated less and less. the left one will be updated like every second frame, the second one will only be updated every 4 frames, the third one every 6 frames and so on and so forth. so, the more mirrors you have, the more "laggy" they will appear because they wont update as fast anymore.

the man citybus series, as an example, has a few mirror configurations. even though only 3 are visible at the time, the long right mirror will appear more jerkily than the short one because the reflection is defined after the reflection of the short mirror so it gets handled differently. you wont notice that most of the time because the first mirror defined in the configuration of the bus is the left one, the second mirror is the right one and the third one is the interior mirror. even if the third one starts to lag, you wont notice it right away because the interior reflection doesn't change that much.

so, to sum this up, thats an intended behaviour for performance reasons.

you can force full rendering of the mirrors though. go to the settings , switch to the "graphics" tab and change the realtime reflections to "full".

also, go to the graphics(enhanced) tab (dont know how its called in english) and change the first two values to something like that:

this way, the mirrors will always be fully rendered, even if the performance is low. you do have to keep in mind though that every mirror can basically divide your framerate by two so you should expect a pretty bad performance.