[Goku]

cjakeman, on 11 December 2016 - 12:56 PM, said:

I wonder whether Goku has had time to plan for procedural generation of fences, hedges, powerlines etc. in his Route Editor.

Yes, but procedural tracks first.

[rickloader]

conductorchris, on 10 December 2016 - 05:34 PM, said:

I agree that an activity editor is important. Fewer and fewer people can even run MSTS.

Another course would be to continue work on the timetable format. Introducing switching into the timetable format and you'd no longer have so much need for an activity editor. If switching could be randomized in the manner of skyline computing's activity generator, well that would be even more cool.

<snip by rick>.

Christopher

I think Cristopher`s suggestion would make a very big advance in ORTS, and answer some of the OP s concerns.
It has the following advantages:
1) It is already on the OR roadmap
2) It would solve the lack of an activity editor issue.
3) It uses expertise already present in the OR team.
4) it develops an area (operations) where ORTS already excels.
5) It raises no requirements for hardware or compatibility issues.

I envisage a merging of Timetable features with Extended AI shunting features. I don`t know if this would best be done by adding to the Timetable Concept, or adding timetables to OR Activity mode. I suspect the latter because Timetable mode demanding platforms is a hindrance to non-route builders, and also Rob has said he won`t be available for a while.

I have made a video showing how a merged Timetables and Extended shunting might play. (sorry for the video quality)

https://www.youtube....h?v=1r1jbrlZMhQ

The video attempts to show a complete loco duty (roster in US?) Loco from depot > collect stock > interact with AI (switching) >dispose stock > dispose loco.

Please everyone, consider the advantages of merging Timetables with Activities. thanks,
rick

[EricF]

The first thing affecting Open Rails that comes to mind is that OR doesn't have the luxury of a significantly large number of volunteer developers. With limited resources, developers have to narrowly focus their efforts on one thing at a a time. In light of that, I think OR has come a long way in the last year or so. Version 1 is coming together well within the originally-envisioned blueprint, and even gaining features (like working turntables) that weren't part of the v1 roadmap.

Where I see more problems coming in is in the relationship that OR has with MSTS. It's not the compatibility aspect; that keeps getting better and better. The problem may lie more in terms with hardware requirements and end-user issues because the environment that MSTS flourished in has changed.

First off, hardware. MSTS hasn't really gotten any harder to get running on modern hardware and Windows versions since Windows Vista came out. Install MSTS outside of the Program Files directory, run as Administrator, and it works, period, as long as you're using supportable hardware. Hardware is probably a stickier point for MSTS than it is for OR because of MSTS' obscure graphics driver dependencies. It's well-establilshed that Nvidia GPUs just work, but recent Intel onboard GPUs usually don't (or only do so with bad artifacts) and AMD GPUs have problems somewhere between the hardware and the Catalyst driver that often breaks out-of-the-box without tweaking the driver and settings. All of that is easy to solve on a desktop PC -- put in an Nvidia-based graphics card. But the hardware market has shifted toward laptops -- often with less-expensive AMD or built-in Intel graphics. Anyone who's bought a laptop in the last ten or fifteen years probably has only a one-third chance or less of having the correct graphics chipset to run MSTS. The end result? MSTS is effectively un-runnable, and that ultimately turns end-users away from MSTS to other sims like TS20xx and therefore away from Open Rails as well. Modern hardware is, to some degree, hurting the "gateway" to OR, which is MSTS.

Second, the end-users themselves are changing. In a market saturated by low-memory, low-power optimized CPUs, and simplified operating systems for handhelds and tablets, complex applications and their associated care and feeding are fairly alien to a large swath of computer users. Now, I don't think "the sky is falling" and the Win32 environment is going away any time soon -- but end-users are heavily invested in alternatives now. The average computer buyer who walks into a store is probably buying a computer that won't run any sort of game much more complicated than Candy Crush. Those buyers don't even look for software more interesting than "casual" games. That's where the real user base erosion is happening. It's not just MSTS and train simming that's losing market share. What I'd call "desktop" PC gaming -- games and simulations that require a reasonable chunk of your time plus a moderately powerful computer running a full desktop operating system -- is changing. It's not dying, but it is shifting. The influx of users moving into desktop-grade gaming aren't new PC buyers enticed by all that the shiny new PCs can do -- instead, they're console gamers enticed by the improved performance and customization of the PC environment. The new influx has a different frame of reference and different initial expectations. The good news is, they generally don't have problems buying higher-end hardware. They already want highly multithreaded CPUs, lots of RAM and high-quality GPUs and go looking for them. So their hardware preferences are already in line with what's needed to run a good simulation -- even old MSTS if they choose compatible hardware. We, the trainsim and OR enthusiasts, just have to reach them. The common denominator is probably model railroading -- another hobby that's getting more and more high-tech. I've met quite a few model railroaders who are also console and computer gamers -- they tend to all be tech-related pastimes. The interest and market is there, just not a high degree of awareness. A lot of them probably don't know that MSTS may be "unsupported" but still has a strong following, and that Open Rails is well on its way as a viable successor. Open Rails needs to be visible to them, and have what it takes to hold their interest -- which is the tools to build routes and to assemble trains to run within them. Relying on the MSTS tools won't work.

So... As far as hardware requirements go, I don't personally see any problem with OR needing increasingly strong hardware to run well. I'm not just thrifty, I'm proud to say I'm a tight-fisted Yankee where my money is concerned. I'm disappointed with a computer if it's performance can't be kept adequate for over five years or more. I've run systems for ten years. But after seven to ten years, a computer has had its run. The value has been used up and there are better things worth spending on by then. If it's necessary to set a target for hardware capabilities, I'd say that it should be set at any desktop hardware built within the last seven years or so. That means anything built in 2010 or newer if we benchmark to the upcoming 2017 new year in a few weeks. That's a pretty good benchmark, really. Up to 2010, there was still a lot of rapid technological improvements in PC hardware. It tapered off quite a bit after 2010, though. Let's face it, anything running a Core2 duo isn't really going to be up to running Open Rails or any reasonably modern game. Intel I-series processors and their AMD counterparts are a technological step ahead and, as a hardware architecture family, have a good bit of life left in them even in their early versions. But in general, once PC hardware passes seven years old or so, driver support gets spotty. So seven years is a fair cutoff for expected support. Given a seven-year window, there's no reason not to begin developing Open Rails with a focus on reasonably modern CPUs and GPUs.

I do agree that the lack of editing/support tools for Open Rails is becoming a bigger and bigger issue. (A BIG thanks goes out to Goku for diving head-first into route editing working toward a modern consist editor.) But, realistically, the effort is still in its early phases. An activity editor, perhaps integrating the timetable mode, is still sorely missing. Route Riter and TSUtil were developed for integrity-checking under MSTS, not Open Rails. As time goes on, OR will need its own integrity-checking and utility tool set. We need these sorts of tools in order to attract new users to OR. Going back to the likely end-users that OR could attract -- Model railway enthusiasts enjoy the hobby because they can build an environment form the ground-up. PC gamers are attracted to the PC a hobby because of game mods and the ability to fine-tune a game to an ideal state. OR needs the tools to support those creative pursuits.

Optimization of the OR code can only go so far -- OR must, by design, support a diverse spectrum of 3D models and scenery in a very large tiled "world". Conventional games are built around pre-defined maps and smaller environments. They work within a tightly controlled range of 3D objects and landscapes designed for a small, closed "world" or series inter-related "worlds". OR faces challenges similar to flight simulators -- it's difficult or impractical to apply conventional game opitmization when you first have to potentially model the entire Earth, and then support an effectively infinite supply of vehicles and structures to populate it. While a route or a locomotive and set of cars can utilize a common collection of textures and modular 3D objects, it's just not possible to constrain the greater Open Rails "world" to those same sets. Some optimization may possible, but not likely on the global scale of typical game development. In the end, it will still come down to robust hardware. That's the perennial debate in the flight simulator word -- how much CPU and graphics capability does it take to run any given generation of MS Flight SImulator, or X-Plane, or FlightGear? The answer is always, "As much as you can afford. (For that given generation of the software.)" I don't see that being any different for Open Rails -- any simulator that runs realistic physics and realistic graphics/scenery is going to require a lot of computing power. Simulators are a hobby, not a casual pastime. It's safe to assume that the core end-user audience is needs to be more computer-savvy and willing to spend a reasonable share of money on adequate computer hardware.

[cjakeman]

cjakeman, on 11 December 2016 - 12:56 PM, said:

Can we focus on Lindsay's intention as the Original Poster - How can we more easily develop new content?

Rob's timetables have been a terrific step forward.
Stefan Paitoni started an Activity Editor - is anyone familiar with that project?
I wonder whether Goku has had time to plan for procedural generation of fences, hedges, powerlines etc. in his Route Editor.

I know nothing about model-building but wasn't there also a call for a new/better plug-in to create OR-compatible 3D objects?

[disc]

cjakeman, on 12 December 2016 - 06:39 AM, said:

I know nothing about model-building but wasn't there also a call for a new/better plug-in to create OR-compatible 3D objects?

This

[cjakeman]

Goku, on 11 December 2016 - 01:07 PM, said:

Yes, but procedural tracks first.

I've sent you a PM.

[Z31SPL]

My main hindrance right now is no activity editor. My solution will be putting together consists and activities on my old pc and then inserting the files into the appropriate folders on the new one. But not everyone has the ability to do this or the skills and patience.

A word on optimization. I just finished my new PC : i7 4790k, GTX1070 8gb, 16 gb ram and run off an SSD and still only manage 45fps and sometimes dip as low as 25. Not complaining but I thought it was funny. :curiousPC: This was running on the MLT Bridge Line in a severe snow storm in a yard with a couple hundred high quality cars and 12 Streamlines and DieselsWest engines though, so not complaining but in reality this setup should be able to eat that no problem if it was optimized a bit. I don't think that should be the priority though.

I find the overall biggest problem with OR/MSTS is just the amount of back-end work and learning that is involved. Most gamers or simmers these days want something that they pay money for and it boots up and is ready to go and works. They don't want to have to search 10 different websites to get rolling stock and routes. Then have to figure out how to install it and get it all running. They don't want to be messing around with .eng files, sound files, cab views and the countless other things you might need to adjust to have a satisfactory experience. On the other hand this is what I personally love about OR is being able to customize everything to my personal tastes and most of the time for free. Another cool thing is unlike other sims where everything is locked and you aern't allowed to touch and see, in OR even if you buy payware content if you have the tools and skills you could modify or add on to these things yourself. Nothing feels better than after setting up and fixing little bugs for a long bass time and in the end it all works out.

As for what should be the focus or need to be fixed I think the documentation, tooling and visibility are what is needed most. I started posting screenshots on r/trainsim on Reddit just to get more content and visibility out there and I'm getting some interest. I've also been helping a few people out getting their setups up and running and they seem to enjoy what it has to offer over the other available sims.

[SP 0-6-0]

Going back to something that was said earlier. I personally have never played world of tanks. But, From looking on Google I can certainly see what the OP was saying about model quality and textures and how they relate to video rendering. If ORTS is to survive it is going to have to make some changes and have more of a look and feel of TS20XX as I feel the TS20XX and Run 8 are going to be the two dominate train simulators going forward.

TS20XX has kind of set a new standard for overall quality and has drawn away several of the members of the MSTS/ORTS community. Run 8 is now getting into AI ability and thus will get slightly more attention as well.

ORTS needs optimization abilities and needs to jump to atleast DirectX 10 style graphics at the minimum.

ORTS is almost MSTS compatible but not quite there yet. The UK signaling is still touch and go and these days I run more UK stock than American or Canadian. I really like my Class 37 English Electric Type 3 locomotives.

Probably more important is the simple fact the MSTS style environmental features still don't work. Which means routes that use Sky Conductor or Kosmos cannot use their custom environments. It's a real shame the person who was working on this in ORTS abandoned their efforts.

As for the dwindling code developers. As has been stated before. If ORTS was to breakout in the Linux Community maybe a dedicated following would insure that ORTS has a healthier code development base. As has been done with the OpenBVE code can be developed ona number of platforms and contributed to the OpenBVE program code base.

Working turntables are great. However, They also still need some optimization for handling catenery wires on electric routes. The lines should terminate at the approach leads to the table. Unless a special custom turntable was built for electrics to use.

I would like to see working transfer tables and the ability to have the GE locomotives spew fire from their exhaust stacks. Both of which Trainz can do now.

Robert

[Lindsayts]

I believe it would be a mistake to consider a train simulator as simply a game, a lot of people running train simulators are deditcated hard core rail enthusiasts, and a significant but small percentage of regular users of such sims are professional railway men. This is another reason for why editors and tools for a train sim is so important, as a good portion of users REALLY would like to own and run there own railway. To such people the hardware to run the sim would not be an serious issue. As has already been mentioned the hardware capable of running such a sim has been availible for sometime, even with Openrails limitation of only a single graphics thread, the performance of object rich routes such as the SOB and the freeware BerninaBahn is more than execptable.

Lindsay

[cjakeman]

Z31SPL, on 12 December 2016 - 10:13 AM, said:

As for what should be the focus or need to be fixed I think the documentation, tooling and visibility are what is needed most.

Back to documentation then (which is where Lindsay began this thread) but tutorial in addition to the a reference manual.

P.S. Great that you're supporting OR on Reddit.