Atomic Systems

RSderek wrote:Hi,
Some of the ambitions that Kuju had back in 2005/6 were compromised in the desire to actually get a product out.
When RSDL took over support for RS, we said we'd improve the things that are broke or not finished and we've already made progress here and have more plans for the future.
Not only have we invested time and resources over the past year fixing bugs and adding new features we have also created new content for the product.
We're going to continue in this mission and we'll definitely be making some further fixes to the dispatcher, but also we need to better educate users and developers as to what it can do and how to do it, which has to be said we've not done a great job of to date.
While many people get great pleasure out of rail simulator we understand that there are areas can and will be improved on.
We have been doing what we set out to do which is being committed to improving RS.

James, you really print that on pink paper and attach it to your screen. Your recent review of RSDL quotes clearly shows that they are becoming more and more aware of the need to do something about the dispatcher core code (as opposed to Lua scripts), and here again, you have a nice open statement. No company would put that on the front page, it is great to have it here on the forum.

Derek, maybe Mk3 can remove the stupid claims that anger James and me so much, at least for the RailSimEditor, which is all we are using. I guess I never looked into the About box, but I keep seeing this "most realistic simulation" blurb. Just bring it back when you recovered all the MSTS 1 features. Then, we will all cheer and agree.

Of course, people can say "just ignore the ads", but there are old-fashioned guys like me who consider the output of a computer programme a communication act between me and the producer of the programme ...

(P.S.: As James just found out, you already started doing so, very fine. Of course, I would prefer complete accuracy with bells and whistle, but while you are working on it, it is a great to adjust the advertising to the status quo.)

mikesimpson wrote:2. Serz.exe was not even supplied with the early copies of the game, so there was no way to see what was in the .bin files, and even when it became available it is a DOS program not easily understood by many users, especially the younger ones.

Just for the record, it was on the first CDs shipped in Europe. The first mention of it dates back to October 15th.
Whether it was planned to be there or not is an open question. As we know the sequence of publishing the fragments was not an ideal one, so I suggest the discussion of the history does not lead to happiness.

My understanding of the points you raise (not intended for easy modification), is this:

A) There are different user groups: "professional teams" of specialists, both payware and freeware; solitary, serious experts; amateurs with little background in railways. Kuju clearly forgot about the second group. If you start from cleverly designing blueprints, you are ok. If you just plunge down houses, you are so, too. If you want to model a route alone, you are having a hard time. This, in part, is due to the sheer amount of detail KRS can render, as opposed to previous programmes. But it is also obvious, that roles like the serious reskinner, the determined builder of long routes, the signal modeller without programming know-how, they all drop below the radar of the software design department.

B) Kuju had lots of ideas that got dropped: DRM, IGA, licence fees, quality assurance programme, central content server (or at least unique ID server), ... Most of them demanded a closed-shop strategy. In the end, they revised that completely, in sync with RSDL taking over from Kuju. So we should credit it to them. Now we have overly complex data structures, and tools that give us access to them. (Most of the extra complexity is bad design, not sinister plot.) A while, I assumed that they are reluctant to publish the data format to keep things in the dark, but seeing as they only now publish absolute goodies like the time-of-day blueprint, I guess it is really just lack of time to write all the docu that we need.

mikesimpson wrote:Some people have suggested that 'someone' should write a utility which would make it easy to change things like brake settings and other items like in the Engine/Wagon file editor in Route_Riter. This would be a good idea, but I am getting too old for this and do not wish to start a new project all over again. The entries in many of the files are not documented so I hope one of the younger group members will take this on.

While I am somewhere between you and anything like young, you can be sure that I will resume the physics fun once the exhaust is liked to it. And I hate manual work, and of course, I will not go the extra mile of the blueprint compilation cycle.

I have a ton of other ideas which will mostly require some more info on the format (mostly just how to create the various IDs), plus a lot of time. Too bad that I am too near to the young generation for early retirement. The following is just a little brain dump.

Asset repossessor. An interactive browser for all the assets, which lets you change the "product" field of selected items. This way, you could split the default content into 10 or so packages, and get rid of individual packs using the object filter - no moving around of files. Example: I need the default signals to go, but of course, I want the houses to stay.

Consist editor. Ok, not new, John already mentioned Conbuilder. But you definitely need a really good database, supporting thumbnails and lots of categories, to keep track of the myriad of items we will soon have.

Track sanity checker. Reads all the track information and tells you about near misses in "track ribbons", orphan signal links, signal links facing the wrong way, sections with predefined properties ("There is no freight-only track in my layout, is there?"), suspiciously short sections of track properties (most likely clicking mistakes).

External track editor. An analytical view of track design was clearly excluded by the design team of KRS. So why not jump between the world editor and a graphically simple tool with great definition strength. It would only show the track in top view or side view, and let you do things like this:
a) Insert a set of switches according to strict design standards (German style).
b) Modify the gradient, to get prototypical rounding without pain, and to generally get it right without pain. You could lay it on a plane in the world editor, then make the gradients of the whole route in the external tool, then go back and do the finer adjustments.
c) Build easements with all the accuracy you can muster. (Personally, I do not mind the KRS easements, but since geometric definitions of easements changed over time, there must be some that KRS does not handle.)

