News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Simutrans Experimental [Original thread]

Started by jamespetts, January 21, 2009, 12:20:03 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

jamespetts

Z9999,

you say that the result was the same - same as what? Can you describe the problem in more detail, and, in particular, when it occurs? Are you referring to the crash when you run the game, or the zip file not unzipping properly?
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.

Dwachs

#106
as you may have noticed, in current trunk there is a feature by prissi that goods wont get routed through overcrowded stations.

Edit: I just checked your git-page. You regularly merge trunk commits in your experimental branch :)  :award:
Parsley, sage, rosemary, and maggikraut.

jamespetts

#107
I thought that I'd post here a preview of some features on which I have been working for Simutrans-Experimental. The source code for them is currently available on Git (link in the original post), but I have not yet compiled a binary as these new features need a compatible pakset for testing purposes, so users would not notice a great deal of difference.

I am currently working on a version of PakBritain, called PakBritain-Experimental, to go with Simutrans-Experimental, which will be available when I have set up enough parameters for it to be in a worthwhile state for testing. For the time being, I still encourage testing of the existing binary linked on the original page.

Reversing

The first new feature is a more sophisticated system of reversing. It is useful mostly for railway vehicles. In essence, it simulates both graphically and in simulation terms the fact that, for many trains, the locomotive needs to run around to the other end of the train, but the whole train does not turn around in the way that, for example, a road vehicle does: it just goes the other way. Likewise, some trains do not have locomotives running around at all, but can drive from both ends.

The attached screenshots show two examples. The first two are of a double headed train reaching the buffer stops and turning around: notice how the locomotives both change ends, but the carriages stay in the same order, just as in reality. The program detects that the train is double headed and acts accordingly. Similarly with steam locomotives with tenders.

The third is of an "autocoach" attached to a steam locomotive: common in rural branch-lines in the UK in the 1920s-1950s. The train can be driven either in the normal way from the locomotive at the front, or from the special cab at the rear of the train. For that reason, the locomotive does not have to uncouple and turn around at the end, and the train reverses without changing formation or direction at all. The picture shows the train travelling in reverse.

In simulation terms, whether trains have to reverse affects how long it takes them to turn around. A train, such as the autocoach example in the screen shot, that can be driven from either end can turn around very quickly. A train, as in the top example, that has a locomotive at one end and that needs to be run around to the other end before reversing turns around more slowly. A train with a steam locomotive with a tender that not only needs its locomotive to change ends, but the locomotive to turn on a turntable will turn around more slowly still.

This will make the game more fun by giving players more interesting choices, as well as by making it look more real: if players want to make their network more efficient, they will have to choose appropriate sorts of trains for the job: trains that can turn around quickly for suburban traffic, and trains with powerful locomotives for long-distance traffic (which may be more slow to turn around). As technology develops, more trains will be able to turn around more quickly. Other interesting decisions include weighing up the advantages and disadvantages of tank and tender engines (tank engines of the same power are heavier, since they cannot spread the weight into a tender, and therefore require tracks and bridges capable of higher weights, but tender engines need to use a turntable); and also the economics of long-distance multiple units: they can turn around more quickly, but, because each individual vehicle has an engine, they are less comfortable and cost more to run than locomotive hauled trains (a good middle ground is a locomotive hauled train with a driving cab at the rear - but those are not available in every era, and can be more expensive to buy).

I hope that this will add enjoyment to people's games. I should be very interested in anyone's comments.

Edit: I thought that I should add some techincal information about this feature for pakset creators.

Technical information

This feature (when used with a compatible version of Makeobj - source code available on the Simutrans-Experimental Git repository; binary not yet available, for the same reasons as above) uses two additional parameters in the .dat file:

1. can_lead_from_rear; and
2. bidirectional.

They are both boolean flags, which means that if the value is set to "0", they are considered to be false, or anything other than "0" they are considered to be true. Convention is to use "1" to denote true.

