Frikbot Item desirability

Discuss Artificial Intelligence and Bot programming.
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

Doing what I said above would be a start. It would set the priority of the item on item spawn. So it would
update to your new random value every time the item spawns.

On the other side, you would want to set the items priority to zero when its picked up.
That would ensure the bots ignore the item until its respawned.
self.thisp = 0;

that will work because the map items are still there, theyre just invisible and inactive.
but THEN, you still need to find the function that reactivates them, and reset their priority (to something random again if you prefer) so when the item respawns its priority is not still at 0, and the bot knows to seek out that item again.

Thats really all there should be to it.
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

I figure because you've provided a ton of wp's for the community someone should get off their ass and help you.
Might as well be me.

this is from the frikbot source, its the priority values.

Code: Select all

// priority scale
// 0 - 10 virtually ignore
// 10 - 30 normal item range
// 30 - 50 bot will consider this a target worth changing course for
// 50 - 90 bot will hunt these as vital items

// *!* Make sure you add code to bot_check_lost to remove the target *!*
if you want to add a random amount of priority to an item on spawn, start by adding a new field to track that amount
in defs.qc.

Code: Select all

.float fb_base_priority;
now that we have somewhere to shove a bonus priority, we need to actually do that.
We'll add the bonus priority when it spawns, and when it REspawns

//add to both SUB_regen and PlaceItem in items.qc

Code: Select all

self.fb_base_priority = rand()*35;	//bump its priority by a random value between 0 and 35
lastly, the frikbot needs to actually know about your new field and do something about it.

in bot_ai.qc at the very bottom of priority_for_thing, the codeblock should look like this

Code: Select all

	if (thisp)
	{
		if (thing.current_way)
		{
			// check to see if it's unreachable
			if (thing.current_way.items == -1)
				return 0;
			else
				thisp = thisp + (13000 - thing.current_way.items) * 0.05; 
		}
	} 		
	return thisp;
};
change it to look like this

Code: Select all

	if (thisp)
	{
		if (thing.current_way)
		{
			thisp = thisp + thing.fb_base_priority;
			if(thisp > 90)
				thisp = 90;		//thisp cap is 90.

			// check to see if it's unreachable
			if (thing.current_way.items == -1)
				return 0;
			else
				thisp = thisp + (13000 - thing.current_way.items) * 0.05; 
		}
	} 		
	return thisp;
};
that adds the items base priority field to the calculated priority before distance is factored in, and makes sure
to cap it correctly to 90.



NOW, as for bots still hanging around items that have been taken, unavailable items are accounted for in the frikbot code
so I'm not sure why you're getting that behavior.

in priority_for_thing in bot_ai.qc at the top, you'll see

Code: Select all

if ((thing.flags & FL_ITEM) && thing.model != string_null && thing.search_time < time)
the models of any taken items are set to string_null, and only repaired when they respawn.
that checks for taken items, and ignores them.

I'm not familliar with the frikbot code, but that SHOULD be enough to get what you want.



///EDIT:

It looks like items are prioritized and added to the list of goals, but the goals arent checked again after that
..though again, I may be wrong.

So we'll check the top goal (but none of the others, because removing one goal removes every preceding goal, and the bot isnt headed for goal2 anyways)

in bot_ai.qc in BotAI() (line 936 if stock) just about smack dab in the middle of the function you'll find this:

Code: Select all

	else if (self.target1)
	{
		frik_movetogoal();
		bot_path();
	}
make it look like this:

Code: Select all

	else if (self.target1)
	{
		frik_movetogoal();
		bot_path();

		if (self.target1.flags & FL_ITEM && self.target1.model == string_null)
			target_drop(self.target1);

	}


that checks the current goal to see if its an item, and if its been taken. If its a taken item, it removes it from the list
of goals.

If everything above works, that leaves just the issue of bots diving into lava in void maps. Which is something I cant help you with.
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

Gnounc, you are awesome. I was going to sit down today and try to figure some of this out myself, but it probably would have taken me all day, and I would have been asking for help anyway. Now I can complete some more waypoints instead. I'll be adding you to the credits for sure.

