Terrible performance in Map Editor, enermous map size, Map Editor bug

  • A few weeks ago the Map editor worked just fine on my PC. But a few days ago when I started to build new parts of the map, the map editor just went crazy. It takes 2-3 minutes at least to even load the map, lags all the time, freezes and so on. I constantly get the red "low performance" text in the right upper corner, and watch this error message 50% of the time:

    Another issue is that when I open the properties of a subgrade, and OK it, the window doesn't close. It's just stuck there, and therefore I can't do anything in the editor...

    It's getting absolutely impossible to build anything. And as I said before, the editor worked fine until maybe the latest patch.

    My PC:

    intel i5-4460 3,6GHz 4 core processor, nVidia GTX960 GPU with 4GB VRAM, 8GB RAM

    According to MSI afterburner, my components are not even getting hot, so it's not like the PC wants to die. The memory is fully used, that's true (maybe I should buy another 8GB RAM to it), also the VRAM of the GPU is fully used (3,8 of the 4GB), I don't even know why. The memory usage of the editor is around 5-5,5GB.

    But the processor cores are not fully used, not a single one (maybe 20-30% of the CPU time is used in the LOTUS).

    Another issue occuring is the size of the map. My map is not that big, it's 8km of suburban railway and another 5-6km of tram.

    That's the route of the sub. train:

    So the map is not that huge, but it takes 7-8 minutes (I measured) to save and package the map. Also, often it doesn't even save the newly build parts, so I have to delete the map files and re-save again. But my bigger problem is that the map files of the map are around 3,8GB. That's ridicoulus. I have maybe 14km of mostly unbuild map, and even now it takes up 4GB. Is that normal?

    How the heck should we build full cities with/without multiplayer if a single plain map takes GB-s of place? I had a bigger map in OMSI (with the same place BTW) and it only took around 1GB of place (with the objects and splines), now I have 4GB only with the map files (and another 0,5GB with the objects).

    I mean this is the map at the moment, does it really look that developed to take gigabytes of place?

  • Hi,

    we are sorry to hear, that the map editor isn't working for you as intended. At the moment there is indeed a performance issue ruining the experience in the map editor since the latest update. We are currently collecting data when users having a performance problem, so please post a screenshot from the performance window. You reach this window by clicking on the clock icon up in the middle.

    Concerning the questions you have:

    Your PC should be fine to run LOTUS and the map editor. Since I recently got a new PC, I can tell, that the speed of the RAM is more important than the amount of GB you've got. So buying more RAM won't solve the problem, I guess.

    The amount of time the map editor needs to save and pack is ridiculous. Is this also happening since the latest patch?

    The size of the map is not unusual and basically the space on the hard drive is not a problem at all these times. A key factor when building a map is, that the terrain, even if nothing is build on it, also needs to be saved (obviously :D). So when you complete the scenery on your map, the file size should not increase that much as when you build towards new terrain tiles.



  • First of all the unusual matter:

    I have maybe 14km of mostly unbuild map, and even now it takes up 4GB. Is that normal?

    Like Florian said already, the terrain may lead to high demand of memory. But the whole Munich map container (without buildings but including all streets, pavements, curbstones, wire...) is smaller than 2 GB...

    In this case, the packing needs some time just because of the high size of data.

    So I believe that you use some kind of special tracks etc. using very many polygons. What types of rail track (or other splines of all other types) did you use on that map?

  • I use splines and tracks made by myself, but I use tie models made by Gcs7e7 (if I remember well you already told him in the past he uses too many polygons for the ties and ballasts). I remodeled them a bit, but still, a tie is around, I don't know 100 polygons maybe (the distance is default, 0,6m I guess).

    Soooo, should I remodel the ties again, and regenerate the whole map because of that?

    Answering Florian:

    I made a few load-ups and saves to collect data:

    Starting up:

    loading.txt  loading2.txt

    Loading tiles...etc:



    After saving and exiting the editor:

    I recorded these while having running only the Map editor, a paint and notepad (and the task manager of course).

    I think I do need a bit more memory, since as you can see I don't have much left, even only with the Map editor running. And usually I have big aerial photos opened in the background (old aerial photos from the 60's which I build the map with) which use another GB of RAM (and since I usually run out of memory, another 2GB in the %Temp%)

    I have 1600MHz DDR3 RAM, one piece of 8GB board. Unfortunately I cannot install higher frequency units since that's the maximum my motherboard can use.


    So, if I want to change the ties, what do I need? Remodel them, upload in the container (Content Tool), that's clear.

    But even if I just update them (same name, not new ties), do I "only" need to regenerate the tiles, or do I need something extra to do? Like opening the properties of the tracks one by one, ok-ing them, or modify the tracks...or something else? I hope I don't have to delete all of the tracks and replace them. ;)

  • Thanks for the screenshots. :)

    100 polygons

    Soooo, should I remodel the ties again, and regenerate the whole map because of that?

    Yes, please. The ties of my rail package has 45 polygons and I guess that is the maximum for a tie. Unfortunately you can't see the details of a tie that good, even if the train is standing. You can see let's say the 10th tie in front of the train clearly, the other ties cost lot of performance and space on the hard drive with absolutely no visual effect. ;)


    I have 1600MHz DDR3 RAM, one piece of 8GB board. Unfortunately I cannot install higher frequency units since that's the maximum my motherboard can use.

    Basically 8 GB of RAM are enough. But only if you are using the map editor and a browser at the same time, it is critical. In this case 16 GB should be a good idea.

    To change the ties, you don't have to import them again, simply open the tie in the content tool, delete the meshes from the mesh list on the right, go to the first category on the left and use the import button to import the main mesh again. If you didn't change the materials you can simply save and pack the ties. The map editor recognizes the change on its own, but somehow it's recommended to click on one track, open the properties and click ok.

    Please create a backup of your container before changing the tie. If a part of railtrack is missing or screwed, all tracks using this part are getting deleted completely.


  • I think the ties are the problem here. I'm not really happy with this "tie technology" yet... on the one hand side, "backing" all ties (like we do now) would increase the running speed in the simulation but need more memory, rendering each tie separately would be bad for performance... The best solution would be 2D ties... but they are just 2D... ;-)

  • Well, it's kind of solved the problem. It now takes only around 1,4GB (still not that little, but better than the 4GB), I have around 10-15fps more, and now it only takes a few minutes to save. But I did have to click and OK every single track in the map, that was painful :D

  • Newly created posts will remain inaccessible for others until approved by a moderator.

    The last reply was more than 60 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.

    The maximum number of attachments: 5
    Maximum File Size: 50 kB
    Allowed extensions: bmp, cfg, ini, jpeg, jpg, lct, ldl, llg, lob, log, lpmtl, lptmt, ltx, pas, pdf, png, railtrack, rar, txt, veh, wav