The first denotes a vehicle that, if it is at the back of a convoy, will let the convoy reverse without turning around, and go exactly backwards. This is useful for railway multiple units, or arrangements such as the autocoach pictured. In the autocoach example, only the autocoach itself need have the "can_lead_from_rear" flag set. This setting is only relevant for the rear vehicle in a convoy: it is ignored for the other vehicles. If the rear vehicle has this flag set, the fastest reverse turnaround is used.

The second denotes a vehicle that can travel in either direction without turning around. For example, an ordinary railway carriage or truck is bidirectional. A horse is not (horses cannot travel any distance walking backwards). A diesel locomotive with a cab at each end is bidrectional. A steam locomotive with a tender is not. A tank engine will usually be bidirectional, unless the tank engine is designed such as to make running in reverse impractical. (I know that tender engines do run in reverse on preserved railways, but that is far from ideal, and they cannot do that safely at anything other than the low speeds at which they operate on preserved railways). If the lead powered vehicles are bidirectional, the train will turn around more quickly than if they are not. Only bidirectional vehicles will keep their orientation when the convoy is reversing. Also, in the latest version of the code, if there is only one vehicle in the convoy, and that is bidirectional, the fastest reversing time will apply.

The whole reversing system is disapplied entirely to road and air vehicles (and kept for water-craft only because canal narrow boats might be bidirectional). The default values for both settings are false. In that state, the vehicles behave as they do in default Simutrans, with the exception of the turnaround time, which is the highest of the three, as it assumes a convoy that needs to reverse in the slowest way.

However, the delay is set from values in simuconf.tab. In the most recent version of the code, those default to 0. Thus, without a custom pakset and custom values set in simuconf.tab, the game behaves exactly in the same way as standard Simutrans: only a specially configured pakset will enable the features. Below is an extract from the simuconf.tab file that I have been using, along with full documentation of the settings, to show what can be customised:


# These settings determine how long that it takes a train-type vehicle to turn
# around when it reaches the end of the line. They do not apply to road vehicles
# or aircraft.
#
# "unit_reverse_time" refers to trains/convoys, such as multiple units, that have
# a cab at each and, and can be driven in reverse without any re-arrangement of
# the order of the vehicles. These will generally take the least time to reverse.
#
# "hauled_reverse_time" refers to trains/convoys that cannot be driven from the
# rear, so the locomotive at the front has to run around the train and attach
# to the rear, but where that locomotive can itself be driven in either direction,
# so that it does not need to turn around.
#
# "turntable_reverse_time" refers to trains/convoys that, as for the above category,
# cannot be driven from the rear, but that also require their locomotive to be turned
# around to face the other direction (such as steam locomotives with tenders) at the
# end of the journey. These will genearlly take the most time to reverse.
#
# All times are in milliseconds (1000 = 1 sec), assuming that the game is set to the
# normal speed.

unit_reverse_time=1500
hauled_reverse_time=2500
turntable_reverse_time=4000
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.

The Hood

Interesting idea.  (Still not 100% sure what it all means in practice but one day I'll have a play with it and find out!).  Have fun (?!) finding appropriate settings for all of these for PakBritain-experimental though!

Oh, and what about trams?  Presumably they would have this feature enabled?   And for bidirectional vehicles that aren't symmetric (e.g. a tank engine) would they run cab first rather than boiler first when in "reverse" mode?

jamespetts

The Hood,

yes, indeed, trams need to be set to "bidirectional", too. To answer your question about tank engines, see the attached screenshots...
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.

kierongreen


jamespetts

Just wait until I tell you about upgrading, comfort ratings and variable dwell times!
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.

gauthier

A small question : are undeground slopes included in ST experimental ?

If yes, please tell me where download it :D

The Hood

Excellent!  All you need to do now is make it so that tender locos actually detach and then proceed to a new turntable feature and run round...  :P

Fabio


jamespetts

Gauthier,

underground mode and slopes are not presently included in Simutrans-Experimental, although, if they have not made the trunk by the time that I finish the new revenue model, they will be.

The Hood,

if you'd like to learn C++ and code that, I'll add it to Simutrans-Experimental ;-)

