Pedestrian Display

[zook2]

Hi everyone,

(I've had a rough time with illness and death in the family, but I'm back now.)

In the new BB server game, can somebody please disable Pedestrian Display, i.e. the (pointless?) window I get almost every time I click on a road tile. I thought it used to be in some options tab, but apparently it isn't so I guess it's a server setting now.

[Ranran]

it's a server setting now.

I'm afraid not. As for simuconf.tab, the one in the pakset folder has priority over the game folder.
Britain pak's simuconf.tab declares "pedes_and_car_info = 1", which means that if you use the auto updater to update the pakset, the settings will be reset to this value.
This means that, unlike other paksets, the britain pak intends to display pedestrian and private car information, ignoring generic settings.
So I think this is a pakset issue.
I don't think such generic parameters should be duplicated in pakset's simuconf.tab unless  pakset author has a specific intention. Players can easily miss it... (´・ω・｀)

[Mariculous]

Totally right but that setting will disable private car info windows as well, which might not be desirable.

There is another (server side) setting to disable pedestrian spawning entirely.
Pedestrians do not interfere with any other object in the simuworld and they do not have any impact on economics at all, thus they are pure eye-candy.
This does not conform to the high-level design goals of simutrans extended, thus we might consider to disable those entirely by default.

[Ranran]

I agree. So I tried to excise pedestrians from pedes_and_car_info.

pedes_and_car_info = 1 ... Can open the private car info window but ignores pedestrians.
pedes_and_car_info = 2 ... Can open the pedestrian window but ignores private cars.
pedes_and_car_info = 3 ... Both private car and pedestrian windows can be opened

Also, it is annoying that this setting must always be done via simuconf.tab. Therefore, I have made it possible to change these from the display setting.

Check the pull request #439. This patch includes a few changes from standard, and also adds an option to change the date format from the display setting.

[Ranran]

The patch has matured and metamorphosed. [ ● ]
Pedestrian info has been ranted by players as annoying, and stoned, oppressed and killed as soon as it appeared. It may be partly because she was too fat. (´　・ ω ・　｀)


So I thought I might be able to save her by scraping off excess fat and slimming it down. 


Please see her who was reborn slim.



This reduced her toxicity and annoyance.   However, very unfortunately, this patch reduces the chances of its appearing, so people may not notice her change. (´･ω･`)
But still I think it's a good change for her to be slim.

FYI, since there are cases where the coordinates do not fit in the title bar when the size is 64 size or the translation is long, the coordinates are drawn on the image.
"Constructed by" already has translations in many languages. If it does not have author data, she will be slimmer.
I'd be happy to hear your thoughts.

[Mariculous]

That's nice but imho a smaller window does not solve the issue.
The issue is that it can be very annoying to select a player vehicle on a busy city road.

The following two things should do the job:
1. Generally, windows opened when clicking in the world should NOT jump in front of the cursor, so we can simply click again and again until the window shows up that we are interessted in.
2. There should be a fixed order of windows opening and pedestians should be the very last thing to show up! Something like
way buildings, markers, player vehicles, ways, private cars, pedestrians

[Ranran]

That's nice but imho a smaller window does not solve the issue.

I'm afraid you replied without reading my one previous post.

pedes_and_car_info = 1 ... Can open the private car info window but ignores pedestrians.
pedes_and_car_info = 2 ... Can open the pedestrian window but ignores private cars.
pedes_and_car_info = 3 ... Both private car and pedestrian windows can be opened

The default setting for exntended is 0, and the default setting for britain pak is 1. (These are unchanged from the existing configuration.)
This means that pedestrian info will not be displayed unless the player intentionally changes the settings.

This is about that.

However, very unfortunately, this patch reduces the chances of its appearing, so people may not notice her change. (´･ω･`)

2. There should be a fixed order of windows opening and pedestians should be the very last thing to show up!

When a request for this was made recently, prissi explained that pressing ctrl would reverse the display priority order. Then convoy has priority over pedestrian. However, pedes_and_car_info must be greater than or equal to 2 in order for pedestrian info to be opened.


I think the underlying problem will be solved.

[Mariculous]

To be honest I assumed it's meant to adress the same issue as it's a follow up of the previous post, which it doesn't.
It's nice to have anyways.

