Mateos

May 28

Good afternoon,

There's a specific spot of a TRIPMINE that does not work in 1944 Nordwind 2, next to the Allied CP, with bot stuck in a loop; while I can myself put them there:

The distance to the wall is correct (made a custom command to call ETUtil.CheckTripminePosition from the goal position to make sure)

Map download link: https://fearless-assassins.com/files/file/2690-1944-nordwind-21-1944_nordwind21pk3-and-waypoints/?do=download&r=13200&confirm=1&t=1&csrfKey=bbb23202fbabcff8052b2c0883131733

Attached waypoints
-> Only CP and this TRIPMINE are available to Allies OnMapLoad
-> CP has a higher priority to be built 1st, because the TRIPMINE is inside the build trigger of it; could that be the issue?

What is the issue here?

Thank you in advance

1944_nordwind2 - TRIPMINE at CP test waypoints.zip

May 16

Works perfectly, thank you once again!

May 16

Good morning,

In 1944 Nordwind, I saw bots spawning at Warehouse (so Warehouse Door destroyed) wrongly following a route for BUILD_Tank once the Tank is past the Depot area
Same if spawning at Axis Spawn
When the Tank is damaged, there's Util.ForceRouting on

I wrongly wrote the Util.ExcludeClass in Tank_Past_Depot_Area, fixed it locally
From: Util.ExcludeClass( "ROUTE_Hill3", CLASS.ENGINEER );
To: Util.ExcludeClass( "ROUTE_Hill3", 0, CLASS.ENGINEER );

When typing /bot sag 3 1 0 (3 to avoid the rendering), I can see the priorities are good for Engis: 0, as expected

I've edited the routes to only have the ones involving ROUTE_Hill3 available to ease testing/monitoring

The Axis Engis still go through that route note, which has a 0 priority for their class

Thus the question: is the route node priority taken into account in the routing processing? Or only its team availability?
My goal here is to have it disabled for BUILD_Tank mainly; I could re-affect the routing tables to have it restricted only to that goal and not all Axis BUILD, but I think it's good and simple enough to just affect the priority of the route node for the Engi class ^^" (Allies don't have that route node in their routing)

Map download link: https://wolffiles.de/filebase/ET/Maps/1944_nordwind.zip

---

Side note:
In the same context, I've scripted OnBotJoin so that Axis bots select the Warehouse spawn, then there's a spawn split function that shouldn't change it
Added prints before the 3 possible calls to ChangeSpawnPoint, they correctly select spawn 4
But they still spawn at Axis Spawn, number 2
I suspect the fact spawns are quite broken on that map to be the culprit
Or I've written some mistake I can't catch

---

Thank you

May 10

Good evening,

I'm porting the work done on 1944 Huertgen Forest Final to the Final 2 version

For the BUILD_Axis_North_Path, I had to go through the custom BUILD goal setup; trace is good as far as I can see, looks the same as Glider's Assault Ramp for instance

But the Axis Engi bot supposed to do it does not go for it (right role, available, reachable, rendered green)

To reproduce: 5 grenades to destroy the Axis North Path on the wood logs, and just add one Axis bot (it will automatically be DEFENDER1, and its highest available goal is the North Path)

Attached the waypoints

Map download link: https://wolffiles.de/filebase/ET/Maps/1944_Huertgen_Final211.zip

Using recently compiled DLL from GitHub repo

What's wrong? ^^"

Thank you in advance

Regards

1944 Huertgen Forest (Final 2) - Axis North Path issue.zip

March 26

Good evening,

I'm trying to manage spawning to avoid bots bottle-necking the single and narrow exit of a spawn...

I had a first try at it in 1944 Nordwind, that I thought working well enough

Now copying and tweaking it in 1944 Huertgen showed bots don't obey MoveTowards their own position, unlike when using Goto in navigational path through or goal

Map download link: https://wolffiles.de/filebase/ET/Maps/1944_huertgen_forest.zip

Should I replace the region trigger by a large waypoint covering the spawn hut with a path through, or is MoveTowards wrongly used or not working in some cases?

Should I create a custom high-priority goal (like the one you made for me years ago, goal_stopbots), and give it/remove it from bots through the algo?

You'll find below a sample code; I've added a print which shows bots just go further and further away from their target position, to the point they're still managed by the algo even though they're outside the spawn... Breaking the closest bot calculation

The sleep before releasing the mutual exclusion is given a high value to ease the observation (originally 0.75)

Attached in a ZIP gm+way (one named waypoint used to position the spawn exit for distance calculation)

