News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Higher minimum load for wait times

Started by Bear789, November 25, 2012, 11:25:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bear789

The title is a little bit confusing but I didn't know how to phrase it better.

The newer versions of the game have a time wait setting for lines, combined with minimum load settings. I use it to simulate simple schedules by putting the min load to 100%. The problem is, if the line is serving a very busy stop, the vehicle may reach the 100% load way before the wait time is expired, thus screwing up all my planned schedule.

My suggestion is to either separate the waiting from the load or to raise the highest minimum load to 101% (or whatever impossible load works better), to make sure that, if the player chooses so, the vehicle will only obey the waiting time setting.
In the second case, I can imagine that's easy to mistakenly set the load to 101% even if you're not interested in time wait, so it may be sensible to add a warning, or even better to let players set the load above 100% only if they already set a wait time.

Fabio

Very interesting and cunning idea.

101% should be selectable only if waiting time is set as well.
Maybe instead of showing this number it might display a short string of text.

Waiting time is an interesting option, but the 1/n month is not so user-friendly, I wonder how could it be improved.

Dwachs

Why do you want a full train to wait even longer ?
Parsley, sage, rosemary, and maggikraut.

Bear789

#3
Quote from: Fabio on November 25, 2012, 11:46:59 AM
Waiting time is an interesting option, but the 1/n month is not so user-friendly, I wonder how could it be improved.

Yeah, currently it works with trial and error. I have no idea on how to change it, however.

Quote from: Dwachs on November 25, 2012, 12:40:50 PM
Why do you want a full train to wait even longer ?

It's good for all kind of vechicles, not only trains, except maybe naval transport since any number of ships can occupy the same tile.
A few reason:

- It helps with spacing and avoids vehicle in a line to pile up one behind the other, which can lead to empty vehicles (thus lower profit).
- You can optimize your infrastructures, both stops (which is important for all form of transport) and ways, especially with trains. In a test game I menaged to have three rail lines running smoothly on a system with a single track common section just by careful planning of the departure times. Without that i'd have to at least double track the common part, wasting money, or risk a gridlock that can happen randomly because if you have the game running long enough you can't predict when all the trains are going to cross that section. For stops and stations,  you have a rough idea of the time when a vehicle is calling there, you can choose the right amount of bays/platforms to keep the whole system running smoothly without the need of cyclopic, dozen-track stations that are full only half of the time. You can already do this, but if the stations are too busy it's all thrown out of the window because the vehicles won't obey their waiting times.
- I know that most people consider this an invalid argument, but it's more realistic: in real life bus and trains don't leave a stop whenever they feel like.

Besides, the feature is already there, I'm only asking to tweak it a little.

jamespetts

This feature, or at least something very much like it, is already present in Experimental: see here.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: Bear789 on November 25, 2012, 01:07:32 PM
- I know that most people consider this an invalid argument, but it's more realistic: in real life bus and trains don't leave a stop whenever they feel like.

Real buses don't spend better part of a month going round a inner city route of ten stops either. The temporal aspects of Simutrans, and all similar games I know about, is fully artificial. For realistic timing, the game would either have to slow down to near real time, or have things speed along by at tremendous speeds.

But is it so unlikely for a fully loaded bus to just drive off? Waiting serves no purpose, beyond holding up the stop.

jamespetts

Quote from: Ters on November 25, 2012, 02:12:51 PM
Real buses don't spend better part of a month going round a inner city route of ten stops either. The temporal aspects of Simutrans, and all similar games I know about, is fully artificial. For realistic timing, the game would either have to slow down to near real time, or have things speed along by at tremendous speeds.

We solve this in Experimental by having two distinct time scales: one for travelling and waiting times, measured in hours, minutes and seconds, and one for monthly cost items, technological progress, etc., measured in months and years. The two have a fixed relationship to each other (depending on the settings, often something like 3 hours per month).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bear789

Quote from: jamespetts on November 25, 2012, 01:25:20 PM
This feature, or at least something very much like it, is already present in Experimental: see here.

Interesting! I should check Experimental more often.

Quote from: Ters on November 25, 2012, 02:12:51 PM
Real buses don't spend better part of a month going round a inner city route of ten stops either. The temporal aspects of Simutrans, and all similar games I know about, is fully artificial. For realistic timing, the game would either have to slow down to near real time, or have things speed along by at tremendous speeds.