I do have some questions about this new code, however:

-First of all, I noticed that my QC compiler was complaining about "rand" being an unknown value in items.qc, so I changed it to "random". Will this hurt anything?

-Should I remove the random values in bot_ai, since they are now calculated in items.qc? After all, you gave everything a universal random value of 35, correct? Are the item priorities even used anymore in bot_ai?
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

yeah random() is what i meant. i always do that for some reason.

Anything you put in bot_ai for randomness beforehand should be reverted, but the priority values are otherwise still used.

Let me know if it works.
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

gnounc wrote:yeah random() is what i meant. i always do that for some reason.

Anything you put in bot_ai for randomness beforehand should be reverted, but the priority values are otherwise still used.

Let me know if it works.
I think the only way for me to know for sure if it's working is to set all the priority values in bot_ai to 0, and see if the bots go for random items during the match (based on your new priority code in items.qc). I tried testing just now with the default priority values, but the bots seem to be going for the same items most of the match. I'll perform more testing and see what happens.
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

yeah, theyre equally distributed random values, so they should be going for the same items roughly. the variance should be pretty slight. doing what you said would help. allowing a wider variation including negative would help too.

you can do that by doing a second random call and using that to set the random bonus to negative 50% of the time.

remembering to cap it at 0 of course. then your range would be from 0 to 65. The difference would be much more noticable then.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Frikbot Item desirability

Post by Spike »

apparent preference for an item can also be affected by the waypoints the bot generates. if it stays within an area, chances are its because it only has waypoints for that area, and because it stays, it doesn't generate any for anywhere else.
I dunno, I'm too lazy to study the code.
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

Spike wrote:apparent preference for an item can also be affected by the waypoints the bot generates. if it stays within an area, chances are its because it only has waypoints for that area, and because it stays, it doesn't generate any for anywhere else.
I dunno, I'm too lazy to study the code.
Well, these are my waypoints we are talking about here. And yes, the bots can go everywhere. ;)
gnounc wrote:yeah, theyre equally distributed random values, so they should be going for the same items roughly. the variance should be pretty slight. doing what you said would help. allowing a wider variation including negative would help too.

you can do that by doing a second random call and using that to set the random bonus to negative 50% of the time.

remembering to cap it at 0 of course. then your range would be from 0 to 65. The difference would be much more noticable then.
What would that look like? something like this?

Code: Select all

self.fb_base_priority = random()*35 + random()*-35;
So far, I'm not seeing much of a difference with the random code. The bots haven't yet gone for a Super Shotgun, Nailgun, Supernailgun, or any lower tiered model. They should be going for them every now and then if the random code is working. One of the maps I'm using as a test has a lot of items (2 red Armors, 2 yellow armors, 3 of every weapon, and all the powerups). The bots only seem to go for the Rocket Launchers, Red Armors, Powerups, and the occasional Lightning Gun. Everything else they ignore, even though the random factor should have the bots picking up smaller items on occasion. I currently have the item priorities set VERY close in the bot_ai file (Red armor is only 5 above the Super Nailgun). I realized that having all the items set to 0 is not a good test, because then it would create a randomized item pick up (in theory). So I instead set all the priorities low, but not the same.

Also, the bots still continue going toward an item that has been picked. To clarify, lets say a Quad Damage spawns and 4 bots decide they want it, they will all start going toward the nearest waypoint. If 1 of the 4 bots picks it up, the other 3 bots will still continue toward the location of the Quad. They will then proceed to stand on the space where the Quad once for a few seconds before moving to their next goal. This often results in bots all fighting in the same room around one powerup they all want.

Edit: Does this random code apply to ammo pickups? I never see bots going for ammo pickups, so I was just curious.
Last edited by Lightning Hunter on Mon Mar 24, 2014 4:05 am, edited 1 time in total.
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

Code: Select all

r = random();
if(r > 0.5)
     self.fb_base_priority = -35;
else
     self.fb_base_priority = 35;
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

gnounc wrote:

Code: Select all

r = random();
if(r > 0.5)
     self.fb_base_priority = -35;