global Map =
{
	Debug = 1,		// Please set to zero before distributing your script

	// Avoid spawn exit bottleneck
	// Only care about bots...
	// Class/weapon not taken into account (aka heavy weaps slowing down first movements)
	tank_spawn =
	{
		Name = "tank_spawn",
		TriggerOnClass = CLASS.ANYPLAYER,
		closestBot,
		mutex = false,
		botList = {},
		OnEnter = function( ent )
		{
			bot = Util.IsBot( ent );
			if ( !bot ) { return; }

			Map.tank_spawn.botList[ bot ] = 1;

			// Immediately capture current bot position
			// If we use GetPosition in the loops, the position is modified because the bot moves...
			botPos = bot.GetPosition();

			// Little sleep to let all spawning bots be listed
			sleep ( .1 );

			while ( bot && bot.Health > 0 && Map.tank_spawn.mutex )
			{
				// Don't move until it's your turn to enter the mutex
				bot.MoveTowards( botPos, 8 );
				Map.PrintBotPos( bot, botPos );
				yield();
			}

			Map.tank_spawn.mutex = true;

			// Determine the closest bot from the exit, remove it from the list, make it go, sleep a bit, free the mutex, exit
			// If the current bot isn't the one, free the mutex and loop until it's the case...
			Map.tank_spawn.closestBot = Map.DetermineClosestBot( Map.tank_spawn.botList );
			if ( bot && bot.Health > 0 && bot.Name != Map.tank_spawn.closestBot.Name )
			{
				//Util.MapDebugPrint( "Freeing mutex because not " + bot.Name + Util.DebugColorString + "'s turn", true );
				Map.tank_spawn.mutex = false;
				while ( bot && bot.Health > 0 && bot.Name != Map.tank_spawn.closestBot.Name )
				{
					// Don't move until it's your turn to move out
					bot.MoveTowards( botPos, 8 );
					Map.PrintBotPos( bot, botPos );
					yield();
				}

				// Now the current bot is the closest bot, take back the mutex
				Map.tank_spawn.mutex = true;
			}

			if ( bot ) { Map.tank_spawn.botList[ bot ] = null; }

			// Only look for the next closest bot if the one we just cleared wasn't the last of the list...
			botCount = 0;
			foreach ( dont_overwrite_bot_var_here and val in Map.tank_spawn.botList )
			{
				if ( !dont_overwrite_bot_var_here || dont_overwrite_bot_var_here.Health <= 0 ) { val = 0; continue; }
				if ( val == 1 ) { botCount += 1; }
			}

			if ( botCount > 0 )
			{
				//Util.MapDebugPrint( ToString( botCount ) + " remaining, looking for the next one...", true );
				Map.tank_spawn.closestBot = Map.DetermineClosestBot( Map.tank_spawn.botList );
			}

			Util.MapDebugPrint( "Exiting mutex as it is " + bot.Name + Util.DebugColorString + "'s turn", true );

			// Let the bot move a bit towards the exit before allowing the next one to move
			sleep( 2 );

			Map.tank_spawn.mutex = false;
		},
		OnExit = function( ent )
		{
			// As we don't wait for the bot to surely exit the spawn
			// (we just leave a bit of time between each bot, so they follow each other in single line),
			// no need for OnExit (botList filled and cleared exclusively in OnEnter)
		}
	},

	PrintBotPos = function( bot, targetPos )
	{
		//Util.MapDebugPrint( bot.Name + Util.DebugColorString + "'s position -> " + ToString( bot.GetPosition() ), true );
		Util.MapDebugPrint( bot.Name + Util.DebugColorString + "'s distance to its target position -> " + ToString( DistanceBetween( bot.GetPosition(), targetPos ) ), true );
	},

	DetermineClosestBot = function( list )
	{
		closestBot;
		dist = 500;

		foreach ( bot and val in list )
		{
			if ( !bot || bot.Health <= 0 ) { val = 0; continue; } // Disconnected or dead meanwhile
			if ( val != 1 ) { continue; }

			currentDist = DistanceBetween( bot.GetPosition(), Map.tankSpawnExitPos );
			if ( currentDist < dist )
			{
				closestBot = bot;
				dist = currentDist;
			}
		}

		//Util.MapDebugPrint( "Closest bot: " + closestBot.Name + Util.DebugColorString + " (" + ToString( dist ) + ")", true );

		return closestBot;
	}
};

global OnMapLoad = function()
{
	// Move self in front of the Tank Spawn
	pos = Vec3( 2739, -3910, 260 );
	wtPos = pos /*+ Vec3( 0, 0, 64 )*/;
	// ExecCommand( format( "wt %s %s %s", ToString( wtPos.x ), ToString( wtPos.y ), ToString( wtPos.z ) ) ); // Just realised I only have this signature locally

	// Grab the exit position only once, then reuse it
	wpTable = {};
	w = Wp.GetWaypointByName( "tank_spawn_exit", wpTable );
	Map.tankSpawnExitPos = wpTable.position;

	// Register the trigger
	OnTriggerRegion( AABB( 2607.125, -4437.875, 193.125, 2912.875, -4127.813, 267.125 ), Map.tank_spawn );

	Util.MapDebugPrint( "OnMapLoad", true );
};

