Mateos

Good evening, On maps such as Rjuken Dam, there's some navigation under water through vertical/horizontal pipes On a vertical entrance, with simple waypoints, bots barely get under water then back up at the surface waypoint, and so not reaching the bottom node Is it possible to have this working with just waypointing, or does it require some path through? It almost feels like ladders when you don't set the related waypoint flag (haven't tried to use that flag in this case) Thank you

Good evening, When launching a dedicated server, OB generates 'omnibot_mapname.log' files per map (I observed it, perhaps that's not precisely that?) Is there something that may turn that off? Writing permissions? Asking because I wanted to investigate why bots behave differently on a particular remote server, but the admin told me these files aren't generated on his end Thank you

I just retried by editing the .gm (forcing spawn #1 in OnBotJoin and only enabling DEFEND_Flag_.* OnMapLoad), and it works first try... I don't know why doing something similar but during game progress with commands does not work the same I'll check my install and try with a clean one

Hello, I just performed a test on Seawall Battery There's a definition for DEFEND_Flag_.* (5 nodes) with a weight of 3 involved MapRoutes["DEFEND_Flag_.*"] = { ROUTE_AxisSpawn = { ROUTE_flagroute = { Weight = 3 }, ROUTE_gunpatrol = {}, ROUTE_southstairs = { ROUTE_guntop = { ROUTE_guntop = {}, }, }, }, }; I've written a command to move all 15 spawned Axis bots to spawn #1 (Axis Main Bunker, where ROUTE_AxisSpawn is; command calling ETUtil.SuicideSpawn), and an other command so these DEFEND spots are the only available goals to them (e. g. a SetAvailableMapGoals called through a console command) I had all 15 bots go through the 3-weighted route (flagroute) 3 times in a row I know the CAMP-type goals are limited to a single bot, but I'd expect sometimes a bot to go through one of the 2 other routing nodes (gunpatrol and southstairs) Is this test biased in some way? Or any misunderstanding of weight behaviour/probabilities behind? Regards Edit: 5 Axis bots, 10 times with the help of kt command, always through the bottom 3-weighted node

OK, but still, what is wrong with the attached waypoints?

Good afternoon, Around 2016-2017, I told Tardis I would look into his Dam Revenge V2 waypoints, because that map has an elevator, and bots are just staying at the top, doing nothing In the current SVN files, there are directly-linked waypoints with a path through property, which I believe breaks the thing; I've reworked them to avoid that, reviewed the initial Enabled states and Wait functions, and fixed the OnTrigger for the lift movement, and the 1st part almost works (going from top to bottom) But once at the bottom, the bot doesn't move away (waypoint connections are correct) I've added some prints in the goal_paththrough_useswitch.gm script to make sure there isn't any more overlap(s) between the 4 path through use switches: bot exits correctly the one he's in and does not seem to enter any other one debugbot all fpinfo indicates it is going for the correct goal at the bottom (planting pipes), no reachability issue printed in console Map download link: https://wolffiles.de/filebase/ET/Maps/dam_revengev2.zip Attached my current files; adding an Axis Engi bot will have it build the CP then go through the elevator to reach the Pipes to plant at the bottom all the time for quick reproduction of the case Thank you in advance Dam Revenge V2.zip

Edit et/scripts/goals/goal_checkstuck.gm, and set this.LogStuckage to true (l. 6)

I think by giving that switch the INFILTRATOR role, auto-given to bots in disguise; see: https://mygamingtalk.com/wiki/Roles

Hello, You can see the DepotRoof trigger from Fuel Dump script; players going in limbo do trigger OnExit IIRC, was fixed quite some time ago

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

Works perfectly, thank you once again!

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

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

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

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