-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add all classic S2 cheats and a few more #1679
base: master
Are you sure you want to change the base?
Conversation
Wow, great effort. |
|
||
bool Cheats::canCheatModeBeOn() const | ||
{ | ||
return world_.IsSinglePlayer(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we can extend this to be a setting inside the create game screen, to allow cheats in multiplayer too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could certainly create an "enable cheats in multiplayer" addon or something similar, but it would be useful to ask which of these cheats make sense in multiplayer. I don't really know a reason to enable most of them since they are so game-breaking.
On the other hand, I guess they could help in debugging, giving someone a handicap (experienced player sees FOW, newbie sees everything; experienced needs geologists, newbie sees resources, etc.) or eliminating the need to send geologists anywhere.
I don't think we should enable cheats in multiplayer, even with addons, I don't see a use case. For balancing reasons we should rather add some real balancing options instead of cheats (which most people are not aware of I think) |
I will place a PR for the first three commits of this one and then add one PR per cheat/feature. I didn't want to do this in the first place because the refactoring may have seemed pointless, but now that a couple of people have seen the results this can bring, I think the first few commits can be merged without much issue and then each cheat can be considered on a case-by-case basis instead of a big blog that is difficult to review. |
I agree. It should only be for debugging/map debugging or some fun, not disturb multi-player games |
…ass "CheatCommandTracker"
Refactoring of existing cheats (see #1679)
I would happily split these cheats into separate PR's, but they all rely on the refactoring, so at least the first few commits would have to be merged before any split can be done.
The all-visible and build HQ cheats are useful for testing campaign scripts, which I have also been working on. The remaining S2 cheats are there mostly for feature parity and setting speed does not work the same as it did in S2 (certainly not fast enough, probably steps are different too).
The reveal resources cheat can be useful not only in gameplay but in debugging as well and the destroy buildings cheat is useful for testing the world campaign progress where the player needs to achieve total domination but also not destroy themselves (as they would with the armageddon cheat).
Related to issue #72