Fabio,

thank you :-)

Upgrading

Another new feature that will be in the next version of Simutrans-Experimental is upgrading. The concept is very simple: instead of selling an old vehicle and buying a new one to replace it, one can upgrade (or refurbish or rebuild, or however one would prefer to describe it) old vehicles into better ones. Certain types of vehicle are marked as upgrades to other types, and, by using the special "upgrade" mode in either the depot window (or Isidoro's replace window), one can see which vehicles to which one can upgrade the present vehicles in a convoy. The price of upgrading can be different (usually lower) than the price of buying that sort of vehicle new. Additionally, some sorts of vehicles can only be bought as upgrades to existing types, not from new (these are shown as light purple in the depot window when "show all" is selected).

When there is a convoy selected in upgrade mode and one buys a vehicle that is an upgrade to one of the existing vehicles in the convoy, one of the suitable vehicles in the convoy is automatically replaced with the upgraded vehicle, without having to reassemble the convoy. One can keep buying upgrades until there are no more of the pre-upgraded vehicles left in the convoy. In upgrading mode, when one buys an upgrade, only the upgrade price will be shown and charged. Dark purple in upgrade mode indicates vehicles to which no vehicles in the present convoy can be upgraded. The screenshots below give an example of upgrading in progress using different types of BR Mk 1 carriage from PakBritain.

A similar system works with Isidoro's replacing system, except that whether a vehicle is upgraded from an existing vehicle or bought new is determined automatically when the convoy gets to the depot: the cheapest option will always be chosen. Also, unlike the original version of Isidoro's replacing patch, the new code will automatically re-use existing vehicles in the convoy when the upgraded type of the convoy contains the same sort of vehicles, rather than always selling the existing vehicles and buying the new ones. That means that the replacing tool can now be used to re-arrange whole sets of convoys for free.

Using upgrades, players will be able to manage their vehicle fleets in more cost-efficient ways, as well as have more interesting decisions about the merits of upgrading existing vehicles, leaving existing vehicles as they are, or purchasing new vehicles.

Technical details

To make a pakset work with this feature, there are three different possible additional settings in the vehicle's .dat file:

1. upgrade_price;

2. available_only_as_upgrade; and

3. upgrade[X] (where "X" stands for the name of a vehicle).

"upgrade_price" is the cost of the current vehicle when it is bought as an upgrade, rather than when it is bought new, expressed in 1/100ths of a Simucredit (in the same way as "cost". The default value is whatever has been set as the normal purchase price. "available_only_as_upgrade" can either be true (1) or false (0). The default value is false. When this is set to true, the vehicle cannot be purchased except by upgrading another vehicle to it. upgrade[X] (where "X" stands for the name of a vehicle) is the list of vehicles to which the current vehicle may be upgraded. Note: as with the coupling constraint values, the vehicles to which it refers must be in the same .pak file for this to work. The vehicle's name (exactly as it appears in the upgraded vehicle's name filed in the .dat file - not the translated version) is used as an identifier.

Here is an example:


cost=583000
upgrade_price=70000
...
available_only_as_upgrade=0
upgrade[0]=BR-Mk1-TO(Blue-Grey)


Loading time

Another feature in the next version of Simutrans-Experimental will be variable loading time (sometimes called "dwell time"). Currently, all load and unload operations for all kinds of vehicles take 2,000 ticks (that is: 2 seconds at default speed). In reality, different kinds of vehicles can be loaded and unloaded faster than others. For example, an old-fashioned coal truck has to be emptied by hand, whereas a modern hopper can be emptied by tipping all the coal into a bunker underneath the tracks, and can be emptied without even stopping the train. Express passenger trains tend to have small doors only at the ends of the carriages, whereas commuter trains have large doors all along the sides of the carriages: commuter trains can therefore load and unload passengers more quickly. Buses tend to load and unload faster than trains, and aircraft and ships take far longer to load and unload than buses or trains.

Different vehicles can now have different loading times. When buying a new vehicle (or upgrading an existing one), one will be able to see the loading time value in the depot window. Players will then be able to choose between faster, cheaper and/or more comfortable vehicles with longer loading times, or slower/more expensive and/or less comfortable vehicles with shorter loading times. (Comfort is a part of the new revenue system, still under development). Generally, shorter loading times are needed for shorter journeys. With this feature, players will have to match the type of vehicles used more accurately to the type of route than they do at present: no longer will it be economical to use express trains on local stopping services, or vice versa.

Technical details

Loading time is always expressed in ticks. 1 tick represents 1 millisecond (that is, 1/1000th of a second) at the default speed of 1.0. To specify a loading time in a vehicle's .dat file, add the parameter "loading_time" and the number in ticks, for example,


loading_time=2500


The default is 2,000: the same as is used in Simutrans standard. The loading time of a convoy will be the loading time of the slowest vehicle in it.
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.

z9999

One question.
In current simutrans, passenger always ride in order, from the first car.
If loading time of first car is 2000 and loading time of second car is 10000, passenger will ride on second car after 2000 ticks even if first car is empty ?

The Hood

Wow, both of those look like good additions for advanced gameplay.  I see one problem though - now my to-do list has just got longer (again!) :(.  I think there are lots of possibilities for using the upgrade in PakBritain Experimental, upgraded/refurbished vehicles could have more recent liveries, or there are plenty of things where there are big changes (thinking e.g SR Merchant Navy, LMS Duchess, LNER P2, LNER A1/A3 etc.).  Unfortunately I think this will have to wait til after Standard pakBritain is much more complete though...

jamespetts

#118
Z9999,

as stated in the section on techincal details, the loading time of the whole convoy is the loading time of the slowest loading vehicle in that convoy.

The Hood,

ahh, sorry about the to do list... ;-) At least refurbished vehicles can be drawn in many cases by making small changes to existing ones  (rebuilt Bulleid pacifics, for instance, can use the same model as the Britania, but with the rondel style nameplates instead of the nameplates on the smoke deflectors), and some existing vehicles can be used as upgrades without any re-drawing (which I can do; likewise with the loading times, etc.).
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.

The Hood

Quote from: jamespetts on March 12, 2009, 11:41:06 AM
The Hood,

ahh, sorry about the to do list... ;-) At least refurbished vehicles can be drawn in many cases by making small changes to existing ones  (rebuilt Bulleid pacifics, for instance, can use the same model as the Britania, but with the rondel style nameplates instead of the nameplates on the smoke deflectors), and some existing vehicles can be used as upgrades without any re-drawing (which I can do; likewise with the loading times, etc.).

