.:: Bots United ::. - idea's bug's

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- Releases, Installers, Docs & Coding (http://forums.bots-united.com/forumdisplay.php?f=48)

- - idea's bug's (http://forums.bots-united.com/showthread.php?t=1775)

here's everything i found in ideas common q's and the outer pb2.6mm forum...

i got tired when i reached the bug reports...so if anyone wnats to finish it be my guest...

Ps: i tried uploading a doc but the files size 51k and max allowed is 19k..

Quote:

bugs:

name leak

the limit is 100 names..

anymore than that would be a memory leak wouldn't it? either that or a buffer overflow..

Just put a check in the code to stop the loop where it reads the botnames.txt file if it reaches the max number of bot names. I thought I had put one but maybe I missed it.

Friendly fire

my brother was kill his team for fun ......oh n they dont seem to fight back when that happens rather they just continue as if ff was off and nothing happened(they shoulda killed him even if it was next round)

if i remember right...pod2.0 would shoot at each other in the middle of a fire fight, because they accidentaly were moving in front of each other attacking the same target......and i could shoot them at the start and they would turn and shoot at me.......but that was pod2.0 if i remember right..only with FF on yeah maybe implement it back with an on\off switch, default off

Debuggoal

If it's possible to make bots ignore enemies during debuggoal phase (friendly mode), is it also possible to make them ignore map goals?

CTs, for example, will abandon their path and get hostages instead of walking past them. And if the hostages are stuck somewhere and try to get to "their" bot (very likely when I test complicated things with a bot), my game lags a bit - gets kinda choppy.

No big deal really, you can always see that you add a bot of the "defending" team, but if it's extremely easy to fix, it might be taken into consideration - maybe it would be ideal to make it a package together with friendly mode? Like, bots ignore both enemies AND map goals or not?

Rapid-firing elites

Pod, they're capable of firing the elite like an automatic weapon - something that's only possible for someone with three hands

not knowing anything about programming is it possible to put a speed-limit on the bots clicking the shoot button?

if anyone knows or knows how to get the time for how long after you switch weapons/reload/shoot before you can shoot again..

because we need those times..

hint: see bot_fire_delay_t

and change cs_fire_delay in bot_globals.cpp

Wp check glitch

Ok, I found one small mistake in the way the automatic WP check works. Let me try to explain this with an example. Let's say you placed a campWP, which happens to be #157 in our example, on top of a crate - and you forgot something there. Much later, you want to save, and now there are three possibilities:

1)You forgot both a connection TO 157 and one back FROM 157.

Result: You'll get the error message "#157 is not connected with any other WP" and be teleported to 157. Perfect.

2)You placed 157, and a connection down from the crate was drawn automatically. However, you forgot to make a nice jump connection up to 157.

Result: You'll get the error message "no path found from 0 to 157" and be teleported to 157. Just fine.

3)You placed 157 with very short apmd setting or apmd off, then made a jump connection up there. However, you forgot to add a connection down.

Result: You'll get the error message "no path found from 157 to 0" and be teleported to 0!!! This is not ideal.

----------------------------------------

So the code does some check like this:

If there's no connection from A to B, teleport to B.

Ideally, the check would be as follows:

if there's no connection from A to B,

check if B is 0.

If B is not 0, teleport to B

else teleport to A.

-----------------------------------------

NOTE: Of course there's an easy workaround: Once you get teleported back to 0, open the console, read the error message and do a manual teleport to the other WP. This bug is really no biggie, but if it's easy to fix...

ideas:

Wp Aim for pwp's

well i read in the other post that T Wrecks was having trouble aiming correctly.

I thought maybe we can have a waypoint turn a different color when pointed at it.

That way you will know which waypoint is being pointed at and that its not some other waypoint near or behind it or something.

Is this a good idea or not?

or as i mentioned somewhere a cool purple(maybe changable in a cfg file so that i could try,make it change colours when u shoot :p) line coming from ur gun n hittin the wp ur targeting at

should be easy as some server have this hook feature which works similar i guess

it's easier to make the selected waypoint bigger, or blink, or glow, than to trace a beam from your gun. But both ways are doable.