May I ask why car and pedestrian windows are coded as bit flags of pedes_and_car_info?
Wouldn't it be better to deprecate pedes_and_car_info and introduce a pedes_info and car_info setting?
Internally, these can surely be stored differently.

[Ranran]

Wouldn't it be better to deprecate pedes_and_car_info and introduce a pedes_info and car_info setting?

I intentionally left it as one parameter since the name of the parameter is pedes_and_car_info, which already implies that it is a parameter that combines both, and I saw no advantage in breaking compatibility.
In addition, the display settings dialog in game treats them as two separate buttons, so it is not a problem.

However, I am not a native English speaker, so I cannot describe the official documentation. Therefore, the simuconf.tab description of it needs to be updated.

[Mariculous]

and I saw no advantage in breaking compatibility.

That's nice, but

pedes_and_car_info = 1 ... Can open the private car info window but ignores pedestrians.
pedes_and_car_info = 3 ... Both private car and pedestrian windows can be opened

will break compatibility!
The old interpretation was

pedes_and_car_info = 1 ... Both private car and pedestrian windows can be opened

To maintain compatibility and get these settings clean, it seems straight forward to me to read the new pedes_info and car_info setting first. If none of these is defined in the config, then fallback to the good old pedes_and_car_info.

[Ranran]

will break compatibility!

I don't think so at all. You said that pedestrian info is very annoying. Do you want players to continue to use it?
And did the author of pak britain want that from the beginning? So changing pedes_and_car_info=3 in my suggested settings is ideal for britain pak? I think it became pedes_and_car_info=1 to display private car info as you said. I don't think it's for displaying predestrian info. If simutrans had such a setting from the beginning, would they?
Why recommend a cumbersome setup when options arise that have never existed before and can be interpreted either way?
I don't understand why you would want to take over something that you said was bothersome to you. I think it's better to default to something that players will have as little trouble with as possible.

Remember the original purpose of this patch. The purpose of this patch is to eliminate the annoyance of opening pedestrian info. But your suggestion is to make this patch half pointless.
When this was incorporated, you learned of the existence of the patch here, so you learned of the option. So you'll use it. But those who didn't notice it will continue to be annoyed by it until they are made aware of it by your machinations.
As you say, information obtained from pedestrian displays and information dialogs is generally worthless. On the other hand, private car info has some worth. So I think it's better to turn it off by default.

Also, there is no advantage to creating a new parameter, but it requires a lot of coding. This is because it requires code to take over the old parameters and convert them. This is because it is possible to keep using the old simconf.tab regardless of the save version.
This means that we will get three parameters from tab. (Two more will be added). I think this is just a waste of effort.

[Mariculous]

I don't understand why you would want to take over something that you said was bothersome to you.

You raised the point of backward compatibility.
Re-interpreting values differently from the previous meaning is not backward-compatibility.
We might argue that purposely doing this here might be a good idea. From my point of view, I can agree with this, but I have really no idea what the original intention of pakset authors using pedes_and_car_info=1 was.

There seem to be two different points now:
1. backward compatibility. In my opinion it's fine to partially drop this in the way you did.
2. is cryptic config parameters.
I personally anticipate with bitflag values in the config because it makes things harder to understand. Doing so require some value documentation whilst a simple boolean 0/1 is self documenting.
This has some merit.

I don't agree that aiming for this is a waste of effort but I accept that you don't want to spend that effort by yourself.

The purpose of this patch is to eliminate the annoyance of opening pedestrian info.

That's a good thing in any case. I fail to see how the suggestion makes this pointless.
Extended paksets seem to be actively maintained, so I'd highly expect pakset authors will update their configs accordingly if they originally desired to show cars but not passengers.
Furthermore, players will usually update their paksets when they update the game.

[Ranran]

I don't agree that aiming for this is a waste of effort but I accept that you don't want to spend that effort by yourself.

No, I just don't want to do it because I still think it's better not to do it from a player's point of view. And I still don't see any benefits.
And if you think it's worth it, you can decompose show_names, which is also bit flag.

