General discussion about Rail Simulator that doesn't really fit in to any specific category. A good place to start if you're not sure what category it should fit in to as well.
AndiS wrote:As many people noted, the passengers are quite funny currently. The clone look can be changed by a quick reskin. Without artistic ambitions, someone could simply recolour cloth and hair. 3 hair colours, 5 jacket colours, 3 trouser colours, gives 45 different passengers from one original alone. You cannot create that many from the suits (male & female), but maybe 10 different suit styles could be possible. Of course, we need the docu to efficiently produce them. At least no one was passionate enough about them to dig through their XML files.
Yes I was , but to what point .. there are --> no tools , no docs , no :bad-words: nothing .
AndiS wrote:I am not sure anyone can be objective, but it is a good idea to remind people to at least try. Short of objective views, one can always try to have constructive views.
Some constructive things I have not said yet ...
The procedural flora grows everywhere, on tracks, out of the middle of the rail head, just as much as in the meadow. However, this will be a feature of the default routes, it must be able to disable it because it is not there in the stations (as far as I have seen).
I won't pretend to have read most of the above but this stuck out as it shows someone who's not used the route editor as had they done so they'd know only a few textures have procedural flora and one actually says 'grass no flora'!
There was a load of stuff about jokes, personal opinions, ants! and goodness knows what else but if that's constructive, I'm Gordon Brown.
In general and aimed at no one in particular, I warned members about getting over-excited as disappointment was bound to follow. I've had no trouble with bugs other than in the scenarios which I've not attempted since shortly after installing the sim but I could point out many aspects which could be improved. Some I'd describe as flaws, others, as something I'd have liked done differently.
It's a long list and they've all been covered.
That said, it's not affected me to any degree as I'm not looking for a replacement for MSTS or Trainz. I can well understand those like 'lad491', sorry, forgotten your first name, who's made a very useful career making activities for MSTS and finding RS a disappointment. Those who used to more than one sim and see RS as seperate or those for whom this is their first trainsim appear far more content. Everyone could find plenty that they don't like or not included or could've been done better though.
Those who've compared MSTS and RS as they appeared and dismissed similarities in the condition in which it was released by saying that Kuju has the experience gathered since. However, they've completely ignored the other side of the the coin which is that members who concentrate on one sim only have come to expect their favoured aspects of that sim in any future sim. This is compounded by having two major sims and a number of smaller ones. These very varied expectations of that which is considered essential didn't exist in 2001.
RS contains aspects common to MSTS and Trainz and a few new ones. It's an amalgum. Seen as such it will satisfy few existing trainsimmers. Seen as a stand alone product only released a month, ago the picture appears far brighter. Imagine ourselves as someone new to trainsimming with a clear slate, no preconcentions, prejudices, previous arguments and the baggage we have all accumulated although some more than others
I've posted plenty of nonsense and attempt to be humorous if the situation appears to call for it but in all seriousness, I'd strongly urge members to tone down the 'Give us the tools and we'll finsh the job' posts.
I've been around long enough to know that if anyone's spent a great deal of time building something then this can cause offence and with commercial add-ons, it simply wouldn't be allowed. Most coud've been improved upon but the developers like to be considered capable of righting their own mistakes if possible. No one's suggesting there arn't any. It's how they're tackled.
These forums have excelled in reverse engineering with MSTS but this not MSTS and I can't see why RSDL can't be treated with some respect on this matter.
It may affect the tools we're given which would be counter-productive.
Those who've assisted so far appear to have done so responsibly and believe they could've gone further but havn't which shows such respect. However, the mood appears to be that once the tools are available then members can let rip.
This could impact on the long term development of the sim by the developers if not handled sensibly and efforts are made in opposition to and not in conjunction with RSDL which is the only way to repair any damage in relations some may perceive and would do no harm in any case.
Hi,
it seems to me that in reading some of the "objective critisim" that some people have not been in the world editor,for instance, passengers fashions can be changed using people from different eras 50s 70s 90s, and so on,people walking into poles etc can be adjusted by moving the mesh that they are guided by.
its all there in world editor just dive in and try it !you dont have to wait for the dev pack,or documentation,its hardly rocket science.
in the winter route i am building,the passengers are huddled under the station canopy! and yes you can change the number of passengers waiting on the plaform
. my only objective critisism for KRS is that we didnt get the GWR mainline filled with castles ,kings,halls,manors,counties,in fact anything with a copper topped chimney
with kind regards
kevin
CORNWALL THE LAND OF PASTIES AND TREVITHICK! INVENTOR OF THE STEAM LOCO.
BUILDER OF THE WEST SOMERSET RAILWAY ROUTE FOR RS.
PENZANCE TO PLYMOUTH,MODERN,IN PROGRESS.
THE HELSTON BRANCH AND WEST CORNWALL IN THE 1950,S,IN PROGRESS.
Here is an extract from an e-mail that I sent to RSDerek on his invitation from a private message in the forum after I posted on signalling a while ago. Even though he intimated an intention to respond, I have never received a reply.
Your website says,
"No railway would be complete without accurate signalling allowing it to operate. Implemented into Rail Simulator is an extremely flexible signalling system using LUA Scripts. Using this system each route has completely accurate localised signal systems with real world functionality including all the bells and whistles."
Also on your website is this,
"Timetabled scenarios are more complex. A timetabled scenario is based around maintaining a whole network. With the option of jumping trains you can play for hours at a time going up and down the route trying to keep all the trains running smoothly and on time. If you get behind the knock on effect will be felt across the whole network!"
The impression strongly given, therefore, is one of a highly sophisticated, accurate and detailed signalling system, capable of maintaining fully realistic railway operations (so realistic, in fact, that it is possible to test real railway timetables with it), and robust enough to work autonomously for hours on end with an entire route full of realistically timetabled trains going about their business and with the possibility of that business being realistically disrupted by bad driving on the player's part. That is an extremely appealing prospect for a railway simulator that is, in terms of the simulation of the trains and environment, as rich and well made as Rail Simulator is.
The reality of Rail Simulator so far, however, has been somewhat different. There are no timetabled scenarios included in the default content: that itself would be one of the forgiveable problems identified of type (1) above, were it not for the fact that it has recently been announced that it will not even be possible to create timetabled scenarios with the soon-to-be-released developer tools. In respect of the timetabled scenario feature, the main concern is that a feature that was always promoted as being one of Rail Simulator's core, defining features, and which was the main reason for many people (including me) being interested in, and then buying, Rail Simulator in the first place is not only missing from the product off the shelf, but cannot be added by the community and there is no information about when, or, indeed, whether this key feature will ever be "activated" (it is still not quite clear what that term means). Will timetabled scenarios be "activated" soon? Ever?
The concern with timetabled scenarios is linked to the concerns with signalling: one of the reasons that some of us have speculated that timetabled scenarios have not been "activated" is that the signalling system, as currently implemented on the routes, is simply not up to the task: if one tried to run a realistic timetable with the signalling as it presently stands, trains would forever be colliding, derailing, or being held indefinitely at red signals.
The main problem with signalling as things stand now appear to be that the signalling logic is not an accurate representation of how real-world signalling systems actually work. I will deal with the UK colour light signalling systems (Oxford-Paddington and Newcastle-York routes) because that is what I know best, but many of the issues are no doubt equally applicable to the other systems, too. Firstly, there does not seem to be any concept of a track circuit: in practically all modern-day signalling systems, there is some automatic way of detecting whether any rail vehicles are present in a defined section of track, which information is of critical importance to the signalling. For simple automatic signals, the occupation of the track section means that the signal in front will register danger, where otherwise it would default to clear. For signals that control junctions, the position is more complicated. The standard practice there is for all signals that control junctions (that is, any sets of points after the signal and before any other signal) always to be at danger unless there is a specific route locked through the junction. In real-world signalling practice, the route can either be locked manually by signalling staff (the traditional way of doing it), or automatically based on the booked path of the approaching train (called "Automatic Route Setting", used in some of the busier and more up-to-date signalboxes in the UK).
In Rail Simulator, it seems to be the case that signals change to danger because a train has passed them, and the fact that a train has passed them ("OnConsistPass") is the only way that a signal will know if the section that it controls is occupied. Similarly, the only way that that signal can clear in the system as it is set up now is for the train to pass the next signal, and for that next signal to send a message back to the first signal telling it to clear. It seems that signals protecting junctions show red only when there are trailing points set against the train, or a train has passed the signal and not passed the next signal on the way out of the section in question. As I have found out in testing, this is capable of producing seriously anomalous results.
Firstly, taking the simpler case of track circuits, if a train enters a section, uncouples, and then only part of the train (for example, the locomotive) goes on to pass the next signal, the signals protecting that track section clears even though there are still vehicles in the section. That means that, whenever there is a situation where a locomotive has to uncouple from carriages or wagons, or a banking locomotive detaches from its train, or two multiple units divide, and there is a train approaching from behind, the train from behind could easily collide with the train or portion of the train remaining in the section. That feature alone makes it impossible to model realistically complicated or intensive operations, as many collisions would inevitably result: dividing and combining multiple units, coupling and uncoupling coaches and wagons, and attaching and detaching banker engines are all common tasks performed on mainline (not shunting yard) sections, without which, it would be impossible to simulate all but the most dismally basic of railway operations. The only possible solution is a function call in the signalling API to detect whether any train (or any part of any train) is physically present in a given section of track, whether or not any other signals in the area have been passed by anything coming out of that section.
Another related problem that I have identified in testing is with portals: when a train enters a track section containing a portal, and disappears into the portal, there is nothing to tell the signal behind that the train has disappeared, so it remains at danger, preventing all other trains from entering into the portal. Although it would, as AndiS pointed out on the forums, be possible to create a workaround for this issue using the existing API by creating a second signal link to clear the first signal just before the portal, such a workaround could not solve the more serious problems identified above.
On the slightly more complicated issue of route locking, signals should simply not show clear unless there is a specific path locked through the junction: showing clear, as they do now, without a specific path locked is unrealistic in itself. Any approaching train would consider itself clear to proceed at maximum line speed through a junction if it had a green signal, so, if two such trains are approaching at once, and the planned paths of both conflict, then, depending on how the pathing engine deals with the conflict, the trains could either collide on the junction having gone through green signals, or a signal turn red just before a train goes through it, without any warning, again causing a collision when the train is unable to stop in time. In many cases, trains' paths through junctions will involve potential head-on conflicts, or will involve conflicting moves over a non-slip crossover, so, if the only basis for a signal showing danger before a junction is a train having passed it without having passed an exit signal, or a trailing point set against the track between it and the next signal, head-on collisions where all trains receive green signals are possible, as are trains colliding over crossovers because the signalling system did not detect the conflict. Another problem with having signals protecting junctions not always at danger unless there is a specific path is that, if the current path set through the junction is clear, but the approaching train is scheduled to take a path that is occupied by another train, or is about to be occupied by another train which has received a green signal, then either the train, on approaching the junction, will simply proceed through it on the wrong path, which would cause no end of problems for the railway operations (and, in the game, for the pathing logic), or the signal woudl change to danger in front of the train when the correct route is set, with insufficient warning for it to stop in time, resulting in a collision. Indeed, in real railway practice, whenever a signal at any other aspect than danger is changed to danger when a train is approaching, all routes through that signal are locked for a fixed time to ensure that, if the train approaching the signal is not able to stop in time, no other train has been in the meantime allowed onto a conflicting path to enable a collision to occur. So, as with track circuits, without proper route locking at junctions, any attempt to create the sort of number and complexity of train movements required for a timetabled scenario would likely result in numerous scenario-ending collisions, as well as the signals just plain looking wrong when they are showing clear through a junction without a specific route being set.
There have also been complaints in the forums about the lack of approach control for low-speed junctions off high-speed lines: for obvious reasons, when a train is being routed on a junction that must be taken at low speed from a line that allows the train to travel at high speed, the driver needs to be given a warning in advance to enable the train to slow down in time. As the signalling presently stands, this is not done, so a driver only gets any notice by the time of the signal feather at the signal immediately before the junction, which is insufficient notice. In reality, drivers would receive yellow or flashing yellow signal aspects to warn them of an approaching junction. Again, without that, in a timetabled scenario, a scenario-ending derailment could easily occur if a player train was not able to slow in time for a low speed diverging route.
The last of those problems can probably be solved relatively easily by improving the signal scripts, but the first two are far more worrying, since there is not presently any indication of any function calls in the signalling API that could allow the effects described to be achieved. This appears to be, therefore, the sort of fundamental architectural problem that is a cause of very great concern indeed. Furthermore, it is a fundamental architectural problem that, as I have explained, makes it impossible for Rail Simulator to do the very thing that it is supposed to be uniquely good at doing: simulating an entire network of railway operations. With the design problems identified above, I cannot see how it will ever be possible to use Rail Simulator to, "carry out basic schedule and capacity planning", or how it could ever allow one to , "...play for hours at a time going up and down the route trying to keep all the trains running smoothly and on time. If you get behind the knock on effect will be felt across the whole network!". The signalling as it stands can hardly be described as, "completely accurate localised signal systems with real world functionality including all the bells and whistles".
For all I know, there could be track circuit and route locking simulating function calls in the API already, waiting to be discovered when the developer tools are released; but, if that is so, why not use it for the default routes? Surely it would be easier to write signal scripts making use of those function calls than try meticulously to work out whether there is a train in the section by asking all the possible exit signals whether a train has come out after one has gone in. Furthermore, even if those function calls are present, all the default routes will need to be resignalled completely to implement new signal scripts containing these function calls. Given the length and intricacy of these routes, that would be an enormous task, and it would have to be done before there would be any possibility of having any sensible timetabled scenarios on those routes. The way in which signalling has been implemented simply does not appear to make any sense, especially when a product written by a lone amateur in his spare time (Rail 3d) has none of these problems, and gets signalling very right indeed.
Concern about the signalling problems is, as you are probably aware, widespread, and will only become more so after the developer tools are released (unless a fix to all but the most trivial of the issues is included with them), since people will then expect to be able to create their own scenarios involving AI trains, and will find all of the problems that I describe above as practical impediments to what they seek to do, rather than just worrying results of theoretical tests. The very real concern is that the problems are so great that they will so adversely impact on the commercial viability of Railway Simulator that there will not be time to fix them before continued development is forced to end, against the wishes and despite the best intentions of the developers, for want of funding.
Sorry for not getting back to you James after I acknowledged your mail. I have asked a number of people to contact me about the issues people have the signalling. Once people have the signal document, read and understood it and what can be done, then we can take the signal subject from there.
Sorry for not getting back to you James after I acknowledged your mail. I have asked a number of people to contact me about the issues people have the signalling. Once people have the signal document, read and understood it and what can be done, then we can take the signal subject from there.
regards
Derek
In which case, I shall eagerly await Monday to see whether the specific issues above are addressed
Although I dont want to be drawn into this any more than I have already, I just wanted to say what an excellent document that was by jamespetts. Although his view of what makes a "timetabled scenario" and mine differ, his points were expertly made and even i could follow his discussion and logic regarding the signalling. If RS wanted constructive feedback that was a really excellent example.
my only objective critisism for KRS is that we didnt get the GWR mainline filled with castles ,kings,halls,manors,counties,in fact anything with a copper topped chimney 
