Unvanquished
Unvanquished copied to clipboard
add g_bot_minPlayers cvar
fix #1786
The current result is buggy, as in, more bots than necessary are created, and excess bots are placed as spectator instead of removed. I do not know why yet. @slipher if you have an idea about that...
There are roughly 3 times the number of requested bots here.
When I join or leave the game, a bot is corrected added or removed from the team I joined. I feel like spectators teams are explicitly filled too, for some reason.
You may want to call G_BotFill(true);
I don't know why the current code wouldn't work, but there is some missing functionality. It ought to respond to changes in the cvar rather than only using the value at game init. Otherwise the cvar won't work if you put it in map/default.cfg
for example.
You would also want to set level.team[team].botFillSkillLevel
to the matching cvar
You may want to call
G_BotFill(true);
Probably not. Doing stuff in the very first frame is usually a bad idea. And the filling will happen after 2 seconds anyway.
I don't know why the current code wouldn't work, but there is some missing functionality. It ought to respond to changes in the cvar rather than only using the value at game init. Otherwise the cvar won't work if you put it in map/default.cfg for example.
Right. I should rename it g_bot_default_min_players then.
You would also want to set level.team[team].botFillSkillLevel to the matching cvar
No, this actually works, because it's handled downstream in the code to add a single bot, which is called by that.
Doing stuff in the very first frame is usually a bad idea.
I wonder if this is not the problem I'm facing, for some reason...
And the filling will happen after 2 seconds anyway
Even with "immediately = true" ?
And the filling will happen after 2 seconds anyway
Even with "immediately = true" ?
No, I'm saying you don't need to fill it immediately because it will be done later.
I don't know why the current code wouldn't work, but there is some missing functionality. It ought to respond to changes in the cvar rather than only using the value at game init. Otherwise the cvar won't work if you put it in map/default.cfg for example.
Right. I should rename it g_bot_default_min_players then.
I don't think that's an excuse to make a feature that doesn't work reliably...
I don't think that's an excuse to make a feature that doesn't work reliably...
Of course, I don't intend to push this until it's reliable. Right now it's draft for that very reason.
Probably not. Doing stuff in the very first frame is usually a bad idea. And the filling will happen after 2 seconds anyway
@slipher You are right. And this is what current code actually does, I think. Or rather, it probably does that even before the 1st frame.
I updated the code to introduce a rather ugly hack, that is, don't /bot fill
before the game is 2s old, and it fixes it.
The problem was, bots were added once, and then the code runs G_BotFill()
anew, but bots didn't had the time to actually connect, so the game runs N*2 more G_BotAdd() calls.
I think the current hack is okayish, it's certainly good enough for me to run on my mod, but I would prefer a cleaner way to merge this into 0.54. If you have an idea, I'm all eyes open (can't use ears on my screen).
FWIW this code should be "correct", or rather good enough. It works with no known bug, but the bug might happen on very slow system where bots take more than 2s to connect.
The code as currently written does not work for setting the number of the bots in the current game. This means it would not work in a map config. So it should not be merged in the current state - it's a bad user experience if there is more than one way to configure something but only one of them actually works correctly.
This means it would not work in a map config.
Indeed, it would only work if ran prior to map config. I edited the description to make it obvious. This is kind of a different feature than /bot fill
in current state, sadly.
it's a bad user experience if there is more than one way to configure something but only one of them actually works correctly.
On this I agree, but I don't consider the map config is the correct place for such a feature (setting number of bots), and map rotation is a much better one.
OTOH, the map config allows to affect individual bots with specific skill and behavior, and to have per-team numbers, and I have no idea how I could get this "upstream", as in, in server's config or map rotation.
If you have any idea as of how to "watch" a cvar's value change and run a /bot fill
command IG instead, I'd be glad to hear about it...
The main problem is, I need to update some property of the level.team[];
member.
An "easy" solution would be to have 1 cvar per team, and just replace that thing, but it would mean /bot fill
would only modify the cvar's content, which feels really bad to me.
It's often considered that the appropriate number of players is different for different maps. So it could make sense to set a different fill number depending on the map. Therefore setting the bot fill should work in a map config.
Therefore setting the bot fill should work in a map config.
but a bunch of per-map configs is harder to maintain than a single maprotation file, especially if at some time we start to have per-layout configs, and layouts are chosen by map rotation
[edit] For example, you would create 100 per-map files to only adjust the number of bots for those? It's silly. And yes, there is around 100 maps ported or official by now, even if of those, only ~10% can be reasonably considered F0SS
In any case, I'm fine if this is not merged today. The code is here and working for those willing to use it, it's the most important thing.
The code as currently written does not work for setting the number of the bots in the current game.
This is now fixed. The only "problem" (or rather missing feature) which remains here is that this applies to all teams, so I consider this still needs improvements, but I'm not sure about the best way for that, as I'm not at all fond of the idea of multiplying by 3 all cvars and related code that applies to team because there are 2 teams (+ the "both teams" situation).
If anyone have an idea to solve this problem, it would be really nice.
With Lua, this becomes a simple Lua script, but I see the value of having this baked into the code itself.
With Lua, this becomes a simple Lua script, but I see the value of having this baked into the code itself.
Imo that kind of "change" should be accessible to non-coders, such as people willing to host a LAN game. There is also currently no official Lua in gamelogic itself, and while I think it might be a useful feature later, it still need to be actually done, and for such a trivial matter I don't think Lua is worth it. The only important stuff which was asked to me in that PR was really to sync the change, and I never used the Cvar::Callback<>() before. Now that I used it, I'm even tempted to rewrite the code for the g_bot_default_skill value to change the skill value of bots that were added without explicit skill.
Lua certainly have good (but not only) points, but it's a scripting feature, not something that normal admins are expected to play with.
LGTM % slipher's comments
LGTM
could use squashing