IPB

Welcome Guest ( Log In | Register )

2 Pages V  1 2 >  
Reply to this topicStart new topic
> RCBot 0.9, Massive TF2 update
Cheeseh
post Jun 25 2014, 09:38 AM
Post #1


Admin
*****

Group: Admin
Posts: 2,990
Joined: 11-September 03
From: uk
Member No.: 1



The main change to TF2 is that scripts have now been removed and it automatically detects points

This makes previously unplayable maps (tc_hydro, cp_degrootkeep, cp_gravelpit) available for bots to play normally

Please update your TF2 waypoints to the new waypoints in the ZIP for it to work correctly.

tf2: bots check if they can see the ground beneath enemies to help aim for rockets and grenades
tf2: removed need for scripts in TF2 -- using TF2 point detection
tf2: bots can attack skeletons on plr_hightower_event
tf2: if capture point is unreachable bots will go to nearest defend points
tf2: updated sniper and sentry and exit building based on current attack or defend point on cp maps
tf2: bots can now high five
tf2: fixed bots attacking sentries from distance
tf2: sentry and sniper placement changes
tf2: added new medic dode
tf2: waypoint autofix 1 command fixes senty waypoints etc with no area on cp maps
tf2: fixed snipers getting stuck
tf2: snipers hide when enemies see them
tf2: spies don't deliberately lose their disguise unless they think enemy is targeting them
tf2: ubered bots don't change to shotgun or melee if they have explosive weapon ammo
tf2: fixed sentry waypoint selection
tf2: more chance of bots going to point when point under attack
tf2: less chance of bots trying to build sentries upon each other
tf2: medics try not to heal cloaked spies or disguised spies as other team
tf2: when points are updated automatically update bots attack or defend points
tf2: bots try to take cover from demo pipe grenades
tf2: fixed sentry avoidance
tf2: added payload avoidance
tf2: bots can now taunt when messing around if taunts are disabled
tf2: fixed sniper bug
tf2: new debug tools (memory scan and memory check)
tf2: fixed current waypoint being -1 if bot stuck in corner
tf2: fixed demomen detonating stickies at wrong CP when under attack
tf2: improved engineer picking up buildings quicker for moving
tf2: areaonly waypoint is activated when area is under attack
tf2: added new waypoint type "owneronly" - this waypoint can only be used by the owner of the point
tf2: fixed improved engineer building code
tf2: fixed piping and sentry attacking
tf2: improved return to defend code
tf2: bots improved aiming for melee attacks
tf2: quicker waypoint
tf2: if capture point can't be reached bots go to nearest defend point (e.g. cp_steel last cap)
tf2: more probability of defending/atacking points under attack
tf2: within 10 seconds of round end bots will push
tf2: fixed some possible crashes
tf2: fixed - bots go to the correct point under attack to defend
tf2: removed need for setup time in script
tf2: medics jump when the players they heal jump
tf2: fixed rocket launcher aiming
tf2: fixed sniper aiming if sniper can't see the ground of entity
tf2: more probability of bots choosing spy or demoman if killed by a sentry if rcbot_change_classes is enabled
tf2: fixed possible pipe waypoint was unreachable
tf2: bots don't investigate sounds if they have an enemy or were recently spawned
tf2: fixed rocket aiming
tf2: faster pipe waypoint searching
tf2: bots stop spy checking a team mate if they attack
tf2: fixed aiming when piping or spamming grens
tf2: medics don't heal if a player's already being healed by a medic
tf2: sniper improvements, taking cover after shooting
tf2: fixed bug when bots would forget getting the flag if enemy dropped the flag
tf2: if enemy drops flag bots stop returning to intel
tf2: fixed snipers walking while zoomed
tf2: fixed new sentry attacking task behaviour
tf2: medics don't hide from enemy if they are ubered
tf2: bots see spies if they are cloaked with no cloak meter left
tf2: fixed bots hearing cloaked bots moving and walking towards them cloaked
tf2: fixed bots looking back at their healing medic
tf2: improved bots choice of taking teleports or not
tf2: bots become less paranoid after they kill a spy
tf2: bots become paranoid when their sentry is sapped
tf2: fixed demoman pipe trap at flag standing location bug
tf2: improved demoman aiming with grenade launcher
tf2: engineers try to walk round their sentries (requires more waypoints)
tf2: engineers tend not to attack enemies if near their sentry so they can repair it instead
tf2: ubered players dont investigate sounds
tf2: fixed possible bug with ghost sentries
tf2: bots only build teleporters when their sentries are okay
tf2: fixed engineers going to other team resupply after building teleporter entrance after team switch
tf2: engineers go to ther sentries if it is attacking
tf2: improved defence and attack on attack/defend maps(must be set in script)
tf2: fixed a small memory leak
tf2: fixed payload bomb crash
tf2: fixed navigation crash
tf2: bots don't investigate sounds when attacking payload bomb
tf2: fixed crashes in PLR and navigation
tf2: spies try to avoid line of sight of enemies
tf2: improved demoman piping and spamming sentries
tf2: medics don't heal if a player's already being healed by a medic
tf2: sniper improvements, taking cover after shooting
tf2: fixed bug when bots would forget getting the flag if enemy dropped the flag
tf2: if enemy drops flag bots stop returning to intel
tf2: fixed snipers walking while zoomed
tf2: fixed new sentry attacking task behaviour
tf2: medics don't hide from enemy if they are ubered
tf2: bots see spies if they are cloaked with no cloak meter left
all: fixed sv_tags multiple rcbot2 tags
all: fixed possible crash while editing waypoints
all: fixed random function
all: reduced cpu usage with lots of openslater waypoints in a map and lots of bots
all: changed waitopen to waitground waypoint
all: waypoint menu shows number of paths to waypoint
all: added new debug commands
all: you can debug a bot by looking at it with the debug bot command
all: fixed crash bug when bot died on trigger_hurt
all: waypoint distances automatically update during path find
all: fixed debug bot crash when bot leaves server
all: added waypoint commands
all: new commands rcbot waypoint check, rcbot waypoint setareatonearest
all: new commands rcbot waypoint teleport, rcbot waypoint autofix
all: more reliability checks for ehandle (more stable)
all: new command rcbot waypoint shiftareas X Y - shifts all visible waypoints with area X to Y
all: bot remembers last failed path and avoids it next time
all: fixed random function to be less biased
all: fixed unable to select waypoint while editing if on the wrong team
dod:s bots periodically check waypoints where other team may hide

