Mateos

Hello, 1944 Huertgen Forest, with the attached WIP waypoints; Axis North Path goal, near Allied Farm spawn, the southest grenade goal is 'evaded' though actually at a safe distance I could just move it way, as I did for one of the 3 goals, but the 3 nodes are at a safe distance It's fine to have it trigger at 400 units; what I'm going for is add a check for AvoidRadius before affecting the high-priority goal making bots evade even though the ent is farther away from bot than the projectile' AvoidRadius, e. g. for the grenade entity between 400 and 320 units Aight, thank you! May I ask your pov about the other points, or do you think it's not worth considering, like benefit(s) would be too small or too much overhead to work around? 1944 Huertgen Forest.zip

Good morning, I'd like to raise several questions on these two things I have setup 3 GRENADE goals having the same TargetGoal, so several bots can do it at once and the destructible gets destroyed rather quickly A little downside of TargetGoal I have noticed is that the bot stops throwing upon the entity getting destroyed, not upon calculating the damage that will cause the last thrown grenade, so there's always an extra grenade thrown (excepted if out of ammo), but that's bearable (a bit less when multiple GRENADE goals targetting the same ent, but nothing dramatic, that's a side information) They're far enough from the ground surface where grenades land to not cause damage to every GRENADE goal position --- Once the bot has started that GRENADE goal, it is totally defenceless: it will keep throwing grenades until the TargetGoal is destroyed or grenades are depleted, even if it is getting shot at all along --- Once finished by TargetGoal destroyed, that extra grenade I talked about earlier, well, the bot will go through the cleared path, not getting any WatchForProjectile, and will often blow itself up with that grenade... --- Other thing: WatchForProjectile goal is affected upon entering WatchForProjectile radius, not checking this.AvoidRadius Would it be a good thing to add something like the following in this.Events[EVENT.ENT_ENTER_RADIUS] before affecting this with AvoidEntClass/Priority? if ( DistanceBetween(this.Bot.GetGameEntity(), ent) > this.AvoidRadius[ entClass ] ) { return; } --- The GRENADE radius should be lowered 250 instead of 320, 250 being the max splash damage from it --- There's a comment about Arty being removed due to making bots locked down, same applies to grenade ^^" Dunno if anything can be done about this --- Once out of grenades and goal still up, when the only available goal is grenade, bots don't go grab in-range ammocab; dunno if anything can or should be done about that --- To finish, a question: InWater and UnderWater are excluded, I guess for the run and crouch behaviour, but should there be a behaviour to evade the explosion, still? --- Hope these points make sense ^^" Thank you in advance!

Oh wow thank you very much! 💜