I suggest that for your version of PakBritain-Experimental, you use a copy of existing graphics (actually a copy rather than linking to same png file) so that when I (or anyone else for that matter) gets the time to alter the graphics, then I only need to update a png file and none of the dat stuff.  BTW where are you planning on hosting pakBritain-experimental sources?

z9999

Thank you. Then, it will accept loading during loading time, it's good.
Before, msp wrote a similar patch, but it didn't load during waiting time.  :(
http://forum.simutrans.com/index.php?topic=882.0

jamespetts

Z9999,

MSP's patch is different in function: this is just about the time that it takes to load, not extra waiting time.

The Hood,

point taken about copying graphics. I was planning to host the sources on Github, if I could get it to work - I tried to create a repository recently, but it would not work properly. I will try again in due course. If that fails, I shall have to consider other options.
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.

The Hood

It would probably be a good idea to have it on sourceforge with the other sources eventually, but maybe leave that until simutrans-experimental is more established and pakBritain is more complete too.

In the fullness of time could you send me a list of all of the vehicles you want upgrade graphics for (I have my own ideas, but if you are writing dats for these anyway, I will try and provide some graphics.  this will be a long way off though!)

Fabio

the lading time should also depend on the amount of goods loaded: the more the longer (with a factor depending on the vehicle's specifics

jamespetts

The Hood,

don't worry - it'll take me a while to get around to dealing with upgrades, too - my priority at present is the revenue system, and that is likely to be quite a big job. The reason why I chose Github is that that is where the source code for Simutrans-Experimental itself is located, and it is also better at concurrent working and branching than SVN. What would be the advantage of using SVN on Sourceforge?

Fabio,

that is an interesting point, and should be reasonably easy to implement. The hardest bit would be calibrating it: currently, all vehicles load at 2,000 ticks. Would the time specified in the .dat file be a maximum, minimum or average time? And should we start from the premise that the current standard of 2,000 ticks (which would be used for all vehicles that do not have anything specified in the .dat file) is the maximum, minimum or average? How much should it be varied? Should it scale in a linear, exponential or logarithmic manner with the quantity of the goods? I should appreciate some thoughts on those matters - if something that looks workable emerges, I may well add it.
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.

Fabio

i'll think about it some more.

in the meanwhile, this paper could be a useful read, maybe..

http://www.cs.bgu.ac.il/~ebachmat/managesubmit.pdf

isidoro

Different loading times is a nice addition, James...  I wonder if this mod can be easily tried: assign to each packet the coordinate of the tile station where it is.  Make loading time depend on the distance from that tile to the tile where the vehicle being loaded really is.

The rationale is to avoid the building of huge stations in which vehicles are unloaded on a far platform and automatically loaded on a distant one of the same huge station.

colonyan

Nothing new to propose but as opinion
-loading time depending on quantity(both good and passangers)
-distance between train and good at station affecting load time
I buy it.

The Hood

Quote from: jamespetts on March 12, 2009, 08:27:46 PM
The Hood,

don't worry - it'll take me a while to get around to dealing with upgrades, too - my priority at present is the revenue system, and that is likely to be quite a big job.

Sounds like a good plan then.  Is the revenue system going to include service quality (e.g. frequency, some notion of timings/speed/congestion, comfort, etc.)?

QuoteThe reason why I chose Github is that that is where the source code for Simutrans-Experimental itself is located, and it is also better at concurrent working and branching than SVN. What would be the advantage of using SVN on Sourceforge?

I was thinking sourceforge because (a) that's where the standard stuff is (b) more people have heard of it (c) simutrans gets publicity through it and the more downloads/stuff the better.  It would only be for the "official" experimental pakset though, if that makes sense?  Anyway, no need to do anything about it right now.

Quote
Fabio,

that is an interesting point, and should be reasonably easy to implement. The hardest bit would be calibrating it: currently, all vehicles load at 2,000 ticks. Would the time specified in the .dat file be a maximum, minimum or average time? And should we start from the premise that the current standard of 2,000 ticks (which would be used for all vehicles that do not have anything specified in the .dat file) is the maximum, minimum or average? How much should it be varied? Should it scale in a linear, exponential or logarithmic manner with the quantity of the goods? I should appreciate some thoughts on those matters - if something that looks workable emerges, I may well add it.

I would say (based on my experience of travelling in the rush hour and at other times!) that if more than a certain proportion of the train capacity alights/boards then increase loading time (probably no need for anything more complex than linear at first, see how it works).  I'd stick with current behaviour (including scope for differences between different vehicles) as a base, as there is always a minimum wait time in the station.  I guess it would be trial and error to determine at what proportion the penalty should kick in, and how much the penalty should be.

Fabio

I thought some more on the loading time.
There is a X min required time (could it be our 2,000 ticks?) for technical reasons (opening and closing the doors). Planes and ships should have it 4 times longer (the boarding time is always much longer). A standard vehicle could be thought having 2 doors, 2 people a time can hop on or off from each of them. I can approximate 16 people moving in another X time (16 pax in 2,000 ticks). The result is then 125 ticks per pax.
This time could be increased or decreased with a multiplier M (wider doors, low on the road/platform, etc...).

So, the formula could be:

LOADING_TICKS = MIN_TICKS + ( PAX_IN + PAX_OUT ) * TICKS_PER_PAX * MULTIPLIER

A similar formula could apply for goods too, e.g. replacing every pax with an amount of weight (e.g. 1 t, here a high multiplier would be set for older vehicles loaded by hands).

The thing Isidoro pointed out is also very true, but we need a distinction:
1) goods vehicles, planes and ships will wait to load goods coming from far tiles, busses, trams (and probably trains) won't.