Download Link
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Emotional
post Jun 25 2014, 04:52 PM
Post #2


Advanced Member
***

Group: Members
Posts: 92
Joined: 5-March 13
Member No.: 2,260



Thanks for your work! smile.gif Getting better and better with each release!
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jun 25 2014, 06:11 PM
Post #3


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Wow, a BIG RCbot update... lots of good stuff... downloading... biggrin.gif

1. Doe's this still use version 4 waypoints format?
btw, I'm glad you removed scripts from tf2, i've tried scripting on other bots and i'm not to good at it... rolleyes.gif

QUOTE
all: fixed possible crash while editing waypoints

Good, think i was having that problem sometimes...

QUOTE
all: bot remembers last failed path and avoids it next time

2. Doe's this help bots use multiple routes better, not use the shortest route so much?

QUOTE
dod:s bots periodically check waypoints where other team may hide

Cool cool.gif ... I see the bots use waypoints i've placed in hiding places to take cover, and on ambush defend wpts, this will make it even better. And if players are camping on those wpts, bots will detect that too smile.gif ...
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jun 25 2014, 11:19 PM
Post #4


Admin
*****

Group: Admin
Posts: 2,990
Joined: 11-September 03
From: uk
Member No.: 1



QUOTE(madmax2 @ Jun 25 2014, 07:11 PM) *

Wow, a BIG RCbot update... lots of good stuff... downloading... biggrin.gif

1. Doe's this still use version 4 waypoints format?


Yep

QUOTE(madmax2 @ Jun 25 2014, 07:11 PM) *

2. Doe's this help bots use multiple routes better, not use the shortest route so much?



