Too many pedestrians that can't be hidden

[Ranran(retired)]

I believe that in extended pedestrians are one of the reasons for the poor performance of the game. I think it's especially noticeable on large maps. I think if this can be improved, it will be playable on poor computers and larger maps.

Code Select Expand

// we create maximal 4 pedestrians here for performance reasonsIn reviewing the differences between the standard and extended pedestrian codes, I found that the standard allows a maximum number of 4 pedestrians to be generated for performance reasons, whereas the extended has no such limitation.
Is there any reason that extended would not do so?

What if the server switched pedestrians off completely to see if that makes a difference?

Unfortunately, Extended cannot exterminate pedestrians by change its setting. The display option can reduce pedestrian spawning a bit.
Especially, [tt]"Pedestrians at stop"[/tt] option is almost broken and makes little sense.
These seems to have changed that way over 10 years ago, but I don't know why.

Certainly removing pedestrians will greatly reduce the burden on your computer. Especially large maps and fast forwards mode.
But we need to change the code to completely remove the pedestrian. So the easiest change is to remove pedestrians.pak from pakset...

As I posted before, there is a pedestrian in extended that the player cannot turn off the occurrence. standard is not. Is there any reason why the display cannot be turned off?


I think currently there are too many pedestrians that cannot control spawn. And sometimes I see strange mass outbreaks.
I changed the code and check at their life(time_to_life) and their life is too much like a boss monster. 
Many pedestrians had over a million life points.

The life point consumed by walking one poisoned tile is roughly 8000 at a glance. That is, he on the right is in the middle of a journey of more than 4000 tiles. 

For example, there are not many opportunities in the real world to walk more than 5 km continuously. Therefore, their life is more realistic to be shorter.
And because their lives are too long they often roam overpopulated areas. I often see them trying to walk to the next town through the intercity load.
Their distribution should be around larger stations and residential areas, and I suspect that if the spawn point is such a place and the life is short, it can be reproduced as such.
My point is that I think the total number of pedestrians is too much because there is no balance between the chance of spawn and the length of its life. And the players are deprived of the means to control them.

[Ranran(retired)]

A brief survey shows that the exntended pedestrian generation system is somewhat broken in some areas.
In extended, generate_pedestrians_at() now requires life to be specified, which appears to destroy the standard-derived pedestrian generation condition. This seems to be one of the reasons why the pedestrian display option is broken. Because there is no pedestrian generated that way. They are all generated by other means.
For example, generate_pedestrians_at() in deposit_ware_at_destination() omits life, and I checked the point of appearance for this, and it appears that the pedestrian generated by this always dies at the moment of birth regardless of the get_show_pax setting. (Modify the code to run ped-> show_info () as soon as it is born. Then, the pedestrian info with life = 0 will be closed immediately after it is displayed for a moment.)
I tested by assigning a fixed value to life and confirmed that the pedestrian is correctly generated at this point. At least now this part of the code seems to be doing a lot of useless work to generate a pedestrian with life = 0. There are seven other similar calls.

Code Select Expand

static void generate_pedestrians_at(koord3d k, uint32 count, uint32 time_to_live = 0);Note that the default value is 0 if time_to_live is omitted, although I have not checked the behavior of the other parts.

It can be inferred from this that the boss pedestrian trying to travel 500 km may be a pedestrian who was allocated the necessary life by calculation when calling generate_pedestrians_at due to a situation that prevents him from reaching his destination.
A possibility is that the pedestrian that is generated when the train arrives at the station normally does not exist because the code is broken, but instead only the passengers who have given up on discarding or riding the passengers are roaming the town as zombie-like pedestrians.

[Matthew]

Ranran, thank you for your work on this. This looks like a really important area for performance.

I have a very basic question that I need answered to understand this topic.

Are these pedestrians only 'eye candy'? = Are they only for graphical display, to make the game pretty?

Or are they used by the Path Explorer in any way?

[jamespetts]

Thank you for your work in looking into this. Pedestrian generation is intended to give the player a clear visual idea of where walking is occurring, so it has a specific function in the game. This is why pedestrians need to be generated in a specific location: that location is the location of the start of their trip. In Simutrans-Extended, pedestrians are generated whenever passengers make walking trips, or when beginning/ending a journey taken by another means, where that beginning/ending involves walking.

Ranran has very helpfully found a bug in which pedestrians were not generated at all in some of the latter cases; I have now fixed this by requiring the time_to_live parameter to be specified every time that pedestrians are generated, and specifying it where it had not been specified before.

