Forced set topology "WRAPX|ISO|HEX" when loading ruleset
I uploaded to this ticket: https://osdn.net/projects/freeciv/ticket/47642 my modpack civ2civ3_earth, that I have been using for my tests, and I will use to report some more issues.
It can be used to check this bug, because it includes a non-hex custom tileset and the related setting "topology", "WRAPX|WRAPY|ISO"
The difference to 3.0.4 is that sending preferences from the client side after ruleset change were completely broken back then.
Depending on what you want, these might help:
1) Lock the topology in the ruleset, so user or client cannot change them
2) Set "for_ruleset" in the tileset, so the spawned server will launch directly to wanted ruleset, and there's no switching back and forth
3) Check what are your saved client preferences, and maybe add WRAPY there if it's missing (or just wipe entire topology preference, so it's not interfering)
I think that (1) gets redundant if you implement (2), and not doing (1) would leave user control over changing the topology.
Reply To cazfi
The difference to 3.0.4 is that sending preferences from the client side after ruleset change were completely broken back then. Depending on what you want, these might help:
1) Lock the topology in the ruleset, so user or client cannot change them
2) Set "for_ruleset" in the tileset, so the spawned server will launch directly to wanted ruleset, and there's no switching back and forth
3) Check what are your saved client preferences, and maybe add WRAPY there if it's missing (or just wipe entire topology preference, so it's not interfering)
I think that (1) gets redundant if you implement (2), and not doing (1) would leave user control over changing the topology.
My desired behavior would be that my tileset is automatically loaded whenever I select my ruleset, but every time I use a new freeciv version I have to change something in order to get it working. I'll see if I can get it right this time...
2) for_ruleset = "civ2civ3_earth" is already set in my tileset, but it seems to be ignored when the topology is hexagonal, because my tileset is rectangular
3) I plan to share this modpack with other players, and I'd like it to load the tileset by default without the need of changing settings. In my personal case, there are no topology settings in my saved preferences. But even if I save my desired topology setting (WRAPY, no HEX), it gets reverted to hexagonal every time I load my ruleset. I thought this was designed this way on purpouse (reload default settings and then ruleset settings every time a new ruleset is loaded, ignoring the saved preferences). Thanks to this, we ruleset authors do not need to force settings that are supposed to be the default ones, and we only include settings that are different compared to the default ones. I hope this is still the same in 3.0.
1) It sounds like what I want to achieve. How can I do that? As I said, I already created an entry in game.ruleset to force my desired topology:
set =
{ "name", "value"
"topology", "WRAPX|WRAPY|ISO"
}
but it is not working in 3.0.6.Reply To bard
Reply To cazfi
The difference to 3.0.4 is that sending preferences from the client side after ruleset change were completely broken back then. Depending on what you want, these might help:
1) Lock the topology in the ruleset, so user or client cannot change them
2) Set "for_ruleset" in the tileset, so the spawned server will launch directly to wanted ruleset, and there's no switching back and forth
3) Check what are your saved client preferences, and maybe add WRAPY there if it's missing (or just wipe entire topology preference, so it's not interfering)
I think that (1) gets redundant if you implement (2), and not doing (1) would leave user control over changing the topology.My desired behavior would be that my tileset is automatically loaded whenever I select my ruleset, but every time I use a new freeciv version I have to change something in order to get it working. I'll see if I can get it right this time... 2) for_ruleset = "civ2civ3_earth" is already set in my tileset, but it seems to be ignored when the topology is hexagonal, because my tileset is rectangular
All that is so complicated as people have so many different use-cases. Sometimes it's the tileset initiating the ruleset change (when you launch the client with specified tileset, and fork the server from there). Sometimes it's the ruleset/server initiating connecting client to change tileset (to matching topology - which client then selects based on settings, priorities, and various fallbacks). Then we have server settings coming from multiple sources, and especially the topology setting being one that affects the tileset choice.
3) I plan to share this modpack with other players, and I'd like it to load the tileset by default without the need of changing settings. In my personal case, there are no topology settings in my saved preferences. But even if I save my desired topology setting (WRAPY, no HEX), it gets reverted to hexagonal every time I load my ruleset. I thought this was designed this way on purpouse (reload default settings and then ruleset settings every time a new ruleset is loaded, ignoring the saved preferences). Thanks to this, we ruleset authors do not need to force settings that are supposed to be the default ones, and we only include settings that are different compared to the default ones. I hope this is still the same in 3.0.
From server point of view: 1) Server side settings get resetted to server defaults, 2) Ruleset settings are applied, 3) User can change settings that are not locked. Client sends its own preferences (in single-player games) as user requests on phase 3. That client settings were ignored (like you seem to expect them to be) was one of the most complained bugs for a very long time (We've still received at least four new bug reports about it *after* it was already fixed, but users still using older versions)
1) It sounds like what I want to achieve. How can I do that? As I said, I already created an entry in game.ruleset to force my desired topology: {{{ set = { "name", "value" "topology", "WRAPX|WRAPY|ISO" } }}}
That does not *force* the topology, but only sets it at ruleset load time. Add "lock" column and set it TRUE for "topology" to prevent user/client from later changing it.
All that said about expected behavior, I'll do some testing with your modpack as it sounds like you've encountered actual bugs too.
Reply To bard
2) for_ruleset = "civ2civ3_earth" is already set in my tileset, but it seems to be ignored when the topology is hexagonal, because my tileset is rectangular
./fcgui -t amplio_earth --warnings
...
2: .../rulesets/3rd/S3_0/data/amplio_earth/forest.spec: unused entry: spec.artists
"Start New Game" -> "Start" -> "Help" -> "About Current Ruleset" : "Civ2Civ3 Earth ruleset 3.0_2021"
That spec.artists should probably be info.artists, but warning is basically harmless.
3) I plan to share this modpack with other players, and I'd like it to load the tileset by default without the need of changing settings.
./fcser -r civ2civ3_earth --warnings
..
./fcgui
"Connect to Network Game" -> Select server + "Connect" -> Preferred Tileset dialog opens, suggesting loading "amplio_earth"
Reply To cazfi
3) I plan to share this modpack with other players, and I'd like it to load the tileset by default without the need of changing settings.
./fcser -r civ2civ3_earth --warnings
..
./fcgui
"Connect to Network Game" -> Select server + "Connect" -> Preferred Tileset dialog opens, suggesting loading "amplio_earth"
Oh, forgot the case of another tileset in use + spawned server + ruleset change:
./fcgui
"Start New Game" -> "Ruleset" -> "civ2civ3_earth" -> Preferred Tileset dialog opens, suggesting loading "amplio_earth"
All these tests (so far) with no topology preference on the client.
'grep "topo" ~/.freeciv/freeciv-client-rc-3.0'
shows nothing.
$ grep "autoaccept_tileset_suggestion" ~/.freeciv/freeciv-client-rc-3.0
autoaccept_tileset_suggestion=FALSE
Thanks for taking the time to check it. I have tested to remove my preferences file and you are right that it works as expected.
I have uploaded the "freeciv-client-rc-3.0" that is causing troubles for me, and I can't find any topology reference there. Could you please repeat your test with this file?
Reply To bard
I have uploaded the "freeciv-client-rc-3.0" that is causing troubles for me
Thanks. With that problems can be reproduced. It's related to the "default_tileset_name", which is a very ugly concept to begin with, but was required for the migration path from older freeciv versions. Can you tell if this file has been created from scratch with freeciv-3.0, or has it been migrated from some older version?
That does not *force* the topology, but only sets it at ruleset load time. Add "lock" column and set it TRUE for "topology" to prevent user/client from later changing it.
Your suggestion to lock the topology sounds like the best option right now.
I want to clarify that I didn't not open this ticket to get it working for me, I always end finding a way to get my desired tileset loaded. What I wanted was help to know the proper way to implement my modpack in a way that it can work for other people who may not know that it includes its own tileset.
That is why I did not try to remove the saved preferences earlier, I'd like to code my modpack in a way that can work for people that had different saved preferences without the need to ask them to delete them.
But I still don't know why my uploaded prefs file is forcing the hexagonal topology. Could it be the line: default_tileset_name="hexemplio"?
Reply To cazfi
Reply To bard
I have uploaded the "freeciv-client-rc-3.0" that is causing troubles for me
Thanks. With that problems can be reproduced. It's related to the "default_tileset_name", which is a very ugly concept to begin with, but was required for the migration path from older freeciv versions. Can you tell if this file has been created from scratch with freeciv-3.0, or has it been migrated from some older version?
Ah, ok. Yep, I think it has migrated from 2.6, but not from 2.5.
Reply To bard
Reply To cazfi
Reply To bard
I have uploaded the "freeciv-client-rc-3.0" that is causing troubles for me
Thanks. With that problems can be reproduced. It's related to the "default_tileset_name", which is a very ugly concept to begin with, but was required for the migration path from older freeciv versions. Can you tell if this file has been created from scratch with freeciv-3.0, or has it been migrated from some older version?
Ah, ok. Yep, I think it has migrated from 2.6, but not from 2.5.
Actually, it would be good if you can attach also freeciv-client-rc-2.6. That may enable us to reproduce also the migration path (if that turns out to be relevant).
Reply To cazfi
From server point of view: 1) Server side settings get resetted to server defaults, 2) Ruleset settings are applied, 3) User can change settings that are not locked. Client sends its own preferences (in single-player games) as user requests on phase 3. That client settings were ignored (like you seem to expect them to be) was one of the most complained bugs for a very long time (We've still received at least four new bug reports about it *after* it was already fixed, but users still using older versions)
I did not know about this new behaviour (I opened the ticket for the specific issue that you already saw), but now that I have tested it a bit, I find it very discouraging for ruleset authors like me. If I understood, when I share a modpack, and another player load it, all the preferences saved by the player before ever testing the modpack, will automatically overwrite the settings defined in the ruleset, and the player will never see the settings that the author used to design and test the rules.
I'll open another ticket to complain, or request an alternative, but I wanted to be sure that I got it right.
What you describe in your comment sounds reasonable:
1) Server side settings get resetted to server defaults 2) Ruleset settings are applied
3) The user, once he has seen the settings defined by the ruleset author, can change settings to his own taste, or load different settings
But what I see in my tests is different:
3) The settings saved by the user (god knows for what other ruleset) are automatically loaded overwriting the "default+ruleset" settings, and before the user can actually see which were those settings. Am I right?
Then, when I download a ruleset, the only way to play with the settings suggested by the author is to remove all my saved preferences before loading the ruleset. In other words, no one that have ever saved preferences while playing any other ruleset is going to play my ruleset with the designed settings, and most of them will never notice it...
And the only solution for the author is to "lock" every possible setting one by one (hundreds of them) so the player will be able to test the ruleset as it was designed, but will not be able to change any setting after that. I really hope I'm missing something and this is not the way it works now.
Reply To bard
3) The user, once he has seen the settings defined by the ruleset author, can change settings to his own taste, or load different settings But what I see in my tests is different: 3) The settings saved by the user (god knows for what other ruleset) are automatically loaded overwriting the "default+ruleset" settings, and before the user can actually see which were those settings. Am I right?
Well, the part "what I see in my tests is different" is not right. Just think that client = user. Server has no way of knowing if the settings that client sends are entered by the user just now, or is the client sending them otherwise.
However, if a user has decided that they want to set a setting to specific value in their preferences, they are in control. Related to this, another bug recently fixed (actually it was fixed first, just so that the issue you are worried about would not get realized as badly) makes client to select settings to save more carefully. It does save only those settings that have really been changed by the user, and not, e.g., those that some ruleset might have changed from the internal default.
And the only solution for the author is to "lock" every possible setting one by one
If you really want to make the ruleset author the one who is in control, instead of the end user, then yes.
Of course, e.g., giving users more control over which settings get saved would be good. Or maybe just a single setting to inhibit sending server setting preferences at all? (I would probably use that setting myself, even if I both 1) don't usually play on client-forked single-player server, but even on single-player want to have control over the server, 2) have almost no server settings saved as client preferences)
Well, I have been playing modded games (and modding games myself) my whole life and the only 3 options that I have ever needed in any game are:
1) load the default settings of the game (current reset in freeciv)
2) load the settings as defined by the user (my saved preferences): all of them, verbatim, the way the user saved them. Not comparing them to default settings that the user sometimes do not know, and loading only the differences.
3) load the settings as defined by the modder (or ruleset, modpack): the modder is supposed to know the default settings, so it is reasonable to load only the differences to default, but the modder can't know the user preferences, and I think they should never be mixed until the user decides to do that.
I use to test rulesets made by other modders, and the most important for me when I load them is to be able to test them exactly as they were designed, to know which features were enabled, which ones disabled, and learn about other design views.
I find important that these 3 options are available, and at the same time I think that any attempt to automatically mix them is a waste of time for the developer, for the modder and for the user. When a game tries to pick only the options that have been changed by the user and mix them with the options that have been changed by the modder, at the end it is a mess that neither the user nor the modder knows the settings being used by each other.
Of course, e.g., giving users more control over which settings get saved would be good. Or maybe just a single setting to inhibit sending server setting preferences at all? (I would probably use that setting myself, even if I both 1) don't usually play on client-forked single-player server, but even on single-player want to have control over the server, 2) have almost no server settings saved as client preferences)
I know that freeciv is a complex client-server program that I don't really understand, that it is hard to satisfy every user, and I'm not active enough to be the one making suggestions, but I'd suggest something like having these 3 buttons in the client preferences window:
- Reset: all settings set to default (as it works now)
- Load: all settings set to default, then load the settings saved by the user (those that changed compared to default), so the result is verbatim to what was saved.
- Ruleset: all settings set to default, then load the settings defined by the ruleset (those that changed compared to default).
Note that there are also user control levels in play - though in local single-player game user usually has the maximum rights. Freeciv-3.2 adds server operator ability to lock some settings so that not even custom rulesets can change them - required on public servers. Further, different settings can be altered different times - some properties cannot be changed mid-game etc.
Yeah, this used to be much simpler when server settings lived completely on the server side, and client touched only its own options, but apparently now that the client has the ability to launch the server it's also expected to control settings for it. It was also simpler when there was clear distinction between ruleset data and server settings (I don't think people thought about losing that clear distinction when rulesets were given the ability to set also settings)
Reply To bard
- Ruleset: all settings set to default, then load the settings defined by the ruleset (those that changed compared to default).
Sounds very bad option. I definitely don't want ruleset to define my network settings, or worse (there would definitely be cybersecurity implications here)
It was also simpler when there was clear distinction between ruleset data and server settings (I don't think people thought about losing that clear distinction when rulesets were given the ability to set also settings)
Right, I never saw the distinction between the game settings defined in the game.ruleset file and most of those settings that are called "server setting" but have the same capability to alter the rules.
If it was possible to save all those "server settings" to a file, and the file was named "settings.ruleset", I'd see no difference with any other ruleset file, except maybe the "network settings" that you comment that could affect security.
The current implementation where server settings are saved in the preferences of the client (freeciv-client-rc-3.0) makes no sense to me too. But again, I don't know enough about the arquitecture of freeciv to suggest any change in this aspect.
As user, I don't care where they are saved, as long as there is some kind of "save" and "load" button (and related command) in the client that allows me to load the server settings exactly as I saved them, and a "reset" button to restore the defaults. I'm talking about the case where the client launches the server and it is the client who selects the ruleset and the settings.
I think that is all I need to get my desired functionality. In order to load the server settings designed by the ruleset author, I'd need to:
1) Make a copy of freeciv-client-rc-3.0 and name it "My Settings"
2) Start a new game with the client. Click "more game options", click "reset", then click "save", to clean the preferences file (freeciv-client-rc-3.0 in this case)
Make a copy of freeciv-client-rc-3.0 and name it "Default Settings"
-> From my tests, this is not working this way right now: when I open freeciv-client-rc-3.0 I can still see server settings saved there.
3) Load the ruleset, open "more game options" and click "save"
Make a copy of freeciv-client-rc-3.0 and name it "Ruleset Settings"
Could you please confirm if this is possible right now? If not, this would be my wished request.
(Noticing that this is getting a bit off-topic for the exact bug in this ticket, but don't think it's a big problem in this case)
Maybe you want to investigate server side commands "write" and "read"
help write
Command: write - Write current settings as server commands to file.
Synopsis: write <file-name>
Level: hack
help read
Command: read - Process server commands from file.
Synopsis: read <file-name>
Level: ctrl
Maybe aifill is an examples of a setting that would not fit so well to your wishes, even if you adjust it so that *some hardcoded* set of settings are ruleset defined, instead of mixing ruleset and user settings freely. Certainly some rulesets are designed for a specific number of players (e.g. number of nations available). But I don't think that *all* rulesets should be dictating number of players.
And about the security aspects, it's not just networking and file handling (savegame related ones etc) settings that have it. There's a lot of game world related settings that affect performance / resource usage.
I've never been fan of the client handling server settings at all, but seems that it's what users want (including you, from a number of comments). Would be much cleaner that server settings would be on the server, and client options on the client.
Somewhat related to all this, there's a ".modpack" files feature coming. It's early form exist in freeciv-3.2 already, but likely all the really interesting stuff comes only later. In short, ".modpack" should act as the toplevel file controlling all aspects of the combined modpack, regardless if it's server side (ruleset is a "child" of modpack) or client side (tileset is another "child")
I've got a bunch of ideas from this discussion. Already working on a client option to control sending of desired server settings: #47673
>I've got a bunch of ideas from this discussion. Already working on a client option to control sending of desired server settings: #47673
Sorry about the off topic, tomorrow I planed to open a new ticket with a little request related to this "client option to control desired server settings".
---
I knew about server read and write, but never felt the neccesity to use them until now. I admit I'm a GUI guy, I'm not good at remembering console commands from one year to another.
---
I do like that server can be launched from the client, I always use it this way, but it is sometimes too evident that freeciv was not really designed this way. For example, when I want to play a hot seat game, either I need to open in the same pc 1 server and 2 clients and switch between them, or use every turn the command "/take playername".
---
That Modpack feature sounds interesting. I'm just a bit concerned about the ammount of duplicated settings that already exist related to this feature: that a ruleset and a tileset are loaded together (although I find important that they can also be loaded separately, and I understand it is not easy to implement). As I commented in the other topic, they appear new related settings in every freeciv release: you pointed recently 3 of them, and there is another one in game.ruleset (preferred = "tileset"). I try to use them all, and I still have troubles to get both loaded at same time. I appreciate that you keep working to improve it. I like things to be as simple as possible, but I can handle complexity if it is the only way to satisfy all possible use cases.
>Maybe aifill is an examples of a setting that would not fit so well to your wishes, even if you adjust it so that *some hardcoded* set of settings are ruleset defined, instead of mixing ruleset and user settings freely. Certainly some rulesets are designed for a specific number of players (e.g. number of nations available). But I don't think that *all* rulesets should be dictating number of players.
From this comment I see that either you did not understand what I try to say, or there is something I still don't get about server settings. Probably because I don't use the right terminology... when I say "the user loads the settings" I actually mean "the server settings are shown in the client GUI" (I'm not sure when are the settings actually sent to the server).
As I understand it, for every server setting already exists a default value, and rulesets only need to define/set the ones that are different to these defaults. If a ruleset doesn't define number of players, a default number of players is loaded. But I guess you were questioning the paradigm of allowing the ruleset to set the number of players in the first place, and you might be right.
In my wish, when the user selects the ruleset in the client GUI:
- Default+Ruleset server settings are automatically loaded (shown in the client GUI), with the option by the user to change them manually, or by loading its own saved user settings.
- or the other way around, the Default+User settings are automatically loaded, and there is a way for the user to load Defaults+Ruleset. (I'm talking about an option available in the client GUI).
- if an unpredictable mix of User + Ruleset settings is loaded, all I ask is a way to unmix them by using the GUI buttons ("reset", "save" and "load" should be enough).
But I personally think that nobody really wants a mix of user+ruleset settings, it will never be a coherent set of rules, nobody has ever tested that mix, nobody has chosen them, and it makes the user unaware of the settings really suggested by the ruleset author.
I'll don't insist on this, I just wanted to try to clarify my point.
Reply To bard
As I commented in the other topic, they appear new related settings in every freeciv release: you pointed recently 3 of them, and there is another one in game.ruleset (preferred = "tileset"). I try to use them all, and I still have troubles to get both loaded at same time. I appreciate that you keep working to improve it. I like things to be as simple as possible, but I can handle complexity if it is the only way to satisfy all possible use cases.
Actually, I hope that ".modpack" as a central piece obsoletes some of these existing settings all over the place, and makes at least modpack author's view simpler (not yet entirely sure if freeciv code gets simpler or more complex)
One thing I missed earlier is that "topology" behaves differently to any other setting (and that's actually the reason why "wrap" has made separate setting in 3.2, so that it would not be tied to same special treatment) - as map and tileset topology must match, client make special request (i.e., it's not one of the "desired server settings" ones) for the server to change map topology to match user's choice of tileset. I think the bug we are facing in this ticket is in how client determines that the tileset choice really is one made by the user -> that user expects it to be used and the server side to adjust.
Reply To cazfi
I think the bug we are facing in this ticket is in how client determines that the tileset choice really is one made by the user -> that user expects it to be used and the server side to adjust.
In previous versions, it appeared a popup question asking the user to change the tileset to the one suggested by the ruleset. Could the change (or not) of topology be linked to this question too?
A possible problem I see is the case where a ruleset is selected to play an scenario. In that case I see 4 different sources of topology:
- scenario's map
- tileset: must fit the topology hex or square. Although I always found unnecessary to force a match between being isometric or not.
- ruleset: topology affects the number of units needed to surround a certain unit, so it affects gameplay and its balance.
- user: preference stored in the client.
As I said, I don't like when apps try to guess the users preferences and mix them automatically. I prefer when user can clearly decide which of the 4 will have priority. But I do not know enough about how freeciv handles this internally to make any suggestion, apart of the obvious: try the result to be as predictable as possible for a user that does not know the internal code.
Reply To bard
Although I always found unnecessary to force a match between being isometric or not.
And it's no longer done in freeciv-3.0.
the result to be as predictable as possible for a user that does not know the internal code.
Hmm, ok, but then "predictable" here means different than "expected". The reason it's currently so complicated is that new users expect things to work certain way, and that "certain way" depending on how they themselves approach it. E.g. users who set the tileset as the first thing when they launch freeciv, expect that things "just work" (that map topology then matches the tileset they chose). One of the main reasons people tried to launch freeciv just once and then gave up was that this didn't happen automatically, but there would have been need for complex server-side adjustments.
Another ticket spun off -> #47699
Reply To cazfi
Reply To bard
Although I always found unnecessary to force a match between being isometric or not.
And it's no longer done in freeciv-3.0.
Oh, I didn't realized, I prefer it this way.
Hmm, ok, but then "predictable" here means different than "expected". The reason it's currently so complicated is that new users expect things to work certain way, and that "certain way" depending on how they themselves approach it. E.g. users who set the tileset as the first thing when they launch freeciv, expect that things "just work" (that map topology then matches the tileset they chose). One of the main reasons people tried to launch freeciv just once and then gave up was that this didn't happen automatically, but there would have been need for complex server-side adjustments.
I admit you are right, I prefer a "predictable" result, but many users will prefer an "expected" result that may require a mix of settings and lots of work from developer to try to guess that "expected" result. I understand now why this attempt to get the "expected" result has to be the default one.
For me, It is possible to get "predictable" results while using directly the server. I suppose my wish would be an alternative to get this kind of predictable "all or nothing" results when using the client.
My modpack uses iso topology (non-hex) and includes its own tileset.
The file game.ruleset includes this setting to force squared isometric topology:
set = { "name", "value" "topology", "WRAPX|WRAPY|ISO" }In 3.0.4 it used to work, and the right topology and tileset were loaded.
In 3.0.6, when I start a new game and select my ruleset, my custom topology and tileset are temporary loaded, but then it automatically appears the command: set topology "WRAPX|ISO|HEX"
and the default tileset "hexemplio" is selected again:
I have to manually change "More game options", to unselect "Hexagonal" and select WRAPY every time I start a new game in order to use my desired topology and my custom tileset.