isidoro

Yeah, it should be refined.  Something like recording the time the packet has been waiting on a station.  If long enough, we can suppose that they have moved to the right platform and will only wait the loading time.   That time would depend on the size of the station to force players not to build unrealistic giant stations.

In my QoS patch, average waiting time are already recorded for each packet.  So that would not be difficult.

The Hood

#131
Quote from: fabio on March 13, 2009, 12:51:03 PM
LOADING_TICKS = MIN_TICKS + ( PAX_IN + PAX_OUT ) * TICKS_PER_PAX * MULTIPLIER

That's pretty much what I was trying to say!

EDIT: Would this calculation be for the convoy or for each carriage - obviously the more carriages, the more doors, so quicker to load the same number of people/goods...

Fabio

good point!

but the pax/goods are added to each single carriage, so it could be calculated for every carriage and the max would be used.

But at this point, in order to optimize the loading for pax, instead of filling the first carriage, then the second one, then the third one and so on, the procedure should split the pax on the whole carriages (e.g. a 4 carriages train boarding 20 people should add 5 people to each carriage, if there are enogh seats there).

The Hood

doing it by carriages is a good idea then.  But only for passengers.

Goods trains are normally loaded one vehicle at a time, so in that case the length of time to load a goods train should be dependent on the number of vehicles - maybe the sum of the loadtime for each vehicle?