I have also tested the hypothesis that pedestrians are being generated with an excessive lifetime. However, I have not been able to confirm this hypothesis. Pedestrian lifetime is measured in ticks. Converting the ticks in-game with temporary debug code to in-game minutes reveals that the code is working as intended: for pedestrians representing a journey, the pedestrians' lifetime is based on the calculated walking time of the journey in question in in-game time measurement. So, a pedestrian generated to represent a trip of 10 minutes will persist for 10 in-game minutes; a pedestrian generated to represent a trip of 1 hour will persist for 1 in-game hour, and so forth. For pedestrians generated where there is no specific journey time, a very short time (2,500 or 6,500 ticks) is given.

For reference, the code that I used for testing was:

Code Select Expand

const uint32 TEMP_pedestrian_in_game_minutes = welt->ticks_to_tenths_of_minutes(time_to_live) / 10u;

in pedestrian_t::generate_pedestrians_at().

The TEMP_pedestrian_in_game_minutes variable always produced reasonable numbers in my testing, consistent with the times allocated to them by the passenger generation code.

[Ranran(retired)]

The TEMP_pedestrian_in_game_minutes variable always produced reasonable numbers in my testing, consistent with the times allocated to them by the passenger generation code.

A simple observation is that passengers with Over 1 million large life tend to spawn where there is no bus stop or train station nearby. It could be near a crowded bus stop.

EDIT:
Many random pedestrians seem to be born with lives in excess of 2 million. But they are an option and can suppress spawning. They spawn in large numbers at the same time in the same tile.

[Ranran(retired)]

For pedestrians generated where there is no specific journey time, a very short time (2,500 or 6,500 ticks) is given.

I think the newly set 2500/6500 life is short because it can't even reach the next tile. This wouldn't make sense like an eye candy. For reference, the station coverage is 15 tiles.

I have also tested the hypothesis that pedestrians are being generated with an excessive lifetime. However, I have not been able to confirm this hypothesis.

Code Select Expand

            pedestrian_t* ped = new pedestrian_t(gr, time_to_live);
            ped->calc_height(gr);
            if (time_to_live>1000000) {
                ped->show_info();
            }
For example, if you change the code to open the pedestrian dialog when a pedestrian is born with a life of 1 million or more like this, you can see that it is opened frequently.
Often there are many longevity pedestrians on the same tile at the same time.
Note that the pedestrian dialog should be enabled in the display options.
I haven't been able to determine where this is the result of the call, but it disappears when I disable "Pedestrians in towns".

Pedestrian generation is intended to give the player a clear visual idea of where walking is occurring,

I don't think this needs to be this longevity. Players often do not detect the outbreak and accidentally come into view. Pedestrians that move over 100 tiles obscure the information.

[jamespetts]

Thank you for this. Testing on the Bridgewater-Brunel saved game from Friday, there are occasionally pedestrians with a time_to_live of > 1 million, but this number can be triggered for a walk of anything as little as 1:30h, and it is entirely plausible for people to walk this sort of distance. The number of pedestrians visible in a town should give a rough idea of both how many people are walking and how far that they are walking, and players need to get some idea of this. Were it otherwise, this number would be entirely arbitrary. Ideally, we would have the pedestrians actually calculate their route to the destination and walk along that route until they get to their destination, but this would be too computationally intensive.

I have slightly increased the longevity of the randomly generated pedestrians, albeit they do not need to last too long as they are intended to represent, e.g., people stepping out of their car and going into the office, etc..

[DrSuperGood]

Unless pedestrians are required as part of the simulation logic it may be possible to turn them into a "visual" aspect that should scale much better with map size. This would mean that pedestrians only need to exist near the camera, and are generated and spawned only near the player's view port. To give a feeling that they already existed when a player brings an area into view, some trickery could be used to spawn some mid journey. This would let them keep their purpose as a visual indicator while not requiring they be generated throughout the entire map. This potentially even allow more pedestrians to be generated, improving the visual impact, such as a busy city showing thousands of them on screen.

[jamespetts]

Unless pedestrians are required as part of the simulation logic it may be possible to turn them into a "visual" aspect that should scale much better with map size. This would mean that pedestrians only need to exist near the camera, and are generated and spawned only near the player's view port. To give a feeling that they already existed when a player brings an area into view, some trickery could be used to spawn some mid journey. This would let them keep their purpose as a visual indicator while not requiring they be generated throughout the entire map. This potentially even allow more pedestrians to be generated, improving the visual impact, such as a busy city showing thousands of them on screen.

I had contemplated this - but sadly, I believe that their use of the objlist on tiles means that they absolutely have to be kept in sync among all clients and the server or else losses of synchronisation during network play are likely.

[prissi]

Standard can run in sync without having the same pedestrian setting. As long as there is enough space left in the objectlist (which is again properly ensured after the recent fix in the other thread), and pedestrians do not use the normal random function and cannot block a road or crossing (and be run over instead), then the game state is not affected.

[Ranran(retired)]