Loft assistant. The offset tool is fine, but you could combine the above view with inserting the right lofts for the embankments/incisions. If the tool reads the elevation data of the tile, it knows the required height. You just specify the family of loft objects to use, and mark the places where you want to have them, in general, and the tool picks the right object.

Another loft assistant is a plug-in in your favourite 3D modelling programme, which lets you define a family of embankments, all in same style, using the same textures, but of different height, somewhat different slope, and optionally with different heights of walls at the base.

Signalling assistant. There are quite strict guidelines for placing signals, and KRS does not support their implementation, because you cannot measure along the track. You could, of course, define several measurement tapes as lofts and place them using the offset tool. But you could also take the bird-eye's view in an extra tool, and say things like "next block length: 2000 m", "distant of distant signal to stop signal: 1000m", "distant of stop signal to point of danger: 70m", then you click on track sections where you want that applied, and the tool does the calculation for you. Of course, you will always return to the world editor afterwards to do the fine tuning, like moving signals next to bridges, and such.

A less ambitions version of the same idea would be a passive signalling quality control tool, which only reads the files, and tells you about anomalies in your signalling, such as forgotten distants, distants with unusual spacing, stop signals very close to each other, unbalanced distribution of shunting signals around a junction, ... Not every anomaly is an error, but a list of 30 "interesting points" in your route is much better than flying mile after mile in search of the reason for some failure.

Loft to object converter. An idea dedicated to a certain creator of excellent viaducts. You place a loft with "follow terrain" in the game, then run a programme which converts the loft into an object in .obj format (showing a ribbon with the correct elevation & position). You import the object into your modeller and align the base of the pillars of your viaduct to it. Of course, you do not include that object in the export.

There are countless other uses of such a trick. E.g., you could have a road crossing objects with 10 cars filing up, as a predefined animation of the 3D object, triggered by the approaching train. I have not tested anything yet, but already wrote a first version of the conversion code.

Magic lofts. Intelligent, moderately random placement of vegetation is one of my favourites. But working myself never appealed me. So I plan to devise this scheme.
1) You define an loft called magic tree line, texture is a yellow stripe with "here comes a tree line".
2) You define a complex pattern of tree and shrub placement, using fuzzy regions for the parts, possibly grouping stuff hierarchically.
3) You place such magic lofts where you want the tree lines.
4) You apply a programme that replaces the magic loft by plants according to the definition in 2).

If you define one side (e.g. the left side) of the loft as the front side, you can create forest faces, i.e., tree lines where the first line is made of "near" versions of trees, followed by 2 of the "middle" variant, followed by several of the "far" variant.

Since Derek says that many objects are bad, step 4 could create something to import into your 3D modelling package from where you export a single object for the whole tree line (or for 100m segments of it). Since this would be a bit of work, maybe creating and .xml file for a custom-made scenery item which contains all the trees as child shapes would be ok, too.

Magic ground textures. Same as above. You spray some special texture and then apply a programme that places something there. Maybe good for background forests. You would suffer from the 8m grid, but the transformation programme could straighten out the steps.

Map-based forest definition. In the track viewer above, you bring in a scanned map or Google Earth photos. You mark the margins of forest areas with the mouse. You could also define tree lines here. This would give you more freedom to define parameters of the lines you draw, but of course, you need to write the viewer first.

Other intelligent placement modes. You define a certain area using one of the 3 methods above. Then, a programme does one of the following:
- Place crook vegetation at incisions in the terrain.
- Place shrub at the foot of embankments.
- Place fences and/or telegraph poles along the track.


As I mentioned, I am out of school and far from retirement, so I'm just dumping thoughts here, with the explicit non-promise to do anything. However, if anyone considers doing anything along these lines, feel free to ask for details. The above is the short summary.

Indeed, while the signals are accurate in areas they are not 'completely accurate'.

AndiS, RSDL are not dealing in magic, if we claimed we could do Magic just think how outraged some people would get.


regards

Derek

Derek, this was not a wishlist for RSDL to fulfil. This was a quick brain dump of what "younger members of the community" could do if they had a lot of time, and if some (not so large) gaps in the docu were filled.

As always, I forgot a few chunks. These are the ones that already resurfaced in the sea of madness:

Loft changer. You create 3 shades of green of a certain embankment (light green, dark green, brownish). Then, you create transitions between them, i.e., 50m lofts where the texture is just a blend-over from light to dark green, etc.). Makes 6 transitions between 3 colours. Then, you specify how long you want the colour to stay the same, on average, and how likely each of the 3 colours should be. Then you lay a long stretch of magic (again) embankment loft and then the programme to be written exchanges that for a series of lofts like "light green" - "light to dark green" - "dark green" - "dark to light green" etc.

