Jump to content

Mateos

Members
  • Posts

    74
  • Joined

  • Last visited

  • Days Won

    5

Mateos last won the day on February 6

Mateos had the most liked content!

3 Followers

About Mateos

  • Birthday 09/05/1992

Profile Information

  • Gender
    Male
  • Location
    France
  • Interests
    Playing, mapping, programming.

Recent Profile Visitors

45879 profile views

Mateos's Achievements

  1. 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
  2. Right, and I've even tested drawing the goal and can't read >.> So affected wrong var in the function Thank you
  3. 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
  4. Can you share the map name/download/waypoints? Is this ETL Warbell?
  5. 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!
  6. 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?
  7. 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
  8. 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
  9. You can remove these in OnMapLoad and manually recreate them in-game through the console, using /bot goal_setproperty for all custom required properties
  10. If you don't script any restriction, it's the same for all bots
  11. First problem: https://mygamingtalk.com/wiki/Paththrough_UseSwitch Other problem: You'll probably have 2 CAPPOINT goals, just have 1 enabled for Axis and 1 for Allies
  12. Yes, that's the best solution, so it's bound to the goal and not the bot using it, far better ^^ Thank you again!
×
×
  • Create New...