How to reproduce:
1) open demo.sve, any older save or a new game (minimal game attached)
2) place a new marker, fill in any text and press enter
3) the marker's text won't be shown. Moreover, after clicking on the marker, the text is empty
Tested with the newest nigthly on Windows.
(https://i.imgur.com/iwpmqMN.png)
Oddly, this can't be reproduced in my debug build, but it can be reproduced in a nightly build...
I cannot reproduce this in a release build that I compiled myself on Linux...
(https://i.imgur.com/3u9R8bF.png)
...nor on today's B-B build:
(https://i.imgur.com/bc4xqUW.png)
So maybe Windows specific??
This can be reproduced at #36c9cd5 on Windows nightly build.
(edit) Also #82f7063 , #6a9ac0a, #9ae3e88(2022/1/22), #0c1269e(2022/1/1), #91945cc(2021/11/27), #644024c(21/09/03), #b18df68(2021/07/20).
It appears fine in #6cb1424(2021/06/13), #bad0022(2021/06/30), #0b597ac(2021/7/15)
I think the commit numbers in the past were incorrect due to a bug.
However, I don't believe that markers have been unavailable for input for so long on my computer.
EDIT2:
Looks like the change between 7/15 and 7/20 last year is affecting it. However, as I have already reported, this is still difficult to fix because I cannot reproduce it in my self-build.
Quote from: Ranran on February 22, 2022, 07:38:51 PMHowever, as I have already reported, this is still difficult to fix because I cannot reproduce it in my self-build.
Welcome to the world of undefined behavior :(
Quote from: Matthew on February 22, 2022, 03:25:53 PMSo maybe Windows specific??
I don't think so. This cannot be reproduced with a debug build on my windows pc.
Quote from: Ranran on February 22, 2022, 07:38:51 PMLooks like the change between 7/15 and 7/20 last year is affecting it. However, as I have already reported, this is still difficult to fix because I cannot reproduce it in my self-build.
Judging by when it happened and what the changes were, I'm guessing it was due to the changes in
bool tool_rename_t::init() in this commit (https://github.com/jamespetts/simutrans-extended/commit/b18df684916f7ce4e7378ed8127b5d82835b2752), but the code in this part is the same as the standard. And this only seems to happen in certain environments, such as different compilers.
I would be grateful for any help from anyone with insight on this.
I have noticed that this problem seems only to be reproducible on cross-compiled Windows builds. Ranran very helpfully identified the area of code where this was likely to have occurred. Visual Studio gave a warning about this line of code, viz. that the "z" was an 8-bit variable, whereas sscanf expected a 16 variable here. I have modified this by making z into a 16-bit variable and casting it back down to 8-bit later when setting pos.
I cannot test this easily on my home system because it is only the cross-compiles that fail, but I should be grateful for any feedback as to whether this fixes the problems with the cross-compiled Windows builds with to-morrow's nightly build. Thank you.
From my own testing, this problem appears to have been fixed.