Posts by PaulIP

The forum is in reduced operation. The Addon and Support forums remain open.
Please note that OMSI is no longer under development. Some of the developers are now working on a new simulator. Further information concerning the LOTUS-Simulator can be found here.

    How can I "center" the line number on a vollmatrix, such that it mimicks the behaviour of an Annax matrix?

    Also, is there a way to display an abbreviated destination and the line number on the same side matrix box (unlike some other buses that have separate boxes for the line number and the destination on the right-hand side.

    And door-related: this one's a bit tricky: when I press the stop request button, I have to manually open said door once the station brake is active (which does well for me). I also want some external door buttons for passengers to use, such that when they are pressed, the doors will open automatically once the station brake is activated. These external buttons have a switch on the dashboard that (de)activates them (i.e. when it's off, the buttons won't work at all, so the entire [withbutton] thing in thr script is rendered useless). Regarding this on/off switch, I was thinking to assign a [visible] command to it, so the "off" position will "replace" the functioning buttons with a set of identical but static ones. Is it a good idea, or the passengers will still "recognize" the buttons? As of the automatic door opening caused by these buttons, I have no idea how to script it.

    I made some good progress with my project, but I encountered an issue that bothers the hell out of me...

    So I was fiddling with the heating scripts to make this process closer to reality (different from SD/NL buses). Apparently, everything goes well, I can load the bus and drive it almost as usual. I say "almost" because all the switches (kippschalter), handbrake, horn, brake pedal and the column levers are mute. I open up the logfile and there is a surprise in it for me:

    1. 313 11:57:16 PM - - Error: ''cabinheater_RPM'' ist kein gültiger Integer-Wert: CV.Calculate - I (vehicles\Rocar De Simon\U412-260.bus)
    2. 314 11:57:16 PM - - Information: Menu pos set
    3. 315 11:57:17 PM - - Error: Zugriffsverletzung bei Adresse 007F02C1 in Modul 'Omsi.exe'. Lesen von Adresse 00000004: CMO.UserVehSetSounds
    4. (...)

    ... and so on until I delete the bus or close the game.

    Now, this cabinheater_RPM doesn't appear in any scripts or constfiles (it does appear in cockpit_varlist, but this shouldn't affect anything), but it used to appear in cockpit.osc and heizung.osc, so I tried removing it from all possible instances (although some other buses, including the one whose heating script I used for mine, keep this line and don't have any issue).

    If needed, I will attach some extracts from the relevant script entries.

    Due to the major recent changes regarding this forum's policy, I shall not keep this thread updated until amends are made in the proper way. Those of you interested in my project can keep up with news on my Facebook Page or the dedicated topic on the WebDisk.

    I therefore ask a moderator to close this thread.

    Thank you!

    Unorthodox Paradox: many thanks!

    Florito: as I fiddled with the scripts, I noticed that, for the needle angle kept constant, there is an inverse proportionality between the rpm value written in the cockpit.osc and the actual value shown on the dial. Nothing to scoffle at, but I want to emphasize this for fellows who might find this thread useful.

    I just realised I forgot to update the progress I've made at the bus :D

    A part of the dials and checklights are finished, and also some small details from the cab.

    Thanks! Now it's not weird anymore.

    I see that in this line:

    1. (L.L.engine_n) 2700 130 / * (S.L.cockpit_drehzahlwinkel)

    you put an asterisk instead of a slash. Wouldn't one be the opposite operation of the other?

    Thank you! For some so-called speculations, they do have logic.

    My engine and antrieb scripts and constfiles are the same as the M&R NL202 ones. As of the cockpit.osc, it started off as a basic NL202 script as well, but I made various modifications according to my bus' real-life specifications. I attach some extracts from it: I do with the constfile. It's a bit weird that, in the constfile, the rev counter is named "tacholinie", whereas in the .osc, "tachowinkel" is the name of the speedometer needle. I got tricked a few times in the beginning.

    I forgot something: can I make a [light_enh_2] source visible by a script? To be more precise, in real life, some examples of the same bus model had a type of position light, while other ones had a different type. It all depends on the fleet number of said bus.

    A bit late to the party, but you might want to check up old Ikarus buses (the 2xx series, namely). These had stop request lights on each individual door (including the first). However, this bus family has a rather unique feature (much alike a "signature" in real life), such that the doors open from one set of buttons and close from a different set of ones. This, however, shouldn't get in your way.

    Then there is also fuljo's Autodromo Busotto. It has a [setvar] command that allows each of the back doors to have its own stop request light (it isn't on the dashboard, but above those doors). I suggest you study the scripts in detail.

    Not to pollute my other question topic, I decided to ask some script-related questions here.

    I have a rev counter (I believe it is called "drehzahlwinkel" in German) whose needle I want to go up to 2300-2400 rot/min. However, when I rev the engine at maximum, it only goes to ~1600 rot/min. Now, I know (sort of...) about the cockpit_constfile and the [newcurve] entries, but in the case of rev counters, these seem counter-intuitive (no pun intended :) ). Instead of some function relating the rpm-s and the needle angle with respect to rest position, I have some pairs that I don't grasp the meaning of (they don't look either like rpm values or needle angle).

    Another issue is the fuel level gauge. There is no entry for it in the constfile, and I want to reduce the area "swept" by the needle (this gauge is different from the usual ones found in OMSI buses, and the ticks for "full", "half-empty" and "empty" levels are a bit closer to each other).

    Also, I would appreciate if anyone lets me know what "maxspeed" and "delay" tags in animations mean.

    Thank you for the prompt and detailed answer!

    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.

    One more question for now: what are the steps to make and export a vollmatrix mesh in blender? I know I have to make 2 meshes (one for the "voll" texture and one for the "leer" texture), but how do I export them and make them work in the model.cfg? I seem to get a fatal error even when I borrow the EN92 scripts and whatever is written in its cfg file.

    Thanks! Worked just fine.

    Another thing now: is it possible to assign more than one [visible] command to the same O3D? One command should be changed by [setvar] in the .cti file, and the other one via clicking.

    The same goes for two [setvar] induced commands, i.e. the second one can be activated only if the first one has a certain value.

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

    Also, do you recommend to "smooth-shade" passenger room meshes or to "flat-shade them"? An even better question would be if you recommend the "edge split" modifier in blender (allows selective smooth-shading under a threshold angle in just 1 click, but it doubles the vertices on the shaded areas).

    So far I've tried to be as accurate as possible, but due to the lack of photos and information regarding the early-production models, I only rely on my (pretty spot-on but not always enough) intuition and whatever details I gather from people who knew their way around these machines.

    Thanks for the tip! I gave it a try, but it didn't appear to be satisfactory. Mainly because the reflexion is "static", not in real time. The mirror option is out of question, because my model is already pretty high-poly (but my decently-equipped PC doesn't nag more with this bus than it usually does when running OMSI).

    Meanwhile I tried adding an matl_envmap tag to the separated roof, first with a magnitude of 0.05, then 0.1, but it didn't make much difference (the outer body has 0.1 and its effect is pretty strong). Does OMSI recognise "inside" objects (like roof panels) from "outer" ones (like the body)?

    As a last resort, I'll leave it as it is, without shininess.