OMSIWiki - User contributions [en]

Main Page

2014-10-17T18:56:25Z

Faaabiii:

<font style="font-size:1.2em;">
'''Welcome on the English version of OMSIWiki!'''

Here you can continue directly to one of the main categories:

* [[FAQs - Frequently Asked Questions]]
* [[:Category:Driving the Bus|Driving the Bus]]
* Developing Addons:
** [[:Category:Developing Reference|Reference]]
** [[:Category:Developing Tutorials|Tutorials]]
** [[:Category:Developing Tips and Tricks|Tips and Tricks]]
* [[:Category:Linked Projects|Linked Projects (e.g. Addon-Manager, OAT)]]
* [[:Category:Addon Presentations|Addon Presentations]]
* [[:Category:Background Information|Background Information]]

'''Attention: Before changing and creating articles, please read our rules first!''' You will find a very short wiki manual further down, too.

''In progress:''
</font>

* --[[User:Dario|Dario]] 10:19, 17 July 2012 (MEST) Translating some articles

== Idea ==

We (the developers of OMSI) have installed OMSIWiki for getting a better platform for every kind of information dealing with OMSI. At the moment, we plan to have the following topics:

* Presentation of background information about addon design by us (creating of objects and vehicles, sound engine, script engine and so on)
* Tipps and tricks or even entire tutorials written by users, e.g. about creating repaints or maps
* Using of OMSI and especially driving bus could be another topic. Of course there exists a manual, but perhaps there are some things which can be explained a little bit better by other users?
* Also presenting additional projects dealing with OMSI could be another function of this wiki; we think about OAT or the Addon-Manager.
* This wiki could also be the right place presenting high quality and complex addons, e.g. manuals for addon buses or descriptions and schedules for addon maps. But we don't want tiny articles about repaints or something like that! For this you can better use our forum.
* Of course you can also present background information about our maps/buses or addon maps/buses (e.g. stories about the real bus service of Berlin in 1989). But it should be a serious article really dealing with OMSI! Don't write unnecessary tiny articles don't dealing with any addon of OMSI!

== Rules ==

=== Does my new article fit into OMSIWiki? ===

Each article should fit in one of the categories on the top of this page!

=== "Golden Rule" ===

First of all the '''"golden rule"''': Before writing or changing an article, please check out if there are changes in our rules! Mainly in the time of commencement, there could be rule changes more often.

=== Do's ===

* If you find a tiny or big mistake, everybody is invited to correct it (even if it depends one of our articles)! But you should feel confident doing that!
* You think one of our articles is too abstract? Then just add a nice example! E.g. I know that I tend to write too "dusty" and abstract if I have to write long technical texts.
* You find a technical term which is not be explained? If you find it in Wikipedia, just place an external link. If it is an unexplained term of OMSI, you could add a small article about it.
* To avoid double writings while you have not finished your article, please add the line "''Note: This article is still in development!''". This can be also useful if someone likes to translate it.
* If your article has an equivalent in the German language section, please link them together! Otherwise, please add a note like "''Note: This article still has no German equivalent!''" or "''Note: The German equivalent still is not up to date!''".
* If you have fun translating articles, you are very welcome here! If you find one of these notes, feel free to translate the article! (German => English or the other way round!) But you should inform the author of the original article later that he gets the chance to read and check your translation. If you have translated something, please remove the notes and add the links!

=== Don't Do's ===