Fabio

max for pax, sum for goods and mail.
it seems the best idea

jamespetts

Update: I have just uploaded a new binary version of Simutrans-Experimental, Makeobj-Experimental and the configuration files: downloadable in the usual places (see the original post in this thread for details).

New features include, as discussed above, reversing, variable dwell times, and upgrading as well as replacing, however, all of those features require a compatible pakset (made with the new version of Makeobj, using specialised parameters as described above) to work. However, it is recommended that all users of Simutrans-Experimental nonetheless upgrade to this new version, as this version has a Simutrans-Experimental specific save game file format. Thus, although games saved with Simutrans-Experimental are not now compatible with standard Simutrans saved games  (standard Simutrans games can, however, be loaded into Simutrans-Experimental), much Simutrans-Experimental specific data are saved, including weight limits, convoys being replaced, and Simutrans-Experimental specific settings.

This version also merges all of the latest nightly updates from the main Simutrans trunk, including all of the new overcrowding settings, and the new tooltips. Feedback is, as ever, welcome on this new version: please test it to make sure that it is stable.

As to all of the above comments on loading times: thank you for the detailed thoughts. Sorry for not replying sooner: I have had a very busy week-end. I shall think more on how to deal with this in a way that is simultaneously realistic, reasonably easy to code, reasonably easy to put into the .dat files, reasonably easy for players to understand (and to be represented through the GUI) and works well with the gameplay overall.

This is likely to be the last Simutrans-Experimental release before the first version of the new revenue system, currently in development, which will be based on the average speed of the line or (if the convoy is not part of a line) convoy, not the convoy's maximum speed, combined with a new comfort rating (already built into Makeobj-Experimental) for passengers. I am also considering having some sort of detection of the directness of the journey to allow the more realistic system of revenue being based on the route rather than the direct distance, but with goods/passengers not taking a route if it is absurdly indirect (more than X times the direct distance between the ultimate origin and the ultimate destination). Another possibility is to have mail and passengers pay for route distance, subject to a directness floor, and for goods to pay for the actual distance, but that may need further consideration. Any thoughts on that topic would be most welcome.

