Ok, here's a bit of stuff I collected (not as thoroughly and concisely as Huntakillaz, though - just to keep track of what's still missing).
I tried to sort it by priority... but of course, priority for you can be different than for me.
First of all, some good news:
-Aiming code has been improved, no wiggling & more human-like (haven't tested yet)
-Grenade throwing bug is fixed (again, not tested yet)
-Changed WP colours in editor for clearer look
-WP check bug (jumped to wrong WP) is fixed
I'm sure I missed some more... but even if it's "only" this, it's a nice package... a TON of thanks and applause to sPlOrYgOn and all others who contributed their part (you know who you are)!
1. Button code
As described in some other threads, the button code doesn't work very well. Bots should
a) ignore things like trigger_multiple (if a button targets a trigger_multiple and the trigger_multiple targets the door) and just look for a func_button or whatever can be used for the same purpose.
b) not stray from WP navigation completely, but first move to the WP nearest to the button detected.
c) push the button and walk back to the nearest WP
d) proceed.
If this is possible, of course...
One idea: We currently have a button flag that forces bots to push a button; else they will only look for buttons if their path is blocked. How about this:
a) The button flag tells bots where to
check for buttons, i.e. it
activates the button code. Now if a connection is blocked by a func_door or whatever, bots would push the button nearest to the flagged WP, and if there's no obstacle detected, bots will proceed to the next WP.
b) If there is no button flag, bots will know that all doors etc. open automatically, and their button search routine will remain idle. They just won't try to push a button, they won't even search for one.
2. DediServer commands / parameters
a)
addbot seems to work correctly - a bot is added if I enter this command, or if I have it in my podbot.cfg. If maxbot (see below) is lower than the amount of addbot lines in your cfg, no addbot should be executed after maxbot is reached.
b)
minbot / maxbot should only determine how many bots may be on the server, but it shouldn't do anything itself, or maybe just add bots until minbot is reached - but not a single bot more.
c)
fillserver should be a command that must be
actively entered (or chosen from a menu) - when executed, it should fill all free slots and then stop. If there are less free slots than maxbot (e.g. 5 free slots on server, rest occupied by humans, maxbots 12), it should be limited by the 5 free slots and not try to add 12 bots. If there are more free slots then maxbot, what then? Stick to maxbot and leave some slots free? Or override maxbot in this case?
d)
autoaddremove should be a parameter that determines if a free slot is refilled with a bot automatically, or if a bot is kicked automatically when a player joins. It should, however, only be used to fill or free slots as human players leave / enter the game. It should not execute any addbot commands or automatically fill the server.
That's the way I understand these functions were meant to work originally - if I'm wrong, please correct me. From what KWo posted, I understand that they don't seem to work like this on a dedicated server.
3. collectexperience
So far, collectexperience off will crash the server on map change. As experience really enhances gameplay, I think it could be forced to on, without an option to deactivate it. As long as it can be turned off, doing so shouldn't result in crashes...
3. WP debuggoal
a) Enemies AND map goals should be ignored during debuggoal
b) debugging passages through various WPs should be possible
c) Bots should stop moving once they have reached the goal WP. They keep falling off walls & ledges before you can enter a new goal WP.
For the rest, see above or ToDo-List... or I forgot