Vision-light \dark
the "vision" of the bots, can they evaluate the lightning of a certain place in a map and then adapting their reaction time and aiming to the light conditions (the darker the worse)?

Or would they need the help of a waypoint flag which would tell them how light a certain area is? And if so, could this be implemented right now even if it wouldn't be used by the bot just for not having to adapt all waypoint files all over again and again?

the idea about lighting is interesting......i dont know if that can be implemented......but a NEW feature like this would not be backwards compatible with an older bot......(i think) because pod2.5 for example, or other compatibles, would not know what to do with a "darkness flag".

Custom sprays

It's in the hpb code bot.cpp file. as far as the code goes.

To make / add your customs for bots to spray.

You have to do the following.

You have to make your own decals.wad containing the custom sprays.

list the sprays in a file (logo.cfg)

The decals.wad file has to be stored in the MOD folder.

and the logo.cfg (HPB_bot_logo.cfg) goes in the BOT folder.

The logo.cfg file looks like this. each entry is a custom spray in the decals.wad.

{bwpinup

{bloodhand6

{fubar

{giyoudie

{pinup

{nvahere

{usmchere

{shrikebot

So far i've only succeeded in making monochome decals.(1 color)

The decals can't have custom names. You can change the decals in the WAD file but you must overwrite existing ones.

Do you mean the decal.wad or the decals inside the wad.

Cos the decals inside the wad CAN use custom names.

Wp Stats

seeing not only how many wps in the map and thier kind......i would like to see how many button flags, lift flags, no hostage flags also

we are prepared to redo tons of waypoints just for this flag thing you know

it would be easier to get in the map.....type wp stats and see if it has any at all.

should be simple to do i suppose......and VERY useful

Waypoint Problem! No path found @ #

When we receive the message "Waypoint Problem! No path found!" - it's possible to add exactly number of the first waypoint causing this problem?

I know - after "waypoint check" I'll find this after fixing some another problems, but maybe this is not so much difficult to implement in code and for waypointers maybe can little help...

Debuggoal

I think I might have a little idea for the debuggoal command, when it comes to checking a whole passage (e.g. up a stack of crates, along a ledge and then a jump into a window something the like), with several ways leading to the WP specified in debuggoal - but you want the bot to test this one tricky passage instead of just having him walk up the stairs and go to the window from inside the house.

The problems that can occur when debugging such a passage are the following:

1) As mentioned - bot chooses different passage

2) When doing it step by step, bots can fall down somewhere because they tend to move a bit around the waypoint they have reached

That's why I thought it would be nice to be able to tell the bot via which WPs he is supposed to go to the goal node.

Let's say we have waypoints 210 - 214 that are a complicated jump sequence up a roof. Let's say there's also a ladder some yards away that also leads up the roof. And imagine one WP on top of the roof has the number 367 (it doesn't matter, really). Now if I typed in "debuggoal 367", the bot would be likely to take the ladder, when I want him to try the jumps! And if I want to do it step by step ("debuggoal 210", "debuggoal 212" and so forth), the bot may fall down somewhere while waiting for a new goal.

Now if I could enter something like "debuggoal 210 214 367" to tell the bot to go to 367 via 210 and 214, I could force him to take this one route I want to have tested.

And once we're at it, I just remembered the print function of WinWord. What's that got to do with it? Easy: By entering e.g. "2,4-7,9,23-25" you can tell Word to print p. 2, pp. 4 to 7, p. 9 and pp. 23 to 25... I wonder if a similar scheme could be used for the debuggoal command? Then I could fly around in spectator mode, see the numbers and tell the bot EXACTLY which passage to choose... opinions?

Auotpath max d connections

When adding / deleting pathwaypoins with the new pointing system, errors can occur. That's not that bad, but you can easily make a looooooong connection if the editor misinterprets which WP you wanted to point at. In the same way, good pwps could get deleted.

That's why I wondered if it would be an improvement to limit the maximum distance for manually making pathwaypoints

a) either to the current setting of the apmd (auto-path max. distance) that's also used for automatic pwp creation

b) or to the default max. distance (250)

c) or at least to a halfways reasonable value, like 320 or something.

Maybe an option to toggle this setting at least to on/off would be nice together with the feature itself? Like "mpmd on/off" (for "manual path max. distance")?

I just realized that there is one advantage of the new pointing system that should not get lost altogether: It's a good method to add a path where two waypoints are just out of reach from each other, but a third one in the middle isn't really necessary. If anybody limits the range of this feature, it would be best to make the limit adjustable...

While I was trying a risky jump, I fell to my ugly death - then I respawned, and the result was the great-grandmother of all jump connections you've ever seen... only that it wasn't quite possible, except perhaps at zero gravity and with noclip cheat on...

Maybe it would be a nice idea to have the connections

a) optionally limited by the current apmd setting

AND

b) not survive ugly incidents like the waypointer's death?

