[Huntkillaz]

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

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.