= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Why not add the option to automatically add the paths directly to the object as an option? I mean there is no reason to use AI cubes when you have the actual splines as object and when the user does this conversion before the AI tracks. The only reason I use splines is for the trains to be in the middle of it anyway. I'm way too lazy to make spline, place in editor, export, and then recreate the paths in the crossing editor based on the splines in map editor.
The answer is simple: I don’t want to break anyone’s already completed bus routes when importing a map into nEditor, and that’s actually very easy to mess up because of how the TTR files are structured.
If I imported splines with paths and then exported them as an object with those paths automatically transferred into the .sco file, it would mean I’d have to modify the OmsiObjectId of the spline to the OmsiObjectId of that object in every TTR file, while also preserving the correct order and defining which path number corresponds to which cube index.
Instead, it will work the way Sobol mentioned. A traffic cube editor will be built directly into nEditor, but users will consciously decide which splines should be automatically converted into cubes, rather than having this forced automatically during export.
As for save slots and saving in general: saving in nEditor ≠ overwriting the original OMSI map. Exporting to OMSI will be a dedicated feature where the user can consciously choose to save the map as something completely new or overwrite an existing one.