Entity ID last in Rule


#1

Can we set effects to variables not using last created, can we designate a value:‘last of id in current script’ instead?


#2

Why? The Last Id will be the last one in current script, unless you have a wait, or the script runs again…


#3

Do we know that all rules are executed 1 at the time?
(except wait of course)
Or is the Last Id remembered separately for each rule?


#4

Good question. Specifically, no two scripts are ever running at the same time. the exception, is ‘Wait’. On a wait, another script may execute during that time.

So, if you need the ID in another rule, or past a wait, then you need a variable.

I can see how it being script-specific would be convenient for certain style of rules, but I think it’s unlikely to change.


#5

Thanks!

On " INTRODUCING THE OVERWATCH WORKSHOP" I read:
“With the exception of the Wait Action (see [Wait Action]) for more information), all Actions execute and finish immediately.”

Would you happen to know of somewhere else to read more ordering information?
For example: are we guaranteed order of execution of several rules triggering at the same time?


#6

I’ve not seen more official information. Someone could experiment and document it though.
I would assume that rules are executed in sequential order, with ‘Per Player’ rules executing once per player in order of their player slots. ‘Damage Events’ are probably executed all in order they where created when the corresponding rule is ran.
A wait causes the rule to stop there, and resume at that point the next script cycle after the duration has elapsed.

These are assumptions based on how I would do it, and what I’ve observed. I may be entirely wrong. We can create tests to figure it out though.


#8

that is false. since it is event based. there are a number of times the last created entity IS NOT the entity that was just created in the script above… if someone presses a button at just the wrong time, the last created entity may switch… there is no reason not to be able to specify an entity created by a specific script… the same script of the set.


#9

No, you are wrong. Events are not triggered in that manner at all. A condition for an event to happen will not interrupt an event already running, and events do not run concurrently. Last Created Entity is correct in the situations I’ve already stipulated. You are spreading blatantly wrong information.

Provide an example that shows your behavior.


#10

It has happened a few times in my script, and a friend’s script where the last created entity stored into a variable is NOT the last entity up in the script. no wait commands interfere with it - it happens under heavy effects loads - the wrong effect (from a different action) gets stored in a variable.

because of this behavior I assumed it was the “last created entity in the game” - which IF the scripts are running in sequence - should be the last created effect in the script rule.

but something is happening.
and it’s not a wait command.
this would never happen if:
created effects could be named - and stored by name.
or my stated solution above.

maybe it is correct behavior and I’m missing something, but wouldn’t being able to name effects be… better anyway?


#11

If this is true, it means severe issues with concurrency. It would effectively mean that you can’t use variables across rules at all, as things would trigger in the middle of other rules executing and such. It would just be horrible…

My hope is that you’ve either stumbled upon a bug, or you’re own rule design has data races or the like. Please provide a demonstration.

Naming is unlikely to happen, doesn’t mean that we should misinform others on the capabilities of the current system.


#12

This simply isn’t true lol. Can you imagine the chaos this would cause if it were? Again, if it were true, it’s a pretty major floor and I think many others would have come forward about it by now.


#13

You(OP) may infact be correct, but once again… if so, it’s a bug we need to find.


#14

OP seems correct.

I’ve had this problem, where under heavy effects/hud load sometimes the event would call ‘Destroy Effect (var)’ and it wasn’t destroying because there was another Entity ID in the var.

I passed some time trying to understand why it wasn’t destroying X effect or hud, and it must only be this.

Just for reference, i was creating custom abilities with effects and huds, and there was a lot of destroy/create entity involved into the event, so i formed a system to create huds only one time when player spawn and destroy when he dies or something like that, and then i would hide/show specific huds or effects by assigning a Event Player to a Var X, and that Var X to the function Create Hud(visible to(Var X)), or assigning Null if i didn’t want it to show. Doing this would prevent from constantly having wrong entities ID (still need to test it more).

That’s my experience, maybe i did something wrong for it to not be destroying, but after a long time trying to understand why my huds wasn’t destroying when it should, this is my conclusion.


