New to the forums, so hi to everyone here. A little bit of background about me, been toying with the idea of creating a game for a long time (its on the bucket list). Just any game really from start to finish. I have used XNA and Unity previously in the past, but never really got to a point where I was making a game fully. I have a reasonable amount of scripting experience, and I think I understand Blueprints for the most part now.
Anyway, I digress … I am pretty sure this has been asked before, but searching for this tends to bring up results that are not exactly what I am looking for.
Hypothetical situation: (or not so as the case may be!) keeping it as simple as possible
A bullet is travelling along, and it hits two overlapping objects (simple arcade style game)
Both objects get hit in the same physics frame
Both objects hit have code in them that fires off to another object (in this case a game manager of sorts), to run a function which updates a variable in the game manager (in this case no of objects hit, an integer)
My question is which one executes first, or do they execute at the same time? I would have thought that game logic in unreal is on a seperate thread, so in theory at least there should be some exection order regardless if the two objects get hit at the same time.
The reason why I ask, is occasionally, just every now and then a couple of objects will get hit at the same time, and the variable in question in the game manager does not get updated the way it should be, which sounds like some sort of race condition going on. This of course then screws the logic up somewhat.
I am sure I am probably being ultra thick here, but things like this always confuse the hell out of me, even though I understand the concepts of multi-threading.
First you need to find if this is bug in your code, or in engine code.
Make game manager remember each hit event not only last one.
Add them all to array and see if they all are registered.
Then add some events that prints all to log or screen.
For better debug dismount your weapon, find problematic direction and target actors layout then try to repeat it few times.
That is what i do, i investigate until i am really sure what problem is, usually answer how to fix it comes along.
Indeed … those suggestions were going to be my next step… The blueprint is pretty simple so I dont think its a problem with how I am doing it. I am pretty sure this is something that isnt unique to UE, but without knowing how the game logic is threaded its difficult to tell.
As you say, step through it and see where the issue lies. There are ways around the problem for sure, but I would rather not use ‘hacks’ as they imply the code is wrong in the first place.
My code does tend to be over engineered in the first instance so I may well be doing something else that is triggering it. In general though it would be nice to know how exactly the physics engine handles multiple simultaneous collisions at the same time, and whether they are ‘stacked’ in any sort of order if you see what I mean.
Thanks for the reply, will let you know how I get on.
One potential problem with physics: moment you force some change of location or velocity like set location or add impulse (with velocity overdrive) some parts of physics get quite unstable for that actor. Sometimes they get insane speeds sometimes start spin etc. So safest way to handle physics is apply force, unless it is initial kick. There are many similar quirks in engine.
Yeah I have seen that in Unity as well, in the end there is only so much you can do with a Physics engine it seems. Saying that none of the objects in question are using physics other than for basic collision checking and they are all explicitly mapped so they only record the collision channels that they need to know about.
I guess its possible that two event hits fired off rather than one from the same object collision , which could have caused the follow on function from calling twice … But again thats a complete guess. As stated there are ways around the issue I can take so I’m not worried as far as getting it working, but its something that I have never really managed to get my head around.