Beiträge von Road-hog123

Four of the keywords you've listed are most definitely used:

[texchanges] is used in the default buses that have rollblinds - it's used for the number blinds that are made up of a series of textures that are changed by a float variable.

[detail_factor] is used in a number of default sceneryobjects - it multiplies the object's screen height to change how far away the object is visible from.

[texcoordtransX] isn't used in any default content, but [texcoordtransY] is. They translate UV coordinates in the U and V axes respectively.

[particle_emitter] is used in the default fireworks cubes for the fireworks particles.

These two I've not seen before, but are present in default content. Whether they actually do something is not guaranteed.

[noDistanceCheck] is used in the default B727 plane and Mi8MT helicopter, presumably to keep them visible from further away.

[matl_zBias] is present in one default sceneryobject, but commented out. Looks like it might adjust the relative position in the render order, if it's still implemented.

The other keywords are not used in any default content, so whether they are implemented or not is unknown. I would also add that [dir] and [friendlyname_inv] are both present in default OMSI 2 content, but I can't seem to find any function to them.

Aha, panic over... such an important resource to many map creators has not just simply vanished.

I notice seeadler that you have a repository on GitHub for the tool with a license allowing modification and such, but the actual code you're using hasn't been pushed to it. Are there any plans to do this? Might be useful for others to re-host the tool if it does go permanently offline in the future?

Zitat von Lukas

Link for the download has been corrected.

Thanks for that. Hopefully the link will stay stable now that we've moved for a forum board software that's more stable and has support that don't break things more and give up claiming they can't fix what they broke themselves...

We (the community that tries to drive on the left) have tried very hard to find a fix for the AI problems, but they are a problem with the Omsi game engine itself. We've also tried to get word on whether this bug can be fixed, but the most we've got from Janine is

Zitat von Janine

Currently I can't say anything about it.

As for London, much of the development posts are made in this thread: Addon-London - Work in Progress
Rhys is working hard on the map to make improvements to the map to address many of the quality issues with the map. I understand the addon will come with the New Bus for London and both diesel and hybrid British-bodied Enviro 400s, but the Citaro is going to be released at a later date as it needs a lot of work done on it. A generic UK version of the Enviro 400 will be released for free too. The price for the addon should be £19.99 (€25.85), which is about the same as X10 and cheaper than Gladbeck. The UKDT team have been helping to give feedback and testing for Rhys to try and improve the quality of the addon where it is lacking, we've identified quite a lot of issues and passed them on Rhys and have also offered assistance to him to try and get a good product.

Here's the current route map:

I'll point Rhys to this thread so he can read the feedback written here himself.