#15

That’s great. Without examples/demonstrations, don’t expect it to every be found/fixed.


#16

Welp… I guess it’s time to waste my life for an hour or two in order to test the existence of this lol


#17

Lol… I’ve been avoiding it for fear of chasing a ghost. Not saying there isn’t a bug causing what these guys are seeing; just that it could be specific to something in their setup/map/order of instructions that even causes the bug. All we have to go on is vague descriptions of ‘high load’.

I also want to know how the people experiencing the issue have proven it’s not the ‘Destroy Effect’ failing (for who knows what reason), rather than their ID being incorrect. Are we sure?

Even if some ‘named’ system was implemented, if the actual problem was something else (ig: corrupt effect memory due to creation/destruction and bugs on their end), it will not fix it.

What the OP has suggested would make concurrency guarantees invalid… it would just be insane imo. I think the bug lays elsewhere. My vote with what little has been provided, is that Destroy Effect is simply failing. I’ve not seen anyone say how they know the ID is “wrong”.

This for example… are you saying that the effect wasn’t destroyed? OR That the effect wasn’t destroyed AND a different one was? That’s what would happen, right? A newer effect would be in ‘LastCreatedEntity’, as what’s being claimed, and it would be destroyed instead. Right?

How do we know that you guys aren’t exposing a bug with destroyentity getting called with the same id more than once? Or something like that? Especially since other similar things are bugged… multiple calls to ‘Disallow Button’ with the same button will crash the game very very quickly.

Please help us find the actual bugs and problems rather than suggesting the whole system is fundamentally broken, and some hack that wouldn’t solve the giant issue you’ve stated exists. If we do have a concurrency bug… then I want to solve it even more.


#18

As i said, it may be something wrong that i’ve done in my script, but i only said it could be “high load” because it made more sense to me, as it would randomly decide to not destroy a entity and would happen more often with a lot of players (from my experience, it apparently wasn’t destroying other entities, but can’t confirm).

I also considered that DestroyEntity could have an actual bug, but i couldn’t understand why it wasn’t consistently destroying my “hero” specific huds and effects (eg. Ring around player, HUD showing cooldown; events that happens more than one time), but it always destroyed my “round” specific entities (eg. HUD Timer; events that happen only one time at round start and destroy itself when rounds ends or something else). Also, even if i called Destroy Entity two times or more, it still wouldn’t destroy consistently

I also suspected that it could be something wrong between client and server side connection, and that for some reason it wasn’t consistently destroying HUD.

I’ll try to investigate it more and post here if i find anything, as i can’t confirm what was happening with the ID (if it was assigning to the variable, but destroy entity wasn’t working, OR if another ID was being assigned into variable).


#19

Yeah, unfortunately, this may be a hard one to replicate. Wish they(bliz) gave us some feedback as to why/when operations/actions fail.


#20

I have not had a chance to play recently - work and such.
I don’t mean to say the whole system is broken.
I am stating the problems I have had - it is not consistent with anything I’ve found yet - other than having “a high load”… even that.

  • It could also be me being an idiot, by the very nature of that possibility: not possible to rule that one out.

#21

Don’t get me wrong, not saying you are. Concurrent programming is difficult, and you may indeed be doing something wrong. It’s also entirely possible that there’s a bug. My money is on a bug.

I just don’t know that the bug is a problem with ‘Last Created …’, and not something like ‘Destroy …’ failing (even though it was given the correct ID). Without a demonstration, or going through your code with a fine comb, I’m left speculating.

I will say that the design of the workshop system seems to imply that rules have certain concurrency promises. This hasn’t been officially stated, but it would be near impossible for a sane system without them. So I’m not in favor of the OP’s suggestion, as I would rather fix the bug/find the issue. An issue, that’s a major one if it’s a concurrency issue.

Finally, I have had concurrency issues in the workshop before. I forget the details, but one of my bug reports was on an action not picking up a ‘set variable’ action right before it was used. There’s no real way to keep up with old bug posts though… so meh.