The International Simutrans Forum

 

Recent Posts

Pages: [1] 2 3 4 ... 10
1
Thank you for your thoughts. It might help to explain a little how the current system works first.
Each packet of passengers generated can have between 1 and n passengers in it, the default value for n being 8. This number is semi-randomised and depends in part on the size of the generating building.

When each packet of passengers is generated, it is assigned (using a weighted random allocation) either to be visiting or commuting. All buildings on the map can have visitor demand. All non-residential buildings on the map can have jobs. All buildings that have visitor demand are added to a global weighted vector of visitor targets. All buildings on the map that have jobs are added to a global weighted vector of commuting targets. Buildings can be and frequently are in both lists. All residential buildings are additionally in a global passenger origins list. Residential buildings may also be visiting targets (giving rise to residential to residential journeys).

Packets of passengers pick a destination at random from the appropriate list: commuting passengers the commuting targets list and visiting passengers the visiting targets list. The lists are weighted random, meaning that the higher the number of jobs that a commuter target building has, and the higher a visitor demand that a visiting target building has, the higher the chance that that building will be picked. Unlike in Standard, a multi-tile building is a single entry on the appropriate list(s).

On generation, passengers are also assigned a maximum journey time tolerance. This is a weighted random number intended to concentrate the times at the lower end of the scale. Passengers are also assigned a maximum number of alternative destinations. This is a random number between the minimum and maximum journey time tolerance values set in simuconf.tab for visiting and commuting passengers: visiting passengers are assigned a random number between the minimum and maximum number of alternative destinations for visiting passengers, and commuting passengers are assigned a random number between the minimum and maximum number of destinations for commuting passengers.
Depending on the settings in simuconf.tab, the minimum and maximum number of alternative destinations for both visiting and commuting passengers can be scaled with the number of buildings (or, more specifically, the total for all visitor demand/jobs on the whole map). This is enabled by default in Pak128.Britian-Ex. This is done with the following simuconf.tab settings:
Code: [Select]
max_alternative_destinations_per_visitor_demand_millionths = 2750
max_alternative_destinations_per_job_millionths = 5000

min_alternative_destinations_per_visitor_demand_millionths = 750
min_alternative_destinations_per_job_millionths = 2500


The idea of this is that different sizes of map should result in the same passenger success rates for any given quality of transport.
If the destination picked first by the packet of passengers is reachable within that packet's journey time tolerance, the passengers make that journey. If not, they pick another destination using the same method, and repeat this process until either they find a journey within their journey time tolerance, or they run out of alternative destinations, whichever is first.
The process of checking player networks to see whether a journey time is within passengers' tolerance is quite computationally intensive (especially as to memory bandwidth), and, because this part of the code is very frequently accessed given the large numbers of passengers generated and the very large number of alternative destinations each on a large map, this can be the single greatest consumer of CPU resources on a larger map, so great care must be taken not to increase this more than necessary.

There is a possible refinement to the uniqueness system that I think would avert the problem that you initially identified, although it might make it harder to calibrate and understand.

The way that I imagined uniqueness as working is that it would stop the search if a unique building was found and the packet of passengers that had found it was not more than X way through the alternative destination search, X representing the uniqueness rating and also the percentage of the search.
For example, for a packet of passengers with 100 alternative destinations and a building with a uniqueness rating of 10, the search would be stopped if the passengers hit that building in one of their first 10 attempts at finding a destination. If the packet was at attempt 11 or later, the alternative destination search would continue if the passengers could not reach that destination within their journey time tolerance.

If, instead of using a percentage of the actual number of alternative destinations, the figure were a fixed number, scaled by reference to the max_alternative_destinations_per... figure, then, as the number of buildings increase, and the number of alternative destinations likewise increase, the passengers would be proportionately less likely to be in that early part of their destination search when hitting a given unique building and thus this would compensate for the larger number of unique buildings on the map.



In relation to your more specific suggestions, I am not sure that there is a need to have separate specific code to handle residential to residential traffic, as this is already handled by the system for visiting passengers. In any event, it does not solve this underlying issue. What you describe as "other" is, together with the residential to residential traffic, what is coded as visiting passenger traffic.
I am not sure that I fully understand your reference to not having lengthy lists of buildings in objects and recursive lists - can you elaborate a little on what you imagine in light of the passenger generation system described above? I fear that you may be imagining a system in which individual citizens are tracked in some way rather than the parameters being randomised on trip generation, which I cannot see being feasible in terms of memory bandwidth (attempting to do something like this was what caused all the trouble with the 2013 version of SimCity and is probably the reason that the maps were restricted to 1km square).