Good evening, I'm trying to script roles so that 2 bots get role A and all the others take role B (or there's only role A perhaps; what's important with A is that it has a different spawn/objectives) Reading the algo in goal_rolemanager.gm, I'm not sure it's possible to have that automatically If there's AllBots false, at beast half the team will get a role If I have role B with higher numbots than A, B will get all the bots except one If I set B numbots lower than A, I even had more bots getting A than its numbots (while I'd expect the role manager to respect numbots and discard AllBots-on-minded algo) Am I missing something, or will I have to manually handle roles in OnBotJoin? That would completely skip the role manager goal Thank you

I see 😕 Was afraid of something like this, that will complicate the scripting then ^^' Thank you!

Hello, Is it possible to modify the concept of Range from direct distance to waypoint-network distance? I have bots walking all around a map because of a constructible in the middle, but I'd like them to keep goals if they're close enough, and I thought range would be enough, but nope ^^" It makes them get out of range from a direct line then switch goal upon being out-of-range, but they should drop the goal as soon as the constructible gets built (since this can change the real distance to reach the target goal), and get the goal upon destruction (same logic), logically? Or is there a way to force re-evaluating distance/priority upon a trigger? Though it seems to be taking the problem from the wrong angle Do you need sample waypoints to check? Thank you in advance Regards

Aight, thank you!

Good morning, It seems that, if you setup roles for only one team, and enable a goal having a role for both teams, the team without a role table will not do that goal Simply commenting-out the goal role affectation enables the role-less team to do the goal, so I'm pretty sure of the behaviour Is this a bug or intended (like, is it needed to add a role to the other team and affect it to the goal?), or something's wrong on my end? It looks like a simple oversight, let me know I can supply test files if needed, I'm doing that on Resurrection waypoints, upon Main Entrance Power destroyed, to split Axis defence without travelling, but keep Allies going for their goals as they like Thank you in advance Regards, Mateos

Right, and I've even tested drawing the goal and can't read >.> So affected wrong var in the function Thank you

Good evening, I'm going through the rework of my old Operation Resurrection waypoints I've added a mobile mortar goal for Axis on start, enabled Mansion cabinets, and specifically increased the range of the ammo one so the mortar goal is within range Once the bot is out of ammo, it does not go for it I've modified goal_usecabinet's this.GetPriority function in the following manner (added the else part to force the DestGoals, and check actual range), and the bot goes for it: if(ammoPriority > healthPriority && ammoPriority > 0.7 && ammo.AmmoType>=0) { if ( this.QueryGoals(Util.QueryTable, 0x52ad0a47 /* AMMOCAB */) ) { this.DestGoals = Util.QueryTable; Util.QueryTable = {}; this.CabinetType = this.CAB_AMMO; this.AmmoType = ammo.AmmoType; this.AmmoAmount = ammo.GetAmmo; this.Priority = ammoPriority; } else { tstGoal = GetGoal( "AMMOCAB_main_ammocabinet" ); Util.MapDebugPrint( "Range from " + this.Bot.Name + Util.DebugColorString + " to " + tstGoal.GetName() + ": " + DistanceBetween( this.Bot.GetGameEntity(), tstGoal ), true ); this.DestGoals = { tstGoal }; this.CabinetType = this.CAB_AMMO; this.AmmoType = ammo.AmmoType; this.AmmoAmount = ammo.GetAmmo; this.Priority = ammoPriority; } } Am I missing something big? ^^" I don't know where to look at the QueryGoals function (called from C?) Attached my current waypoints Map download link: https://wolffiles.de/filebase/ET/Maps/operation_resurrection.zip Thank you in advance Operation Resurrection.zip

Change name to Name

Can you share the map name/download/waypoints? Is this ETL Warbell?

Oh god the == instead of = on the var init >.> So it was initialized with a boolean and not a string as thought/expected... Hope to have a copy of your eyes someday I prefer your solution as the sleep is now in the door moving table rather than the button pressing one, looks more logic! Thank you very much for the investigation and related commits to the repo!

What I did is watching the console and set a debug print at the top of the trigger OB script side I had the debugtriggers prints (all at once, thus making me think just use the one having a velocity, to know if the door is either opening or closing, since the button event is twice 'opening' on both events), then a delay before the debug print, that's what made me think there were a delay I've followed the wiki page about path through switch, but it seems, as did Tomek, that moving the Enabled false from 'after the Opening/Opened' to 'before' helps forcing bots stop using the button, even though the condition in ExitConditions looks right (first instruction of trigger is to change door status from Closed (0) to Opening (1), and ExitConditions tests status > Closed, just like in the wiki) IIRC most of OB is single-threaded, perhaps it stays somehow stuck in ExitConditions, and thus the status switch happens later; and as the map author did not protect the button from spamming, it gets the whole thing stuck; but why would setting Enabled to false would then make it react so quickly? I'm not sure to understand the flow; perhaps the issue here is only that the button is unprotected by map author, contrary to some other maps? Or am I totally misunderstanding things?

I think, using your solution with 2 triggers, only moving Map.Switches.right_lab_door.Enabled = false; before the sleep( 1.25 ); is enough, and that makes the ExitCondition table useless, and seems to work yeah Was hoping for a working single-trigger solution, but heh Here's the merged work: voilegarde_b3.gm