The International Simutrans Forum

 

Author Topic: Schedule features: technical discussion  (Read 17381 times)

0 Members and 2 Guests are viewing this topic.

Offline Ranran

  • Devotee
  • *
  • Posts: 1467
  • Languages: ja
Re: Schedule features: technical discussion
« Reply #140 on: January 04, 2021, 03:15:20 PM »
Thank you for your feeding.

Quote
The logic for this is not written yet, but all the parameters are present. The logic will be that convoys will have to make a range stop every time that the distance to the next stop would exceed the distance specified in the last range parameter since the last range stop or last leaving the depot. For example, if a convoy had a range of 100km, and stops at 40km apart, the first stop after leaving the depot would be 40km from the last range stop or depot visit. The second stop would be 80km away, so the first stop would not need to be a range stop. The third stop, however, would be 140km away from the last depot visit or range stop, so the second stop would need to be a range stop. The third stop would then be 40km from the last range stop; the fourth stop would thus be 80km from the last range stop, so the third stop would not need to be a range stop, and so forth.
Are there parameters as if the station had refueling equipment?


Quote
That is a nice idea. I wonder whether, instead of the green arrow symbol, it might be clearer to join the two lines in a loop after the first and last stops?
I find it difficult to draw. Drawing beyond table cells is tedious. simutrans is difficult to draw beautiful and thick curves. It's easy to draw a rough straight line. Display area problems with station name display, etc.


Quote
I cannot see an example of this in the displays above; but I wonder whether there might be a clearer way of designating a depot than a square; perhaps a square with an oversized triangle on top of it representing a gabled roof to depict a depot building?
The first design was at number one in the second image of reply # 126, but the design has changed as you suggested.



Anyway, due to the 2021 year, the schedule UI has transformed (hentai). (´・ω・`)
Feel the essence of Jarápagos.



A big suggestion for changing the seasoning is to split the layout left and right.
I think this is necessary due to previous visual changes. The schedule list tends to be longer than before, so it's more convenient to have a more comprehensive view.
And the option buttons were crowded due to the large number of options. Group this into a vertical list.

Quote
One thing that might be even better - although not a high priority - is a graphical difference between stops at which only convoys of this line (or only this convoy, if it does not belong to a line) stop and stops at which other lines/lineless convoys stop. This is common on maps of metro networks around the world. One might use a circle with a number to represent a non-interchange stop and a square with a number to represent an interchange stop.
For example, I think it is difficult to write a number in a circle to display a three-digit number. If you try to put a number in a circle, the height of the line will increase. Therefore I propose a distinction as shown in the picture above.
The stop with a white background is the interchange station.

Quote
I am not sure that this is the clearest way of representing this, as this looks as though it is giving general information - I wonder whether a set of diverging arrows with a red cross through it may be more suitable?
This can now be defined as:
Code: [Select]
Obj=symbol
name=IgnoreChoose
But I haven't made a symbol. If the pakset does not have a symbol, the information symbol will be displayed as above.


Quote
If send and receive  are already indicated by the triangle direction and color, the '+' and '-' indicators are probably redundant. They might also be confusing, since '+3' indicates trigger no. 3 rather than 3 triggers.
It was changed like this. It's good to save space.

Quote
(17) discharge payload;
(18) set down only;
(19) pick up only;

(0) flags, as above (32-bit);
I have added these parameters for testing the dialog.


Quote
(7) maximum speed (32-bit).
But unfortunately this couldn't be implemented correctly so I didn't add it.
Therefore the speed limit input is currently dummy.
In my plan, if you set a number there, you will see a speed limit label in the space opposite the distance.


As a new feature,
(1) an electrical mark will be displayed if the line or convoy needs electrification.

(2) If the convoy or line has a convoy with a range limit, the range limit is displayed.
And if you stupidly set a schedule longer than that range limit, the distance display will turn red.
For example, in the image above, you are scolded by the schedule dialog because you are set to travel a distance of 31.1km even though you are using a horse with a 20km limit.
(At the moment it is checking the distance between two points, but this is expected to be improved to check between stations.)


EDIT:
The arrows for wait_for_trigger and broadcast_trigger were in opposite directions. It will be fixed.


EDIT2:
The schedule setting status is not reflected immediately except for the change of minimum load. I'm stuck on how to fix this.

memorandum:
- I thought about removing the entry by abolishing the remove button and putting a garbage button on each entry and clicking it, but it seems difficult to implement.
Placing the button there seemed complicated. The standard has a posbutton in the entry, but this was actually a fake image rather than a button.

- I noticed that there was an issue lying in the current travel distance logic. That is, there is a contradiction between the schedule display and the calculation.
The travel distance is calculated as a straight line distance, that is, the shortest distance. If you set a waypoint in the middle, the total value on the display will not be the shortest value, which is inconsistent with the value calculated by the player in his head.

EDIT2:
It was brushed up.


One problem with discharge is the combination with mirror schedule. For example, if you want to limit the speed to the next station, the mirror schedule will work correctly by referring to the speed limit of the previous station. But what about discharge?
This also makes it difficult to get the correct behavior that freddy said above. It is probably not recommended to use the mirror schedule in that case.


Ambition, I wonder if we can make something like this. This will give you a more modern game look.
« Last Edit: January 06, 2021, 07:55:38 AM by Ranran »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20713
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #141 on: April 02, 2021, 01:19:11 PM »
My apologies for not having replied to this for a while: this is a rather large topic, and I have been preoccupied with other things of late; since I am still working from home, I have been preferring to spend my evenings doing something other than working on a computer in order to have some variety, so have been focussing on my model railway of late. This is still a worthwhile project, however, so I hope that you will forgive the delayed response.

Thank you for your feeding.

Are there parameters as if the station had refueling equipment?

I do not think that any requirement for stations to have refuelling equipment has yet been encoded. I am not sure how significant that this would be in economic simulation; what would it have cost in reality to have a pile of coal at a station? Also, nearly every airport has refuelling facilities, so it would make little sense to have the ability to build an airport in game without this. It would require significant extra balancing and possibly significant extra work in producing graphics. However, if we decide that this is important in the future, it should in principle not be hard to add this.

Quote
I find it difficult to draw. Drawing beyond table cells is tedious. simutrans is difficult to draw beautiful and thick curves. It's easy to draw a rough straight line. Display area problems with station name display, etc.

That is understandable; do not worry if this is too hard to implement.

Quote
The first design was at number one in the second image of reply # 126, but the design has changed as you suggested.

Excellent, thank you.

Quote
Anyway, due to the 2021 year, the schedule UI has transformed (hentai). (´・ω・`)
Feel the essence of Jarápagos.



