BRUT/BRUTUS (Entry for the December contest)

[a9902957@nepwk.com]

I was chatting a bit with Kelly about out-of-zone stuff. I don't know if something else was operated here but things might be solved - I guess...
Whatever actor or that zone itself can lock-down paths for nodes out of range and then Pawns won't walk there - poor lost Pawns will remain to die.
Paths lock-down can be done by adding 100000000 Cost perhaps even ExtraCost or retrieving connections with DescribeSpec and removing connections from Paths upStreamPaths PrunedPaths lists exactly like in map SkaarjTower pathed by Higor where some Teleporters inactive needed to be hacked as long as Teleporter code it's incomplete. A Teleporter disabled should lock paths as well not only when pawn is closer (with SpecialHandling) leaving it to Wander around. Higor's actor is tracking teleporters based on a timer and is placing paths back into lists if Teleporter is going enabled. It's a bit engineering but is doable - demonstrated.

Thanks, I came across the PN costs while researching but I certainly do not want to go a binary active/disabled route here because it is specifically this "poor lost Pawns will remain to die" scenario i.e.
any Botz that are outside of the zone without a "nearest" NP that is in the zone getting stranded sloppy thing that I aim to not willingly accept / go for such a poor / flawed easy choice here.
Motto: Leave no-one behind.

Also later Botz should get smarts like ducking into near zone but out of zone parts to retrieve juicy items or somesuch when health/situation permits.

Yup, papercoffee check viewtopic.php?p=131298#p131298
That is my current main problem to tackle. But still in a way that is not global but per each Botz (at least figuring in its location/situation).
Actually the main one at the moment is the pile up at the ZoneGenerator that can happen where Botz just hug each other there. Seems to be more of a FerBotz 18 / XC_Engine 25b thing maybe. Confer below.
But Botz hugging each other and not using the rounds for their currently equipped weapon in that situation is a general problem.

Also I think I am noticing a pronounced difference in FerBotz 18 on UT 469b XC_Engine 25b vs
FerBotz 20 on 436 XC_Engine 19 currently:

The thing is another current issue is Botz piling up at just beneath the ZoneGenerator. That is they "hug" each other appearing to each reach that spot but do hardly if ever attack each other in that situation.
469 seems to suffer much more from this (if not even exclusively).
Either they are better at reaching that spot or the problem just has a higher likelihood to come into existence there for some reason.

I am also still buffled why bots go to that specific spot and stick to it like that at all.

I have quite some new things I found looking at FerBotz code to still toy with and attempt to use to better things here. But man it is more complicated than I first hoped for.
Respect to all the coders here! Rock on


A recent thing I remembered which might have caused it was BRUT's / JackGriffin's BotBurger stuff which I just kept 1:1 when I added the few lines for FerBotz support (at that point I knew that may come back to bite me), but it is not caused by those.

[sektor2111]

A mitigation can be to deal with a sort of flexible Inventory - more exactly adjusting desire for an item.
Inside zone whatever inventory can be unlinked from InventorySpot and adding this new one.
How does it need to work ?
The most far away Bot will have a huge desire for this item and coming closer in zone. Bot nearby item won't like it, "omg, this is ugly". If bot is really too close, desire will be -1, letting him to crawl around. This item can be connected directly with zone size. If Bot is closer to zone boundaries it will have a strong desire for coming at item, if not, desire can be into a normal level.

Of course it needs more work around and hours of tests and polishing code after figuring instances from more maps.

[a9902957@nepwk.com]

Here is the current version of my botch work on this.
It works sort of decent on 436 with FerBotz20.

I know this one does not work as intended on 469b with XC_Engine 25b and the FerBotz that are 469 compatible which Higor shared on discord.
Dunno if FerBotz 18 UScript version would work OK there. The problem seems to be (among others I think) IIRC that Timer does not work there in the TargetAdder it seems.

Newer hacked/botched BRUT.u this time as well.
https://ufile.io/ywl6of4y BRUT.u unzipped will live 30 days there
BRUTForFerBotz20.7z ( BRUTFerBotz.7z there) Mirror: http://medor.no-ip.org/index.php?dir=Ga ... tleRoyale/

[a9902957@nepwk.com]

I am again attempting to improve bot play with this.
This time with MBot_F (could also copy/switch that to regular Bots).
I think one would maybe have to subclass those.

With the current mutator attempt and Timer function in it you only get limited control over the bots and I am struggling with getting them to break off from a fight and concentrate on moving into the zone instead.

Code: Select all

     Interested.Enemy=none;
               Interested.OldEnemy=none;
              
               Interested.MoveTarget=Interested.FindPathToward(CZGB, true, true);
               Interested.OldMoveTarget=none;
               Interested.GoToState('Roaming', 'Moving');

Won't do it for example.

I am beginning to see how wrong and futile it is to attempt to go the route with abusing the Timer function inside a mutator in hopes of getting good control over bots..
I would really need to subclass a Bot and override its functions to really suite the gametype.
Guess that'd be for another day(s).