Prevent overwriting of default maps

[Delphik]

It is possible to save over the default maps in edit mode, breaking potentially breaking game-play on maps and facilitating cheating. I ran into a new user in the discord very frustrated about encountering this issue, and he had to reinstall to fix it.

[SalatielSauer]

Hi, in TQ it is not possible to overwrite a default map by mistake (i.e pressing F5 unintentionally), the bind itself checks if the map name is included in the list of official maps, however it is possible if you manually type /savemap...

By hardcoding this limitation, we would be hindering the process of saving official maps, not preventing it. (after all, we need to be able to change official maps in an easy way :D )

Regarding cheating, the server detects (or should detect) players who have a modified version of the map and force them to spectator.

[Delphik]

I considered the issue for the developers. Perhaps when using the command to overwrite official maps, we could prompt users with a warning, and have a ( y or n) confirmation? I'm still trying to help that guy from before through a language barrier.

[yellowberryHN]

I have a suggestion on how to fix this problem that I plan on implementing in my own fork.

1. In the C++ code, create a temporary variable (VAR) called forcesavemap that is set at 0 by default.
2. Add a check in savemap that checks if the map you are trying to save already exists in the pool of official maps, which could be defined in CubeScript even.
3. If forcesavemap is disabled, prevent saving the map.

When wanting to change an official map, the editor can just run /forcesavemap 1 when they would like to save.

I feel like it solves both issues at the same time.

Also, on the issue of modified maps and cheating, the server forcing them to spectator isn't exactly communicated to the user effectively, so if there is say a language barrier, it makes it difficult to understand why you can't play if you've accidentally saved a map over an official one.

[Delphik]

1. In the C++ code, create a temporary variable (`VAR`) called `forcesavemap` that is set at 0 by default.

2. Add a check in `savemap` that checks if the map you are trying to save already exists in the pool of official maps, which could be defined in CubeScript even.

3. If `forcesavemap` is disabled, prevent saving the map.

I like this solution better than what I proposed. Simple enough for advanced users, and won't risk tripping up new users by default.

[SalatielSauer]

@yellowberryHN sounds good, but what if we could prioritize maps saved in the main folder?
This confusion occurs because when we save an official map it goes to the custom maps folder (which receives priority when loading maps), while its original version remains in the main base folder... I'm not really sure if this is possible.

[janitor-raus]

My suggestion is slightly different. Allow the saving of maps that match the names of official maps, but put up a warning prompt the first time one attempts to "overwrite". If they opt to proceed, that's it, the map is saved with that name, and the prompt will not appear again for as long as that map is in session. It will only appear again if the map changes to a different one. If they decide to not overwrite, the name of the map is changed upon saving like in the picture above.

One question I have though is how exactly the numbering works. What if an official map was named "map_2" for example? :P

[yellowberryHN]

From what I know about the virtual filesystem code, there is no real good way to differentiate between the game directory and the user directory, as in game they are treated as if they were the same directory

[janitor-raus]

From what I know about the virtual filesystem code, there is no real good way to differentiate between the game directory and the user directory, as in game they are treated as if they were the same directory

The game's default map list is defined manually anyway, not generated on the fly. Throw that as a hardcoded array in the source somewhere and reference it on the checks. Not really an issue.

[qreeves]

In Red Eclipse, I decided trying to prevent overwriting default maps was a little excessive and never liked how this worked in AssaultCube, so I opted to have the map synchronised between clients by way of CRC's. The server will check if it has the requested map and use the version it has if available, otherwise it will ask a client for their copy of the map in order connection time to the server from longest to shortest.