A big suggestion for changing the seasoning is to split the layout left and right.
I think this is necessary due to previous visual changes. The schedule list tends to be longer than before, so it's more convenient to have a more comprehensive view.

And the option buttons were crowded due to the large number of options. Group this into a vertical list.

That does look good, and makes it nice and easy to understand. Excellent!

Quote
For example, I think it is difficult to write a number in a circle to display a three-digit number. If you try to put a number in a circle, the height of the line will increase. Therefore I propose a distinction as shown in the picture above.

The stop with a white background is the interchange station.

Yes, I can see the advantage of doing it that way. That does look good.

Quote
This can now be defined as:
Code: [Select]
Obj=symbol
name=IgnoreChoose
But I haven't made a symbol. If the pakset does not have a symbol, the information symbol will be displayed as above.

Thank you for clarifying - we should probably have a custom symbol at some point, since the "i" symbol is potentially confusing in this context, but it is a reasonable fallback where we do not have a symbol defined.

Quote
It was changed like this. It's good to save space.

Excellent, thank you.

Quote
I have added these parameters for testing the dialog.

But unfortunately this couldn't be implemented correctly so I didn't add it.
Therefore the speed limit input is currently dummy.

In my plan, if you set a number there, you will see a speed limit label in the space opposite the distance.

May I ask what problem that you had with implementing this?

Quote
As a new feature,
(1) an electrical mark will be displayed if the line or convoy needs electrification.

This is very useful indeed!

Quote
(2) If the convoy or line has a convoy with a range limit, the range limit is displayed.
And if you stupidly set a schedule longer than that range limit, the distance display will turn red.
For example, in the image above, you are scolded by the schedule dialog because you are set to travel a distance of 31.1km even though you are using a horse with a 20km limit.
(At the moment it is checking the distance between two points, but this is expected to be improved to check between stations.)

This is also very useful and will make players' lives much easier - thank you.

Quote
EDIT:
The arrows for wait_for_trigger and broadcast_trigger were in opposite directions. It will be fixed.


EDIT2:
The schedule setting status is not reflected immediately except for the change of minimum load. I'm stuck on how to fix this.

Do you mean that the underlying data does not update until the dialogue box is closed?

Quote
memorandum:
- I thought about removing the entry by abolishing the remove button and putting a garbage button on each entry and clicking it, but it seems difficult to implement.
Placing the button there seemed complicated. The standard has a posbutton in the entry, but this was actually a fake image rather than a button.

This would be a nice feature to have, but do not worry if this is too much work.

Quote
- I noticed that there was an issue lying in the current travel distance logic. That is, there is a contradiction between the schedule display and the calculation.
The travel distance is calculated as a straight line distance, that is, the shortest distance. If you set a waypoint in the middle, the total value on the display will not be the shortest value, which is inconsistent with the value calculated by the player in his head.

Can I clarify - is this an error in your code or in the code already existing in Simutrans-Extended?

Quote
EDIT2:
It was brushed up.


Interesting! That looks splendid. May I ask what the orange highlighting on the line represents?

Quote

One problem with discharge is the combination with mirror schedule. For example, if you want to limit the speed to the next station, the mirror schedule will work correctly by referring to the speed limit of the previous station. But what about discharge?
This also makes it difficult to get the correct behavior that freddy said above. It is probably not recommended to use the mirror schedule in that case.

This is an interesting thought. I wonder whether mirror schedule ought to work in a special way in conjunction with discharge and do the opposite thing if the convoy is in its reverse direction?

Quote
Ambition, I wonder if we can make something like this. This will give you a more modern game look.


Interesting - is this intended for the display when adding items to a schedule or viewing a schedule? If so, that would be very useful indeed.

Offline Vladki

  • Devotee
  • *
  • Posts: 3705
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Schedule features: technical discussion
« Reply #142 on: April 02, 2021, 03:44:50 PM »
Quote
I do not think that any requirement for stations to have refuelling equipment has yet been encoded. I am not sure how significant that this would be in economic simulation; what would it have cost in reality to have a pile of coal at a station?

A pile of coal is indeed not a big deal. But a water tower is. Also a gas/petrol station is definitely not on every bus stop. Compare refueling facilities to the cheapest stop, not to a big station. Airports without refueling exist in remote places, where the only way to bring fuel is by plane.

Offline Freahk

  • Devotee
  • *
  • Posts: 1435
  • Languages: DE, EN
Re: Schedule features: technical discussion
« Reply #143 on: April 02, 2021, 04:52:30 PM »
I do not think that any requirement for stations to have refuelling equipment has yet been encoded. I am not sure how significant that this would be in economic simulation; what would it have cost in reality to have a pile of coal at a station?

In the real-world it's not as simple as piling up some coal at the station.
You need special infrastructure to load the coal as swell as infrastructure to refuel water.
The same goes for Diesel, Hydrogen or any other kind of fuel. Even for electricity in case of battery vehicles.

I like the very last image. It really gives a more modern look at the map.
I'd really love to see the route itself to be painted on the map. I am aware that this route might depend on the actual vehicle on the line, so we could use the very first vehicle of the line to calculate the route and a dummy when there is no vehicle assigned yet.


As this thread is all about schedules, I'd like to throw in a consieration about timed schedules aka timetables:
In the real-world, routes are scheduled with a fixed waiting time in stations and a fixed journey time between these.
The scheduled time should usually be longer than the time it actually takes to wait at a station or to travel in between stations at full speed.
Once the scheduled time is shorter, we have a delay, in which case the train might exceed the scheduled speed or spend les time in a station time to catch up.
In simutrans, we cannot handle delays at all. Either we don't schedule a stop at all (depart when ready) or we schedule it to depart at a fixed time, in which case we will wait for the next time slot as soon as we are delayed by only a second.

I don't want to "request" a feature to handle delays here, but the above discussed scheduling concept should at least keep this in mind.
An "is delayed" condition to allow for exceeding the scheduled maximum speed, as well as an attribute to allow for delayed departures should be enough in most cases.
Optionally, a field to enter a maximum delay at which a train may still depart.
In that case, we'll also have to consider what to do when a train is much too late (more delay than the maximum delay).
Currently, maximum delay is 0 and trains exceeding that delay will simply wait for the next schedule slot.
« Last Edit: April 02, 2021, 05:08:06 PM by Freahk »

Offline Matthew

  • *
  • Posts: 547
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Schedule features: technical discussion
« Reply #144 on: April 03, 2021, 12:32:55 PM »
As this thread is all about schedules, I'd like to throw in a consieration about timed schedules aka timetables:
In the real-world, routes are scheduled with a fixed waiting time in stations and a fixed journey time between these.
The scheduled time should usually be longer than the time it actually takes to wait at a station or to travel in between stations at full speed.
Once the scheduled time is shorter, we have a delay, in which case the train might exceed the scheduled speed or spend les time in a station time to catch up.
In simutrans, we cannot handle delays at all. Either we don't schedule a stop at all (depart when ready) or we schedule it to depart at a fixed time, in which case we will wait for the next time slot as soon as we are delayed by only a second.

I don't want to "request" a feature to handle delays here, but the above discussed scheduling concept should at least keep this in mind.
An "is delayed" condition to allow for exceeding the scheduled maximum speed, as well as an attribute to allow for delayed departures should be enough in most cases.
Optionally, a field to enter a maximum delay at which a train may still depart.
In that case, we'll also have to consider what to do when a train is much too late (more delay than the maximum delay).
Currently, maximum delay is 0 and trains exceeding that delay will simply wait for the next schedule slot.

Perhaps worth mentioning that OTRP has already implemented this feature.