Page 2 of 2

Re: Coding Frikbots to be scared of heights

Posted: Fri Mar 28, 2014 4:32 am
by Lightning Hunter
qbism wrote:Some good news!
...OK, I missed a spot in frik_obstacles replacement. Go into frik_movetogoal:

Code: Select all

	way = normalize(way);
	self.keys = self.keys & 960 + frik_KeysForDir(way);

	//qbism remove:  frik_dodge_obstruction();
	frik_obstacles(); //qbism add
	frik_recognize_plat(TRUE);
What you will see is much fewer silly falls. That moment of eureka will soon be replaced by the realization that sometimes bots will just stand near the edge taking long shots instead of breaking off and heading to the next item.
Hmm, I'm not sure I really see any difference. Am I supposed to add your earlier code above as well as this new code? I tried adding it all, and the bots still seemed to die quite a lot on Coagula2 by charging off edges. What version of the Frikbots did you modify? In the "Frikbot Item Desirability" thread, we were recently discussing how there were multiple versions of the Frikbots, and there is confusion about which one was the most recent.

Re: Coding Frikbots to be scared of heights

Posted: Fri Mar 28, 2014 1:11 pm
by qbism
I used the version from 'definitive frikbot waypack' with both sets of changes. I'm testing with 3 bots plus myself. Just through observation and scrolling through console messages, it appeared to be at least 50% reduction in falls. I don't know if it could get any better without more extensive traceline checks and/or prediction (bots simulating physics beyond one move).

Keeping the bot on-task to reach items would kill two birds with one stone. When a bot has a weak weapon, let it shoot but keep moving to the next goal. In any case limit enemy engagement to X seconds then move on.

Re: Coding Frikbots to be scared of heights

Posted: Fri Mar 28, 2014 9:55 pm
by qbism
Rats, all my last edit did is kill off attempt to move around obstruction, which is why they were falling less but standing around more. I realized this when going back and testing dm4.

Re: Coding Frikbots to be scared of heights

Posted: Fri Mar 28, 2014 11:05 pm
by Lightning Hunter
qbism wrote:Rats, all my last edit did is kill off attempt to move around obstruction, which is why they were falling less but standing around more. I realized this when going back and testing dm4.
Haha, no big deal. Keep trying, you are bound to improve something. :)

Re: Coding Frikbots to be scared of heights

Posted: Sat Mar 29, 2014 1:23 pm
by qbism
Thinking about the no-bots concept again... This is a hypothetical engine-side and mapping feature. Use the map itself to guide bots. I haven't looked at the q2 code for no-monsters but it would be kind of like that. No-bots would be a brush texture similar to noclip except it applies only to bots. The mapper would place nobot walls at the edges of unjumpable ledges, or use them to keep bots out of places where bots get stuck. The botplayers would need a flag of some sort so the sever would know. Of course nobots would not apply to bots already in the air, that would look weird. I don't know if it could be done qc-side with placed ents. Perhaps a nobots entity placed with DP or FTE ingame editor and saved in entertainment file?

Clearly AI improvement would still be the more universal way. I wonder if any other qc bots have dealt with ledges successfully?

Re: Coding Frikbots to be scared of heights

Posted: Sat Mar 29, 2014 4:10 pm
by frag.machine
One idea...

Hack the QBSP utility to generate an "ai_nav" hull in the 4th. unused slot supported by the Quake BSP file. The ai_nav hull would be very similar to the player hull in dimensions, but would hold information about environmental hazards (slime,lava,void,etc). Then, on the engine side, the walkmove and traceline builtins ought to be adapted to use this information when available, falling back to current behavior otherwise. This way, not only bots would navigate better, but regular monsters AI would be improved, too.

EDIT for grammar.

EDIT2 Forget about QBSP: bake the 4th hull generation in the engine BSP load. It already generates the point size hull during map loading anyway.

Re: Coding Frikbots to be scared of heights

Posted: Sat Mar 29, 2014 6:45 pm
by Lightning Hunter
qbism wrote:Thinking about the no-bots concept again... This is a hypothetical engine-side and mapping feature. Use the map itself to guide bots. I haven't looked at the q2 code for no-monsters but it would be kind of like that. No-bots would be a brush texture similar to noclip except it applies only to bots. The mapper would place nobot walls at the edges of unjumpable ledges, or use them to keep bots out of places where bots get stuck. The botplayers would need a flag of some sort so the sever would know. Of course nobots would not apply to bots already in the air, that would look weird. I don't know if it could be done qc-side with placed ents. Perhaps a nobots entity placed with DP or FTE ingame editor and saved in entertainment file?

Clearly AI improvement would still be the more universal way. I wonder if any other qc bots have dealt with ledges successfully?
Having an object that is manually placed to warn bots of edges is not a terrible idea, but it involves placing many such objects in every map. If it were done by the mappers when the map was made, it would be no big deal. However, I just don't have the patience to go through hundreds of maps and place them around every edge. That would take hours, and I've already spent hours on each map I've waypointed (I calculated that I've spent around 2,000 hours waypointing 700 maps; possibly longer). Anybody who implemented code for something that has to be manually placed would really be wasting their time, unless someone else wanted to sit down and place them in all the maps. I am personally not ready to spend hundreds of hours more on something like that. The solution for bots not falling off ledges would have to be something automated, or nothing at all.

Re: Coding Frikbots to be scared of heights

Posted: Thu May 15, 2014 7:11 pm
by Cobalt
Thats an interesting concept. Could you also somehow hack those hulls so the engine recognizes any kind of collision - not just the default point, player and shambler ? Lord Havoc told me in Q3BSP, they have this, but I wonder if the engine could "emulate it" at a q1bsp level....
frag.machine wrote:One idea...

Hack the QBSP utility to generate an "ai_nav" hull in the 4th. unused slot supported by the Quake BSP file. The ai_nav hull would be very similar to the player hull in dimensions, but would hold information about environmental hazards (slime,lava,void,etc). Then, on the engine side, the walkmove and traceline builtins ought to be adapted to use this information when available, falling back to current behavior otherwise. This way, not only bots would navigate better, but regular monsters AI would be improved, too.

EDIT for grammar.

EDIT2 Forget about QBSP: bake the 4th hull generation in the engine BSP load. It already generates the point size hull during map loading anyway.