1944_huertgen_tank_spawn_exit_management_sample.zip

March 22

Extra case: if a bot is about to throw a grenade at the same time the target is destroyed, it will change facing (because going for an other goal I guess), and the grenade will get thrown somewhere between these 2 facings ^^"

I believe it should still throw the grenade at the dead target, to avoid wrongly throwing it (and avoid killing mates), since leaning does not cancel the throw unlike panzer

March 13

If there's already something to save charge for PLANT, it's perfect!

My main concern was the selfkill/teamkill, but that probably happened while going for building CP then; but the spot where that issue happens and the CP location are far enough to replenish the charge

Thank you for the 3 possibilities ^^

March 12

Good morning,

I use roles to split bots between an east front and a west one

On the west one, I'd like the Engineers to use a Thompson instead of a Garand, so that the charge isn't consumed by firing grenades instead of planting dynamite or building neutral CP for new spawn... oh, and also avoid blowing itself and sometimes teammates up that way due to narrow corridors, which neutralises the offensive heh

Once a specific trigger occurs, that enforcement turns useless, because new spawn and no more roles needed

I thought first of OnBotJoin, but bots don't have a role yet (I guess that's to allow the waypointer to have full control on role management before the role manager goes through to take care of it, which sounds perfect to me)

So I've made a region trigger on the spawn, setting the TriggerOnClass on Engi to save a condition inside the OnEnter table; the name of the trigger is later used to delete it upon the 'specific trigger'

It works well until OB sometimes wants to switch the weapon of the Engi mid-game: it makes the Engi get stuck in a spawn/selfkill loop for weapon switching, if I understand what I witnessed correctly

Am I making a correct assertion here, or is it something different? How can I work around that issue?

I'm kind-of going for temporary weapon prioritisation depending on team/role/class, to sum the thingy

Thank you

February 26

Extra-thing I've just noticed: if a bot gets revive upon a GRENADE goal, the grenade will be dropped at its feet, since there's a delay before being able to actually shoot again, and I guess the bot tries to shoot as soon as it's revived ^^"

Or the reviving Medic blocked the throw (while dispensing medkits), dunno

January 28

Hello,

7 hours ago, palota said:

Which map is it ? Does the target entity have health information which could be used to calculate exact amount of grenades needed to destroy it ?

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

7 hours ago, palota said:

We can't ignore EVENT.ENT_ENTER_RADIUS if distance is greater than AvoidRadius. If a bots is moving towards a grenade or a grenade is moving towards a bot, then the event is triggered once at distance 400.

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

7 hours ago, palota said:

If you want bots to go to ammo cabinets, you can change priority

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

January 27

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!

January 18

Oh wow thank you very much! 💜

January 17

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

January 10

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

January 8

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

October 15, 2024

Aight, thank you!

October 14, 2024

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

September 11, 2024

Right, and I've even tested drawing the goal and can't read >.>

So affected wrong var in the function

Thank you

September 10, 2024

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

July 7, 2024

Change name to Name

July 7, 2024

Can you share the map name/download/waypoints?

Is this ETL Warbell?

July 7, 2024

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!

July 6, 2024

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?

July 5, 2024

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

July 5, 2024

Good afternoon,

I'm going through Chateau Voilegarde waypoints again, and I'm going through the button-commanded doors for Axis, so they get as quick as possible where they're needed

I've noticed there's a delay between the console prints you have with `bot debugtriggers on` and the call of the OB trigger bound to it, where I change the door status, which is used in the ExitConditions (the table where you tell the bot to stop trying to click the button)

The issue here is that these buttons can be spammed, which resets the door animation... The spamming stopping after the switch script table timeout

Tried to play with timeout to see if it could help (initially 3000, tried 1000/750/150, kept 1000), but it quickly gets messy when it's crowded

I'm using the door goto event to tell if it's opening or closing, the button has its own events since it moves, but since the events of both the button and the door are fired at once through the console command, I guess it's fine?

I've attached my current waypoints, with the door near Axis Laboratory spawn scripted; Axis will spawn there and go through the path through switch when the Courtyard flag is owned by Allies, since it is the shortest path to get back to the flag

Map download: https://www.wolffiles.de/index.php?filebase&fid=224

Thank you in advance

Chateau Voilegarde Waypoints.zip

Sign In

Forums

Profiles

Events

Gallery

Downloads

Articles

Posts posted by Mateos