Your request is a change that reduces the number of  beneficial players. It is based on the perspective that only you will not lose.
We also need to consider the impact of not overriding the simuconf.tab setting, but you ignore them. That's the compatibility I'm talking about.
This means that the previous setting of pedes_and_car_info=1(for pak britain) is the same as before, which means that this patch is half pointless, and that is the result you are asking for. However, I think it would be better if pedes_and_car_info=1 did not open pedestrian info, which would save a lot of people who started the game with that setting from a lot of hassle.

but I have really no idea what the original intention of pakset authors using pedes_and_car_info=1 was

I think this is only pak britain. Do you like that "open pedestrian info" is set to on every time you update your pakset using autoupdater?
I don't think it intends to continue opening pedestrian info. Because the request "Please do not open it" is the essence of this thread. No one has ever objected to the change based on the fact that it is annoying. But I understand that it has the condition that it does not affect private car info as you pointed out. Recall that until now there was no setting to meet the needs of people who wanted to allow opening private car info but not pedestrian info. Other people's opinions on what default settings are preferable in this regard may be helpful.
And as I've already explained, it's best not to specify such personal preferences in pakset.
There are several such settings under ## Display settings ### in simuconf.tab in pak128.Britain-Ex.

I personally anticipate with bitflag values in the config because it makes things harder to understand.

It's a bit flag format, but there are only three options. It's not worth sticking to the old format in the first place.
Do it in the GUI, just as standard allows you to change the date format in the GUI. Therefore, the meaningless numbers 1, 2 and 3 are mostly used internally.
Other than pakset setting a default value, it makes little sense for the player to understand it. So the accompanying explanation is sufficient.

[Mariculous]

Let's sum this up:
I really don't want to offend you nor your implementation of this nor is this discussion about winning or losing.
It's nice to have this option in any case and I'm totally fine if you don't want to spend time on the suggested change.

The original concern was about
1. changing semantics of pedes_and_car_info=1 and
2. using the pedes_and_car_info as a bitflag attribute in the config.

I guess we concluded that we want to bring the behavior of showing private cars, but not pedestrians to the majority of players.

The point we seem to differ in is whether this should be done by changing semantics of pedes_and_car_info=1 or by pusing changes to paksets simuconfs.
Generally I anticipate with changing semantics of well defined behavior. In this specific case, it might be an option, but on the other hand,
all paksets practically relevant to extended are actively developed, so developers can and will most likely update their simuconf to adapt that feature.
Thus, I don't really see a need to change the semantics of pedes_and_car_info=1 in the code.
In the end the only argument against it seems to be coding effort, which surely is an acceptable argument.
Do you object?

The second point is about how that information should be coded in simuconf.
Should the existing pedes_and_car_info be interpreted as a bitfield or does it make sense to introduce two new variables instead?
I'd argue yes, it clearly makes sense to introduce these fields so these can stick with the same semantics that ground_info and townhall_info use.
Again, besides the acceptable "waste of time" point, do you object?

There is one point I am not quite sure if I understand that objection correctly.

We also need to consider the impact of not overriding the simuconf.tab setting, but you ignore them.

I did not ignore this but I do not see an issue here.
Surely I might have missed something .
So what exactly is the impact you refer to?

And as I've already explained, it's best not to specify such personal preferences in pakset.

I totally agree! You should always use simuconf.tab in your user dir to for personal preferences.

[Ranran]

What makes this discussion worthless and a waste of my time and very demotivating for me is that you keep repeating arguments that would not come up if you tested this. It's difficult to explain everything in words alone, so I usually give the necessary explanations for the testing. Most of the people who have tested and provided feedback so far have been very grateful for the good advice.
Your claim hasn't changed, so my answer hasn't changed either. I am sick and tired of saying the same thing over and over again. Almost explained in a previous post.

[Phystam]

If you change the settings to break backwards compatibility, you will need the consent of the pakset developers. And I agree with breaking backwards compatibility in this case.

[Ranran]

I'm sorry I can't understand your claim at all. JP does not represent the language abbreviation Japanese ("I speak Japan" is not correct), so I don't know if you are a native Japanese speaker. But there are many otaku in the world who love Japan.
(´・ω・｀)可能なら日本語で説明してくれると助かるかも

And I agree with breaking backwards compatibility in this case.

What does this mean? Can you elaborate on this?
(´・ω・｀)これはどういう意味です？

