News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Station name moves while building it

Started by danivenk, May 31, 2019, 03:27:14 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

danivenk

Hey,
So I haven't played Simutrans in a while and I'm currently using r8756 (I also tested it in r8764).
Every time I build a station the station name moves position. This really frustrates me, how can you somehow fix it in place or how do you need to build your station to have the name at a certain position?
I usually try to position the name in the middle of the station. And move it using the public tool but now it still uses the position of the public station....
https://www.dropbox.com/s/o51fj4xbimd49tq/simscr20.png?dl=0
Before
https://www.dropbox.com/s/r2q13wlcobxo65u/simscr19.png?dl=0
After

EDIT: It always moves to the station square which is the top most screenwise

danivenk

prissi

It moves to the middle of the station, or rather the tile closest to the middle, if every tile is weighted by it level. Since there are level zero station tiles (platforms in pak128 and jetties for airports), those tiles effectively do not count. (This could be changed of course, like removing the weight or just use a minimum even for zero tiles.)

Since it can only move to station tiles, and the bus stop made the difference and shifted it to the north plattform, it looks like this.

danivenk

#2
https://twitter.com/danivenk/status/1135517391402782721?s=09
I thought the problem was with the OTRpatch but they couldn't find the problem... Here is a video of building a station with the same squares and the Station name mobes to the top part...

EDIT:after some discussion on the OTRP channel of the Simutrans Japan discord server we found out that it might be caused by an overflow when calculating the position of the Station name.

I don't know If you can help me...

shingoushori

It turned out that it occurs even if it is not only OTRPatch.

The reason for this problem might be a parameter overflow : "cent" and "level_sum" on haltestelle_t::recalc_basis_pos.

It did not occur in case of koord3d of station is (90, 90, 0), but in case of koord3d of station is (1990, 1990, 0),
so I noticed.

For example, this problem can improved by changing it as shown in the attached file.
Best regards sincerely.

ACarlotti

Using floats is definitely not the right solution - they are imprecise and liable to cause desyncs in network games. You should also avoid using 'int', as this can be different sizes on different platforms, also potentially leading to network desyncs. Since the issue is that koord uses sint16, which is not big enough, then a correct fix would be to declare the coordinate sums as separate sint32 variables. You also seem to be using the variable 'cent' in a confusing way in your patch.

shingoushori

thanks for your response.
but my biggest concern is the coordinate sums using koord.
Even if divides the koord it into sint32 variables, the worry of overflowing remains,
because sint32 is formed by multiplying 5 sint16 variables
(1st : gb->get_pos().get_2d().x or y, 2nd lv, 3rd x of station range, 4th y of station range, 5th z of station range).
Incidentally, I do not want to separate koord to two sint32 variables if possible.

So I made a new remodeling plan. Please look at the attachment.

danivenk

I have this feeling this might need to be moved from the Help Center to the Bug Report section...

Ters

Quote from: shingoushori on June 11, 2019, 03:50:46 PMthe worry of overflowing remains,
 because sint32 is formed by multiplying 5 sint16 variables
Five? I only see a multiplication of two 16-bit variables, x or y times level. The result of this is put into a sum. To overflow uint32, there would have to be either many buildings or high levels in a huge map. The easiest way to avoid overflow is to multiply into sint32, and then sum into sint64. Maybe that will still overflow if you fill a max sized map with buildings, I haven't done the exact math, but that seems too extreme to worry about.

danivenk

Quote from: shingoushori on June 11, 2019, 01:01:31 PM
It did not occur in case of koord3d of station is (90, 90, 0), but in case of koord3d of station is (1990, 1990, 0),
so I noticed.

So I've tried building stations on my map all over the place, it seems that for (x,y,z):
if (x,y,z) has x bigger than somewhere between 500 and 700 the station name moves to the position with the smallest y position
if (x,y,z) has y bigger than somewhere between 500 and 700 the station name moves to the position with the smallest x position
if (x,y,z) has x and y bigger than somewhere between 500 and 700 the station name moves to the position with the smallest x and y position

EDIT: my map is 3072x3072

shingoushori

Quote from: Ters on June 12, 2019, 09:07:16 AMThe easiest way to avoid overflow is to multiply into sint32, and then sum into sint64. Maybe that will still overflow if you fill a max sized map with buildings, I haven't done the exact math, but that seems too extreme to worry about.
OK, I was convinced. The node_count of slist_tpl is uint32.

Well ... I made a new remodeling plan. Please look at the attachment.
And If the problem will be solved, my implementation does not have to be adopted.
(and to tell the truth, i hope that such a complex operation will be simplified or to be able to skip ...)

Ters

Quote from: shingoushori on June 17, 2019, 05:20:14 AMThe node_count of slist_tpl is uint32.
Well, you can't have more nodes than there are bytes available. Simutrans is at heart a 32-bit application, even if it can be built as a 64-bit one and apparently work. In no case would a single simple application be able to operate on two thousand million elements of importance with any kind of real-time performance.

I fail to see the relevance of this for multiplying 16-bit values and summing them, though.

ACarlotti

This isn't performance-critical code, so I think just using 64 bit integers, as in shingoushori's latest patch, is what we should do. It seems very unlikely that the anyone will ever get this value to overflow a 32-bit integer unless deliberately trying to do that, but there's no harm in coding it more defensively for this case.

prissi

Thank you, shingoushori, added in r8767 (after all the server troubles fixed)

danivenk

Quote from: prissi on June 19, 2019, 12:05:58 AM(after all the server troubles fixed)
How long do you think this will take @prissi?

ACarlotti

Quote from: danivenk on June 19, 2019, 10:36:41 PM
Quote from: prissi on June 19, 2019, 12:05:58 AM(after all the server troubles fixed)
How long do you think this will take @prissi?

prissi presumably means that this fix would have been added sooner if there hadn't been trouble with the server, but now the server is fixed so he has been able to add this change to trunk (in r8767).

danivenk

Quote from: ACarlotti on June 19, 2019, 10:47:23 PMprissi presumably means that this fix would have been added sooner if there hadn't been trouble with the server, but now the server is fixed so he has been able to add this change to trunk (in r8767).
I mean more like, when r8767 will be released? Do you guys have an estimate for that?