I think that even now some pedestrian spawning is affected by the two display options in extended. Therefore, there may still be differences in the pedestrian displayed by some players even now. 
however, since they are just eye candies, I don't think they will affect the sync except for removing operation. And their presence should also have no effect on the convoy operation or economy. So I don't think there is a need for synchronization to remove pedestrians either.
Also, the fact that pedestrian, which freddy complained about earlier, interferes with the execution of the remove tool should be convenient to allow the remove tool to be executed by completely ignoring the pedestrian by options.
It's ridiculous to have to use a dedicated remove tool because of their presence. And since they often overlap on one tile, as in the main subject of this thread (probably more around the station due to recent changes), they tend to get in the way of the player.
Ideally, players who think pedestrians will interfere with the remove operation should be able to do this by turning off its display.

[jamespetts]

Pedestrians certainly should not be affected by the remove tool, and it is not a sensible design decision to have the remove tool remove pedestrians and nothing else. If there are pedestrians on the road when the remove tool is activated, both road and pedestrians should be removed.

In terms of allowing players to have fewer pedestrians, I wonder whether we need a new setting - or whether we need to modify one of the existing settings so as to affect pedestrians generated when walking trips are generated?

[Mariculous]

From my personal players perspective, I'd definitely prefer improved performance over an animated "is walking" map overlay.
Whether or not I'd disable these surely depends on how much they affect performance.

[Matthew]

From a player perspective, I would also strongly support allowing players to turn off pedestrians, especially in multiplayer.

For several years I could not play multiplayer at all for performance reasons and the Discord server has had a few newcomers who have tried to join but failed.

Playing without pedestrians is better than not playing at all.

I do sometimes look at pedestrians to see whether a route is working, but like Ranran I find that more detailed analysis is difficult because there are so many pedestrians everywhere. And there are many days when I don't look at them at all.

A couple of thoughts in the hope of inspiring those of you who actually understand this:

• Would it be possible to only permit a certain percentage of pedestrians to be generated? Or maybe set the level using some power-of-2 factor since percentages are expensive to calculate?
• Alternatively, I wonder how long it would take to populate a reasonable sample of pedestrians if they were just generated when required?

Please silently ignore those suggestions if you know they are unworkable or unhelpful.

Standard can run in sync without having the same pedestrian setting. As long as there is enough space left in the objectlist (which is again properly ensured after the recent fix in the other thread), and pedestrians do not use the normal random function and cannot block a road or crossing (and be run over instead), then the game state is not affected.

This is good news. So the best outcome is possible, though it looks like a substantial coding project.

Pedestrians certainly should not be affected by the remove tool, and it is not a sensible design decision to have the remove tool remove pedestrians and nothing else. If there are pedestrians on the road when the remove tool is activated, both road and pedestrians should be removed.

I never, ever want to remove individual pedestrians, so if you are saying that then I agree.

I am surprised that pedestrians need to be removed when a road is deleted. I see pedestrians more or less everywhere on the map, so I didn't think they depended on roads. TIL.

[jamespetts]

I have run a profiler to calculate the effect of pedestrians on performance. On the Bridgewater-Brunel saved game from the 20th of May this year (last Friday), running a Visual Studio optimised debug build on my home computer, pedestrian_t::sync_step took 1.89% of CPU time and the destructor for pedestrians took 0.14% of CPU time, making a total of 2.03% of CPU time directly attributable to pedestrians.

[DrSuperGood]

2% of CPU time is big enough to be considered a potential area to optimise. The additional cache overhead of processing them might even affect user performance beyond that.

If generating them locally only around the player's view port it might be possible to significantly reduce this CPU usage well below 1%. It might also allow pedestrian density to be increased as thousands of pedestrians could be placed within view rather than having to be spread around a few dozen per town.

[prissi]

When checking in Standard, pedestrians reduced the fast forward rate of the yoshi testgame by 15%.

Hence, r10664+10660+10659 made passengers independent from the game state. So a client can switch off passengers (or the server can switch off them.)

I noticed also that passenger generation was quite inefficient, there were many instances of 60 passengers exactly on top of each other. This is also addressed by the above revision, and suddenly there are crowds when a train arrives where before only three passengers (with each 60 on top of each other) were generated, wasting just memory and calculation time.

[jamespetts]

When checking in Standard, pedestrians reduced the fast forward rate of the yoshi testgame by 15%.

Hence, r10664+10660+10659 made passengers independent from the game state. So a client can switch off passengers (or the server can switch off them.)

I noticed also that passenger generation was quite inefficient, there were many instances of 60 passengers exactly on top of each other. This is also addressed by the above revision, and suddenly there are crowds when a train arrives where before only three passengers (with each 60 on top of each other) were generated, wasting just memory and calculation time.

Interesting, thank you for that. It may well be worthwhile incorporating those features into Extended, particularly the latter.