you will need the consent of the pakset developers.

I think we're both arguing that pakset shouldn't have a duplicate of that setting in the first place.
The following has already been explained in English.
(´・ω・｀)らんらんが正しく理解していればそもそもそういった設定をpaksetが重複して持つべきではないと二人とも主張していると思うんだよね
(´・ω・｀)普通そういった汎用表示設定はsimutransのconfigの変更で十分だと考えるのに、なぜかpaksetが重複してそれを持っているせいで
(´・ω・｀)変更したつもりなのに設定が変わってないんだけど？ということになって、プレイヤーにとって面倒なだけだからです
(´・ω・｀)しかもpaksetを更新する度にその設定がリセットされる(歩行者ウィンドウ表示がオンになる)のだからうっとうしくてかなわない！というのがこのスレッドの開始地点
(´・ω・｀)それがこのパッチでゲーム内の表示オプション設定画面から変更できるようになるからかなりマシになるはず？
(´・ω・｀)ちゃんとスレッド読みました？ほとんど機械翻訳なので変だったら教えて？


Did you make such duplicate settings in pakset's simuconf.tab as well? If so, it would be helpful if you could tell me what your intentions were in doing so.
(´・ω・｀)あなたはpaksetのsimuconfにもpedes_and_car_infoを置きました？
(´・ω・｀)だとしたらなぜわざわざそうしたのか理由を聞かせてくれると参考になります？

[Mariculous]

Well I tested this patch yesterday, before the shrink of window size and falsly assumed it was meant to be an alternative solution to the pedestrian annoyance.

I saw that the pedestrian window will be disabled when pedes_and_car_info=1 is set.
I also noticed that in the UI it's two different settings, which is great.

My concern was solely about the representation in simuconf as well as the changed interpretation of the value 1 in simuconf, which the testing could not answer.

It seems that pakset authors of the three extended paksets concluded that it's fine to change semantics of pedes_and_car_info=1, so it's fine in this specific case.
At least it's my personal philosphy about breaking semantics of something well-defined. You should only do this if there's no way around, except if everyone affected by this is fine with it.


I guess the conclusion about splitting these two settings in simuconf is "not worth the effort", but I don't know so I asked whether this is the conclusion, sorry for asking...

And yes, the show_names bitfield in simuconf is just as unfortunate in my opinion.

[Ranran]

As I've explained many times, I still think your proposal doesn't have any advantages, only the hassle, despite some disadvantages.
For example, I don't need private car info either, so I put pedes_and_car_info = 0 in simuconf.tab in the user folder. Then, regardless of the pakset setting, these will not be displayed by default. (But as I claim, it's enough to remove this setting from pakset and control it only in the game folder's one.)
You should be aware that this is compatible with standard. Is there really an advantage in decomposing parameters? Even if extended abolish pedes_and_car_info, we need to keep the code to read it for compatibility in settings.cc, and we also need the code to convert it to two new bools. Is it really worth adding these codes? That's the point I say isn't worth the effort.
In addition, for those who have previously thought that pedes_and_car_info = 0 is enough to not open those windows, the changes you propose will produce unwanted results.
Let's assume that we split pedes_and_car_info into show_privatecar_info and show_pedestrian_info. But pedes_and_car_info needs to be maintained for compatibility.
Then, does show_privatecar_info = 1 not disable pedes_and_car_info = 0?
In order for your proposed new two bools to work properly, I think we need to break compatibility. I don't think my method, on the other hand, breaks compatibility. This is because the conditions related to one parameter are included. On the other hand, in your suggestion, the three parameters coexist, but these can cause inconsistencies.
I said don't open both windows, but does the one parameter contradiction that was decomposed negate it? Is it easy to understand? Are there any benefits?
Thus your suggestion only breaks compatibility and adding it just wastes effort. This is the point where I say it has no advantage but disadvantage.


