Conversation
this also adds the option to disable the chat messages with the g_bpTransferNotify cvar
this commit introduces the command: /updateBPVampire, to be used when manual changes are made to the BPInitialBudget, it can be removed later once a better system is in place for storing the stolen BP. this commit also replaces the use of a loop with the G_UpdateBPVampire( -1 ) function.
DolceTriade
left a comment
There was a problem hiding this comment.
looks good. some minor cleanup
DolceTriade
left a comment
There was a problem hiding this comment.
I think this is plenty good to iterate on.
cu-kai
left a comment
There was a problem hiding this comment.
I think this is a good start, based on the small number of games I've played so far. Like @DolceTriade said, we should iterate on this as required. I believe it may require more testing and fine-tuning, but with more servers able to access this mode, gathering feedback will be easier.
I do have one request though, @sweet235 can you provide easy-to-understand instructions for server hosts to enable this? For example, are there any other ideal cvar values to be set?
| static std::vector<buildable_t> alienBuildables = { BA_A_SPAWN, BA_A_BOOSTER, BA_A_BARRICADE, BA_A_ACIDTUBE, BA_A_TRAPPER, BA_A_SPIKER, BA_A_HIVE, BA_A_OVERMIND }; | ||
| static std::vector<buildable_t> humanBuildables = { BA_H_SPAWN, BA_H_MGTURRET, BA_H_ROCKETPOD, BA_H_ARMOURY, BA_H_MEDISTAT, BA_H_REACTOR }; | ||
|
|
||
| static void ResetDestroyedBuildables( team_t team ) |
There was a problem hiding this comment.
Doing it per-team is pointless. Just memset the whole thing.
There was a problem hiding this comment.
That part of the code shows my uncertainty about what how to do this. I thought that sending such messages to clients at each frame could be too much in some situations. So I tried to keep the code flexible enough to accumulate the destructions over several frames in later PRs.
A related problem is that the client only shows the latest destruction message in the HUD, overwriting an older and maybe more important message there.
One problem with accumulating on the server: at a destruction, the server would have to wait a little for eventual additional destructions. That would introduce a delay noticable to players.
| bool hBlink = false; | ||
| bool aBlink = false; | ||
|
|
||
| const Color::Color humanBPColor = Color::Color( 0.0f, 0.0f, 1.0f, 0.5f ); |
There was a problem hiding this comment.
constexpr or static const (so it doesn't occupy memory in the object)
There was a problem hiding this comment.
Does this work with something not known at compile time like Color::Color( 0.0f, 0.0f, 1.0f, 0.5f )?
There was a problem hiding this comment.
How is that not known at compile time?
The thing with constexpr is that the class has to specifically support it, so that's why I suggested static const in case it was not implemented.
There was a problem hiding this comment.
How is that not known at compile time?
I do not know. My compiler does not accept either.
Maybe we could add scripts |
This is explained in #3284.
Maybe later. But I doubt this will be neccessary. |
Why do I think that? The only required adjustment is that miners have to be disabled. In case a map layout contains miners, it is also good idea to set the BP per miner to zero. One solution would be to disable miners automatically and also omit placing miners from a map layout automatically. But this PR is already long enough, so let's save that for a later discussion. |
|
LGTM. Don't forget to squash! (you can add the Co-Authored-By lines for multiple authors) |
As explained in #3284 and seen on the map testing and bug squash central servers.
This is the unchanged development branch from which I removed a few temporary commits.