.:: Bots United ::.  
filebase forums discord server github wiki web
cubebot epodbot fritzbot gravebot grogbot hpbbot ivpbot jkbotti joebot
meanmod podbotmm racc rcbot realbot sandbot shrikebot soulfathermaps yapb

Go Back   .:: Bots United ::. > Developer's Farm > General Bot Coding
General Bot Coding See what a pain it is to get those little mechs shooting around

Reply
 
Thread Tools
Foxbot and detpack issues on rock2
Old
  (#1)
Zybby
Member
 
Status: Offline
Posts: 8
Join Date: May 2009
Location: Smelly Brighton UK
Default Foxbot and detpack issues on rock2 - 13-11-2009

Hi, I'm working on Foxbot development and there's one problem that I would
like to solve, but have not been able to despite repeated attempts.
Foxbot uses a script system that changes the availability of a waypoint
based upon network messages.
e.g. "#rock_red_yard_opened"
The problem is that there are maps where no network messages
are transmitted when certain parts of the map are demolished.
For example, no network messages are issued on rock2 when the rubble is blown
up or restored.

I was wondering if anybody here would have a better idea than me on how to
solve the problem.
For example, would it be possible to detect the presence of the rubble on
rock2 when it has not been blown up?
I'll be offline for a while after posting this topic, but will give credit
where it's due in the Foxbot documentation for any ideas given.

Here's a few of the ideas I've had so far:
A new waypoint tag
------------------
You could create a new waypoint tag(e.g. W_FL_TFC_DEMO_OPEN) which tells
Demomen that if they can't see the next waypoint on their route that they
should set a Detpack at their current location.

A forbidden solution
--------------------
I call this idea forbidden because it goes against how the map scripting
system should work.
What you do is make detpack waypoints work in reverse to every other type of
scriptable waypoint. Demomen should only go for a detpack waypoint if a
script says that it is NOT available. Also each detpack waypoint should
have the same script number as one or more other goal waypoints.
For example, a demoman sees that a detpack waypoint marked as script number 7
is not available and blows it up. A check is performed to see if the detpack
actually suceeded in opening up a new path. If so, all waypoints with script
number 7 become available and demomen no longer try to blow that detpack waypoint.

Make each bot smarter
---------------------
This is perhaps the ideal solution but tricky to implement.
You give each bot a memory which can store the status of a number of detpack
waypoints. Then, when a bot thinks about passing through a detpack waypoint it
can remember if a path through the detpack waypoint was available or not.
The main problem with this idea is that the waypoint navigation code is based
upon a Floyds matrix algorithm which is pre-computed and then stored statically.
i.e. the bots can't spontaneously come up with alternate routes around a
closed detpack waypoint.
You could however get the bots to kill themselves when they get stuck at
a detpack waypoint.

Never close unscripted Detpack waypoints
----------------------------------------
With this solution Demomen should only blow unscripted Detpack waypoints
if their path is blocked.
For example, on Rock2, you would first make sure that the rubble detpack
waypoints do not have a script number flag(i.e. they are always available).
Then if a Demoman considers blowing up a rubble detpack waypoint they would
check to see if all paths from it are reachable.
If not, they can go ahead and detpack it and clear the path.
One problem with this idea is that Demoman bots would not know how to
deliberately close a rubble waypoint back up, via a script.
  
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
vBulletin Skin developed by: vBStyles.com