Secondly you also agreed that pakset should not have those settings. Then you don't have to worry about its relevance to pakset. There is no consistency in your argument.
The presence of that option in the display setting makes it even less of a concern.
For example, the station name display settings are also in simuconf.tab, but users can change them through the display setting. When that happens, players will only care about simuconf.tab the first time and expect the changed settings to continue to be retained. It's ridiculous to bother closing and restarting the game if you want to change it. That's one of the reasons I don't stick to the old format. Standard also recently discarded it in date format. So I imitated it. But you seem to stick to an old, almost worthless format.
However, it is possible that this is not working as expected but the same thing can be said for the date format incorporated from standard, so I think it needs to be confirmed. Currently there is code to save it, but it seems to be overwritten by simuconf.tab. If that's the correct behavior, there's no point in saving it.

Code Select Expand


# Show name signs and statistic?
# 0 = don't show anything
# 1 = station names
# 2 = statistics
# 3 = names and statistics
# The visual style is added to this number:
#   0 = black name in color box
#   4 = name in player color with outline
#   8 = box left of name in yellow outline
show_names = 3

At least three options are much simpler than the flags above. If you say it's worth doing, you should make an effort to change it now.
EDIT:
In doing so, consider carefully whether disassembling it does not break compatibility, as mentioned at the beginning of this post.

[Phystam]

@ Ranran
こっちのスレッドは全然読んでなくて、DiscordでFreahk氏に言われて気づいたから見ただけなんですよね >< Freahk氏に言われた要点としてはpedes_and_car_info=1の動作が以前と異なるようになる(互換性を壊す)けど大丈夫？といった趣旨だと思ったのですが、このスレッドではそうではなかったのですね。
pak256としては、単にPak128.Britain-Exの設定を引き継いだだけでありそこまで深い意味はなかったこと、そもそも歩行者オブジェクトを持たないことなどの理由からこの設定の変更があったとしても問題ないと判断しました。
もちろん、本体側のsimuconfとpakset側のsimuconfで重複があるのが問題であるというのなら、pakset側の設定を削除し重複を解消しても問題ありません。

I didn't read this thread at all, I only saw it because Freahk mentioned it to me on Discord and I noticed it. The gist of what Freahk said was that pedes_and_car_info=1 will behave differently than before (breaking compatibility). I thought that was the point, but I see that was not the point of this thread.
As for pak256, I decided that there was no problem even if this setting was changed, because it was simply inheriting the setting of Pak128.
Of course, if the problem is that there is duplication between simuconf on the simutrans side and simuconf on the pakset side, there is no problem if you delete the settings on the pakset side to eliminate the duplication.

[Mariculous]

I took a few minutes to demonstrate the suggestions being made based on your branch.

May I ask why car and pedestrian windows are coded as bit flags of pedes_and_car_info?
Wouldn't it be better to deprecate pedes_and_car_info and introduce a pedes_info and car_info setting?
Internally, these can surely be stored differently.

See this commit https://github.com/irgend42/simutrans-extended/commit/3e6fc5a587f3a64a0bf4bb78cf903e09910942c9
Overerriding seems to be working and I do not see how this breaks compatibility.
The merit of this is simuconf simplicity and consistency with ground_info and townhall_info as well as the ability to set and override these two independently.
A user can now disable car_info without affecting the pedestrian info window setting obtained from a previous source in the override chain.
The disadvantage is clearly some effort being made, which now has been done anyways.

Currently there is code to save it, but it seems to be overwritten by simuconf.tab. If that's the correct behavior, there's no point in saving it.

I can confirm, that in my testings simuconf seems to override the ingame settings of car/pedestrian info windows as well as the date format setting.
That's due to the override order, where settings-extended.xml is loaded at the very beginning.
I am currently observing how the other display settings solve this.

Edit:
After some coffee and plum cake, I noticed that other display settings handle this by not being defined in simuconf at all, so there is no override going on.
Which practically means defining them in any simuconf (simutrans, pakset as well as user config) effectively disables the ability to save and load UI settings persistently.

[Ranran]

I've already explained that I don't think it's just a matter of effort. It just makes things harder to understand.
You only understand it because you have written the code yourself and already have knowledge about simuconf.
Throw away all your knowledge, then you are a new player.

Code Select Expand


pedes_and_car_info =
pedes_info =
car_info =

