The most important thing

Spot-on, if you ask me. And, for what I see, you're the first person to deliver content and criticise the abscence of a graphical editor. In the many years I've been here and on Michelle's official boards before the question has been raised several times and usually existing content creators came back with "well I'm the one of us two who actually does something and I didn't miss a graphical thingy, so nope, not needed". I don't know if the contact is still active, but I got Chris and LokSim3D's Lukas in touch once. Maybe it'd be feasible to adapt LS3D's visual route editor? Not necessarily for the old format, but from what we've heared from @leezer3 the new format should conceptionally be more comparable to .l3dstr, the LS3D route format; e.g. with independant tracks etc.

It's not like I miss it - I am capable of doing things this way. But I think any newcomer, who is not REALLY into discovering this and figuring them out, will give up when he/she sees the mountain of time to be climbed.

As for me - of course, if there'd be something that would save time, I would definitely appreciate it. For example Phil's Script editor has been of great help already - it's just that you have got to reload everyting every time to see if things are placed/rotated correctly. And if not, you shift things left, right and center... often by a few centimeters as well.

Totally agree with Dexter.
if an editor was available to build routes, I think the simulator would be much more popular (and I would finally be able to finish the Genova route after years of work...).
I'm sorry I don't have much programming experience, otherwise I would have gladly contributed to develop a route editor.

I also agree with dexter

An proper route editor gonna make this game 10x better, i know a friend who make a route, he need atleast 9 or more months to finish it and its not only 1 scenario but usually 4 scenario for Local, express, rapid etc..

Anyway, we have a route viewer why not extending it ?? Like a user can move, rotate an object with a cursor. Or make the route viewer had 2 mode, 1 for inspecting (this what route viewer intend for isnt it ?) 2 to edit. For edit mode the program only reload the object user choose not the entire route, so the entire object in route except the object user choose is freeze while the user modify.

Im gonna post my UI suggestion for this in my previous ui thread, maybe if i dont busy tomorrow.

UI is the easiest and least important thing at this stage, I don't think that'd be the reason why not ;-)

The problem with the way that Michelle wrote the Route Viewer is that to view changes the file must be reloaded, as Dexter has said. I did try to make the process as painless as possible when I wrote the Editor, saving and re-loading within the application - but there's no getting away from from the original program design. The Viewer needs to be reloaded to see what you've done. I can make it easier (I've learned an awful lot more since 2015!) but I cannot eliminate it.

So, what is being suggested here is a new graphical user interface with which to load/create and position objects while simultaneously writing out the route file. This is not trivial stuff! Commercial software houses would throw a lot of programming talent at a job like that, at great cost I might add.

Chris L is doing a great job at sorting out Michelle's legacy code, I'm (presuming) that he wouldn't want to take time out undertake such a major task.

I'm having some thoughts how it might be done: don't hold your breath!

Phil

PS If you would like to refactor the Route Viewer to add extra functionality - good luck with that.

The problem isn't really moving objects from within Route Viewer (we implemented touch based controls for cabs a while back, which could be adapted), but rather that the whole internals of the thing aren't designed to be converted back into a routefile.


TLDR:
Converting a 2D path into a 3D worldspace isn't mega difficult, but going the other way unfortunately is.
Let's take the classic example of a routefile which passes back over itself; You've either got to specifically tell the thing whether your object is attached to the first or the second part of the path, or write an algorithm to decide this.
Similarly, the visibility algorithm simply doesn't take this sort of thing into account (try some of Smace's early BVE2 demo content to find the total mess this can cause), and this would probaby need significant work to do anything.

Unfortunately, the end-answer is that we're highly unlikely to get any sort of 3D editor for the current formats. Further, any such editor would end up being fundamentally compromised in order to deal with the issues of said formats.

So, is the answer to simply implement a new set of replacement formats, and to keep the original formats as legacy?
It's not that simple
The entire internals of the OpenBVE engine were designed and implemented as a clone of BVE4, which in turn was designed to simulate a very limited subset of Japanese EMUS.
In order to make any improvements, at times I'm having to essentially write from scratch new code without these limitations.
Perhaps surprisingly, one of the easiest ways to do this is the loading of content from other simulations (Mechanik, BVE5, MSTS etc.)- This gives a useful point of reference, both in terms of behaviour and the interaction of differing subsystems.

Well...
That very unfortunate.
Anyway you say its more easy to load other simulator to openbve, is this apply to common 3d format as gltf ?. Maybe if glb variant of gltf can get implemented can make distributing addons more simple when not using package.

Another one, can we get a directional shadow get implemented ? We already have directional lighting in route command, isn't it better to have both ?

I do understand that creation of a visualizing route builder is a very demanding task. However, I felt the need to point out why I think the sim does not have a much wider fanbase.

Let me also take a few moments to thank all, who are actively contributing to the sim development. Especially Chris. He has done a lot of work that allows me to still enjoy the sim.

Also Phil, I have been using his script editor for quite some time now. :-)

Thanks for your attention. :-)

I think one of the reasons why the sim doesn't have a huge fanbase like others is because of it's graphics engine (is that the right term for it?). The lack of dynamic shading and fluid lighting probably does not appeal to newcomers to the sim especially if they are used to games like railworks and Train Sim World. I have heard things from people who talk about the possibilities of porting openBVE to Unreal Engine or Unity though I would imagine that building a new sim would be easier than performing a successful port with legacy support.

That being said, the projects I have seen being developed in the past couple of years are much higher standard than what people thought of openBVE when it was new so I guess the quality and look of the content has increased to match higher expectations and in my opinion, some of the screenshots from addon development for the sims actually looks better than what is offered in other sims. 

This is more of a non-developer point of view I suppose.

From what little I understand, Chris' hard and huge work on moving all the stuff into internal plugins is paving the road for making the whole thing way more modular and thus way more adaptable to technological novelties.
This being said, I do also think the creator base is way thinner than the user base, and I think the inaccessibility of content creation is the bigger stop block than the graphics. I know plenty of games and simulations with old-as-hell graphics which still have a wide fanbase and still get new people on board. Lord of the Rings online is just one example. And OpenBVE's graphic engine as such might be outdated, but thanks to photographic textures and an age-old pool of ingenieous tricks invented by generations of content creators, in combination with the fact that it's usually used in driver's perspective only, the "end product" on the user's screen isn't nearly as outdated as the engine restrictions would suggest.

OpenBVE has become more sophisticated because computers and information are now more sophisticated than when it first began. We can take advantage of developments and data which is readily available for free online.

Plans of railway vehicles and infrastructure are more readily available in many countries. Textures and 3d models can be found for many objects. Geospatial information can be sourced from government and private agencies. Whole terrains and city buildings can be imported from Google maps which make the process of route building easier.

Computers are powerful enough now to process all this information in big junks and so is OpenBVE. I think the 'pen and paper' approach to content creation does not do this program the justice it deserves.