* '''Very important: Please think well about the title of a new article! It is not possible to correct it easily. If you add dowdy article titles careless, you will get the chop!
* bad style in writing! Ok, my English could be much better - but everyone writing here should take trouble writing good articles! Of course if you will find a mistake, you are invited removing it! ;)
* just advertising unknown, small projects, forums, virtual companies and so on. The idea behind OMSIWiki is not the advertising of projects but being an information platform!

=== Communication ===

* Before starting your work, add a brief description and your signature into the "in progress" section on top of this page.
* If you would like to do larger changes on one of our articles, it would be very kind to inform us and we can keep track of everything.
* Before starting a new article, it could not be bad informing us about your intention via e-mail!
* Don't create new categories without our agreement!

* Please mind the possibility to discuss on the discussion page! Typical source code you will find on Wikipedia discussion pages. And don't forget: the signature can be generated with <nowiki>--~~~~</nowiki>.

=== Multilinguality ===

OMSIWiki was installed in two languages: English and German. Like on the well-known Wikipedia, articles of both languages can be linked together. Of course it would be ideal if both parts of OMSIWiki are on the same state. Of course in practice, this aim cannot be achieved completely...

=== Access ===

In difference to Wikipedia, you have to have an account to make changes. But I don't think that we expect too much... we hope this could be a useful sanction keeping enough control about the wiki.

== Manual ==

Some hints for newbies who do not like to read the complete manual. How do I "build" an OMSIWiki article?

* Signature: Click on the button or write <nowiki>--~~~~</nowiki>.
* Create a new article: After let us know via e-mail or forum, type the well-considered name for the new article into the "search" field and click on "Go". Because this page does not exist, OMSIWiki will ask you if you would like to create a new article with this name. Just click on "yes" and get to the empty editor.
* A sensible structure can be created like this:
== Main Title ==
=== Sub Title ===
==== Sub Sub Title ==== and so on.
* Lists (like this one) can be created like this:
* Point
* Point
** Sub Point
* A # instead of a * will create a numbered list.
* Bold and italic:
<pre>
''Italic''
'''Bold'''
</pre>
* You can add your article to a category (e.g. ''Driving the Bus'') by adding <nowiki>[[Category:Driving the Bus]]</nowiki> at the bottom of your article.

Further information about creating wiki articles:

[http://meta.wikimedia.org/wiki/Help:Contents http://meta.wikimedia.org/wiki/Help:Contents]

== History ==

* Sept. 9th 2011 - Marcel Kuhnt: Creating of the English Main Page of OMSIWiki
* Sept. 13th 2011 - Marcel Kuhnt: OMSIWiki is now public

== Links ==

* [http://www.omnibussimulator.de/english.htm www.omnibussimulator.de] - official website of OMSI]
* [http://omnibussimulator.forumieren.com omnibussimulator.forumieren.com] - official OMSI forum

== Other ==

[[Technical Information about MediaWiki]]

[[de:Hauptseite]]

Guide to Performance-Friendly Vehicle Construction

2014-10-17T18:51:33Z

Faaabiii: Created page with "''This article is originally written by Marcel Kuhnt. So'' I ''refers to him.'' As the name suggests, this guide is to provide opportunities and food for thought to make OMSI-ve..."

''This article is originally written by Marcel Kuhnt. So'' I ''refers to him.''

As the name suggests, this guide is to provide opportunities and food for thought to make OMSI-vehicles as performance-friendly as possible.

A OMSI vehicle consists of 3D-models, textures, sounds and scripts - and in all four areas you should pay attention more or less intense on an optimization in terms of performance!

But one thing always applies: '''Even if you no longer have to be stingy as in the past: You should waste by no means!''' So for each part that you model, for each sound and for each texture you should have in mind what is both useful and necessary, or what may be more than you need. That this is a matter of taste, of course, goes without saying.

== 3D-Models ==

=== Theory ===

First we must define the term 'drawcall':

While the bus is drawn (as everything else) of single triangles, the triangles are combined to meshes with the same material properties, textures, and so on. Such a combined drawing process is called 'drawcall'. Internally, this is first prepared by OMSI, then all the parameters are passed to the graphics card and finally the graphics card processes "independently" the drawcall with all its triangles.

This connection also explains why one drawcall with 100,000 vertices is processed considerably faster than 1000 Drawcalls with each 100 vertices.

=== Not too many o3d-files and not too many individual textures ===

Each o3d-file causes at least one drawcall per texture that uses the o3d-file. Each o3d file causes at least one Drawcall per texture that uses the o3d-file. In certain cases - and in particular at x-files - it may even be multiple drawcalls per texture and o3d file.

This results in the following rules:

'''Use a minimal number of o3d-files per bus.'''

Inevitable is a separation for animations and often for transparent things where the rendering order is set on the separation. There is no way out of that.

However, it is easily possible to put the vehicle together out of very few non-animated o3d files, e.g. (order = rendering order):

# Interior mesh including driver's workplace without indicator lights, switches, etc.
# Transparencies in the interior
# Exterior mesh
# window panes from the inside
# window panes from the outside

'''Within an o3d-file as little different textures as possible.'''

With the explanation above probably easy to understand: If my entire exterior mesh has only one texture, then it is only one drawcall. This is better than my exterior mesh using two textures, so that it must be rendered in two drawcalls.
If a component is always getting animated anyway (typical example: wheels), then it is less tragic if the texture is separate. However, the [[LOD]]s should also be considered: Since our cars do not have animated wheels at a greater distance, we have integrated their texture into the main texture, too.

=== Use of reduced display for distance and AI vehicles ===

By using LODs, a vehicle can be drawn simpler at greater distance. It should also be simplified when not in use by the user.

'''Every vehicle should have at least two LOD-levels, so it is simplified a lot below about 10% of the screen size.'''

[[Image:2012 0716 05 Performance.jpg|600px|link=http://www.omnibussimulator.de/omsiwiki.de/images/3/34/2012_0716_05_Performance.jpg|thumb|right|The very simple LOD mesh of the SD77 for greater distance. Although rather simple, it is sufficient for greater distance and fairly economical. Only downside: Because of the repaint-possibilities the big 1024-texture for the exterior mesh must be loaded all the same, but apart from the reflexion texture that is all!]]
In this scale one can already do without the interior, the exterior should only be a very simple mesh anymore (20-50 vertecies). We also renounced on night textures and light effects in this distance entirely. One must only see that "there is a bus driving".

'''All vehicles should be greatly simplified for AI.''' (The same applies to "abandoned" user vehicles. All flags, such as the following, which relate to this nomenclature, classify abandoned user vehicles as AI vehicles.)

This purpose serves the viewpoint command. The number underneath can take following values:

* 0 = always visible
* 1 = only visible from outside on the current user vehicle
* 2 = only visible from inside on the current user vehicle
* 3 = 1 + 2, visible from inside and outside on the current user vehicle
* 4 = only visible on AI vehicles
* 5 = 4 + 1, visible on AI vehicles or only from outside on the current user vehicle
* 6 = 2 + 4, visible on AI vehicles or only from inside on the current user vehicle
* 7 = 1 + 2 + 4, always visible (same as 0)

Note: You only look at an AI vehicle from outside and usually not so accurately. However it can be close by and you often look into it from behind (at traffic lights or at a bus stop).

* AI vehicles should therefore have the complete and detailed exterior mesh and rough things of the interior mesh like panelling, seats etc. Those things that you see from behind are particularly important.
* AI vehicles do not need an animated cockpit (animated seat, steering wheel) and handrails can be greatly simplified. Theoretically this also goes for your ''own'' bus from outside but you do not need to be so saving here because your own bus is visible only once - AI vehicles on the other hand often in large numbers.
* Drawcalls provide a high potential again: Typically with all optimization there will be more than one textur for the interior but only one for the exterior mesh. So it makes sense to save as many textures of the interior as possible. The static dashboard, the steering wheel, the remaining handrails etc. often use seperate textures and should be mapped on a small area of a still necessary texture in the AI-mesh, e.g. a simple dark-grey, slightly "roughened" surface. But be careful: This is only useful if one or more complete textures can be saved.

==== The AI model of the SD77 as an example ====

The AI interior mesh of the SD77 only needs the textures SD77_02.bmp, _03.bmp and _04.bmp. The textures of the driver seat, panel, thermometer and cashdesk are saved compared with the user interior:

[http://www.omnibussimulator.de/omsiwiki.de/images/2/2b/2012_0716_03_Performance.jpg Picture]

Differences between AI and user mesh of the SD77. In the view from behind those slight differences can be spotted, which especially mesh simplifications with larger poly-reduction potential have: handrails, stop-request buttons, handles on the seats. Important details like seats, stringers or lamps must remain:

[http://www.omnibussimulator.de/omsiwiki.de/images/5/5d/2012_0716_04_Performance.jpg Picture]

=== Do not use too many vertecies - textures can provide reasonable assistance ===

Once upon a time™, when we began to build models for Flight Simulator, we had to draw the mesh by hand on graph paper and measure out and convert the coordinates ourselves. Then we sat down in front of the punch-card punching machine and we had better not make a mistake... okay, enough of those antiquated tales of former times™! :-D (Although the beginning is correct, the design programs for Flight Simulator only really got going with the versions 2000/2002 with FSDS and Gmax...)

What you can learn from this story: Simply out of selfishness one was frugal with polys and vertices. You keep this attitude - while today we look at the freeware-NL202 and admire the 3D-lion and the 3D-letters - and are just as amazed that OMSI tolerates this...

Of course, the NL202 is a successful and naturally very popular OMSI addon. Nevertheless, I am being cheeky and put it next to our NG272 (WIP at that time):

[http://www.omnibussimulator.de/omsiwiki.de/images/5/5d/2012_0716_04_Performance.jpg Picture]

What do you notice? The NL202 has much more polygons than the NG272. Of course, certain things can only be represented with appropriately detailed modelling, e.g. the oblique position of the air vents or the profile of the rubber bars of the windows. But when building a vehicle one must constantly wonder: Do I really need that? Is the effort and the higher polygon count worth it? Certainly it looks very nice but how often are you back at the engine compartment?

If you look at it from far away, a photo real texture is generally sufficient. Of course, in return our air vents do not shine so prettily in the sun! :)

=== Only put verticies in places where they make sense ===

Another example on vertex saving:

[http://www.omnibussimulator.de/omsiwiki.de/images/1/16/2012_0716_07_Performance.jpg Picture]

Of course, the pipe in the middle is the nicest! :) But it also has most polygons. Now, the question is - how exactly do you save polygons and how much optical loss does it take?

In this case, polys can either be saved longitudinally or circumferentially. What is better? If you would like to maintain about the same numbers of vertecies and faces, then the pipes look as shown. The left pipe is no longer broken in longitudinal direction, but the scope still has 32 edges. The right pipe on the other hand has only 8 edges, but all seven breaks (also corresponds to 32 corners along the full circle!) could be maintained which is obviously the better solution since you only notice the cross-section where the profile ends (e.g. exhaust) or where it encounters a different-coloured surface respectively takes on a different coulour itself while you often look directly at the longitudinal direction, as you do in this example.

Handrails, which are often lively designed in today's buses, typically resemble this: There the swing should also be sufficiently round - in return the profile can be a bit edgier (octagon or even hexagon).

So in order to get back to the beginning: In 1995 the FlightShop-Jumbo for Flight Simulator 95 had an octagonal (!!!) fuselage profile! You schoul always consider this when constructing a handrail profile with 32 edges! :D

== Textures ==

An important aspect has already been mentioned:

=== Few big textures are generally better than many small ones ===

... especially when they are applied together on one o3d file. Obviously there are limits: On one hand textures become a bit unhandy at a certain resolution. That is why we usually only go up to 1024x1024, although this limit is certainly not quite up to date.

=== Use regular resolutions! ===

Once every object builder for Flight Simulator knew what is no more common knowledge today: Textures should have pixel dimensions that follow the power-of-two row:

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, (2048, 4096, ...)

The values in parentheses are beyond what we usually use and frankly I do not know what restrictions there may be even today. But up to 1024 is no problem.

Rectangles are also ok, as long as the series above is maintained. Earlier in Flight Simulator, 256x256 was the ultimate standard for all textures, thus "old stagers" often use this measure today still. But 1024x128 is also ok, as is 512x512 or 4x128. You should only avoid crooked measures (200x300 or 256x77) because the processing tends to get worse. To what extent this is still the case on current graphics cards, I do not know - but in order to achieve compatibility to older graphics cards it cannot hurt to stick to the rule.

Such "crooked" cases are rounded to the next "allowed" measure, anyway. So you can round up by yourself right away and use the remaining areas sensible instead of letting them expire.

=== File formats ===

DirectX loads quite a lot formats. The traditional format is bitmap (*.bmp). Since this format is not compressed, some are inclined to use JPG.

Wether the loading time gets faster or slower, I cannot say and that certainly also depends on the look of the texture and a variety of other factors. But it should be clear to you that (as far as I know) it does not help to save graphics memory because JPEG-formats cannot be applied in the graphics memory.

So if you want to save graphics memory, you should rather take the DDS-format which offers a compression that - if I am correctly informed - also carries over to the graphics memory.

== Sound ==

When it comes to sound you cannot do much wrong, actually. Basically OMSI is quite frugal there and designed so that vehicles can have maaaany sounds in order to make a whole lot of fun and normally slightly longer samples of 48kHz should be no issue.

However OMSI has for reasons of performance a sound counter and a sorting function which ensure that a certain maximum number of sounds is not exceeded. This affects not only currently audible sounds but also "theoretically audible" sounds, which must be constantly checked whether they need to be heard soon. So that no free "sound spaces" are unnecessarily wasted, there is the possibility that AI-vehicles (and abandoned user-vehicles) are equipped with a simpler sound set.

This is quite simple to realize:

1. First you create the normal sound.cfg as usual and finish it completely.

2. Now you copy and rename it, e.g. to sound_AI.cfg.

3. Now you delete all sound entries in this file that are unnecessary for vehicles which are not controlled by the user - these are:
:* starter and switch off sound
:* sound effects that are primarily audible from within, e.g. the air compressor or the rattling in stand in the SD
:* cockpit or similar system sounds like switches, warnings, IBIS, rollsigns, wipers, etc. pp.
:* But we have kept the sounds of engine and gearbox, which are audible from outside, and of retarder, doors, auxiliary heating and brake squeal as well.

4. Last but not least you have to add the following entry to the *.bus/*.ovh-file: [sound_ai] | sound\sound_AI.cfg, so that OMSI knows that there is an AI-soundset.

You will quickly find out how much you can save here and how many more vehicles will then still "sound" nearby as opposed to previously.

== Script ==

=== Generally ===

Similar to the sound, it is possible to run a simplified script. How this is done is described in the article [[Scripting System]].

However, in order to be able to take over a vehicle at all times, all normal variables are always keep ready. But this is usually not a major problem.

Apart from that OMSI is also frugal in terms of the script respectively there is no big optimization potential. In general one can give script developers this to take along: as little as possible as much as is necessary. You need not be stingy and you should not waste. When you can decide between two variants, you should try to take the one with better performance.

Incidentally, if repeatedly used script sequences are outsourced in a shared macro, you save loading time and memory. Probably only microscopically little, but all the same! ;-)

=== Special performance problems ===

However, what you should be aware of, are possible bottlenecks. The script itself is relatively uncritical. But system macros need occasionally some processing by OMSI, e.g. when some .hof-file is searched. So it makes sense to be sparing with system macros.

In addition, the variable '''Refresh Strings''' allows a specific updating of OMSI-fonts on the vehicle (or sceneryobject): This should only happen when something actually changed. On your own vehicle this is not so critical but AI-vehicles should only refresh their strings when something actually changes - e.g. the matrix display.

[[Category:Developing Reference]]
[[de:Leitfaden performancefreundlicher Fahrzeugbau]]

File:2012 0716 05 Performance.jpg

2014-10-17T18:29:38Z

Faaabiii:

Main Page

2014-05-16T14:24:17Z

Faaabiii:

<font style="font-size:1.2em;">
'''Welcome on the English version of OMSIWiki!'''

Here you can continue directly to one of the main categories:

* [[FAQs - Frequently Asked Questions]]
* [[:Category:Driving the Bus|Driving the Bus]]
* Developing Addons:
** [[:Category:Developing Reference|Reference]]
** [[:Category:Developing Tutorials|Tutorials]]
** [[:Category:Developing Tips and Tricks|Tips and Tricks]]
* [[:Category:Linked Projects|Linked Projects (e.g. Addon-Manager, OAT)]]
* [[:Category:Addon Presentations|Addon Presentations]]
* [[:Category:Background Information|Background Information]]

'''Attention: Before changing and creating articles, please read our rules first!''' You will find a very short wiki manual further down, too.

''In progress:''
</font>

* --[[User:Dario|Dario]] 10:19, 17 July 2012 (MEST) Translating some articles
* --[[User:Faaabiii|Faaabiii]] 16:24, 16 May 2014 (MEST) Translating "Guide Performance-friendly Vehicle Construction"

== Idea ==

We (the developers of OMSI) have installed OMSIWiki for getting a better platform for every kind of information dealing with OMSI. At the moment, we plan to have the following topics:

* Presentation of background information about addon design by us (creating of objects and vehicles, sound engine, script engine and so on)
* Tipps and tricks or even entire tutorials written by users, e.g. about creating repaints or maps
* Using of OMSI and especially driving bus could be another topic. Of course there exists a manual, but perhaps there are some things which can be explained a little bit better by other users?
* Also presenting additional projects dealing with OMSI could be another function of this wiki; we think about OAT or the Addon-Manager.
* This wiki could also be the right place presenting high quality and complex addons, e.g. manuals for addon buses or descriptions and schedules for addon maps. But we don't want tiny articles about repaints or something like that! For this you can better use our forum.
* Of course you can also present background information about our maps/buses or addon maps/buses (e.g. stories about the real bus service of Berlin in 1989). But it should be a serious article really dealing with OMSI! Don't write unnecessary tiny articles don't dealing with any addon of OMSI!

== Rules ==

=== Does my new article fit into OMSIWiki? ===

Each article should fit in one of the categories on the top of this page!

=== "Golden Rule" ===

First of all the '''"golden rule"''': Before writing or changing an article, please check out if there are changes in our rules! Mainly in the time of commencement, there could be rule changes more often.

=== Do's ===

* If you find a tiny or big mistake, everybody is invited to correct it (even if it depends one of our articles)! But you should feel confident doing that!
* You think one of our articles is too abstract? Then just add a nice example! E.g. I know that I tend to write too "dusty" and abstract if I have to write long technical texts.
* You find a technical term which is not be explained? If you find it in Wikipedia, just place an external link. If it is an unexplained term of OMSI, you could add a small article about it.
* To avoid double writings while you have not finished your article, please add the line "''Note: This article is still in development!''". This can be also useful if someone likes to translate it.
* If your article has an equivalent in the German language section, please link them together! Otherwise, please add a note like "''Note: This article still has no German equivalent!''" or "''Note: The German equivalent still is not up to date!''".
* If you have fun translating articles, you are very welcome here! If you find one of these notes, feel free to translate the article! (German => English or the other way round!) But you should inform the author of the original article later that he gets the chance to read and check your translation. If you have translated something, please remove the notes and add the links!

=== Don't Do's ===

* '''Very important: Please think well about the title of a new article! It is not possible to correct it easily. If you add dowdy article titles careless, you will get the chop!
* bad style in writing! Ok, my English could be much better - but everyone writing here should take trouble writing good articles! Of course if you will find a mistake, you are invited removing it! ;)
* just advertising unknown, small projects, forums, virtual companies and so on. The idea behind OMSIWiki is not the advertising of projects but being an information platform!