Is it immediately understandable for these overwrite relationships?
Again I have to say the same thing. Those who do not want to open either dialog may find pedes_and_car_info = 0 sufficient. Because it looks like a superordinate parameter that solves two with one parameter.
However, pakset's pedes_info overwrote the setting, even though pedes_and_car_info was only set in simuconf.tab. The player is confused. What's going on?
He can't find it anywhere else by looking for the letters "pedes_and_car_info". Because the culprit is pedes_info.
To avoid that, we have to put detailed documentation about these in simuconf.tab. It's much easier to understand just to comment on the three values, like show_names. There is no need to describe the parameter overwrite relationship. So I can't find any advantage to your change. And what is worse it will be written in English, which is unfortunate for us - Japanese. Most of them are allergic to English because they studied Jangrish but not English.
From a translation point of view, I think it is useless to stick to simuconf.tab. This doesn't really matter when player can change it with the options button in the GUI in the game.
That's what I said you're always a profiter's point of view. You will surely be able to avoid this problem with your knowledge. However, inexperienced players can suffer such disadvantages. There are players who play with standard paksets, old paksets, and various combinations. Not all players always play with the latest combinations with the automatic updater. Thus I think there is no benefit to this change.

However, it is possible that this is not working as expected but the same thing can be said for the date format incorporated from standard, so I think it needs to be confirmed. Currently there is code to save it, but it seems to be overwritten by simuconf.tab. If that's the correct behavior, there's no point in saving it.

In this regard, I noticed that I had to comment out these settings from simuconf.tab in order to control pedes_and_car_info with the GUI on the game and enable its saving. Therefore, it is convenient to comment out these settings not only from pakset but also from the game folder. Therefore it is almost useless to separate it into two parameters. Because it is recommended to comment out.

[Mariculous]

It just makes things harder to understand.

Well either way round it's not easy to understand in some cases.
A documentation as complex as "Replaces the pedes_and_car_info setting" should be sufficient to note: "You should not use pedes_and_car_info anymore. Use pedes_info and car_info instead"
It will allow searching for that string as well.

Admittedly, the other way round it's not much different.
The values must be listed and the relation to those two UI parameters should be described.

I remember being confused of options being in a different category and called differently in the new map settings UI and simuconf, when I was a rather new player setting up a simutrans server game.
I'd expect to be just as cofused about parameters being represented differently in between simuconf and the UI.
But who knows? I'm not a new player anymore.

Players setting things in an old simuconf won't know about the ability to disable private cars without disabling pedestrians either ways.
Players setting things in new and old simuconfs will be informed about the relation.

Finally, I guess we conclude that we do not agree on what is less confusing. Introducing new parameters that doe basically the same as the old one, or putting that information into the old one which makes it inconststent to other *_info parameters and the UI.
That's fine. People cannot always agree on something.

I want to point out that this patch is quite useful in any case and the work on this is appreciated.

[Ranran]

- The point of this thread and my patch is that it doesn't affect privatecar info but doesn't open annoying pedestrian info by default. (This includes cases where it is inherited by old settings or saves.) You seems to have forgotten this sometimes.
In standard two windows are equally worthless, but in extended their usefulness is not the same. You disagreed, saying that pedes_and_car_info=1 must be car_info=1 && pedes_info=1. You prioritize keeping pedestrian info open in this regard. You try to treat them equally, saying they are not equivalent. Your argument is full of contradictions. And you ignore all but "pak128.britain users using auto updater". You haven't been able to offer any solution to my point. That's what I point out that you only think of your own benefits. In other words, a person who updates only the game version without knowing the existence of the patch will not get any advantage. Do you make it the person's responsibility?

- My second point is that this patch makes the pedes_and_car_info option in simuconf.tab obsolete and almost worthless. (The same is true even if the parameters are split.) Compatible but not recommended for use. Must be changed by the player's explicit intention to reset to that setting each time the game is launched. It can be replaced by display setting from now on. You were terribly obsessed with and opposed the simuconf.tab setting its existence. I think you are fixated on very trivial matters.

EDIT:
Thirdly, pedes_info and car_info are very bad parameter names....

[Mariculous]

https://github.com/irgend42/simutrans-extended/commits/simuconf-display-setting-refinements
Feel free to pull or cherry pick any of the changes being made.
Changes are well described in the commit message.
I state that neither "all people not using pak128.britain" are ignored nor will this introduce any additional incompatibilities.

