barbolani 198 Posted June 11, 2018 Hi all! I know that kind of event handler does not exist, but since the "AUTOCOMBAT" AI feature exists, it is definetly something BIS should implement to avoid disabling it and looping around unit current behaviour and switch it "manually". I want to take advantage of some UPSMon feature which orders AI to set in STEALTH, and, in that case, add them a supressor and make them use it. Is there any Smart way to do this avoiding loops? Thanks in advance! Share this post Link to post Share on other sites
Grumpy Old Man 3545 Posted June 11, 2018 20 minutes ago, barbolani said: Is there any Smart way to do this avoiding loops? Not that I know of, even as a scripted EH functionality like that doesn't exist. A simple waitUntil loop should do just fine though, even without sleep, since it's pretty fast to check for a units behavior (~0.0007ms), especially when only run once per group per frame. You could probably work around a waitUntil using fired/firednear and/or hit eventhandlers to guesstimate a units behavior mode, the waitUntil check is just too convenient and most likely more accurate in that case. Cheers 2 Share this post Link to post Share on other sites
barbolani 198 Posted June 13, 2018 I thought about the "FIRED NEAR" etc. EH, but if the unit hasnt done anything but spotting you, those won't fire. That EH would be a fine addition which will allow things such as: - Situational music scripts :) - On switched to "COMBAT", check under certain conditions and switch to stealth (for example, tank detected). - Similar process to make the AI assemble / dissassemble supressors. And other cool things which I lack of imagination but others sure can add. 2 Share this post Link to post Share on other sites
bad benson 1733 Posted June 14, 2018 you could try to abuse some other frequently fired EH like "AnimChanged" and do the check for behavior yourself. just gotta make sure you don't spam heavy code and do it only where needed in terms of locality. Share this post Link to post Share on other sites
barbolani 198 Posted June 25, 2018 That Will definetly comsume more resources than a loop, even when you make a super - idiot boolean check on animchanged…. Share this post Link to post Share on other sites
Grumpy Old Man 3545 Posted June 25, 2018 17 minutes ago, barbolani said: That Will definetly comsume more resources than a loop, even when you make a super - idiot boolean check on animchanged…. Waituntil runs mostly once each frame. That's 60 times per second at 60 fps. Doubt animations change more than 4-5 times a second, except spamming WASD. Cheers Share this post Link to post Share on other sites
Dedmen 2685 Posted June 25, 2018 You have to keep in mind that Eventhandler code is always recompiled though. And that the EH code is unscheduled and will drop fps if you do anything wrong. I would probably go for a perFrameHandler. That's the best you can get for missing Eventhandlers. Share this post Link to post Share on other sites
barbolani 198 Posted June 25, 2018 yes yes except if your waitUntil is placed with an sleep because you dont need an ultra fast response, just a check lets say every 30 seconds... 1 Share this post Link to post Share on other sites
Grumpy Old Man 3545 Posted June 25, 2018 26 minutes ago, barbolani said: yes yes except if your waitUntil is placed with an sleep because you dont need an ultra fast response, just a check lets say every 30 seconds... Then you wouldn't need a behaviour eventhandler in the first place, if timing doesn't matter. Cheers Share this post Link to post Share on other sites
barbolani 198 Posted June 25, 2018 AFAIK the purpose of an EH is not only having fast response and perform actions right before a state change but also avoiding loops to check the state change. Anyway, no worries, it was just an idea! Share this post Link to post Share on other sites