News:

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

Wrong numbers of visitors and commuters shown at abbeys

Started by Jando, August 05, 2019, 02:19:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Jando

Greetings all, greetings James!

Over the weekend I went back to a freight map and noticed more odd numbers of visitors and commuters at consumer industries. I had posted about this before, namely here: https://forum.simutrans.com/index.php/topic,18781.0.html). I could not make sense of the numbers of visitors and commuters I saw in the industry detail window. Decided to investigate a bit. Tough though to get a clear picture, with passengers also going to houses around the shops and then supply and demand also playing a part. I happened to remember abbeys. Easier to check those: decent demand for both visitors and commuters, always out in the countryside away from other buildings and no cargo needed to create passenger demand. Thus I took a passenger map I had and added passenger services to three abbeys. All abbeys connected with horse coach to nearest town with railway station. Example screen shot here:



Also shown on screen shot: Arrived and departed graphs of the stop at the abbey, abbey information window with visitor and commuter numbers and the transported graph of the line serving the abbey. I carefully watched each coach arriving at one of the abbeys.

Observations:
- Abbey information window says 131 visitors and 68 commuters so far for this year. Both the stop and the line information however say that many more passengers have been brought to the abbey in that time. Indeed 131 visitors and 68 commuter travelled to the abbey in less than two months instead of in half a year. The info from the stop and line management info is correct, I took the numbers of arriving passengers down as they arrived at the abbey. Thus the numbers of visitors and commuters in the abbey window (and I suspect in all other of these location detail windows) is wrong.
- Occasionally one sees the visitor and commuter number in the abbey window rise without a coach arriving. I assume that are travellers walking to the abbey instead of using the coach service.
- Frequently one sees a coach arriving at the abbey stop without change in the visitor and commuter number of the abbey detail window.
- Comparing the connected abbeys with unconnected ones it seems the numbers in the abbey detail window only scale with distance of the abbey from next town, regardless of whether a transport service exists or not.

I believe the code counting visitors and commuters is just plain wrong there. I almost suspect that the code only counts visitors and commuters arriving at the abbey (and other locations) by foot and disregards all other arrivals.

Saved game (at time of screen shot) is here: https://www.jschuh.eu/Shared/AAViscom.sve

jamespetts

Thank you for the report. Can I check whether you have taken into account the people, if any, working at the stop itself? I cannot recall immediately whether this type of stop has any workers.
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.

Ranran(retired)

First of all it is a building detail window, not an industry detail window. :)
(Industrial commuter counts use different codes.)

Anyways, as far as I can see, in the case of a multi-tiled attraction building, commuters and visitors coming from the station do not seem to be counted.
The single tile attraction building counts properly.
pak.Britain-ex does not have multi-tiled city buildings, but probably also applies to them.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Jando

Quote from: jamespetts on August 05, 2019, 03:13:26 PMThank you for the report. Can I check whether you have taken into account the people, if any, working at the stop itself? I cannot recall immediately whether this type of stop has any workers.

Every passenger (out of hundreds) I've seen went to the abbeys, none had the bus stop at destination.

Jando

Quote from: Ranran on August 05, 2019, 03:42:48 PMAnyways, as far as I can see, in the case of a multi-tiled attraction building, commuters and visitors coming from the station do not seem to be counted.

Thanks, Ranran. That's also a good explanation for another odd thing I see: all cathedrals in all towns are always out of staff - or nearly out of staff.

jamespetts

Thank you for your reports/analyses. As indicated on other threads, I am in some difficulties undertaking substantial Simutrans-Extended development work at present as my computer is in a poor state, making running Simutrans-Extended (and many other things) painfully slow; I am awaiting component availability, which seems to be problematic at present, in order to build a new computer.

My apologies that I have not been able to deal with these issues more quickly.
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.

Ranran(retired)

I investigated this issue a little more. This seems to be a somewhat complicated issue.

First of all, multi-tile buildings have a data area for each tile.
Secondly, the building detail dialog that opens depends on the camera orientation.


All four are the same building, but we can open four dialogs for each camera angle. But as you can see, the coordinates are different.
In addition, the data they have is also different.
Now visitor and commuter are transferring to different coordinates.



At the end of these transfers, only the data for the windows with matching coordinates changed.



I tried inserting the following line in void karte_t::deposit_ware_at_destination(ware_t ware) and changing it to record the data in the base tile:
gb_dest = gb_dest-> access_first_tile ();
This was incomplete. It does not support camera rotation.
Rotating the camera changes the windows that are opened and the tiles that are recorded.
I think it is necessary to fix the tile where the data is recorded and the tile that the dialog refers to in the same way as in the factory.
The problem of opening different windows when the camera is rotated is a common issue with standard. I reported it to the standard's bug report thread.


I am sorry for my incomplete work. I hope this information is useful. (´・ω・`)

EDIT: I replaced the image. (Color-coded by coordinates)
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

#7
Thank you for your investigation into this.

As you identified, the problem ultimately originates from Standard. A multi-tile building is regarded as many one tile buildings. Unlike with an industry, there is no single overarching object in a multi-tile attraction or city building that stores data for the whole building. Instead, whole building data must be stored in one of the tiles of the building. In Extended, this is the tile that is returned by the access_first_tile() or get_first_tile() methods (which come from Standard). Unfortunately, it seems that these are not consistent for all camera rotations. The most straightforward fix would be simply to adjust which tile is returned with get_first_tile() based on the camera rotation.

Edit: I have identified the relevant code, but am unsure of the geometary as to how to implement a fix; I have posted about this in the Standard thread relating to this issue.
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.

Ranran(retired)

I have pullrequested a standard commit that fixes this bug. Please check #283.
I've confirmed that it no longer opens the same dialog more than once, but I'm not sure that the passenger records are correct. (´・ω・`)
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Thank you for this. I have tested this, but find that it produces a crash when a dialogue is left open on a multi-tiled city building (e.g. the football stadium in demo.sve) on rotation.
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.

Ranran(retired)

#10
Thank you for the testing. And an apology for overlooking the error.

I can't see the crash in r8653(120.4.1) branch that incorporates a lot from the standard, so it's probably missing another related commit.
It seems that something is still missing in the r8434 patch.

EDIT:
Unfortunately I couldn't figure out what part of the code was wrong so I couldn't find the missing commit.
Patches prior to r8653 will need to revert this commit. Please check the behavior again after merging the r8653 branch.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)