=== Communication ===

* Before starting your work, add a brief description and your signature into the "in progress" section on top of this page.
* If you would like to do larger changes on one of our articles, it would be very kind to inform us and we can keep track of everything.
* Before starting a new article, it could not be bad informing us about your intention via e-mail!
* Don't create new categories without our agreement!

* Please mind the possibility to discuss on the discussion page! Typical source code you will find on Wikipedia discussion pages. And don't forget: the signature can be generated with <nowiki>--~~~~</nowiki>.

=== Multilinguality ===

OMSIWiki was installed in two languages: English and German. Like on the well-known Wikipedia, articles of both languages can be linked together. Of course it would be ideal if both parts of OMSIWiki are on the same state. Of course in practice, this aim cannot be achieved completely...

=== Access ===

In difference to Wikipedia, you have to have an account to make changes. But I don't think that we expect too much... we hope this could be a useful sanction keeping enough control about the wiki.

== Manual ==

Some hints for newbies who do not like to read the complete manual. How do I "build" an OMSIWiki article?

* Signature: Click on the button or write <nowiki>--~~~~</nowiki>.
* Create a new article: After let us know via e-mail or forum, type the well-considered name for the new article into the "search" field and click on "Go". Because this page does not exist, OMSIWiki will ask you if you would like to create a new article with this name. Just click on "yes" and get to the empty editor.
* A sensible structure can be created like this:
== Main Title ==
=== Sub Title ===
==== Sub Sub Title ==== and so on.
* Lists (like this one) can be created like this:
* Point
* Point
** Sub Point
* A # instead of a * will create a numbered list.
* Bold and italic:
<pre>
''Italic''
'''Bold'''
</pre>
* You can add your article to a category (e.g. ''Driving the Bus'') by adding <nowiki>[[Category:Driving the Bus]]</nowiki> at the bottom of your article.