Well, there are a lot of options between 100% realistic timetable and totally unpredictable schedule.

Quote from: Ters on November 25, 2012, 02:12:51 PMBut is it so unlikely for a fully loaded bus to just drive off? Waiting serves no purpose, beyond holding up the stop.

I can't generalize, but in all the countries I visited, while the stops in the middle of a trip are usually stop and go, no bus leaves the line's terminals before the time no matter how full they are. Sometimes that applies to important interchange stops too.
However, as I said, I know that most people consider realism an invalid argument. There are gameplay reason too.

Ters

I don't like it when all buses on a line end up bunched together, but having them wait on stops will just interfere with other vehicles. I'd also like a solution that doesn't require manual set-up by me, as I find setting up bus lines boring as it is.

prissi

The enforced waiting will not help you when for instance ships have piled up behind a elevated bridges in pak128 or busses at a red crossing at an intersection. That would rather require the minimum spacing intervall of experimental.

An not matter how you turn it: Having full vehicles waiting for nothing will not gain on the money side at all. In the contrary, with ships it might easily result in passengers not created due to an overflowing harbour.

tjoeker

I don't understand why you are so against this idea?
if he wants to use this feature, than he may use this feature...
I mean, the coding part isn't that big (I guess, it's only changing the 100% max. to 101% max.).
if you don't want to use this, than you don't use it, just ignore this feature.
it won't change the entire game, isn't it?
after all, he is just asking for more realism...  ;)

I think you shouldn't discuss about implementing this feature, but about how it should be done.
like: should it be done the way he said (101%) or can we use a tick box 'allways wait'
...

prissi

As coder (who in the end has to implement and maintain and explain it) I am somehow concerned whether starting to work on it or not.

But that aside: It is very easy to add features that almost nobody knows and use, which the often result in bugs long hidden (most famous example was Microsoft Word). In the end it makes the program a less enjoyable experience. Insofar a discussion whether to include a feature or not is quite valid.

Especially the waiting time issue will solve nothing: If the convoys bunch up, they will still bunch after the stop. Or they were not fully loaded, in this case they will wait for full load and thus resolve their bunching. Just see the old discussion about line spacing.

Moreover the feature is included with experimental in a better way for real scheduling (i.e. spacing of same vehicles on a line).

Moreover, in patches you find the timetable patch, which is the ultimate approach on scheduling.

Ters

Quote from: tjoeker on November 25, 2012, 09:19:25 PM
I don't understand why you are so against this idea?
if he wants to use this feature, than he may use this feature...
I mean, the coding part isn't that big (I guess, it's only changing the 100% max. to 101% max.).
if you don't want to use this, than you don't use it, just ignore this feature.
it won't change the entire game, isn't it?

Every feature adds to the complexity. It must be coded, tested and supported. It's not worth it if just one, two or ten players want it, especially if it confuses two, four or twenty others.

I've heard a rule (from some non-Simutrans place) that every new feature starts with -100 points. Only once it has reached 0 can it start competing with other features for development time.

tjoeker

I don't know c++, or any other language written in C, but I know how java works.
so sorry if I make any mistake in my statements...

'every feature adds to the complexity' => in this case, I think this statement is wrong. sure, there are lots of impossible featurerequests out there, but this oine is just changing the 100% load to 100%+1 or 101%, remove the variable that sais you need a minimum load for a waiting time or any different small addition. it wouldn't change anything in the code (if the code is written well, and I believe it is ;-) ).

on the other hand, it won't change the gameplay. ok, it doesn't give anything really helpfull*, but as I stated earlier: it gives more realism to the game. (and the TS says he can do something usefull with it, even though, it is complicated).
if you explain this feature right, it wouldn't create any problems for the users. example: the convoi will allways wait this amount of time at the station.
and as I stated before: I you don't like it, don't use it ;)

'it must be coded' => yes, few lines have to be rewritten/added/removed... I don't believe the entire code is written so this small feature is IMPOSSIBLE.
'it must be tested' => yeah, this small feature will take hours to test, isn't it? just a few seconds, and you will see wether it works or not. the only thing that should be tested is that the vehicle would leave after the assigned time. I you are able to write the new peace of code so that it wil interupt with any other part of the game, you must be a genius ^^
'it must be supported' => I don't understand what you mean with this, I think you are saying the same as it must be coded, or their should be need for it. But that takes us to the next statement.

