Skip to content
This repository has been archived by the owner on Jan 6, 2024. It is now read-only.

Prevent overwriting of default maps #61

Open
Delphik opened this issue Nov 7, 2020 · 9 comments
Open

Prevent overwriting of default maps #61

Delphik opened this issue Nov 7, 2020 · 9 comments

Comments

@Delphik
Copy link

Delphik commented Nov 7, 2020

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
Copy link
Member

SalatielSauer commented Nov 7, 2020

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...
image
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
Copy link
Author

Delphik commented Nov 7, 2020

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
Copy link

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
Copy link
Author

Delphik commented Nov 7, 2020

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
Copy link
Member

@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.

@coornio
Copy link

coornio commented Nov 9, 2020

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
Copy link

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

@coornio
Copy link

coornio commented Nov 9, 2020

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
Copy link
Collaborator

qreeves commented Nov 10, 2020

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants