
Hi. Please look at the image. (´・ω・｀)刮目して？
Image #1
Now the bus arrived and 7 commuters are transferring to the orchard.
(https://i.imgur.com/cGbVp6C.png)
Image #2
Now 7 commuters have successfully entered the orchard.
(https://i.imgur.com/YwBlzys.png)
Then please pay attention to changes in the numbers on the dialog.
There were 7 commuters transferred.
The chart's Passengers Arrived has increased by 7.
Jobs (available) has decreased by 14.
Commuters this year increased by 14.
Thus they seem to work twice as much, like a Japanese. Oh, please give them a holiday. :::)
You can always check this symptom any industry buildings.
EDIT:
Looking at the graph, it seems that twice as many commuters as commuters arriving on the farm are being generated.
(https://i.imgur.com/pSMGaeN.png)

Then please pay attention to changes in the numbers on the dialog.
There were 7 commuters transferred.
The chart's Passengers Arrived has increased by 7.
Jobs (available) has decreased by 14.
Commuters this year increased by 14.
Thus they seem to work twice as much, like a Japanese. Oh, please give them a holiday.
You can always check this symptom any industry buildings.
EDIT:
Looking at the graph, it seems that twice as many commuters as commuters arriving on the farm are being generated.
Commuters travel in both directions. People go to work just like they go home. Hence for every passenger arriving there is also one generated that is leaving. At least this is how standard works and it would make sense for Extended to work in a similar way to simulate people going to and from work.

I understanded that system and pointed out the possibility of count mistakes.
The number of employment is not related to both directions. It is strange that it will be counted twice in one commuting.
(https://i.imgur.com/LWgcEOv.png)
And the arrival and departure of the bus stop near the farm are almost the same number.
This is the number that should be originally. Commuters correctly commute to work and return.
However, factories report incorrect numbers and disguise as many people are working there.
Passengers who go back to home are not generated twice at the factory.

Don't forget that 'months' in Simutrans Extended (at least with default pak128.Britain settings) last for 6.4 hours, and there is no simulation of day/night cycles or peak working/travelling periods. To work around the latter constraint, productivity, etc. is scaled assuming that there are less than 24 hours in a reallife day (I can't remember the exact values used, and can't easily find where this is discussed in the forum).
So we want to consider the sustained transportation capacity of reallife networks (which will different to the peak capacity since the peak capacity is usually directional and often not sustainable for more than an hour or so). Let's also consider the sustained rate at which transportation is overall as profitable as now (which will probably be somewhere between the current peak and offpeak transportation rates). Let's say, for the sake of our argument, that a reallife 24 hours of tranportation could be fitted into about 12.8 hours if it were taking place continuously at rate somewhere between the reallife average (daytime) rate and the maximal possible sustained rate.
Let's also ignore weekends, and assume everyone works five days a week.
Then we would find that such a commuter would be modelled in game as someone who makes a return commuting trip to work approximately every 12.8 ingame hours  i.e. once every two ingame months. Then the total number of workers at any one site would be twice the number of commuters arriving in any one month.
I don't know for sure that this is a particularly correct or accurate explanation for why you're seeing the numbers you mention, but I think they are reasonably close to correct (i.e. out by much less than a factor of 2). As was mentioned in another thread recently, often things that look like a bug in these sorts of calculations turn out not to be when the algorithm is investigated further.
Of course, maybe I'm completely wrong and there actually is a bug. But I think it's most likely that the only error is a failure to clearly document the numbers ingame (e.g. if the help texts don't mention anything about how numbers can be rescaled, then they probably should be modified to do so).

Scaling is OK. What I want to say is why scaling is done there, not a calculation method.
(https://i.imgur.com/JCstcXJ.png)
If player see the fact that the factory is looking for 2,000 workers, they probably think that they have to carry 2,000 passengers there.
I thought, "Wow, is it possible to collect so many commuters?". Because the scaling of the transportation network is that.
But in fact the player is confused if 1000 passengers are enough. And is that explained somewhere?
So I claimed that this would not confuse players.
(https://i.imgur.com/jy7KVpn.png)
If the calculation or scaling is incorrect, I think that this is correct.
(https://i.imgur.com/Nn747ZC.png)
People do not move one by one, but averaged chunks move.
EDIT:
The first picture seems to be half wrong.
The factory records on the chart that seven passengers have arrived, but records that worker as 14 people.

If player see the fact that the factory is looking for 2,000 workers, they probably think that they have to carry 2,000 passengers there.
I think that is a false analogy, on a par with saying that because there are about 100 million passengers who travel through Waterloo each year, that must mean there are about 100 million (ok, maybe 50 million) people working in London. (And that's not even counting other stations or modes of transport.)
Since the number of workers (absolute number) is not the same as the number who arrive in a given time period (for some fairly arbitrary time period), I think it would be foolish to adjust the logic to make the numbers match, In fact, it would be making the economic simulation much less accurate for the sake of simplifying some (already basic though unstated) equations, which is exactly the opposite of SImutrans Extended's ideology.

If we do not supply a certain percentage of workers to the number of recruitment, we will suffer a penalty to lower the occupancy rate of the factory. Therefore, the player will refer to the numerical value written there.
Anyway, the important thing is that unlike commuters visitors are not divided.
Check this out.
(https://i.imgur.com/eyFK1o0.gif)
Now 2 commuters and 4 visitors are transferring.
And then, the transfer is completed:
The chart's Passengers Arrived has increased by 2. (it's only count commuters)
Visitors this year increased by 4.
Jobs (available) has decreased by 4.
Commuters this year increased by 3.
(Is there a difference in falsehood due to processing below the decimal point?)
One more set(´・ω・｀)ﾜﾝﾓｱｾｯ:
https://i.imgur.com/uqC3I6C.png
https://i.imgur.com/uT4Bfav.png
That is,
Commuters are counted like this.
(https://i.imgur.com/JCstcXJ.png)
Visitors are counted like this.
(https://i.imgur.com/jy7KVpn.png)
Why? I do not think any of your theories justify using different scales for visitor and commuter.
I think it just confuses players. Visitors travel in both directions too. (Although it may move to another place rather than home)
One passenger is one visitor, but one passenger is two commuters, they are both depart from same resident and ride on same vehicle. This seems as if a traveler sits alone in one seat and commuters seats in one seat by two people. What does this simulate?
Therefore, I think it's a bug.

The worker number has nothing to do with the player. It is used for the economic simulation. Factory workers count as employed when it comes to city building. Offices, non consuming shops/services and nonproducing factory buildings also generate employment which competes with factories for employees.
Currently there is a problem that the number of city buildings that generate employment are not factoring in factories or are not tuned correctly. Where as a city might only have enough people for 2,000 workers, it might have 15,000 jobs in city buildings on top of its 1,000 jobs in shops and factories. The result is that there is not enough workers to ever get the factories to run unless job producing city buildings are manually bulldozed.
I would not rule out bugs in the commuter code either. Since I swear sometimes as good as no one is taking a job if there are a lot of jobs available.

Ranran  on the face of it, this does look as if it might be a bug  I will have to investigate when I get a minute after fixing all of the higher priority bugs.
Dr. Supergood  if you can reproduce any instances in which jobs fail to be fulfilled in circumstances where you can rule out lack of available commuters or the fact that the jobs are in an industry which is not operating for other reasons (e.g. lack of supply), then I should be grateful if you could post a bug report with a full reproduction case in a separate thread.

I may have found the cause of commuters divide. :lightbulb:
Is the processing of set_commute_trip() duplicated?
simfab.cc
sint32 fabrik_t::liefere_an(const goods_desc_t *typ, sint32 menge)
{
if( typ==goods_manager_t::passengers ) {
// book pax arrival and recalculate pax boost
book_stat(menge, FAB_PAX_ARRIVED);
if(!building)
{
building = welt>lookup(pos)>find<gebaeude_t>();
}
building>set_commute_trip(menge);
arrival_stats_pax.book_arrival(menge);
update_prodfactor_pax();
return menge;
simworld.cc
if (ware.is_passenger())
{
if (ware.is_commuting_trip)
{
if (gb_dest && gb_dest>get_tile()>get_desc()>get_type() != building_desc_t::city_res)
{
// Do not record the passengers coming back home again.
gb_dest>set_commute_trip(ware.menge);
}
}
I removed "building>set_commute_trip(menge);" in fabrik_t::liefere_an and tested it, then commuters stopped dividing anymore.
I think that it records twice since it records directly to the building and records it to the building via the factory.
I think that this is just a record on the outbound route and there is no other bad action.
Book_stat (menge, FAB_PAX_ARRIVED); is doing the correct arrival record to the factory.
Could you confirm it when you have time?

Thank you  that is very helpful. This does indeed appear to have been a bug, which I have now fixed as suggested. Thank you again.