Nope, it just makes bots a little smarter, for example if there is a bad waypoint path they will try to walk towards but never actually reach waypoint B from waypoint A they will remember it so they will avoid it next time and take a slightly different route. in some cases it might cause them to take different routes just because they thought they were stuck
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jun 26 2014, 07:07 AM
Post #5


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Copied from .85 topic, I don't know if this is happening in 0.90, but thought i'd post it while i was thinking about it. rolleyes.gif

QUOTE
[edit] I don't think it's related to the breakables, but I see bots blocked at doorways quite a lot in donner by NON-breakable furniture. They get stuck on top of the furniture that gets blown into doorways. It looks like they are trying to jump off, but keep banging their head and they stay in a standing position, and they never crouch. In this situation they need to crouch to get off the furniture. I've got some images i'll post so you can see what i'm talking about...


I've seen it multiple times and more than once at this location, but "quite a lot" might be an exaggeration. Oh, the bot is trying to go though the doorway, and in the first 2 images it is the only path out of the room after going to a sniper/defend wpt on a balcony (dead end). At one point I had them jumping off the balcony, but they would get blocked by furniture there too!

dod_donner0011_2.jpg
http://www8.zippyshare.com/v/49790920/file.html

dod_donner0012_2.jpg
http://www8.zippyshare.com/v/94670543/file.html

I think 3 bots were stuck this way here (maybe only one bot was on the table, but was blocking the other 2 bots), but something hit the table & moved it just before I took the SS, then bots got through...

dod_donner0017_2.jpg
http://www8.zippyshare.com/v/17246241/file.html

Maybe just have them crouch once, every 3 or 4 times they try to jump free from an obstruction will fix this?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
YuriFR
post Jun 26 2014, 11:49 PM
Post #6


Member
**

Group: Members
Posts: 42
Joined: 7-January 14
Member No.: 2,318



I'll enjoy the mr. madmax2 posts who are here (continuation of "topic .85"), and add something to this topic over version 0.9:

QUOTE(madmax2 @ Jun 26 2014, 04:07 AM) *

I don't think it's related to the breakables, but I see bots blocked at doorways quite a lot in donner by NON-breakable furniture. They get stuck on top of the furniture that gets blown into doorways. It looks like they are trying to jump off, but keep banging their head and they stay in a standing position, and they never crouch. In this situation they need to crouch to get off the furniture.
(...) At one point I had them jumping off the balcony, but they would get blocked by furniture there too!
(...) Maybe just have them crouch once, every 3 or 4 times they try to jump free from an obstruction will fix this?


1 Similar situations occurred to me too in dod_flash: the 3 images (screenshots on the .zip) by itself explain. I've Put in: http://www.mediafire.com/download/fzauca1u8ymt2o1/Rcbot2+-+Obstacle+problems.zip

[I advance the description of these pictures below:
"The obstacle [fuel drum], which was launched there [door] without premeditation (explosion), is preventing the passage of Rc-bot: he is not able to crouch, lie down, or to try work around the door, or to retreat/backward its previous route (path / waypoint) to take different ways (to avoiding the door capped.) He just jumps, without success. "
And, on another picture:
"The obstacle (fuel drum) is here [door]: still preventing the passage of bot, times after."]

QUOTE(madmax2 @ Jun 25 2014, 03:11 PM) *

2. Doe's this help bots use multiple routes better, not use the shortest route so much?
[Cheeseh answers: Nope, it just makes bots a little smarter]


2 I very much appreciate the implicit "suggestion" of mr. madmax2: "Rc-bot not use so often the shortest way". I think this idea deserve be studied, because in some maps Rc-bots prioritizes overly certain routes, so that the longer routes become almost abandoned. I notice too that the Rc-bots insists on the shortest path, even if he show the "most higher mortality rate" and bigger danger found, on area, in relation to the rest of the routes from a map.
I will cite one location as example: the map dod_donner. The alleyway of allies attack (in the form of "L"), which gives direct access to the beginning of the germans field (I think to the second flag of axis). Every time I start a match in Donner, this alley is where occurs 70% at 80% of the skirmishes of the entire map. Although the shootout and carnage at the site is intense, the bots on both sides continue prioritizing the alley instead of daring new ways to ambush the enemy, or to do conquer the opposing flags.
It is obvious, however, that some Rc-bots choose other routes, and achieve enemy flags. Yet they continue to use the alleyway with a much higher frequency, than any other path.