Kick named Bot

There is a possibility to kicking some bot (randomly or latest added - I'm not sure about this) from podbotmenu, but you can't decide which team bot should be kicked from. For example - you play with your friend in one team together with 2 bots against 6 bots in another team. Now they are joined 2 your friends and you want to make CLAN training - all people together against bots team. In this case you have to remove 2 bots from your team, but from podbotmenu this is impossible now. OK - You can do this from console line - You have to type status and after you type instruction:

kick #player_nr

or you type

kick bot_name

If the name is long and if detailnames is on , you have to type for example:

kick "[P*D]James_Bond (87)"

Both two metod give the possibility to kick the selected Bot from the game, but this command "Kick Bot" from podbotmenu in this case is useless. Maybe in another case this command is good, but possibility of kicking selected bot or at least bot from selected team can be more comfortable.

If this is not too many work to with changing this "Kick bot" and kicking randomly bot to "Kick Bot" -> open menu 1. Kick Bot from T team, 2. Kick Bot from CT team, I'll be thankful. This is not much important future right now to do - I'know - there are many more important work to do, but if this is easy...

Bot personalization -realbot style Already mentioned. But be able to really customize bots like the Realbot Manager where you can pick everything from favorite gun to the likeyhood of him to defuse the bomb.

2. Bot personalisation: Yes, not bad. However, at least IMHO, this should remain an option, with other ways of adding bots (bot menu or whatever) still remaining. Nobody wants to spend seven hours choosing each bot's likelihood to fall over its own shoelace on a de_map on thursdays in a dark corner when less than 4 players are remaining and he's carrying a gun with more than 10 rounds of ammo left and the bomb has been planted etc etc etc... It's great if you have the possibility to do so, but it should remain a possibility (as I am sure you all had planned it, just to make things clear). Come to think of it, would it be possible to add a further cfg file where players can enter & edit their favourite bot personalities and backup them for the next time they have to reinstall their OS or something?

I am not sure if you are fimilular with REALbot AI or not but they come with a bot personality manager. It works by using a CFG file. That way all you have to do is make a CFG for a custom bot but you don't even have to do that it will add random bots if there are no configs.

fear for life......

they rarely do.....

they will jump places where they can lose life...they will go places where they can lose it.......they need to be taught how to stop dying from foolish reasons that arn't accidental...

me thinks if possible some code that will restict them from doing jump or going where they will hurt themselves 10hp+ (from natural causes ie water drowning)

when they have low lifelike 35hp or less or something

A kind of "HP" check would be nice to prevent bots with 3 HP from dropping down somewhere where they'll lose 10 HP...

However, this is only necessary in very few maps. IN 99% of all cases, it's (IMHO, at least) the waypointer's responsibility to avoid such connections that will hurt bots seriously. 2-3 points are ok, but IMO, a WP file where a bot can lose 5 points or more by following a regular connection is a bad waypoint file. Water waypoints should be placed at the surface anyway; there are generally only few spots where bots really have to dive.

I agree with T Wrecks on the deadly drop check, and it is doable. One can weighten the A* pathfinder costs with the HP of the bot.

Does that mean that a bot losing x HP due to jumping down from somewhere would lead to the "landing" WP being weightened with a higher danger factor?

In that case all bots would avoid the WP, right?

Well, I guess it's the best possible way w/o changing the WP system again. Of course, the ideal scenario would be that bots know approximately how much HP a connection will cost them and decide on that basis whether they go there or not. So any bot with 100 HP would easily do that jump, whereas a bot with 20 HP will steer clear of it....

no no no, no worry - that would apply to the bot only. Kinda the same thing as a bot trying to find a path suitable with hostages. It's about temporarily discarding some waypoints during the search by assuming they have a super high danger value. But this value is valid only within the search session. Another bot finding another path will ignore this completely.

Re: idea's bug's

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... :D
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 :D

Re: idea's bug's

One good news - kick bot from selected team is made already by sPlOrYgOn.

Another thing wanted by many people - for all releases , all betas - write exactly version number in code to show in console or as motd or something in log. This can be also building number (like for HL). But every release - official or beta - separate number.
For example last sPlOrYgOn beta - 2.2beta4 .

Another thing I posted this - bots at the end of one map , after mapchange should be the same at begining of the new map (ignoring addbot command from podbot.cfg after mapchange - execute them only at first load the game) saving the list of bots at end of the one map and re-enter them to the game at the start the nem map (hard because of this changelevel and ServerDeactivate).

Re: idea's bug's

okay for release numbers..
here's how it goes..
"Podbot 2.6mm Release X.Y"
X will be incremented for each release..
Y is incremented only when there was a problem with the first initial release such as a little tiny bug that needed fixing..
the next release is R3... so the betas are actually R3 betas..

the min_bots and max_bots problem can all be solved..
if only you guys read what was in the podbot.cfg since pb2.5...

Quote:

# Remove the comments on the 2 lines below to support a minimum and maximum
# number of bots running on a dedicated server. Bots will be added to the
# server until the total number of players (bots and humans) reaches the
# max_bots value. Each time a new player joins the server, a bot will be
# kicked from the server unless there are only min_bots number of bots
# currently on the server. After players disconnect from the server, bots
# will be automatically added back to the server until the total number
# of players reaches max_bots again. You should make max_bots be AT LEAST
# one less than the maxplayers value (otherwise no one will be able to join
# your server).

and that is exactly how it is implemented in the current beta...
it's pretty close how CF wanted it..
yet KWo complains that it's an auto fillserver...
I will now DEFAULT min_bots and max_bots to ZERO..
that way there will be no limits and no bots added automaticly when those 2 commands are commented out..
once you uncomment it should do exactly like how that quote is..

Re: idea's bug's

Quote:

Originally Posted by sPlOrYgOn

if only you guys read what was in the podbot.cfg since pb2.5...
# Bots will be added to the
# server until the total number of players (bots and humans) reaches the
# max_bots value.

Now I now, why You are wrong.
Read this above 10 times carefuly and quiet. "Bots will be added to the server..." - here is nothing about autoadding bot (Can You see some word as "automaticaly"). If there would be "Bots will be added to the server automaticaly until..." - in this case You could be right. But there is nothing about "automaticaly". So in this case You are wrong. Bot will be added until ... This until is the most important word in this frase (an accent of this frase). So You can use addbot command until reaching the max_bot or maxplayers value. The same for fillserver - bot will fill server until reaching max_bot or maxplayers value. But never without these commands! Yes - only in one case - some player is disconnected - without commands fillserver or addbot - some bot will be added automaticaly.
# After players disconnect from the server, bots
# will be automatically added back to the server until the total number
# of players reaches max_bots again.

And here You have this word "automaticaly". This is only one case of auto joining bots. Try to understand this. It's simple.
I hope now this is clear.

Re: idea's bug's

you see..
the problem is..
automatic is implied...
if it wasn't automatic..
it will NOT reach max_bots...
will implies that it is going to happen in the near future...
and in order to make that statement true it NEEDS to be automatic..

Re: idea's bug's

Quote:

Originally Posted by sPlOrYgOn

Look in this way. Min and max are allways some limits only of some variable. But never max is implied as a default value of this variable You define.
You are a coder. You have to know this. When You define for example some array, Your default (start value) is the max of this array definition implied? No - You have to define the start value manualy. (almost allways default is min, BTW :) )
But why it has to reach max? Why do You think in this way the number of bots has to reach max_bots value? It can , but it hasn't...This max_bots variable was made by CF to prevent the situation, when You use fillserver and all free slots are filled by bots and there isn't any free slot for a player. If You not define (comment out) this variable, bot will fill Your server until reaching max_players variable (max_bots by default is 32). To prevent this situation CF made a limit (LIMIT, LIMIT, LIMIT). Try to understand this intention of author. He wrote this intention exactly - set this variable (max_bots) at_least one less than mp_maxplayers (read this comment in podbot.cfg once again) to let at least one player to join.
OK - I'm tired by explaining this. Maybe the problem is once again my bad english. In my country is now 3 AM so it's a time to sleep for me.

