Line breaks are mostly made with "<br>".
Line breaks are mostly made with "<br>".
If you have a road for example which is a bit complex (two sidewalks on each side, a separated grassy part between the roads, I don't know), and the road is almost the same for kilometres long (except a few parts), then what do you do?
The two maps, I created, don't have such roads and for me it is annoying to change the program often, so I would prefer polygons. Sometimes I use sidewalk splines, but that's all.
But building complex roads on slopes or hills is not that pleasant (with polygons)
Can you tell an example of such a problem?
Maybe it's not the editor's fault, more like the lack of documentation, if almost everyone do it wrong.
The editor has some simple "rules" when using polygons. An example: If the Map Editor should merge the surface to one mesh, you can help the editor by placing your polygons "smart".
A thing I recommend to everybody, who is creating surface splines, are "cutting meshes". These are very helpful, but in fact not properly documented. The conclusion is, it is more likely to get holes in the terrain when using the content beside the base content from LOTUS.
1. Well, you are the developer, not me, so you should know. There are games out there which works way smoother even the are finished and more complex than LOTUS.
A good start could be that the game could store only parameters of splines, so you shouldn't refresh your map every single time, and it wouln't be stored in the tile files, which could drastically decrease the size of maps.
You can't change fundamentals of LOTUS. When you want to decrease the size of maps, you have to decrease the number of cuts in the terrain.
but just don't get upset because someone has another way of thinking and just don't see the point. We, as creators would like to have a nearly perfect program, but we want developers who listen, not mute voices who don't agree with them.
Well let's conclude this topic at all. Someone posted a screenshot with a road made of errors next to an huge amount of hours to create these errors. Then the discussion escalated quickly. I asked some questions and everybody was offended. In the end I'm tired of reading sentences like "Your source code is shit", "The program is buggy", "Give me 10 hours and I create a better LOTUS", "Other games work like a charm", "LOTUS is not complex, so why is the FPS low" and so on. And don't get me wrong, I'm just cynical, not upset. Maybe that is fallen flat when translating from German to English and from English to Hungarian.
Last thought: My point was to provide the solution, the Map Editor is optimized for. Not changing anyones mind.
Easier option than making an optimized game..
Please share your great ideas, where we can optimize the game. I'm curious.
No, not all the roads look the same. But there are hundreds and hundreds meter of roads where it is (on one place, in one street for example). Also, please tell me how the road isn't the same on all the pictures I can see in the forum. In the official maps, in the DLC, in the thread you posted...etc. All of them use mostly ONE road texture as polygon. Putting one patch texture around a kilometer doesn't make the roads unique.
It is not the texture, it is the shape of the road. Is it that hard to understand?
On the second question: what I meant is that a spline just simply shouldn't make that much more polygons on the map than the buggy polygon tool itself. Unless there are some pretty huge problems with the program. But sure, getting mad solves problems like the huge unoptimalization of terrain reservations (like you place a kilometre of track, and square-kilometres of DEM terrain is packaged to the map, taking up hundreds of MBs) or the into-terrain saved splines.
The polygon tool is buggy? Please tell me more. If you got issues, then tell us, otherwise they don't get fixed. Besides that there is no other point in this discussion anymore.
No offense, but I'd really like to see you or anyone from the staff doing a mountain road using only polygons.
No need for that, there is a good example: Twinaue
I have no clue why it had benefits if I used distinct road curb splines AND polygons instead of using only one single spline.
Does every road in Hungary looks like the same? No road bumps? No car parkings?
If the code behind the map editor is not that garbage, then it shouldn't make a difference
Just because of this stupid sentence, I won't answer this question at all.
(on the other hand the rail ties DO CAUSE a problem, since God knows why every spline is formed into the terrain in LOTUS, and that means using even a tie of 10-15 polygons can cause plus gigabytes of harddrive space on a bigger map, not speaking about the default ones which have way more polygons...)
Also, what do you mean by debugging? In OMSI it was possible to open tile files with a single text editor, and look for errorous parts (like I don't know, kilometre long splines placed -200m deep...etc). But as I see all the tile files are coded, so can you tell us how is it possible to debug so?
It is not possible to debug any container. It was just a comparison.
Especially the road splines, that overlap each other, are nonsense. Why would you do this?
I know it is terrible. So this will be good way? How ai will come in the splines/roads? How can we will set in Editor?
This is definitely a better way.
I'm in doubt, that the spline will help you in any case for placing ai paths.
Excuse me but I can't agree with it. I am also using my own road splines to make even shorter streets, because it's much easier to add abbrasion and markers later on.
And also, making a small elevation with polys are terrifying, while working with splines is a way easier method.
Of course I don't overlap them, but in smaller intersections I use the spline for the main road and then expand with polys.
I recently had an argument with someone, who proclaimed a scrappy solution as an easier way. The result of this conversation was, that we want the Map Editor used as intended. And the intention is to use a lot of polygons to create an unique looking scenery. If you found an other way to build maps, it is fine. But of course, it is our aim, that users learn the functions of the Map Editor as intended. You can compare this with source code. The scrappy one may work too, but at the time you want to debug it, your are screwed. I guess, I will do a specific tutorial video about the Map Editor soon. The things you mentioned, like abrasion and markers also as elevations, work like a charm when using polygons. But that might be to much to write in this case.
I guess this discussion gets cut from the map thread.
You should use splines as roads
What is the benefit on doing this? Maybe on a long distance road outside the town, but elsewhere there should be used polygons.
You mean that the cross contruction?
Especially the road splines, that overlap each other, are nonsense. Why would you do this?
You know good work takes time, but sometimes it takes extra time (Like in Lotus)
If you knew how to work with splines and polygons, it would not take that long. So maybe invest your time in studying the map editor, instead of blaming the developers? Let's do quick math: 10 hours of watching or reading tutorials and 1 hour of building the roads is 11 hours in total. Right?
Beside that shitty sarcasm: The roads you created on your map have tons of errors. I have no clue, what you did there. The only thing I know is, that this is not how it works. If you have questions about that topic, feel free to ask. IMHO it is a shame, that you did not question the way you are making roads, while taking that much time.
My grandfather told me a joke about it. If i need 16 Hours to make this road, i will need 10 years to finish the map. Its funny....isn't it?
I'm quite sure, your grandfather said something like "If you need 16 hours to build this road, the way you are building this road is horribly wrong." Your grandfather seem like a wise person to me.
Now, that was more informative. I don't want to be rude or anything like that, sorry if I was, but that's (in my opinion) is at least a point we can start from.
Honestly support is not an easy task and especially the errors concerning the Map Editor can't be answered with a standard sentence. So we have to rely on the data given us by the users. So we decided to create a template for support threads to get this data. When this template is not filled in correctly we probably can't help you. This is the fact, why we were pointing towards the template in the first place.
BTW the second error message says: "A tile could not be loaded or is corrupted. Do you want to delete it?"
Maybe there's such a big error the map editor cannot even load it?
Ok, the error message is a big part in the puzzle. Basically if you get this error message, you need the files from a back up. The Map Editor is capable of cleaning the map and get a consistent data basis. When this fails, the tile has to be removed permanently. You only can replace it with the same file, but in an older version.
Do you know, is there any size limit that the map editor doesn't really likes to load a tile file above?
There shouldn't be a reachable file size. The effects of having high size tiles affect the performance and the loading times when changing the tile in the simulation. The editor should also have a worse performance, but I don't think 200 MB are enough to crash the editor. A key fact is, that the tiles nearby are also very big. Maybe this changes the equation.
To get in touch with some numbers, I had high sized tiles in my map Duesseldorf as well. The biggest tile had like 130 MB. On a medium PC with like 4 or 8 GB RAM, the map had performance issues. Janine has an old laptop to also check such oncomming performance issues, you'll find the specs somewhere in the lexicon/writings about minimum PC specs. I decreased the size of this tile by 50 % simply by optimizing all splines and rails.
Another effect we recognized were the loading times for the tiles when not stopping at tram stops. I've reworked the ties to get a better performance and smaller loading times in the editor and in the simulation.
A normal tile should not hit the 50 MB mark at all.
Also, what thing can he do if the map editor doesn't open those tiles? Delete the tile files and rebuild the content of it, or nothing?
The file contains the terrain. If you delete the file, the terrain is gone and all information about it too. If this happens, you are basically screwed. Because of simulating the globe and its round shape, every file is unique and can't be replaced by an other tile file.
To be fair, that's not so informative.
Could you please at least give some tips for him what can cause this? 'Probably made by the map creator (...)' Yes, probably, though he claims he didn't change a thing in the last year. Even if we'd know it might be because of a spline, a subgrade, objects, track...etc error, he could start to look after some things. But that's just needle in the pile of hay.
To be fair the first post of this thread is not so informative either and I have no information to provide a simple solution. On the other hand we got the Map Editor, which is a very complex system, that struggles the most, when the user does something the editor doesn't like at all.
So let's conclude: The first screenshot has a warning, that a spline-like object will be deleted, followed by a message, written in a language I can't understand. The warning is mostly not critical, this just deletes the object. The next screenshot shows the files, where we can see 3 nearly impossible huge tiles. If I'm not entirely blind, these tiles are each above 200 MB and these values are insane. What is the content of these tiles?
The next screenshot shows an error message I haven't seen in a long time, same as the error messages in the other screenshots.
The logfiles, that are attached to the post, are not quite helpful and the, for this case very important, Debug-Logfiles are missing.
All in all it's not that easy to help in this case. One thing is, that huge files sizes unfold in the RAM a little bit, which could be causing the errors, but this is only a wild guess.
To be honest, it is good to have some data about your specs. The template should be filled out, because the error message says something about the RAM.
A key fact is that the Map Editor is not capable of creating a working map, so there is some error, probably made by the map creator, that is a threat to the Map Editor causing the issue.
You have to generate the terrain again, after modifing/deleting the tracks, splines. Eg. if you delete the track you can still see it, but you cannot click on it, because according to the editor, it's actully deleted.
I'm not entirely sure, but after deleting the ballast from a track or when doing similar stuff, the deleted object disappears after a certain time, let's say less than 5 minutes. In my opinion this won't get faster when refreshing all the time.
sziriusz12 he is saying that your map is in early access and it's pretty much empty and it's already 3.5 gigabytes which is way too big for an early access map. At least that's what he is saying.
Guess he fully understood, what the problem is.
Let me mention that you did something wrong in the optimization (likely that you used hi-poly ballast or tracks, IDK) because the map is 3,5 gigs in this pretty early stage...
He didn't. When building large maps the filesize increases simply by occupiing the terrain. So when he is filling the map with streets and houses, the file size won't increase that much.
depending on the program you use, the simple way is to save your jpg or png file as a bitma. Then reimport the texture into the program, the UV Mapping should remain the same. I guess, that would be a task of 2 minutes.
Maybe the translator works within boring lessons at university.
The article is finished now.
Thanks for the screenshots.
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.
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 ). 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.