you say their should be audience for it first? I am  a big fan of the Rollercoaster Tycoon, a game orriginaly meant for managing your themepark.
Invented by Chris Sawyers, but destroyed by iratA. (Atari for those who don't know what happened in our RCT-community). like I said it was meant for management, but the fans took it to an entire other meaning: designing themeparks, not managing them.
I know that the mainstream of the simutrans community goes for the managing part, but there are also a lot of people making travel-videos for youtube, sharing it on forums, ... lots of members who want, need eyecandy,... just give them this small realims adition, and make them happy...

don't feel attacked personnally, just saying I got this feeling this community doesn't want to 'expand' their game, doesn't want to take it to another level. maybe I am wrong, and sure you guys allready made some beautifull improvements, but these small features make it complete. I would love to see airports with planes really staying a wile at the gate. have ports with waiting ships, stations with waiting trains.
(yes I know expiremental simulates loading times, but it isn't the same. planes aren't waiting for the bagage, oil, they just leave with the passengers)

once again, I don't know anything about C languages. and maybe even less about where you guys want to go with this game...
maybe I should just shut up about this :p
but thanks for reading anyway, and for reading my thoughts about improvement for this game. ;)

Fabio

I'm not in the dev team, but I've been in the community long enough to draft an answer.

Is it possible? Sure it is, nobody said it's impossible.

Is it desirable? This is questionable. Personally I don't see anything wrong with it, it might be interesting.

Does it break anything? Possibly. As said, if set to 101% (by mistake) without waiting time it could ruin a game, if 101% is allowed only with waiting time additional checks are needed.

Testing: sure, you test if it works. But it could break less obvious parts of the code, so it's delicate enough.

Is it cost (devs' time) effective? Only devs can answer.

Bottom line, can it cause unwanted results?

prissi

Quoteevery feature adds to the complexity

I should have added: complexity to a beginning user. Simutrans is most often put away because it still has a steep learning curve. The problem is the balance between too much features overwhelming new users (or more neutral said increase the chances of mistakes) and the expertes who want more features.

However, for the current feature I rather see a line spacing option for your desired effect and not a full waiting time. Just think of buses at a harbour or airport: Even with this setting they would all leave at the same time, when once bunched up (because emptier buses accelerate faster).

isidoro

@Bear789: a poor man's solution can be (in the case of trains) to make the station a bit shorter than the convoy and put a maximum load of 100%.  Since the convoy is longer, it will never reach full load...

Fabio

Another solution for busses would be to put the line terminus on a stop not enabled for pax... (e.g. Ware or mail only)... It won't ever load there!  Then, after 1 or 2 tiles, the real stop. ;)

sdog

Another sollution, wich give you actual timetables is using a trafic light.

At the end of your bus line, put a waypoint and a large enough assembley area. Put a crossing with a trafic light on it, set the red time to the fixed schedule you want, set the green phase to a time short enough only one bus can pass. Now you can stage your buses behind the trafic light and let it controll the fixed timetable your vehicles start.

While i like the timetable features in experimental quite a lot, i don't see the use of the requested extension. Without a fixed timetable behind it, it doesn't really solve anything.
While it is very easy to code, it is not so to document and explain well enogh. Things like the 101% setting easily cause frustration.

Ters

Interestingly, I find these unintentional solutions more intuitive (and less misidentifiable as a bug) than the proposed solution of 101 %.

colonyan

Um... There sure are few interesting solutions...

Fabio

Back on the extension request, I add one consideration.
Now you can select wait time only if you selected a wait load as well.

They could be independent, instead.
If you select only wait load it will wait indefinitely until loaded.
If you select only wait time it will wait for that scheduled time regardless of load status.
If you select both, the sooner between scheduled time and being loaded.

IMHO this solution would be very intuitive.

Ters

That's probably the best solution in terms of UI. At least so far.

prissi

One would just need to reset these settings when adding a stop.

Bear789

Sorry if I didn't answer, it's been a busy week.
My whole point was to make vehicles obey waiting time, the 101% was just a tweak that I thought was easier to program than to make the two settings indipendent; it seems that I got it wrong.

I support Fabio's version.