As to visitor destinations having a capacity and closing: closing/opening is part of town growth rather than passenger generation; something like this is eventually planned, but an overhaul of town growth will be a very major piece of work, and will have to wait until vehicle maintenance is complete; fine tuning of passenger generation along the lines suggested in my original post is much more minor and can be done as a priority. As to capacity, there is some provision for this: commuter targets have a capacity represented by the number of jobs filled, and shops selling goods have a capacity in the sense that, when they run out of goods (as shipped by players), people can no longer reach the destination (and it is treated in the same way in the passenger generation code as a destination not reachable within the journey time tolerance). Non-goods based visiting destinations do not have a capacity limit, but I have not seen evidence so far of any buildings being over-visited to an unrealistic extent as a result of this.

As to passengers not travelling to the first place that they find within range, this would increase the computational load on the passenger generation algorithm by requiring more journey attempts per passenger, so this is best avoided. In any event, in reality, people do not always travel to the closest possible place, but have a particular preference as to where to go and a travel time budget to go there (there is some research on this topic), so will travel to preferred destinations if reachable.

In any event, thank you again for your thoughts on this topic: they are much appreciated.
2
Simutrans Gaming Discussion / Re: Copy object from paks to another pak
« Last post by prissi on Today at 12:53:03 AM »
If you add extended objects to standard, the later will crash. You need to load this with extended. But then using the standard pak britain does not make much sense ...
3
Amazing!!!!
4
So I can think of three different kinds of journey, which need handling in different ways:
Commuting - Residential->Workplace->Residential. This should be balanced on both sides - i.e. number of journeys should be tracked and capped at both the homes and the workplaces. I don't know exactly what the current system is; perhaps it already works well. The success rate (i.e. number of jobs filled at an industry, and number of people in employment in a residential location) should influence the future development of the cities and industries.

Residential->Residential - This could represent people visiting friends/family, or people going on holiday elsewhere. For these, the existing generation system ought to work reasonably well - families and friends will typically be located so as to be reasonably reachable from each other, and so the efficiency of the transport network shouldn't affect numbers too much. This success rate probably doesn't need tracking to be used elsewhere.

Residential->Other - This represents people seeking out a particular type of place, whether it be a supermarket, a butchers, a theme park, a theatre, or whatever else they want to seek out. I think the overall level of demand will probably need to be coordinated by dividing this into categories, with an estimated (maximum) frequency with which people to travel to buildings of each category (and also a typical journey time tolerance). Within each category it will be necessary to devise a way of distributing passenger among the different types of buildings, including their willingness to consider alternative destinations. I think one parameter should be the (typical) proportion of buildings of some type that a passenger attempting to visit that type will consider. Another parameter might be a list of other types of buildings for them to consider as alternatives (with a probability of considering it). To prevent having lengthy lists of buildings in every object this could be recursive, so that if someone is looking for a butchers, that might indicate a 50% chance of considering a supermarket instead, which may in turn indicate a 25% chance of considering a bakery (so 12.5% chance of considering the bakery if the are no other chains that might lead to it).
EDIT: These 'Other' destinations should also have a capacity (perhaps both an ideal capacity and a maximum capacity). This then avoids excessive numbers of passenger travelling to a single location, and could also act as a driver for new locations opening or closing. Places that have few visitors might close down, while visitors that don't manage to visit a location of the desired type (or similar) have a small probability of triggering the creation of such a place near to their home, or near to another building of that type that is overcapacity (which could help similar building types to cluster).

Another thing to consider is whether passengers should travel to the first place they find within range, or whether they should continue searching, with a probability that they will switch to a closer destination if one is subsequently found.
5
Pak128.German / Re: Screenshots of PAK128.german
« Last post by pumuckl999 on Yesterday at 11:59:50 PM »
Yes, looks much better.

After a few weeks with a stressful and nasty job, I have now time for creating new objects... I hope:


It´s the last working mill in my hometown. In ST it will produce flour and animal food.
6
Simutrans Gaming Discussion / Re: Copy object from paks to another pak
« Last post by jamespetts on Yesterday at 11:56:43 PM »
I am not sure what the results are of trying to mix pakset objects of different sizes - but there is no harm in trying this, since, if you find that it does not work, all that you will have to do is remove it again and it should work as before.

I do not think it very likely that you will get good results (the aircraft will be tiny compared to the others, if it works at all), however.
7
[FR]Français (French) / Re: Matériel Français
« Last post by traintrain on Yesterday at 11:55:19 PM »
Avelia horizon alias le tgv du futur ou TGV of the future si vous voulez parler de lui a l etranger

oui il y a de bonnes intentions sur des artciles alstom , qui donnent une petite idée. 
"lowering costs (-20% acquisition and -30% in maintenance compared to the previous generation TGVs) and increasing passenger capacity (+20%) resulting in a single unit to accommodate up to 740 passengers in the highest-capacity configuration chosen by SNCF. The Avelia Horizon will consume 20% less energy than existing TGVs."
il va remplacer les tgv sud est et atlantique.