So - for now a little suggestion. Maybe You are right, maybe I'm right - wait for opinion of other peoples and change nothing in this topic. Majority will be a winner.
Now I start a pool - who is right? Me or sPlOrYgOn?

Re: idea's bug's

name leak, check wp glitch, friendlyfire, wp status (done by PMB.. long ago I believe..), Auto Path Max Distance (APMD) (also by pmb), and kick name bot. ALL OF THOSE ARE DONE :D
and to the rest...
some are in progress...
some are too hard for me to do with my current knowledge..
and some I haven't started yet :D

[edit]
okay KWo lets give you a situation...
suppose a person wanted 10 bots to begin with..
then he wanted one to leave everytime a player joined..
and one to join everytime a player left.
if 10 players join then there should be no bots..
but this guy who owns this server is lazy and wants it all done for him...
if min_bots and max_bots was the way you want it..
he would never beable to have it all done for him..
because he would set min_bots to ZERO and max_bots to 10..
making no bots automaticly join..
but a bot will join if a player leaves..
so after the first player leaves then a bot will join if there are less than 10 players..
but that wouldn't be what the server owner wants..
but if max_bots and min_bots were implemented the way I interpreted CF's message...
then there would be 10 bots that auto join at the begining of server..
then after that the bots will leave each time a person joins until there are no more bots because min_bots is zero..
and also if maxplayers is set to 32 then once the amount of players reach 10 there will be no more bots but max_bots does not restrict people joining meaning people can keep joining until it reaches min_bots.
once enough people leave to go under max_bots then bots will fill in the spaces to make the amount of players in the server 10..
at any given moment the server will have 10 or more people/bots..
that will attract people to join the server if all he wanted the bots to do was to attract people..
and that brings me to my goal of working on this bot..
which is to make them humanlike enough so that people that join the server would never know they were playing against bots..
so if these 2 things are done then server owners can attract people with "people" (bots :D) and they wouldn't even think that those other guys weren't people :D..
[/edit]

