Give non-debug users a view-all option

[Astuur]

When somebody who cannot use the debug version, wants to test a map or see some effect of things he has modified,
he can only use the editor for a static picture, or a replay (no stepping back there!) to get the full overview.
This is a very uncomfortable procedure.
My suggestion is to implement some way (starting parameter?) to be able to see what is happening on the full map from the very beginning of a developping game.
I could also imagine that this option could be set inside the editor for new maps (self created, auto-created or self modified) only, and disbled for officially distributed maps. That would be a little more restictive policy which may be good.

[Hans Joachim Desserud (hjd)]

I see your point. I ran into the same problem when making maps for Heroes of Might and Magic 3. There, one of the factions can get a special building which let you see the entire map, so when testing I set my starting position to that faction with that building built. As Widelands don't really have any buildings like this, it is not possible to do the same here. (I should add that this building was only available if you found the holy grail, which in some cases were the objective of the game, so it was not easy to get hold of in normal games)

Though my first concern reading your proposal is cheating. Especially in multiplayer I would like to know that the other player does not have access to viewing the entire map. How do you plan to prevent this? The obvious problem with setting it in the map is that people will be able to change the map before running the game, so that's not really a guarantee for anything. So while I do see the need, I think we should be really careful to avoid giving players some way of gaining unfair advantages.

Maybe the solution would be to only check for this parameter if a map is specified when starting Widelands. That way a mapmaker could run "widelands --scenario=map_work_in_progress.wmf --view-map" to see the entire map, but "--view-map" would be ignored on its own. (Though from my brief testing here it looks like scenario only loads campaign maps, not regular maps, so I don't know if this is feasible)

[Astuur (wolfsteinmetz)]

Hello HJD -- nice to hear your voice among the general silence :)

Again you are promoting me to a programmer :)
Honestly, the "How-to" (or how to prevent ...) is a question that somebody who knows how to code can answer much better, than I can.
But I can at least try to answer this in a more general way.
When you offer a multiplayer-enabled game, especially such a highly configurable one like Widelands, with a lot of editable files, I think, the program should check a few things in order to assure a fair, competitive gameplay,
as soon as the multiplayer option gets enabled.
Is this the same version of WL ? (host and all clients)
Are the conf files the same throughout all players?
Maybe some more things as well....?
Does Widelands do so?
If not, such a routine should be programmed, IMO.
So, why not have the multiplayer mode check a flag that gets set when "view all" is enabled?
_If_ the state of the flag is not the same for all participants, _then_ give a meesage and offer to make it so.
_Else_, close the game with a "sorry - "no cheating allowed" message for the clients.

Most options should be allowed to differ though, like font, resolution, Open-GL, Sound, FullScreen etc.

I guess a CRC check would not help for the executable, given all the different OSes WL may run on,
so, a version check must do here, but it may help with ensuring uniform conf files and a uniform "visibility option".

However,I would not opt for a hardcoded CRC value inside the .exe for the conf files, to allow their modification, if it is the same for all players.

But as I said - the "how to" is coder's wisdom, and so not mine :)

[Hans Joachim Desserud (hjd)]

> Is this the same version of WL ?
I have translated some strings related to this, so this check should already be in place. Not sure how thorough it is, as I have not looked at the actual code. I believe it at least checks the version number.

>So, why not have the multiplayer mode check a flag that gets set when "view all" is enabled?
With some tweaks, I think this could work. For single player you can check if this flag is set and load with the whole map visible to allow mapmakers to test, if it is not set the map is loaded with fog of war as today. Though for multiplayer I think it would be better to ignore this flag all together and load with fog of war no matter what, to keep multiplayer fair. (This of course depends on how common the code for loading a map is, if it is even possible) This would of course prevent mapmakers from testing with full map in multiplayer, but I can't think of any problems they wouldn't spot in single player off the top of my head. In summary: maps are by default loaded as today, unless the flag is set AND it is a single player map.

>However,I would not opt for a hardcoded CRC value inside the .exe
Implementing this would probably be a lot of effort with little to no gain. As Widelands is open source, it would be far to easy to alter the values, then recompile to allow their edited files to be accepted. (This also affects proprietary software, where checks like these are found and disabled or circumvented in order to run the program without the checks. I believe this is how various forms of DRM and similar schemes are circumvented, but I do not know the details.)

In general I think the commandline option would be the easiest way to implement this, and it would also save us from updating and adding another field to all maps created. Though I wonder how comfortable mapmakers would be with running widelands from the commandline?

[Nasenbaer (nasenbaer)]

Fix commited in bzr revision 5944. You are now able to select the new win condition "endless game (no fog)" for you single- or multiplayer game.
In multiplayer games the win condition is set by the host, therefore it is no more no less a chance to cheat. ;)

Btw.: Creadits go to SirVer, as I adopted the fix from his script for the "island hopping" multiplayer scenario currently under development.

[Astuur (wolfsteinmetz)]

UUiiii - that was a quick one :)
I'm perfectly happy with this solution, as it allows what I initially wanted.
So should others, I think.
Thank you VERY much, Nasenbaer !!

[SirVer (sirver)]

Released in build17-rc1.