Cotterell is the first map by the UKDT (UK Design Team). It is a semi-fictional left-path map based on the city of Bath, in south-west England. It consists of one line, running between the town centre and the University of Cotterell.
The map was mainly built to test the ability of those of us in the UKDT to work together before moving on to a bigger project. We reckon it's been a success, so look forward to more coming soon!
The map is self-contained, but you will need to install the required buses. Links are in the read-me, included in the download (the map is unlikely to work if you don't read it).
Download via Fellowsfilm Forums (registration is not required).

Picture and Video:

Routeres1994 video of the preview release of Cotterell

Copyright:
Do not upload the map to any other sites. It's fine where it is.

Feedback:
Feedback is appreciated, with normal rules of constructive criticism apply as with other maps.
We'd prefer if you left bug reports, etc., on the Fellowsfilm forum thread as that's where it's easiest for us to see them, although we'll endeavour to check back here to help with any issues.
None of us in the UKDT speak coherent German, so please leave your comments in English where possible.

Note: There is a bug with AI buses pulling up to stops weirdly. This is a bug with Omsi itself and as such only Marcel/Janine can fix it, it's not a bug with our map. We've reported the bug many times and nothing has been done about it so please direct complaints about it towards M+J and not us because we can't fix it.

Enjoy!

Hello!

There are a lot of new British left-path maps either being developed or recently released that are much improved in quality. However, all of these maps are affected by an issue with the core game handling of left-boarding bus stop cubes and particularly the way AI buses handle stopping at these bus stop cubes.
If a bus stop cube is aligned with a kerb as it would be on a right-path map, passengers queue properly but AI buses drive onto the pavement to align with the cube. When this is accounted for by moving the cube into the road, the AI will stop correctly, but passengers walk out partway into the road when the user approaches the stop. All AI buses also indicate right when pulling over to bus stops on the left. Although this is an improvement to the left-path handling in Omsi 1, these issues affect and detract from the experience in *all* left-path maps for Omsi 2. I'm aware that development is currently focused on the new LOTUS project, but I can't see that it would be too onerous for the code already implemented with right/left side cubes to be modified to correct the AI stopping position so that both passengers and AI can be correct. Buses indicating right can be ignored, but it still feels like it would be something that would be easy to fix.
Thank you for your consideration towards these issues.

It is entirely possible that the Editor, which can still occasionally be unstable, has corrupted one or more of the tile files themselves so it cannot read them. I would suggest replacing the problematic tiles with those from one of your backups that you may have made. If you haven't made any backups, then I will remind you of the importance of doing so.

If you have a lot of objects in your sceneryobjects directory, loading all of them may take Omsi above the 2GB RAM limit for 32-bit applications (4GB with patches) that Omsi is. If that is the case, Omsi should probably throw an error, but in this case is simply unloading or not being able to load the textures because it cannot use any more RAM. The problem won't occur in the game as you don't have at least one of every single object in your sceneryobjects folder placed at the same time, so it doesn't need to load them or their textures.

If you flip the face backwards, so the back side is facing away from the screen, you have an invisible click surface, that mimics a non-moving button very well, and is more resource friendly than a transparent texture.

You've posted in the English area...

To change to "buses always stop":
Go to the "Tracks and Trips" tab, select your route from the drop-down list and click "Edit Profile". Select your profile in the new window and set "Always" or "Always and Wait" for the bus stops where you have the problem.

Click for larger image

To set the passenger numbers:
Go to the "Objects" tab, select the red "Bus Stop Cube" and click "Options". Then, you can set the name, max and min passenger boarding numbers, passenger exiting number, exit side, docking distance (distance away from a stop a bus can open its doors I believe) and optionally the side and sub-name.

Click for larger image

Yes, you need to make the windows transparent.

You need the ticket printer scripts.

(ticketprinter.osc/ticketprinter_varlist.txt/ticketprinter_stringvarlist.txt/ticketprinter_constfile.txt)

Zitat von Marcel Kuhnt

I don't understand which physically variable you mean with "output". The rotation rate? And it depends on which gear box you mean.

I mean the information that the script sends to the Omsi physics engine, whatever that information may be, for it to calculate the wheel speed.

Hello J+M, a couple of queries:
1. What variable do I need to write to for the output of the gearbox? I've tried looking in the scripts but everything is in abbreviated German, which I can't understand...

2. I believe you mentioned during the development of Omsi 2 that you had made a font generator, is it planned to be released?
3. The official Omsi wiki talks about requiring a login, but I've never been able to figure out how to register. Is it possible to be registered there and write articles or is it now only for 'trusted' people?
And a little feature request, could you perhaps put a line break in just before the tile number/coordinates in the red text in the Editor? For people like me with small monitors, the text goes off the screen.

Danke!

The ANNAX refers to any of the maxtrixes. You could use the code that was developed earlier in this thread I believe to display two screens, and specify the same top line on each, so it wouldn't change.

The developers of Omsi use Blender version 2.49b, which is recommended, but Blender has a steep learning curve for beginners. Other newer versions of Blender can be used, however some problems have been experienced with the Direct X exporter which has reduced options in later versions. Other 3D modelling software can be used, however it is possible that you may get less support, or experience problems when converting file types to Omsi.
In terms of knowledge, before starting a bus you should become confident with using the 3D modelling software and try to produce sceneryobjects first before moving onto move complicated things. It would also help to become familiar (where possible) with the scripting language and the syntax of Omsi files, this will make getting your bus into the game easier.
When deciding to make a bus, it is important to choose one that has a lot of documentation, preferably blueprints or accurate drawings, plenty of pictures from many angles, and preferably access to the real bus so that you can experience how parts move, record sounds and get angles on parts that may not be in pictures.
Hope this helps.

An alternative could be to create a helper arrow with a "no entry" or similar texture and simply attach them to an invisible spline, or a spline buried under the terrain; or to attach them to each other with attach-points.

The Usti map used either a simple scripted delay to trigger the announcement a set time after leaving a stop, or the internal next stop updating to trigger the playing of the announcement, and then played it again when the doors opened at the stop... Scripting a trigger when nearing a stop is more difficult. The pedestrians moving to the stop when a bus approaches method most likely wouldn't work because humans and vehicles are entirely different things, meaning the scripts won't talk to each other, and even then there isn't an outputted variable set when the passenger moves to the stop anyway... The easiest method would be to set a long delay on playing the announcement, but that could present other problems when stops are different distances apart. This could possibly be combated by adding the ability to set a value for delay per bus stop in the HOF file. A more complicated solution could be to do some calculations to find out when to play the announcement, but I'd have no idea how to do that...

You could try changing the [matl_alpha] or [matl] values... that might fix it.