The almost wortless point, I can partly agree with but on the other hand especially with the effect on user preference loading it is advantageous being able to set these independently if one really wants to set this in the config.
The same almost worthless point applies to your slim pedestrin. Almost worthless is still worth.

About parameter names, these simply stick with tree_info, ground_info, townhall_info and pedes_and_car_info and are just as bad or good as those.
Changing the name to anything different is not a big deal.

[Ranran]

Feel free to pull or cherry pick any of the changes being made.

Interesting, nothing I expected as an explanation was added to simuconf.tab. I explained it repeatedly because it is important. But you don't. So I believe that you never try to help a beginner understand because it is enough for you to only you can understand it. (That's what I'm saying repeatedly.)
- Why "delete" old parameters? It obscures things. You didn't explain it, you just hid its existence. Who knows that compatibility remains? You said we can find it by searching, but it doesn't exist there. You are an imposter!
It must exist for compatibility. It definitely has a past that existed in extended, and standard has it too. Where did it go? How is it currently handled? Yes you know, but what can tell us? You hide the facts and create confusion. So we have to describe more explanations there. That's why this separation has no advantage for anyone other than a veteran like you.

- What I think must be stated there is that if player uncomment them, it will be reset to that value each time you launch the game.
This is one of the reasons this thread was created. In addition, you are leading to its recurrence. Not only is there no explanation for it, but add a unique parameter, which overwrites the old setting.

- Overwrite relationship for three parameters. (The one is that have been deleted by you)
The overwrite relationship I said does not mean that pakset's one will overwrite it. But talking about overwriting by another folder, it's not limited to "display settings". If pakset's one doesn't have those (parameter) lines, the player wouldn't normally add additional lines to it. When it is done, it is intentionally executed. So it is enough to remove those lines from pakset's one.
And why put a warning to the pakset author there? Is it an item that every player should see?
What I said "overwrite relationship" is the strength relationship with the old parameters. Despite what I said many times, you deleted the old parameters to hide and obscure things. We have to explain how those three seemingly conflicting parameters work.
It is necessary to add so many explanations, and not all simutrans extended players are native English speakers. I've already explained that, right?
You make things complicated and difficult to understand.
You are only confident that you will definitely benefit, ignoring those who suffer. This is because, despite repeated requests, you have given very little of the necessary explanation and even tried to hide it. In that respect, I think it has become clear from the discussions so far that I and you will never understand each other. There was a similar discussion before, but the point is the same.

Also note that the difference from standard will be large. All I've done is extend what was up to 1 to 3 so the difference is small. What I'm reiterating is whether (*)changes (and increments) are really needed and beneficial. (*)Note that you are throwing out the coding halfway and there is not enough effort at all. (check the end of the post)
Which is easier for the "reader", if we just need to add a description for the values 1 to 3 or if you have to add a lot of description? Is it preferable to pollute simuconf with a lot of explanations? Do players have to read it? And will newbie be scolded by veteran for asking a question without reading it? I'm not an English speaker, so it's difficult for me to tell things accurately in English with a few words.
However, simuconf should also be easy to read with minimal unnecessary explanations.
The show_names you decomposed should also be available in standard. I think the show_names decomposition is good◎. But note that the situation is not the same as pedes_and_car_info.


I wasn't accusing you of being a new player, I was saying you should think from the perspective of a new player. Sadly, that too was not understood by you. | ´ ・ω・ ｀ |

The same almost worthless point applies to your slim pedestrin. Almost worthless is still worth.

Interesting again. What you say is not worthwhile is usually worthwhile to me.
It should be noted that the slim pedstrian info is part of the experiment and the first step. This was intended to reduce large dead space and I thought it would be useful when playing on android or small monitor.

tree info, water(ocean tile) info and citycar info(in standard) etc.
Try opening them with pak192 or 256.

We don't need the two lines of information that an object that shouldn't have an owner doesn't have an owner. If we remove it, all that remains is the author and one additional line. Then, a slim dialog that is almost the same as a slimer pedinfo is sufficient.
That is, the code for this dialog can be used universally for those dialogs. I think convoy and even stations can have that additional minimization method. That was my future goal of slim pedinfo, but it has nothing to do with this thread. There is no doubt that they are worthless to you. But I don't have to mind it. I don't want to waste any more of my time because I don't need to hear any worthless selfish opinion. It is impossible that there is no dissenting opinion. That is the only outcome of this long discussion. ‖　´ ・ω・ ｀　‖