Shape variant creator.
Use case 1: You made 10 reskins and need to get them into the game.
Use case 2: You have a signal script for junctions with any number of arms, but you need distinct XML files for arm count 1 - 10.
Use case 3: You have 5 load shapes, each fitting on any of 10 wagons, so you need to create 50 XML files.

In each of these cases, you could crank the blueprint machinery, or you could just type in the changing bits in a text file (I always use Excel and save as "text with tab" since I am too lazy to write user interfaces and also too lazy to parse difficult data formats in my tool.) Then you tell a tool the name of the master XML file and that tools creates copies with the varying fields set accordingly, e.g., 50 wagon files with slightly different names, having different child objects for the load. Or signals with different number of signal links, etc..

Timetable printer. Reads a scenario file, prints a nice timetable. Best take a two-level approach. First create an XML file containing the data for the timetable. Next apply 5 different formatting scripts on it, because people can never agree about layout, and prototypes differ.

If you access the track layout, you can add speed limits, gradients, location of level crossing and signals, arriving at the complex and complete information that they hand out to drivers in some countries. (Called Buchfahrplan in German; also comes in lots of different variants.)

Anomaly detection in scenarios. You read the scenario file and make up a map who is where when. When you spot a location where two services seem to pass more or less at the same time, you report. Could be useful, could be an impossible mission, I have not studies the scenario format close enough to say.

Another anomaly detector would look into saved scenarios and detect trains which the dispatcher intends to reconsider after doomsday. Of course, we hope that the need for that one will go away soon.

Train runs visualisation. X & Y coordinates are a map of the route (showing only the track), Z coordinate is time. Each train movement is shows as a series of cylinders. The extend of these cylinders would be 3 or 5 minutes in the time dimension, depending on your minimum block occupation, and 3,5 to 4,5 m wide, depending on the track spacing. This means that the cylinders would become vanishing lines when you zoom out a little, so you need some intelligent zooming, which reduces the width of the cylinders/lines less than proportional when you zoom out. The nice thing is that you need not do any abstraction if you follow this line.

A bit better, and a bit more work, is this: The user marks a segment of the network. You show this then with mileage being the X dimension and time the Y dimension. Advantage: clearer presentation, more resemblance to the charts of the prototype.

Both forms have the big advantage that the tool programmer need not try to find train collisions, the user can try to figure out potential sources of problems while looking at intuitive representations of the whole he created.

Train service cloner. You define the first of a series of similar services, then you give the cloning tool a set of starting times when you want the service repeated. Of course, you must not do this after you defined some complex, colliding service. Instead, start the scenario by defining more or less boring background activity on the route, without any collision. Then let the dispatcher digest what you cloned. He should not cough it up if there is not potential for mishap. Then add all the interesting stuff, as long as the dispatcher can take it. Do not apply some external cloning later. It would be simply unfair.

Better scenario descriptions.
a) Simply show all the text that will be displayed in bubbles during the scenario (instructions, success messages, ...) in a tabular form (together with some info in the service, so users know what is what), and let the user simply edit the text in that table.
b) Would it help to give wagons a more descriptive name? This "take wagon 45678 to siding34" needs to go. What if I clone the XML file of the wagon and call the wagon "Coal to X", just for the sake of the scenario? Needs some research on what exactly is shown in the F6 bubble.
c) Maybe, there is some potential for automatic text generation. You would place all your train orders in the scenario editor, without entering text. Then, some tools fills it in from templates, thereby providing intelligent extension like mapping wagon numbers to something meaningful.
d) Create an itinerary from the scenario instructions, to be printed out by the user. Nice to keep an overview, some people love to have one.

I know next to nothing about scenarios, but I am convinced that keeping user instructions in dozens of different dialogue boxes ensures inconsistency.

Hi All

Once again we find a thread which seems to have an underlying theme of RSDL bashing and whilst it is now becoming quite entertaining, I cannot help but get the feeling that for some people the scoring of points is the main motivation for posting to the forum rather than any genuine concern for the development of this simulation.

I think by now most people are aware of the problems with the simulation and RSDL are doing the best within their resources to fix the faults. I cannot see what can be achieved by continually trying to score points against RSDL other than the self satisfaction and ego boosting of those involved.

By now there must be a general realisation that Kuju may well have ditched Rail Simulator because of its basic problems and had it not been for RSDL, Rail Simulator may not have gone to market. Why take pot shots at a Company that has taken a big risk to mend and develop a faulty program for our enjoyment.

Despite the snipers, there have been a lot of good suggestions and constructive criticism in this thread and I am sure that RSDL will take note and try to do what they can within their resources. Indeed, some of the ideas are quite inspiring and hopefully some of the 'younger' contributors might like to have a go at them.

Whilst everyone has their opinions, I find it difficult to understand why some people keep posting to this forum when they seem to have little interest in the simulation itself. I really think they would do themselves a service by trying something else that does please them rather than be in a continually dissatisfied state of mind. How miserable is that?

My support for RSDL is unchanged and I am happy enough to wait for the development work to progress.