else
     self.fb_base_priority = 35;

I'll try it out. Did you see my many edits in my post above?

I just wanted to confirm that this is correct. This is how the code looks for items.qc under PlaceItems:

Code: Select all

{
	local float	oldz;

	self.mdl = self.model;		// so it can be restored on respawn
	self.flags = FL_ITEM;		// make extra wide
	self.solid = SOLID_TRIGGER;
	self.movetype = MOVETYPE_TOSS;	
	self.velocity = '0 0 0';
	self.origin_z = self.origin_z + 6;
	oldz = self.origin_z;
		if(random() > 0.5)
     self.fb_base_priority = -55;
	else
     self.fb_base_priority = 55;
	if (!droptofloor())
	{
		dprint ("Bonus item fell out of level at ");
		dprint (vtos(self.origin));
		dprint ("\n");
		remove(self);
		return;
	}
};
And this is sub_regen:

Code: Select all

void() SUB_regen =
{
	self.model = self.mdl;		// restore original model
	self.solid = SOLID_TRIGGER;	// allow it to be touched again
	sound (self, CHAN_VOICE, "items/itembk2.wav", 1, ATTN_NORM);	// play respawn sound
	setorigin (self, self.origin);
	if(random() > 0.5)
     self.fb_base_priority = -55;
else
     self.fb_base_priority = 55;
};
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

no i hadnt seen the edits. Yes, the randomization should apply to ammo as well.
Also you said the bots still fight over a spawn item thats already been taken..above i mentioned in botAI checking for an item being taken and removing it from the list, I dont see you mentioning having put that code in. If items arent removed from their goal list, they will continue to try to get them.

Also you may be better served at this point by going to the irc channel.
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

Well, the Random code must be doing something, because I just saw a bot try to pickup Shotgun ammo for the first time. However, the bot also continued to go for that one shotgun ammo the entire match, which tells me the priority was never updated/changed once the match started. Not sure why that is.
gnounc wrote:Also you said the bots still fight over a spawn item thats already been taken..above i mentioned in botAI checking for an item being taken and removing it from the list, I dont see you mentioning having put that code in. If items arent removed from their goal list, they will continue to try to get them.
Yes, I added all the code you had mentioned (and double/triple checked it). The bots still go for an item sometimes even after it has been picked up. :-/

I did notice just now that in part of the bot_ai code you posted, you put the line "thisp = thisp + thing.fb_base_priority;". Shouldn't it be "self.fb_base_priority", or is "thing." correct? Sorry if some of these question are noobish. I certainly wish I knew a lot about code, but the truth is that coding was always very difficult for me to understand (like Algebraic equations). I was always a mapper/waypointer/modder rather than a coder. I can sometimes understand a line of code by staring at it for 5 minutes, but doing anything from scratch makes my brain hurt. :o
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

thing is correct there.

thing is the argument name of the entity being passed.
if you look a bit above that it says something like thing.waypoint.
Lightning Hunter
Posts: 169
Joined: Wed Nov 28, 2007 6:15 am

Re: Frikbot Item desirability

Post by Lightning Hunter »

After doing more testing today, I can confirm that the random priority seems to be working at the start of each match. However, the random values don't seem to be updated each time the item is respawned, because the bots go for the same items the whole match. Also, I noticed some strange behavior with the Frikbots now in which they randomly decide to deviate from their current goal, get off track, and run in to some walls. I think this happens when they decide they want a different item and attempt to go for a different waypoint/item, but don't properly calculate how to get their based on the nearest waypoint. They instead just run straight toward the item/goal/waypoint (which may be across the whole map), and get stuck on a wall.

Thanks for the help so far Gnounc, but maybe this is more trouble than it is worth? Of course, if you have some ideas of what might resolve these issues, I would love to hear them. :)
gnounc
Posts: 428
Joined: Mon Apr 06, 2009 6:26 am

Re: Frikbot Item desirability

Post by gnounc »

sorry, I'm out of ideas.
I'm really not sure what else to do, except ask frikac for help.
I hope you manage to get something going though.
Post Reply