on peut lire ça sur le net. ça donne une idée du design. si il ne change pas
là c est le design présenté en mars , mais l'article dit bien que cette image est issue d'une étude de design de 2016
http://railcolornews.com/2018/03/22/fr-sncf-wants-100-high-speed-trains-of-the-future/

ici un article plus proche de nous où le design présenté est a peu près équivalent , la robe change il adopte le inoui design
http://railcolornews.com/2018/07/26/fr-this-is-the-avelia-horizon-the-next-generation-very-high-speed-train-for-sncf/

Je sais pas combien de temps ils vont l'appeler tgv du futur mais j ai hâte de voir ça. ils auraient du l'appeler tgv3000 ça aurait été plus simple dans le genre ridicule: Guillaume pepy pense que le TGV du futur,c'est l'avenir.

Mis en route 2022, 320kmh
 "Ce train devra être à la fois plus modulaire et évolutif dans le temps, plus confortable, plus connecté, tout en étant capable d’accueillir plus de voyageurs. Et, bien sûr, moins cher d’au moins 20 % à l’achat et d’au moins 25 % pour la maintenance. Bref, il va falloir faire plus avec moins. » blablabla
"La cinquième génération de TGV devra transporter quelque 700 personnes par rame, contre 550 actuellement, pour un prix d’achat de moins de 25 millions d’euros pièce (30 millions aujourd’hui)."
https://www.lemonde.fr/economie/article/2016/09/08/le-tgv-du-futur-est-presque-sur-les-rails_4994576_3234.html

Selon liberation il n y aura pas de voitures bar http://www.liberation.fr/futurs/2016/09/07/le-tgv-du-futur-en-cinq-chiffres-cles_1488646 Libération sous entend que ce sera des moteurs comme pour l'AGV , mais c'est parce que le journaliste rêve tout seul. Le journal Le Monde semble plus sérieux la dessus et contredire cette hypothèse. et les autres infos disent que ce sera deux motrices avant et arriere notamment sur l'international rail journal du 26 juillet dernier où on a différentes données sur le design et les capacités de l'engin
"The train’s windows are 37cm longer than on the previous sets, offering 10% more glass,"
longueur 200 mètres ( meme longueur que les tgv actuel selon l article.
"740 passengers in the highest capacity configuration."
"reduce the €30m cost of the TGV Duplex double-deck trains by 20% to €25m." 35 millions si vous voulez en acheter un pour mettre dans votre jardin.
"Among the performance highlights of the new train is the regenerative braking energy system which will reduce energy consumption by 20%"
pour eux vitesse de 350 kmh et 8 megawatt pour bourriner "Avelia Horizon has a maximum speed of 350km/h compared with 320km/h for a TGV Duplex, a maximum output of 8MW and a maximum axleload of 17 tonnes."
https://www.railjournal.com/index.php/high-speed/sncf-awards-E3bn-next-generation-tgv-contract.html

sinon je pensais aussi au tgv ouigo. la robe change , le nombre de place est plus important qu un tgv dit classique, et la maintenance donc le cout est plus bas. je sais pas si ça vaut le coup de s y intéresser, mais comme vous avez déjà fait des tas de variantes peut être que le ouigo manque au palmares.

sinon le avelia liberty pour amtrack il est pas mal non plus, on dirait une tete de serpent la loco. si ca se trouve c'est un robot Transformer on le sait pas. bon on est hors sujet mais je ne crois pas que j ai vu qqun s'intéresser aux versions tgv amtrack sur le forum anglophone
8
Simutrans Gaming Discussion / Re: Simutrans object file
« Last post by jamespetts on Yesterday at 11:55:05 PM »
This is possible, as the pakset in question is open source. You will need to obtain the source code for the pakset here, make the modifications that you wish to the .dat files, and then recompile it using Makeobj (the easiest way of doing which is to use the Python script Makeall.mos if you are using Windows, or the makefile if you are using Linux).
9
Pak128.German / Re: Shipyard and Floating Dock in different water areas
« Last post by pumuckl999 on Yesterday at 11:49:48 PM »
Tunnel for ships exist not before next version, I think :).
10
Simutrans Gaming Discussion / Simutrans object file
« Last post by ROCAMBOLER529 on Yesterday at 11:27:23 PM »
Hi community:

Is posible to change the codes of an object in Simutrans?? I wanna change some objects like the post man in Pak128 Britain-Exp or  remove somethings of the Simutrans Experimental or Standart that (for me) arent necesaries
Pages: [1] 2 3 4 ... 10