About parameter names, these simply stick with tree_info, ground_info, townhall_info and pedes_and_car_info and are just as bad or good as those.
Changing the name to anything different is not a big deal.

Yes, this is not a big deal, but interesting. That way my intentions never get through to you. Certainly, Japanese people expect too much from the other person's understanding.
I mean, tree_info was not tr_info, ground_info was not grou_info, townhall_info was not townh_info, but pedestrian_info becomes pedes_info by you. There is no single word omitted in the example you gave. Many times, you seem to be avoiding clarifying things.
Also "car" is ambiguous. I think it refers to what is expressed as citycar in standard and privatecar in extended.
I interpreted that they were only prevented from becoming long when they were united.
But after all I don't think there is any advantage to being decomposed that way. There is a Berlin Wall between us, which has become stronger and will never break. ┃壁壁｀・ω・´壁壁┃


And what you are missing. Your effort is not enough yet. You need to modify settings_stats.cc correctly according to your changes. If you are still worth the effort, please continue to do so.
But as I've explained many times, I think it only complicates things, and I don't think you're offering a solution to it. ┃壁壁壁｀・ω・´壁壁壁┃

[Mariculous]

I just picked this up in https://github.com/irgend42/simutrans-extended/commits/simuconf-display-setting-refinements
This has not been tested yet. It will be tested once a decision about settings_stats.cc was made (see below)

You said we can find it by searching, but it doesn't exist there. You are an imposter!

That seems a bit harsh. I assume it's a translation issue.
I suspect, the following went bust when reordering simuconf in the second commit.

# The following two options replace the pedes_and_car_info, allowing both information windows to be enabled independently of each other.

That description was not quite well worded anyways, so I just wrote a new one, which also mentions how overriding between those three works.
Although in my opinion the only thing a player needs to know about this is that he should use pedestrian_info and car_info instead, now it's there and I guess that's fine as well.

What I think must be stated there is that if player uncomment them, it will be reset to that value each time you launch the game.

Line 3. should state this.
Surely I can reword this. If you have anything specific in mind, please let me know.

1. ################################# Display settings  ################################
2. # Use with care
3. # Settings made here will override player preferences set via the Display settings UI
4. # Do not set those in simuconf unless you know exactly what you are doing!

Removed the pakset author line. They clearly need to be aware of this but simuconf might indeed be the wrong place to state this.

You need to modify settings_stats.cc correctly according to your changes.

Thanks for noting.
I see that the same applies to show_names.
I was not aware that those display settings exist in settings_stats as it seems to be quite unusual for display settings to exist over there.
In fact, the only ones that exist in both are left_to_right_graphs, show_month, show_names, pedes_and_car_info and follow_convoi_underground.

Which yields a new question to me:
Is there a reason for these to exist over there whilst the others don't?
If not, should simply drop these from the general settings dialogue.
I have moved that discussion to a different thread in the standard board as standard seems to be affected as well.


Last but not least this seems to be a huge missunderstanding.
There have been many missunderstandings in either direction. It might be a translation issue but this one feels extremely harsh.

I wasn't accusing you of being a new player, I was saying you should think from the perspective of a new player. Sadly, that too was not understood by you.

I am not sure if that's the translator but this feels to be quite accusing.

In fact, I did understand the above and I did not feel accused as being a new player, thus I answered:
"I remember being confused of about ..., when I was a rather new player ...",
which means at some point in the past, I was a new player, and at that time I was confused about something.

What was I confused about?
" ... of options being in a different category and called differently in the new map settings UI and simuconf ..."

I then continued
"I'd expect to be just as cofused about parameters being represented differently in between simuconf and the UI."
Which means, nowdays as I am not a new player anymore, I would expect to be confused about "parameters being represented differently in between simuconf and the UI"

Finishing this as "But who knows? I'm not a new player anymore."
Which means, any thoughts about what would be if I were a new player being confronted with this is purely speculative. I can imagine how it could be, but as I am a human, I cannot entirely disable my knowledge I obtained about this topic in the meantime, so any speculation about this might be wrong.