[edit2]
bleh screw this arguement..
I think it's having a negative effect on these forums...
I'll just do it the way you interpreted CF's words...
the little story above can be fixed if that lazy person just put "pb fillserver" or something...
bleh.. tired of arguing.. gets us no where...
[/edit2]

Re: idea's bug's

Ok ok, having read all this stuff I think that this is not even a question of right or wrong - as the argument showed, there are really two ways to interpret CF's explanations, and there are also two ways to get these functions to work in a way that makes it easy for server admins to have bots behave exactly as they (the admins, not the bots) want.
I'm still a bit wasted right now... half past nine local time and still a bit drunk from yesterday... I'm gonna ask my friend Robert if he's happy with the way DS works right now... he's always running games on DS, so he ought to have noticed if something goes wrong or is bad to handle. We've been discussing this stuff a lot now, but I think what would really help is some feedback by a user not involved in the discussion; some user who doesn't read or interpret all this stuff, but only tries to reach a certain situation and uses the given commands and parameters in order to do so - is this difficult or confusing for him or does he get what he wants right away?
Concerning the rest, I agree... much has been changed already, and when I remember the somewhat chaotic start, it's all the more astonishing what a good job you actually do, sPlOrYgOn - kudos and thanks again! =)
Just one little remark concerning the apmd thingy... afaik, path creation is now limited to the distance apmd is set to. This is nice, but originally I had thought about an option to have it this way. You know, sometimes it can come in very handy if you want one or two longer connections... that's why I'm still waypointing with R1... :D

Re: idea's bug's

so do you want longer APMD numbers??
yes i agree with T_Wrecks (sorry i had originally thought it was an a.. for a very long time..)
we should ask how Server owners want it...
that way instead of having it like CF's way we can please the people who will actually use these commands..