Further information about creating wiki articles:

[http://meta.wikimedia.org/wiki/Help:Contents http://meta.wikimedia.org/wiki/Help:Contents]

== History ==

* Sept. 9th 2011 - Marcel Kuhnt: Creating of the English Main Page of OMSIWiki
* Sept. 13th 2011 - Marcel Kuhnt: OMSIWiki is now public

== Links ==

* [http://www.omnibussimulator.de/english.htm www.omnibussimulator.de] - official website of OMSI]
* [http://omnibussimulator.forumieren.com omnibussimulator.forumieren.com] - official OMSI forum

== Other ==

[[Technical Information about MediaWiki]]

[[de:Hauptseite]]

Bounding Box

2014-05-16T14:21:11Z

Faaabiii: Created page with "The bounding box is needed in the geometric data for the configuration of a vehicle. =Application= The bounding box is entered under "[boundingbox]" in the respective .bus-file..."

The bounding box is needed in the geometric data for the configuration of a vehicle.

=Application=

The bounding box is entered under "[boundingbox]" in the respective .bus-file or .ovh-file of a vehicle. It creates a cubical collision model around the vehicle which ensures that it can collide with the scenery and other objects.

=Definition=

The bounding box is made up as follows:

==Requirementsn==

*Width without outside mirrors in m of the vehicle to be simulated
*Length in m of the vehicle to be simulated
*Height in m of the vehicle to be simulated

==Procedure==

The bounding box is made of six values which are entered in one line each:

#Width
#Length
#Height
#Distance of the center of the bounding box from the origin of the local coordinate system on the width axis in m (x)
#Distance of the center of the bounding box from the origin of the local coordinate system on the length axis in m (y)
#Distance of the center of the bounding box from the origin of the local coordinate system on the height axis in m (z)

=Note!=

Many maps have at object transitions "invisible walls" where mainly low-lying vehicles get stuck. To avoid this, the height of affected vehicles can be reduced by one meter and the distance of the box to the origin on the z-axis can be increased by one meter.

[[Category:Developing Reference]]
[[de:Boundingbox]]

DISABLED-Command

2014-05-16T14:18:55Z

Faaabiii: Created page with "''OMSI 2 only!'' Some Configuration Files allow the commands "-<DISABLED>-" and "-<ENABLED>-". These commands can be used to comment multiple lines withou..."

''OMSI 2 only!''

Some [[Configuration File|Configuration Files]] allow the commands "-<DISABLED>-" and "-<ENABLED>-". These commands can be used to comment multiple lines without having to comment the relevant keywords individually.

It is simple to use:

<pre>
...
{valid lines}
...
-<DISABLED>-
...
{commented lines}
...
-<ENABLED>-
...
{valid lines}
...
</pre>

This command can be used in the following configuration files:

*.bus, *.ovh, *.sco, *.hum, model.cfg, envir.cfg, passengercabin.cfg, path.cfg

[[Category:Developing Reference]]
[[de:DISABLED-Befehl]]

Inverse of the Minimum Turning Radius

2014-05-16T14:16:47Z

Faaabiii: Created page with "The inverse of the minimum turning radius is needed in the basic physical data for the configuration of a vehicle. =Application= The inverse of the minimum turning radius is en..."

The inverse of the minimum turning radius is needed in the basic physical data for the configuration of a vehicle.

=Application=

The inverse of the minimum turning radius is entered under "[inv_min_turnradius]" in the respective .bus or .ovh-file of a vehicle.

=Calculation=

The inverse of the minimum turning radius is calculated as follows:

== Requirements==

*Wheelbase in m of the vehicle to be simulated
*Turning radius in m from the outer wheel to the outer wheel of the vehicle to be simulated
*Optional: Windows calculator in scientific view

==Procedure==

# (2 * wheelbase) / turning radius = sin(maximum turning angle of the wheels on the steering axis in °)
# tan(maximum turning angle of the wheels on the steering axis in °) / wheelbase

[[Category:Developing Reference]]
[[de:Kehrwert des minimalen Lenkradius]]

Vehicle Mass

2014-05-16T14:12:50Z

Faaabiii: Created page with "The mass of a vehicle is required for its correct simulation. OMSI always calculates the current weight by adding the kerb weight (specified in the basic physical data under [mas..."

The mass of a vehicle is required for its correct simulation. OMSI always calculates the current weight by adding the kerb weight (specified in the basic physical data under [mass]) to the mass of all passengers currently on board.

Therefore, if possible it is important to use the dry weight when entering a value for [mass], thus without tank capacity, luggage, passengers and of course the drivers themselves.

The mass of the vehicle is specified in t.

[[Category:Developing Reference]]
[[de:Fahrzeugmasse]]

Scripting System

2014-05-16T14:08:12Z

Faaabiii: Created page with "The scripting system in OMSI lets you equip sceneryobjects and in particular vehicles with individual systems, which communicate via variables and function calls with the main pr..."

The scripting system in OMSI lets you equip sceneryobjects and in particular vehicles with individual systems, which communicate via variables and function calls with the main program and the grafics engine respectively the sound engine.

== Files of the Scripting System ==

The scripting system contains the following files:

* scripting files with executable code (*.osc)
* varlist files and stringvarlist files in the OMSI\program directory for the definition of systemfiles and predefined files
* varlist files and stringvarlist files for the definition of uservariables
* constfile files for the definition of userconstants and function tables

Apart from the files for the definition of systemvariables all required files for each vehicle/sceneryobject (below short: object) must be registered in its [[Configuration File]].

For this purpose, there are the commands ''[script]'', ''[varnamelist]'', ''[stringvarnamelist]'' and ''[constfile]''. The first entry of each command is the number of files followed by the corresponding filenames (including the path relative to the configuration file). The names of the files are not relevant as long as they are correctly entered in the lists.

The function of the respective files will be discussed in the course of describing the scripting language.

== Basics of the Scripting Language ==

The OMSI scripting system works with the [http://en.wikipedia.org/wiki/Reverse_Polish_notation Reverse Polish notation]. That is, the operator stands behind the two operands; put simply it means, that the operation " 1 + 2 " is instead listed " 1 2 + ". A more complicated example: " (1 + 2) * (4 + 5) " matches " 1 2 + 4 5 + * ".

Note that OMSI textfiles and especially the scripting language is [http://en.wikipedia.org/wiki/Case_sensitivity case sensitive]! So always pay attention to uppercase and lowercase.

=== Stack and Register ===

When processing the scripts OMSI uses a [http://en.wikipedia.org/wiki/Stack_(abstract_data_type) stack] for [http://en.wikipedia.org/wiki/Floating_point floating-point numbers]. Below "stack" always refers to the stack for floating-point numbers. Otherwise it is spoken of the "string stack".

Both stacks contain 8 memory slots, which are numbered from 0 to 7. Every script operation can insert (push) one or multiple new values into one of the stacks, where the new value is set on position 0 and all of the following values "move up a place", or it can pull one or multiple values out of the stack (pop) or just read them (peek).

For the temporary drop of numbers there are additional eight memory slots, which can be written or read directly, in the so called "register" - however, there is only a register for the floating-point numbers.

=== Example Operations ===

Example: The operationn " 1 + 4 ". The code for this is:

<pre>
1 4 +
</pre>

The table below demonstrates how the stack behaves on this occasion:

<pre>
operation: stack: 0 1 2 3 4 ...
-----------------------------------------------------------------------------
before: 0 0 0 0 0
"1" 1 0 0 0 0
"4" 4 1 0 0 0
"+" 5 0 0 0 0
</pre>

In the initial state the stack is filled only with zeros (or unknown/random values). The command "1" pushes the One into the top stack space and pushes all the other values (zeros) back. The command "4" pushes the Four on the 0. place and all the other values, so in particular the One on the respective next place. In the next step "+" the top two values are pulled out of the stack - that is 4 and 1 - and summed up. The result (5) is in turn pushed into the stack. The two original numbers are no longer present in the stack.

A second example:

(1 + 2) * (4 + 5) must, as already mentioned, be listed as follows:

<pre>
1 2 + 4 5 + *
</pre>

So the stack behaves like this:

<pre>
operation: stack: 0 1 2 3 4 ...
-----------------------------------------------------------------------------
before: 0 0 0 0 0
"1" 1 0 0 0 0
"2" 2 1 0 0 0
"+" 3 0 0 0 0
"4" 4 3 0 0 0
"5" 5 4 3 0 0
"+" 9 3 0 0 0
"*" 27 0 0 0 0
</pre>

So in the end the correct result is on stack space 0!

=== Floating-point Numbers and Strings ===

The OMSI scripting system works exclusively with the datatypes float (simple precision with sign) and string. Both datatypes have seperated stacks. Therefore the processings of floats ad strings generally run independently side by side. However it can happen that certain functions (e.g. converting numbers to strings) access both parts at the same time.

Boolean variables have been omitted. In general the numerical values 0 and 1 are used for boolean values.

== Script Keywords ==

=== Comments ===

Comments can only be done by setting an apostrophe ['] at the front of the row to be commentated:

<pre>
'I am a comment line
'I am NOT a comment line!
</pre>

=== Entry Points and Exit Points, Macros and Trigger ===

All commands must be between an entry point and an exit point.

The entry point is characterized by one of the keywords listed below:

* {frame} During each frame OMSI calls through this entry point the framewise script processing, if it is available.
* {init} Bei der Initialisierung ruft OMSI über diesen Einstiegspunkt die Script-Initialisierung auf.
* {init} When initializing, OMSI calls through this entry point the script initialization
* {frame_ai} This is a variant of the {frame}-entry point, which is called with vehicles, when they are not in the focus of the user, e.g. when it is travelling as AI vehicle. If this entry point does not exist, but only {frame}, then the latter is called alternatively. With sceneryobjects this entry point is not considered.
* {macro:''name''} This entry point calls a subsection (macro), which must always be defined '''after the call'''
* {trigger:''name''} This entry point is called from the main program, when the user calls the key combination or the mouse event with the designation ''name'' - there are also certain trigger, which are called directly by the main program, e.g. when OMSI changes the display on AI busses

{end} is the universial exit point. It must always close the block, which is opend by one of the commands above.

==== Macro Call ====

A macro is called by (M.L.''name''). The macro must ''always'' be called before its definition. Otherwise OMSI will report that the macro could not be found.

==== Distributing the Script into Several Files ====

With simple scripts (e.g. for pure AI vehicles or sceneryobjects) it is generally sufficient to create a *.sco-file, which comes with a {frame}...{end}-block and possibly a {init}...{end}-block.

If it is, however, a complete vehicle script, then it is advisable to create separate files for the various subsystems. This case should be approached as follows:

* There is a main script and the necessary subsystem files. The main file contains the {frame}-blocks and {init}-blocks, which, however, only call macros defined in the subsystem files.
* There is a *.sco-file for each subsystem and as required an own varlist and consfile with the variables belonging to the system. Furthermore the triggers for the key commands are sorted here.
* It is sensible to name the macros {macro:''subsystem''_frame} and {macro:''subsystem''_init}.
* To ensure that a makro can be called by the main script, it must be called first in the list of the scripts in the object configuration file. The order of the scripts must also be chosen so that all cross-file macro calls are always before each macro definition.

The restriction that macros must always be defined after the call can indeed sometimes be a hindrance, but is a very effective protection against circular reasoning and infinite loops.

==== Trigger ====

As has been written, a {trigger:'' name''} ... {end}-section can be called by different ways from the main program. These include:

* Triggered via keyboard: Has the key combination been called ''keycombi'', is {trigger:keycombi} called, if the key is pressed and {trigger:keycombi_off} if the key is released.
* Triggered via mouse: Has a mesh with the [mouseevent]-designation ''mouse_ev'' been clicked on, {trigger:mouse_ev} is called if the mouse button is pressed, {trigger:mouse_ev_drag}, while the mouse button is held and {trigger:mouse_ev_off} id the mouse button is released.
* There is also a number of system triggers.

=== Operations ===

==== Stack Operations ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |%stackdump%
| align="left" |Gives out a dialog box with the floating-point stack content. Should therefore naturally be used only for debugging purposes.
|-
| align="left" |s0, s1, ..., s7
| align="left" |Saving the current stack value in the register indicated by the number. The value remains in the stack.
|-
| align="left" |l0, l1, ..., l7
| align="left" |Loading the corresponding register value and shifting it into the stack. The register value is retained.
|-
| align="left" |d
| align="left" |Dublicating the top stack value. All the other stack values are pushed back.
|-
| align="left" |$msg
| align="left" |Writing the top string stack value into the debug line of OMSI. Wether it is a AI vehicle, a user vehicle or a sceneryobject.
|-
| align="left" |$d
| align="left" |Dublicates the string stack value similar to "d".
|}

==== Logical Operations ====

The logical operations operate on the principle 0 = FALSE, everything else is TRUE.

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |&&
| align="left" |AND, that is, if one of the top two stack values is 0, the result is 0, otherwise it is 1
|-
| align="left" |<nowiki>||</nowiki>
| align="left" |OR
|-
| align="left" |<nowiki>!</nowiki>
| align="left" |Negation
|}

==== Rational Operations ====

Rational operators compare the values in the two top stack spaces and insert, depending on the result, 1 or 0 into the top stack space. The "greater than"/"less than" symbols are here according to the order, in which the values were specified before. That is:

4 2 > is true for the internal operation performed is in this case "4 > 2".

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |=
| align="left" |"1", if the top stack values are identical, else "0".
|-
| align="left" |<
| align="left" |"1", if stack value 1 is less than stack value 0, else "0".
|-
| align="left" |>
| align="left" |... is greater than ...
|-
| align="left" |<=
| align="left" |... is smaller than or equal to ...
|-
| align="left" |>=
| align="left" |... is greater than or equal to ...
|-
| align="left" |$=
| align="left" |The same as "=" only for the string stack
|-
| align="left" |$<
| align="left" |Less than (string). The inequality operations on strings check on alphabetical order. So "A" is less than "B".
|-
| align="left" |$>
| align="left" |Greater than (string).
|-
| align="left" |$<=
| align="left" |Smaller than or equal to (string).
|-
| align="left" |$>=
| align="left" |Greater than or equal to (string).
|}

==== Mathematical Operations ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |+
| align="left" |Plus
|-
| align="left" |-
| align="left" |Minus (stack space 1 - stack space 0, so in principle, as in the greater/less than operations)
|-
| align="left" |*
| align="left" |Multiplication
|-
| align="left" |/
| align="left" |Division (stack space 1 / stack space 0)
|-
| align="left" |%
| align="left" |Remainder of the division (extended as follows for floating-point numbers: stack0 - trunc(stack1 / stack0) * stack1 )
|-
| align="left" |/-/
| align="left" |Sign change
|-
| align="left" |sin
| align="left" |Sine
|-
| align="left" |arcsin
| align="left" |Inverse function of sine ''(OMSI2 only)''
|-
| align="left" |arctan
| align="left" |Inverse function of tangent ''(OMSI2 only)''
|-
| align="left" |min
| align="left" |Choosing the lesser of the two top stack values
|-
| align="left" |max
| align="left" |Choosing the greater of the two top stack values
|-
| align="left" |exp
| align="left" |Exponential function to the base e (e^Stack0)
|-
| align="left" |sqrt
| align="left" |Square root
|-
| align="left" |sqr
| align="left" |Square
|-
| align="left" |sgn
| align="left" |Return of the sign; either -1, 0 or 1
|-
| align="left" |pi
| align="left" |Circle constant pi
|-
| align="left" |random
| align="left" |random integer 0 <= x < stack0
|-
| align="left" |abs
| align="left" |Return the absolute value
|-
| align="left" |trunc
| align="left" |Rounding down to nearest integer
|}

==== String Operations ====

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |"''bla''"
| align="left" |Insert the string ''bla'' into the top string stack space
|-
| align="left" |$+
| align="left" |Join two strings. "Omnibus" "simulator" $+ results in "Omnibussimulator"
|-
| align="left" |$*
| align="left" |The top stack string is repeated until the resulting character length is just less than or equal to the top stack value is. Example: "nu" 6 $* results in "nununu"
|-
| align="left" |$length
| align="left" |Returns the number of characters in the top stack string back into the stack.
|-
| align="left" |$cutBegin
| align="left" |Cuts ''stack0'' characters from the front of the top stack string.
|-
| align="left" |$cutEnd
| align="left" |Cuts ''stack0'' characters from the back of the top stack string.
|-
| align="left" |$SetLengthR
| align="left" |Adjusts the length of the top stack string to ''stack0'' aligned to the right by removing leading characters or by adding spaces.
Attention: The command does not remove the float operator from the stack. I.e. the value, to which the lenght of the string is truncated, remains on stack0.
|-
| align="left" |$SetLengthC
| align="left" |Adjusts the length of the top stack string to ''stack0'' centred by removing leading and trailing characters or by adding spaces ''(OMSI2 only)''.
Attention: The command does not remove the float operator from the stack. I.e. the value, to which the lenght of the string is truncated, remains on stack0.
|-
| align="left" |$SetLengthL
| align="left" |Adjusts the length of the top stack string to ''stack0'' aligned to the left by removing trailing characters or by adding spaces.
Attention: The command does not remove the float operator from the stack. I.e. the value, to which the lenght of the string is truncated, remains on stack0.
|-
| align="left" |$IntToStr
| align="left" |Rounds down ''stack0'' and converts the resulting integer to a string.
|-
| align="left" |$IntToStrEnh
| align="left" |The enhanced version of IntToStr. Here, the top stack string is used to determine the format of the string conversion: The first character of the string is used to fill the missing characters. The following characters must result in a number, which indicates the digits. Example: 35 " 5" $IntToStrEnh results in " 35" and 123456789 "011" $ IntToStrEnh results in "00123456789". If an error occures, "ERROR" is output.
|-
| align="left" |$StrToFloat
| align="left" |Converts the top stack string to a floating-point number if possible. Otherwise, a -1 is written.
|-
| align="left" |$RemoveSpaces
| align="left" |Removes all spaces before and after the actual string. " Spandau Freudstr " becomes "Spandau Freudstr" ''(OMSI2 only)''.
|-
|}

=== Accessing Variables===

A distinction is made between system variables and local variables. The system variables apply OMSI-wide, the local variables are stored belonging to the vehicle/object.

For local variables, there are always a number of variables which are predefined by OMSI. In addition, any number of variables can be added using the varlist files. Furthermore there is the variant in OMSI 2 that, although one must define the variable by themselves, it will still be connected to an OMSI internal state ("on-demand pre-defined variables").

{| class="wikitable" style="font-size:95%;"
|- class="hintergrundfarbe5"
| align="left" |(L.S.''varname'')
| align="left" |Loads the system variable ''varname'' in the top stack space
|-
| align="left" |(L.L.''varname'')
| align="left" |Loads the local variable ''varname'' in the top stack space
|-
| align="left" |(L.$.''varname'')
| align="left" |Loads the local string variable ''varname'' in the top string stack space
|-
| align="left" |(S.L.''varname'')
| align="left" |Saves the top stack space into the local variable ''varname''
|-
| align="left" |(S.$.''varname'')
| align="left" |Saves the top string stack space into the local string variable ''varname''
|}

=== Constants und Functions ===

Local constants and [http://de.wikipedia.org/w/index.php?title=Datei:Linear_interpolation.svg&filetimestamp=20080226155013 piecewise defined linear functions] can be defined in the constants files (''constfiles'', ''~_constfile.txt''). The structure of each constants file is the same as the structure of the [[Configuration File|configuration files]]. There are only three keywords. Note that so far no strings but only floats can be defined as constants.

[const] defines a new constant and specifies its value:

<pre>
[const]
name
value
</pre>

Example:

<pre>
[const]
power
200
</pre>

[newcurve] initiates the definition of a new (piecewise linear) function:

<pre>
[newcurve]
name
</pre>

[pnt] adds a new x-y pair to the previously with newcurve defined function. Each function should normally have at least two pairs. The order of the pairs ''must'' be ascending in the x-direction!

<pre>
[pnt]
x
y
</pre>

Example:

<pre>
[newcurve]
speed_torque_curve

[pnt]
50
0

[pnt]
300
400

[pnt]
1000
600
</pre>

Constants are loaded into the stack on the command (C.L.''constant name'')

Functions are called on the command (F.L.''functionname''). At that the value previously stored on the top stack position is always passed as the x-parameter and the resulting y-value of the function is instead stored on the top stack space. Is the x-value outside the limits of the vertecies defined by the [pnt]-entries, the y-value of the nearest vertex is always used. Thus the function is extended horizontally to infinity before the first and after the last vertex.

=== Sound Trigger ===

Do not mix up the sound triggers with the above mentioned triggers!

They rather represent a way to directly play a desired sound. There are two options for doing this:

(T.L.''soundtriggername'') is a simple sound trigger. The so marked sound is played (once).

(T.F.''soundtriggername'') is a sound trigger with file change function. The top stack string is read and used as the file name, where the file path is interpreted as relative to the sound folder of the object.

Example:

Assuming the sound file is "this.wav" and is linked to the trigger ''My trigger'', then

(T.L.MyTrigger)

plays the file "this.wav" and

"other.wav" (T.F.MyTrigger)

plays the file "other.wav". As an alternative to (T.L.''soundtriggername'') can at the command (T.F.''soundtriggername'') also be a "null string" in the stack (i.e. "").

=== System Macros ===

The current methods allow the scripts following communication options with OMSI:

* Reading values of the system variables and pre-defined local variables
* Writing values on them
* Receiving keyboard, mouse, or system triggers

Finally, there is another way to communicate with the main program, the so-called system macros, sometimes imprecisely referred to as "callback functions".

In certain situations it is necessary that the script gets values from OMSI, which are present in larger databases and therefore can not be transmitted via predefined variables, e.g. the contents of the hof-file. This is where the system macros come in.

They work script-sided very much like the local, self-defined macros: The call (M.V.''macroname'') calls the system macro ("V" originally stood for "Vehicle-Macro", but applies equally well on scenery objects) which gets values from both stacks and/or writes into them during the execution.

=== Conditionals and Loops ===

The control of the program flow is so far only possible with the IF-condition.

==== IF-Condition ====

<pre>
'Here must be a condition, e.g:
(L.L.bla) 1 =
{if}
'This section is executed if bla = 1:
2 3 +
{else}
'Otherwise this section is executed:
3 4 +
{endif}
(S.L.blub)
{end}
</pre>

The fact that first the condition is formulated and then the keyword {if} follows, should be clear: First of all the value must be dropped on top of the stack and anly then the keyword {if}, which checks this value, follows. Here, similar to && and ||, equality with zero is equivalent to ''False'', all other values mean ''True''.

So if in the example above ''bla'' has the value 1, then ''blub'' is set to the value 5, else it is set to 7.

Nesting of IF-conditions is used as a substitute for the (nonexistent) "Else if"-constructions:

<pre>
'Here must be a condition, e.g:
(L.L.bla) 1 =
{if}
'This section is executed if bla = 1:
2 3 +
{else}
(L.L.bla) 5 =
{if}
'This section is executed if bla = 5:
3 4 +
{else}
'Otherwise this section is executed:
13
{endif}
{endif}
(S.L.blub)
{end}
</pre>

Pay particular to the double {end if}! Here the following applies:

* bla = 1 ==> blub = 5
* bla = 5 ==> blub = 7
* else ==> blub = 13

[[Category:Developing Reference]]
[[de:Scriptsystem]]