With regard to this matter, may be necessary to make more changes, with the aim of reduce this discrepancy and preventing the Rc-bot becomes very repetitive and predictable, in the act of choosing their routes/routines.


Thanks, guys! smile.gif

[I using google-translator, sorry for any misunderstanding...]
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jun 27 2014, 02:09 AM
Post #7


Admin
*****

Group: Admin
Posts: 2,990
Joined: 11-September 03
From: uk
Member No.: 1



ok well I've added this to the code , will test it later
CODE

bool CDODBot :: checkStuck ()
{
    if ( CBot::checkStuck() )
    {
        ...
        edict_t *pGroundEnt = CClassInterface::getGroundEntity(m_pEdict);

        if ( pGroundEnt ) // stuck on furniture?
        {
            if ( strncmp(pGroundEnt->GetClassName(),"prop_physics",12) )
            {
                // Duck
                if ( randomFloat(0.0f,1.0f) < 0.9f )
                    duck();
            }
        }

but I think the addition of bots avoiding their last failed path would solve this issue for a short time, when a bot for example walks into a door with an oil drum or whatever and can't pass through it should take another path unless it is stuck completely on the oil drum. One thing that might prevent this is other waypoints that have other paths that would cause the bot to get stuck in the old drum again causing a vicious loop
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jun 27 2014, 09:09 AM
Post #8


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Okay, sounds good, thanks... smile.gif


I just installed 0.9 and I'm seeing corruption of screen credits, on the "Waypoints by" message. The message shows correct the first time the waypoint is loaded, but the second time it's loaded the message is trashed. Almost looks like the "Waypoint modified by" might be over writing it even tho there is no waypoint modifier. But not sure about that, I just see an M in it every time? Oh, and the corruption seems permanent there after... I checked it on vigilance, march, flasher_rc1, and avalanche. Anyone else see this?

Way past my bedtime [nods off, plants face on computer] later..... blink.gif
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
YuriFR
post Jun 27 2014, 01:36 PM
Post #9


Member
**

Group: Members
Posts: 42
Joined: 7-January 14
Member No.: 2,318



QUOTE(Cheeseh @ Jun 26 2014, 11:09 PM) *

ok well I've added this to the code , will test it later
[(...)]
but I think the addition of bots avoiding their last failed path would solve this issue for a short time, when a bot for example walks into a door with an oil drum or whatever and can't pass through it should take another path unless it is stuck completely on the oil drum. One thing that might prevent this is other waypoints that have other paths that would cause the bot to get stuck in the old drum again causing a vicious loop


Cool!! biggrin.gif

One note to add: as the games (Dod:S, TF2 etc) are dynamic, some situation may occur in which even squat/crouch/duck isn't enough to bot go pass through a portal, door, hole, alleyway etc, blocked. Example: in my case, fuel drum was launched by an casual explosion to the portal/door, impeding the passage.

I've been thinking of ways to solve the issue, and came to me 4 steps, but do not know to evaluate if they would be difficult or easy to execute/implement (programme):

1st step (already mentioned): squat/crouch/duck action. If that fails, then ... :

2st step: second action subsequent to "squat/crouch" that would be "lie down/prone" (ie: try to go crawling by way blocked).

3rd step: if the attempt to go through on prone also fail, one third action can be adopted by bots: go back a bit along the way that led to the obstacle, and try to remove it at the base of the gunshots and grenades.

Step 4: If not even the gunshots and explosions remove the obstacle, the fourth action is: Rc-bot will ignore the obstructing path (and their immediate path-connections, from that blocked point, onwards) during the entire rest of that game-match.
For this process to be not repeating, (for each Rc-bot for the same blocked point), one idea can be: once the first Rc-bot is forced to adopt this 4th action, it becomes automatically applied to all of other Rc-bots, on the same team. Ie: from that event, none bot will try to pass that way again - not on that game-match.


Final note: a combination of these "strategies", in different orders, can produce a flexible solution, perhaps even definitive. Because allows to Rc-bots a number of "pack-resources" that can be used to deal with obstacles in different and unpredictable scenarios/situations.


Thanks! smile.gif

[I using google-translator, sorry for any misunderstanding...]
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jun 28 2014, 02:53 AM
Post #10


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Hi YuriFR,

My opinion & thoughts wink.gif :

Good ideas, but lets wait & see if a crouch or a crouch-jump will solve the problem. I see some possible problems with #3 & #4. And I don't want to see them proning any more than they do now unless it is really needed (random proning for avoidance of enemy fire or grenades is good). I guess it would be ok if they can tell the difference between a piece of furniture blocking thier path and the edge of a doorway (worldspawn). But I don't think prone will be needed for Non-breakable obstructions? I'd prefer they just go another way if it is available to them...

#3 Many areas this happens at are to confined to use grenades safely. The browning (support) can move a piece of furniture easily. but a rifle barely nudges it. So, how would that work? The spade and knife don't work either, not for a heavy desk. I think it would be hard for the bots to know which way to move it, which direction to shoot it from, so grenade may be the only way?

#4
QUOTE
Rc-bot will ignore the obstructing path (and their immediate path-connections, from that blocked point, onwards) during the entire rest of that game-match.

There are many places in most maps that are waypointed as dead ends, hiding & cover places, sniper perches, just one way to go (donner balcony). These areas would become unavailable to bots, or bots maybe trapped? A player may come along & remove the blocking obstacle, but this would leave the bots unable to use the path for the duration? I don't think that would be good?

User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jun 28 2014, 04:04 AM
Post #11


Admin
*****

Group: Admin
Posts: 2,990
Joined: 11-September 03
From: uk
Member No.: 1



QUOTE(madmax2 @ Jun 28 2014, 03:53 AM) *

#4
There are many places in most maps that are waypointed as dead ends, hiding & cover places, sniper perches, just one way to go (donner balcony). These areas would become unavailable to bots, or bots maybe trapped? A player may come along & remove the blocking obstacle, but this would leave the bots unable to use the path for the duration? I don't think that would be good?


Haven't had much time to test yet but on my next day off I will get the chance. With regard to bots ignoring paths, they won't ignore them forever they will only ignore them once until they can find another path and then they will reset and try the old path again. As I thought something like that might happen.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
SPYderman
post Jun 28 2014, 06:35 AM
Post #12


Advanced Member
***

Group: Members
Posts: 59
Joined: 10-August 13
Member No.: 2,299



A lot of TF2 stuff
SPYder happy!
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jun 29 2014, 12:29 AM
Post #13


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



QUOTE(madmax2 @ Jun 27 2014, 02:09 AM) *

Okay, sounds good, thanks... smile.gif
I just installed 0.9 and I'm seeing corruption of screen credits, on the "Waypoints by" message. The message shows correct the first time the waypoint is loaded, but the second time it's loaded the message is trashed. Almost looks like the "Waypoint modified by" might be over writing it even tho there is no waypoint modifier. But not sure about that, I just see an M in it every time? Oh, and the corruption seems permanent there after... I checked it on vigilance, march, flasher_rc1, and avalanche. Anyone else see this?

Way past my bedtime [nods off, plants face on computer] later..... blink.gif

Quoteing myself rolleyes.gif ...

[edited]
I re-checked this in both 0.85 & 0.90 dods, it is a new bug in 0.90(allthough a minor bug), and it doesn't happen in 0.85. The 2nd time a map is loaded the "Waypoint modified by" message doe's appear to be over writing the "Waypoints by" message. Even if there is no waypointer or waypoints modifier on that rcw. So, I guess this is more obvious than I first thought...duh... laugh.gif

Screen Credits corruption in RCbot 0.90
dod_marche0000_2.jpg
http://postimg.org/image/uv20ckcoz/
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
YuriFR
post Jun 29 2014, 12:52 AM
Post #14


Member
**

Group: Members
Posts: 42
Joined: 7-January 14
Member No.: 2,318



Hi mr. madmax2 !!
You made ​​important observations!

I'll try to clarify on certain points. The intention here, as usual, is not to overload mr. Cheeseh with many demands, but only try to help raise possible solution-lines.

QUOTE(madmax2 @ Jun 27 2014, 11:53 PM) *

Good ideas, but lets wait & see if a crouch or a crouch-jump will solve the problem. (...)
I don't think prone will be needed for Non-breakable obstructions? I'd prefer they just go another way if it is available to them...


I agree in part with this argument of mr. madmax2: in fact, all the other suggested steps may involve wasted work if the "crouch and crouch-jump" definitely solve the problem.
I also prefer that the Rc-bots take another direction, if this is possible and easy to them do. But there are at least 2 reasons to argue that the Rc-bot will not always be able to dodge the obstacle with "crouching/jumping" strategies, or simply taking a different direction. The reasons are: (1) the unpredictable dynamics of game-matches, and (2) the existence (on Dod:S) of many "objects non-breakables" (I assume that the term refers to objects that are not the furnitures, eg: fuel drum, bicycle, radio... others). These "non-breakables" can trap the bot on any door/gateway, so that it only with gunfires, grenades, or attempt to pass lying down (dragging on prone), may produce some success (ie: bot continue the usual way).

OBSERVATION: I tried to illustrate the following with the images posted on mediafire (the previous link: http://www.mediafire.com/download/fzauca1u8ymt2o1/Rcbot2+-+Obstacle+problems.zip), but it did not work because I didn't get a picture that showed the following condition: one bot get stuck on top of a fuel drum (with his head against the ceiling) unable to get back on their route, and simultaneously: (most importantly!) remain colliding head on the ceiling (or door edge) even still in the "crouched" position!

QUOTE(madmax2 @ Jun 27 2014, 11:53 PM) *

I see some possible problems with #3 (...)
Many areas this happens at are to confined to use grenades safely. (...)
I think it would be hard for the bots to know which way to move it, which direction to shoot it from, so grenade may be the only way?


The 3rd step, referred to "Using grenades and gunshots" actually require some degree of skill on the part of Rc-bot. Completely agree with mr. madmax2: Rc-bots should be able to throw a grenade without injuring his colleagues, or injure themselves, and should also be able to successfully aim a target that is not an enemy. Above all, the Rc-bot should be able to do some judgment about the blocked area, things as: direction to move (and the direction to shooting), the distance from the grenade had been thrown etc. All this is difficult to produce (programming it is complex ...)!
In short: I think this step 3 can be considered as "the last option" to do !

QUOTE(madmax2 @ Jun 27 2014, 11:53 PM) *

The browning (support) can move a piece of furniture easily.


This seems like a very good idea! I have not thought about this possibility. But it is up to mr. Cheeseh evaluate it: because I never noticed, with proper attention, the effects of the (gun)shots of the "support" class (bots controlled!) on the furniture ... !

QUOTE(madmax2 @ Jun 27 2014, 11:53 PM) *

(...) These areas would become unavailable to bots, or bots maybe trapped? A player may come along & remove the blocking obstacle, but this would leave the bots unable to use the path for the duration? I don't think that would be good?


As to this question, in particular, mr. Cheeseh commented. I answer you, mr. madmax2, adding to the response of Cheeseh, my point of view (which is enclosed in brackets):
"With regard to bots ignoring paths, they won't ignore them forever [exactly!]. They will only ignore them once [ie: once in the each game-match], until they can find another path and, then, they will reset and try the old path again [the "reset" will occur when the next game-match starts]. As I thought something like that might happen."

That's it!
I hope I have explained the things better now!


Until next time! smile.gif
[I using google-translator, sorry for any misunderstanding...]
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
genmac
post Jul 10 2014, 12:42 AM
Post #15


RCBot Guru
*****

Group: Waypointers
Posts: 571
Joined: 11-November 11
Member No.: 2,098



Hi yah guys!

This is an awesome update especially for tf2 fans!
I might as well download tf2 really soon.

I'm starting to miss my fav source games starting wth hl2dm and dods so will
do some testing with this soon!

Anyway awesome work as always CHeeseh, YOURE THE MAN!!!
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jul 11 2014, 12:26 AM
Post #16


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Hey genmac, nice to see you back here... tongue.gif

Hey Cheeseh,

Think I saw another bug on dods with rcbot2 .9? A few times on donner, I spotted axis mg bots camping/using waypoints tagged noaxis. I haven't spotted allied mg's camp on noallies wpts. Perhaps allied bots briefly will use noallies wpts when under fire, but not camp? At the 2 places I saw it happen, one is tagged noaxis/mg/snipper, the other is tagged noaxis/defend/mg/sniper. In one case the axis mg was killing a lot of allies, so maybe thats why he stayed there, at the other place he was not shooting to often. In both cases, there were gaps in the action where I thought the bot would move but did not. It might be hard to track down, I did not see it very often, but I wasn't always looking for it either. I'm not even sure this is a bug, but I don't think it was happening on .85 or .76? It's sorta random I think?

btw, great job on the snipers, they are much more deadly in .9 than .85 or .76! I do have more observations i'll post later...

Besides the donner rcw's I just uploaded, i'll be adding screen credits & tweaking my modified flash rcw so you can include it as an optional rcw with your next release. The flash rcw that was included with rcbot2 .9 does not have credits either. I'm not sure what to put on it, the rcw is different than mine. Should the dod_flash credits be:

Waypoints by Testeryyy modified by Cheeseh

And I'm doing the credits & tweaks on .85 so they won't be corrupted...
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jul 11 2014, 07:19 PM
Post #17


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Excess Prone Problem?:

Can the proning be turned down a bit, or maybe it needs a fix unsure.gif ? I first noticed on snowbridge with rcbot2 .85, bots were proning long distances, like all the way up & down long slopes, even when not under fire. It's a large open map, so I thought they might be seeing enemies & staying proned, but I don't think so now. In donner with rcbot2 .9, I saw a axis bot prone in a loop around those concrete barriers, then from one end of the street back past the axis 2nd flag, continue to axis 1st flag (he killed one allied bot there), then prone back to where I first saw it proning, then it was killed by an allied bot! Oh, it was not a sniper or mg, it was a support or assault class. On snowbridge i remember a mg doing it. I don't think it is limited to a specific class. This seems to be a pattern, where sometimes a bot will keep proning until it is killed, or for a very long time even when no enemies are near. In small size maps it is probably less noticeable and less of a problem because the proning bots get killed quicker than they would on a large map. On medium & large maps, excess proning may be effecting the pace of the game, slowing it down...?


Comparison observation:

Since I was switching between rcbot2 .85 & .9 a lot while waypointing on donner, I was watching the attack patterns on the overview map a lot. Even with squads turned off, it seems .9 bots stay grouped together much more and don't spread out as fast as they do on .85. Is it because they are less dependent on fixed positions in .9, or are more flag goal oriented. Bots don't seem to use the fixed positions as much? I can't figure why, but the speed of flag caps & recaps seems higher in .85, I think it is they just don't group together so caps are easier with fewer enemies near, plus they use alternate route more (not moving in groups as much as .9). Is the squads disable not working in .9? Or is this just new behavior?

When you have the time to test yourself, no hurry, just reporting this stuff while I have time... wink.gif
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jul 16 2014, 04:50 AM
Post #18


Admin
*****

Group: Admin
Posts: 2,990
Joined: 11-September 03
From: uk
Member No.: 1



Interesting that you saw a comparison with the attack patterns because there were no changes made to this in the new version. There were no changes made to the squad code.

As for the proning, .85 and 0.9 use the same system, its a simple learning procedure which inhibits proning if they are killed while proning they won't do it next time, and if they kill someone else while proning they will do it more. But they don't remember every map they must re-learn at the beginning of the map, so the longer you let the map run the more it will be better, although each time you start the map it will be different because they all start random
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jul 16 2014, 06:35 PM
Post #19


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



Hi Cheeseh,

Yeah, the attack pattern is a mystery, as I didn't see anything in the changelog that would suggest a difference! But it seems bots don't seek out the fixed positions as much in .9 (dods)? They seem to be heading towards the next flag in greater numbers instead of going to the fixed positions. I may not be explaining it to good, but when I set up fixed positions in .85, bots don't appear to use them the same in .9? In dod flash, fewer bots seem to go to the #2 flags defensive positions at certain times, fewer bots seem to be waiting at those positions for the enemy to show up? It's not a scientific observation, thats for sure. wink.gif

Proning doe's appear to be the same in both versions. Bots learning when & when not to prone is cool. I'm looking for a limit on thier proning distance, say maybe, approximately twice the width of a street, not twice the length of a street? Actually, it seems just some bots don't know it is safe to stand up again and just keep proning until killed... Not every bot doe's this (excess proning), just a few. I'd like to see all bots jump to thier feet a little faster, but it seems a few completely forget they can walk. laugh.gif

P.S. I will be posting flash rcw's today...
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jul 17 2014, 05:34 AM
Post #20


RCBot Guru
*****

Group: Waypointers
Posts: 790
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



I added screen credits to the dod_flash rcw that comes with .9 (done with .85), I'm just not sure it's correct? I also did a very small edit to it to balance axis & allies a little bit. I just removed 2 paths at allies first flag so allies can't retreat behind their flag, just like the axis side was done. Screen credits will show:

Waypoints by TesterYYY modified by Cheeseh

I also included my new modified rcw you may also include, either as an optional rcw or as the default, with the next rcbot2 release. Screen credits will show:

Waypoints by TesterYYY modified by MadMax2

I did a number of changes to it. I removed the last defend tag from a flag (center), bots won't camp on it any more and move past it quickly smile.gif . Added several new wpts for cover places, some are cover_reload or defend. New paths for expanded bot movements... added 3 breakable wpts to windows.

Wanted to get these posted now before you release again, I won't have much time over the next week or 2 to work on rcw's. I'm still tweaking on flash, so may update it again before your next release, or maybe not? This one works good...

dod_flash_rcb85_rcws.zip
http://www25.zippyshare.com/v/23120423/file.html

I also fixed the expired links for the 2 rcw packs with screen credits (in the .85 topic), just in case you need them again (since .9 corrupts the screen credits)... (still 30 day links from last download)

stock_dods_rcws1.rar
http://www25.zippyshare.com/v/6117455/file.html

madmax2_dods_wpts_pack1.zip
http://www25.zippyshare.com/v/52471281/file.html

==================================================================

Okay, I ran 9 more 20min bot matches in flash today, 2 on .85, 2 on .9, 3 on .85, then 2 on .9... My focus was on proning, but I also watched the pattern some. Bots seemed to spread out ok to the #2 flag areas this time on .9. I didn't notice a significant difference between .85 & .9 attack pattern, but there may of been a few times when bots didn't go to those areas? I was thinking, maybe the proning was effecting a difference in attack patterns, but I could not confirm that today unsure.gif ...

I could not see a significant difference with proning between .85 & .9. I did decide flash is not a good map to look for the proning issue. On flash, bots usually get killed to fast to see excessive proning. But I did spot a few bots prone a long ways. As you said, bots only learn proning for the current match, and I saw them prone more in the 2nd half of match as compared to 1st half. Most of it wasn't excessive and occured because the bot was under attack (center flag). Many of the proning bots were killed before they got to cover or a safe area. But occasionally a bot would get clear and keep proning a long ways. If they did not get killed, I saw all of them eventually get to thier feet. Some would keep going until they caught on something like the corner of a door or building or stairs, then they would stand up. I should add, I did see many other bots get to a safe area and stand up on thier own, or even stand up when not at a safe area, and return fire. So it is a minority of bots that prone long distances, and it may be hard to spot on a smaller high action map like flash. I did take a few debug images this time, but I don't think I got a good one, cause something caused the bot to stand at about the same time.

When I have some time in the next week, I'll check this on some other maps like donner or snowbridge, and should be able to get a good debug image. I was seeing it more on donner when I was waypointing, which means it was probably a long session because I have no timelimit set by default for waypointing. So at times, my sessions may of been going over a hour, giving more time for the bots to learn to prone. rolleyes.gif

btw, cover_reload is a cool little addition to the bot. I think i'm using it correctly, for bots to hide in corners and take cover behind sandbags & low walls. I've combined it with defend & sniper wpts too, but usually just cover_reload/team or non-team... smile.gif
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

2 Pages V  1 2 >
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



- Lo-Fi Version Time is now: 21st January 2019 - 12:22 PM