In the meantime, happy testing - do post any feedback in this thread so that I can improve it even further!
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.

The Hood

Quote from: jamespetts on March 16, 2009, 12:41:09 AM
This is likely to be the last Simutrans-Experimental release before the first version of the new revenue system, currently in development, which will be based on the average speed of the line or (if the convoy is not part of a line) convoy, not the convoy's maximum speed, combined with a new comfort rating (already built into Makeobj-Experimental) for passengers. I am also considering having some sort of detection of the directness of the journey to allow the more realistic system of revenue being based on the route rather than the direct distance, but with goods/passengers not taking a route if it is absurdly indirect (more than X times the direct distance between the ultimate origin and the ultimate destination). Another possibility is to have mail and passengers pay for route distance, subject to a directness floor, and for goods to pay for the actual distance, but that may need further consideration. Any thoughts on that topic would be most welcome.

If you are calculating average speed of a convoy / route anyway for the revenue system, and you can calculate the route distance, maybe there is some scope to take a longer route as long as it is not significantly slower than the shortest distance route (using average speed for calculation purposes)?

jamespetts

Quote from: The Hood on March 16, 2009, 08:54:40 AM
If you are calculating average speed of a convoy / route anyway for the revenue system, and you can calculate the route distance, maybe there is some scope to take a longer route as long as it is not significantly slower than the shortest distance route (using average speed for calculation purposes)?

The plan ultimately is for goods to assess the directness of the route as well as the speed, and calculate the best route on the basis of the likely approximate journey time taking into account both directness and speed. I do not know how well that this will work in practice: it might be reduced to guessing the approximate directness of the route based on the straight line distance between all transfer stations, or alternatively, recording average directness of all journeys per line ex post facto, and calculating based on an average directness. In any event, the first task is to measure average speed and use it to calculate revenue: the system of goods choosing their route is the next step.
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.

The Hood

Just a thought - goods traffic in real life virtually never cares about the journey time (except certain high value low volume goods, which probably resemble mail more in simutrans), and the only consideration is cost.  I suggest that passengers/mail consider journey time/speed in route-finding, but goods just take the cheapest route (if someone else can offer a cheaper trip, then industries will use it to cut costs, as their coal/steel/whatever doesn't usually care about spending 8 hours in transit rather than 3!).  The only possible exception to this are things like newspapers or possibly food?

The next question for goods would then be how to calculate the cost?  Seeing as no transport business would choose to operate a goods service at a loss, I suggest that the goods cost should be route-distance based (greater distance = more fuel) - but then again this probably needs a lot more thought!

jamespetts

The Hood,

what I had intended to do was make the revenue system use the same speed sensitivity settings as the speed bonus (some goods are more speed sensitive than others, with bulk goods, such as coal, having a 0% speed sensitivity (passengers, I think, were at 18%)), but use average rather than maximum speeds. That way, much of the existing speed bonus code could be re-used with relatively modest changes.

As to the distinct but related question of route preferences, the weighting of speed as a factor could again be used in the same way, with 0% goods not taking speed into account at all. Cost is a very difficult thing to calculate, though, as I do not think that it is possible effectively to simulate a market in Simutrans, in which the prices are set by a function of supply and demand, as neither demand nor supply are simulated in enough depth. Instead, the revenue system has to make implicit and very approximate assumptions about the elasticity of demand and the availability of alternative supply to come up with prices that are more or less right overall. It is difficult to apply the same thing to actual choices made by goods packets, though, which is why using cost is not a particularly useful measure. One possible measure of service quality s the number of transfers; another, the directness of the route. The system for choosing which route that goods take is somewhat harder than the system for determining what revenue that they should generate.
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.