[Rohit]

 Lutz_s, on 17 August 2015 - 07:02 AM, said:

I think your keyboard is broken, it's writing the same again and again. You already got an answer to the question when the shunting will be included into the timetable mode, which only captain_bazza could have answered better (literarily). I can show you heaps of trains which are composed once and then drive their route each day, without changing anything (at least in germany the train companys try to do this, because every shunting is a shunting too much, in their eyes). So the timetable mode isn't far from the real world. There are changes of the traction type in the real world, yes. Maybe it will be possible to do this in the timetable mode one day. At the moment you have to live with what you have. I think every question of "when" delays it two weeks.

Cheers Lutz

PS: It could be, that it was easier to disregard player trains in shunting actions, than implementing it.

Mr. Lutz...,

My keyboard is not broken. Till now a keyboard is not programmed to write the same matter again and again. It is the person who is writing the matter to get a response. I am not ready to argue with you in this regard. I have raised a real question and you are not in a stand to answer it in positive sense. Better I must avoid conversing with you. I am raising questions based on what that is happening in my Railway System. There is nothing in raising questions to those who are pre-programmed...I met several researchers in my life who are eager and enthusiastic in hearing the same problem and work on the issue. They never count the number of similar questions. Instead they think again and again and work on the same issue and are ready to mitigate the limitations.

I have lot of things to do in my life like research work, studies etc and hence I will be concentrating in them. I have tried to point out some limitations in Open Rails. I won't be away from this forum, but will be stopping my constructive suggestions on the "timetable"..............

Cheers,

Rohit R Krishnan

[roeter]

Quote

It is the person who is writing the matter to get a response.

You have had a response from the 'development team' (for I am actually the 'development team' - on my own) - in post #86. But, apparently, you choose to ignore it.
You may not like the answer, but repeating the question time and time again is not going to change it.

Quote

Hence shunting is very important in time table mode as it resembles the real scenario.

Do you really think this is an 'error' in the program, an 'oversight' by the developer (i.e. me), that I am not aware that shunting (and attaching / detaching) exists in the real world? I have been watching trains split/combine since I was 6 years old, and I have spend more time on trains which consisted of portions with different origins and destinations (which therefor combined and split) than you have had hot meals. If it were that easy to implement, I would have done so. But obviously it is not - and as for the reason it has not been implemented yet, see post #86 again.

Quote

Is there any reason for excluding player train shunting option in time table mode?

Obviously there is, otherwise it would not have been disabled. We're not in the habit of throwing out functions just to pester the users.
As for the why - have some trust in the developers. The reasons usually are very technical and not so easy to explain, often raising more questions than answering any.
But as you insist : here are the reasons.

As first build, the pogram has a class which holds all data and functions for controlling the player train, the Train class. A child class, AITrain, holds data and functions specific for AI trains. At first, the timetable also used the Train and AITrain classes. But as the timetable functions became more elaborate, and started to deviate in an increasing number of aspects from the functionality as implemented for activities, it was decided to split the code for activities and timetables so they could be further developed independently, and create a new class, TTTrain, which holds all data and functions specific to the timetable concept - for both player and AI train. The timetable concept therefor only works with TTTrains. The existing code for combining and splitting trains, however, still works with the Train and AITrain classes. Using this code in timetable mode would therefor compromise the data as it uses the wrong class, and, when splitting, creates the wrong class of train. This would cause problems in other parts of the processing in timetable mode, and it was necessary to disable the function until new code, proper for the timetable mode, can be developed.
But that's not all. In activity mode, when a train is split, the details of the player train will stay with the player.
But in timetable mode, that would not always be correct. Take, for instance, the run-round function. If the player detaches the engines to run round, those engine would still have the path of timings as were set for the train itself. They should, ofcourse, be changed to the path and timings as defined for the runround. But the existing logic cannot handle this - not least because, as detailed above, the existing logic has no access to these details as it can not process the TTTrain class which holds these details.
Furthermore, splitting and combining other than for runround would have to be defined in such a way that AI trains would behave the same as the player would intend to do - so there need to be additional parameters which would define the required actions. All that requires a lot of additional code to process these parameters etc.
The reason none of this exists yet is, again, given in post #86.

Finaly a bit of irony. Even if all these functions would have been implemented, you would not have been able to use them in your timetable. For, as I pointed out earlier, the signalling of your route does not support 'call on' functionality, which is essential to allow trains to attach to one another. But the signalling of your route does not allow a train to pass a signal onto a section allready occupied by another train, and therefor coupling of trains is simply not possible. That is not a program error, but a shortcoming of the signal logic of the route.

This is my last post on this subject - I consider this thread as closed.

Regards,
Rob Roeterdink

[Rohit]

 roeter, on 17 August 2015 - 01:09 PM, said:

You have had a response from the 'development team' (for I am actually the 'development team' - on my own) - in post #86. But, apparently, you choose to ignore it.
You may not like the answer, but repeating the question time and time again is not going to change it.


Do you really think this is an 'error' in the program, an 'oversight' by the developer (i.e. me), that I am not aware that shunting (and attaching / detaching) exists in the real world? I have been watching trains split/combine since I was 6 years old, and I have spend more time on trains which consisted of portions with different origins and destinations (which therefor combined and split) than you have had hot meals. If it were that easy to implement, I would have done so. But obviously it is not - and as for the reason it has not been implemented yet, see post #86 again.


Obviously there is, otherwise it would not have been disabled. We're not in the habit of throwing out functions just to pester the users.
As for the why - have some trust in the developers. The reasons usually are very technical and not so easy to explain, often raising more questions than answering any.
But as you insist : here are the reasons.

As first build, the pogram has a class which holds all data and functions for controlling the player train, the Train class. A child class, AITrain, holds data and functions specific for AI trains. At first, the timetable also used the Train and AITrain classes. But as the timetable functions became more elaborate, and started to deviate in an increasing number of aspects from the functionality as implemented for activities, it was decided to split the code for activities and timetables so they could be further developed independently, and create a new class, TTTrain, which holds all data and functions specific to the timetable concept - for both player and AI train. The timetable concept therefor only works with TTTrains. The existing code for combining and splitting trains, however, still works with the Train and AITrain classes. Using this code in timetable mode would therefor compromise the data as it uses the wrong class, and, when splitting, creates the wrong class of train. This would cause problems in other parts of the processing in timetable mode, and it was necessary to disable the function until new code, proper for the timetable mode, can be developed.
But that's not all. In activity mode, when a train is split, the details of the player train will stay with the player.
But in timetable mode, that would not always be correct. Take, for instance, the run-round function. If the player detaches the engines to run round, those engine would still have the path of timings as were set for the train itself. They should, ofcourse, be changed to the path and timings as defined for the runround. But the existing logic cannot handle this - not least because, as detailed above, the existing logic has no access to these details as it can not process the TTTrain class which holds these details.
Furthermore, splitting and combining other than for runround would have to be defined in such a way that AI trains would behave the same as the player would intend to do - so there need to be additional parameters which would define the required actions. All that requires a lot of additional code to process these parameters etc.
The reason none of this exists yet is, again, given in post #86.

Finaly a bit of irony. Even if all these functions would have been implemented, you would not have been able to use them in your timetable. For, as I pointed out earlier, the signalling of your route does not support 'call on' functionality, which is essential to allow trains to attach to one another. But the signalling of your route does not allow a train to pass a signal onto a section allready occupied by another train, and therefor coupling of trains is simply not possible. That is not a program error, but a shortcoming of the signal logic of the route.

This is my last post on this subject - I consider this thread as closed.

Regards,
Rob Roeterdink

Thanks for your reply. For the past few weeks, I have been spending 70% of my free time for this. Now I think that I would have utilized that for my all time hobby i.e, reading, vedic studies etc. which would be worth. Once again I tell you that questions which I have raised is from a real scenario. I am not selecting each and every sentence of your statements and replying to it because I have no time to spend for it and I am not interested in speaking in that level. Also don't think that you only knows everything and is perfect. But I will thank all the other developers except such self appraised people for making such a wonderful program that I have been using since 2012........I will continue to be a fan and user of Open Rails and will not speak with you except with some eminent senior people associated with this program who have brought me into this forum...

[conductorchris]

Rob, thank you for the work you have put in on this and the technical chops you bring.
Christopher

[B & O GUY]

Can anyone tell me what this message is about? Please give it to me in layman terms as I've not been part of this conversation and on reading the post's I still don't understand. This was a PM to me.

Quote

From
Rohit R Krishnan


Sent 14 August 2015 - 10:01 AM
Dear Developers........

First of all I salute you all for developing such a wonderful software with lots of realistic features. I am using only this software since 2013... I am also happy that my post has now 1800+viewers most of which are same people. If you don't take it seriously, I would like to ask you the following doubts. Please mind that I am not forcing anybody........

1) In the real world, there is no player and AI train, they are all behaving as trains in timetable mode... In the real railway system, a locomotive from shed starts and gets coupled to a train at source station and proceeds to destination. At the destination the locomotive will be decoupled and proceeds to the trip shed. The train will be taken from the destination station by a shunter to pit lines. Hence shunting is very important in time table mode as it resembles the real scenario. Is there any reason for excluding player train shunting option in time table mode?

2) All the features except this are excellent in timetable mode...........

Please take it only as a suggestion... Personally I am happy with timetable mode except this feature...

What does this have to do with me?

Allen

[Rohit]

This was a query made by me regarding timetable mode. I have sent a message unknowingly that you are not a timetable developer. Now the discussion regarding this matter is closed and you are not supposed to reply to this query.