Thralls still falling through ceilings and tables

#1

Game mode: [Online | PvE | Official #1026]
Problem: [Bug]
Region: [EU]

After the first hotfix for the MOAP that was supposed to address the Thralls falling through stuff I hoped that it was finally over.
But my dancers still keep falling through their stages (foundation/ceiling + fences + 2 tables + wall + folding screen).
I already rebuild the stages, and re-positioned them, but they keep falling through it, while a different Thrall on the same setup keeps dancing without falling through it.

Those were made just before this post

20180709225823_1
20180709225823_1.jpg1920x1080 573 KB
20180709225917_1
20180709225917_1.jpg1920x1080 528 KB

While this one keeps dancing on his stage (had to build it like that to prevent the “Decay system” from killing his stage over and over again)

20180709225850_1
20180709225850_1.jpg1920x1080 621 KB

Then wen I logged in yesterday evening I had to saw this

20180708212131_1
20180708212131_1.jpg1920x1080 404 KB

This is where she usually stands

20180709230224_1
20180709230224_1.jpg1920x1080 664 KB

This is getting really tiresome and annoying and I hope a fix or workaround will be found soon.
Before the MOAP and the hotfix it happened rarely that my dancers fell through the tables, but since then I can re-position them every hour (not that I would actually still bother doing so)

#2

Bump, also during purge npcs will just glitch through structures/ terrain until they are inside base…

#3

Ok…1 more explanation on Why this is happening. This is definitely a misunderstanding on how to set up proper collision and the physics cycle in the UE4 game engine.

The basic principle in engine physics is to do math…and this math between various ‘like’ objects. Some objects have no physics but instead they have simple mesh colliders that May or May Not block ‘Other’ Objects including Physics based objects.

Non- Physics objects need to be simulated by code…meaning if a hammer smashes the head and that body flips and rolls on the ground…the coder must write all the vector and rotational math to do such a thing. Really difficult to do right…or animate that sort of thing with Mocap. Also tough…but very doable. In comes Physics Simulation to the rescue. It specifically simulates friction, force, rotation, and velocity math all at a defined ‘Cycle Rate’…or ‘Timing Rate’ if you will.

You will see that UE4 does not hold the developer’s hand to set this up properly (nor does any game engine for that matter). Funcom simply needs to sit down and grind their engine hard with an Automation Performance Limiter to really heavily ‘Load Test’ the game…THEN…start playing with physics cycle timing to see where the engine is most happy. They also must make sure that only things that actually do need some physics are actually used…meaning it would be better to code in some simple simulation that is ‘Good Enough’ which releases loading on the physics integration.

This is where detailed optimization takes place…and many ‘coders’ and ‘designers’ really struggle with this.

So instead of me typing a wall of text…how about I simply give a link that already explains this in very good detail…and actually it is easy enough to read for a non-engineer as well.

Enjoy.

#4

Thanks, very insightful and I think I got the basic gist from your post (more than from that article. At least right now. Need to take more time for it when it’s daytime again).

What wonders me a bit though is that before the MOAP and hotfix I never had an issue with Thralls falling through ceilings under these circumstances like in the last two pics. The only time they ever did was when I destroyed a building tile within my base.
I also only had to re-arrange my two dancers like twice or thrice a week.

So I guess that they changed something in that patch, but I also guess that it won’t be easy to track down.

#5

Awesome! Thanks for sharing this. Funcom developers might benefit if the community managers catch this post and share it.

#6

Directly related to engine cycle rate (known as Frames Per Second…but at the engine level). What happens is that since the overhead burden is already struggling because of the method in which runtime game memory is being used (not a UE4 issue but ‘How’ the ‘Tool’ is being used by Funcom) and that UE4’s UObject is single threaded (serial based This then Next then Next) the game is very heavily CPU bound. This means that when ‘any’ moderately sized ‘optimization’ or ‘changes’ patch happens that CPU Framing Time must be under direct scrutiny…again and again. When the CPU Framing goes above 25ms (0.025s or 40 FPS) (this is related to but different than GPU FPS) there will be issues…especially with physics.

#7

Alright, thanks for the explanation.

#8