Behaviour change Event Handler

[barbolani 198]

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! 

[Grumpy Old Man 3540]

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

 

[barbolani 198]

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.

[bad benson 1733]

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.

[barbolani 198]

That Will definetly comsume more resources than a loop, even when you make a super - idiot boolean check on animchanged….

[Grumpy Old Man 3540]

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

[Dedmen 2588]

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.

[barbolani 198]

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...

[Grumpy Old Man 3540]

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

[barbolani 198]

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!