Incompatibility issues, Gun lag, heads and other things do not turn...

[InputSoldatcc]

Describe the bug
The bugs are plentiful;

1. Everyone is an amputee
2. Heads do not turn
3. Guns fall through the floor (I doubt they even have collision)
4. decapitation
5. Lag when someone has a gun

Steps to reproduce

1. Launch game
2. No game

Expected behavior
Game

Screenshots or video

The inexplicable "Main Menu™"

Main menu errors

Thy Wardrobe

The terrifying image of death. (Oh look he has arms now!), also crashes the game when reviving

The crash output in question after trying to revive

How come he has arms but I dont?

Upon entering a level where someone has a gun, the fps reaches an all time low

Desktop (please complete the following information):
Windows 11
Build 22631.4037
MIR Versions: Up to 0.49.1

Additional context
None

[mestiez]

Wow that's spectacular. What kind of computer do you have?

[InputSoldatcc]

Wouldnt qualify as a good PC thats for sure, I have another GPU, Ill test the game with it tomorrow morning if I remember to.

Oh also, two grunts spawned with a single hand. (refer to #38 (comment))

[leycarnet]

same for me
update didnt fixed it

[InputSoldatcc]

Atleast theres someone else with this bug. The other gpu didn't fix it too, nor did updating .NET, it might have something to do with the compression mode?

(IIRC something like this happened in the fake mir demo)

[InputSoldatcc]

as of 0.48.5 the voided levels have been fixed

[InputSoldatcc]

If I place my mouse near my character while holding a gun, I can see my hands, but only can point up and down.

The reason some grunts spawn with a single hand is because they are carrying a melee weapon

(after thinking about this for a while, it seems more probable that the arms did load. however, there are two possibilities, the arms dissapear and reappear when one of the 2 conditions above are met, or the animation positioning* is bugged and the hands are just offscreen, the crash screen after dying seems to reinforce the second possibility)

[SwissCheese047]

my game lags out when i pick up a gun or melee weapon, and when i spawn in a weapon and it drops on the ground then it disappears and i cant pick it up

2024-09-10.19-55-02.mp4

2024-09-10.20-28-03.mp4

[InputSoldatcc]

ive noticed that no one added the crash output after dying so ive added it to the first message

The crash output in question after trying to revive

Edit: This also happens when attempting to spawn an ally using the HP disk
Edit 2: This also happens when dying with the Tricky disk

[mestiez]

Oh! This is definitely because the hands are positioned as NaN which propagates to fuck knows where and may cause crashing. This also causes the raycast to throw because it's in NaN space. And it goes without saying that they don't render if they are in an invalid position.

What causes NaN? Division by zero, most likely. So look for that.

[InputSoldatcc]

Right so I also forgot to mention that the head doesn't turn at all, only when an animation plays. that may mean something.

same with weapons (#38 (comment)) and the savior disk's shield thingy.

The raycast errors also happen when attempting to fire a weapon with the telekinesis disk.

[InputSoldatcc]

Oh! This is definitely because the hands are positioned as NaN which propagates to fuck knows where and may cause crashing. This also causes the raycast to throw because it's in NaN space. And it goes without saying that they don't render if they are in an invalid position.

What causes NaN? Division by zero, most likely. So look for that.

I have a question, is the same NaN value that is causing the hands to enter the void also affecting the head's (and the Saviour shield's) ability to turn? Because I don't see any other reason why they wouldnt rotate, unless they are tied with the hand's rotation itself.

[InputSoldatcc]

OK now im really confused (FistFight method in HandPosingFunctions)

(This is before I tried to revive my character and check the output.)

Is poseParams.Character.AimDirection supposed to be like that?

[mestiez]

NaN tends to propagate all over the place. It's likely that the same division by zero is causing the head to be positioned incorrectly.

[mestiez]

I am mainly confused by the inconsistency of this NaN. Why does it only happen on some systems?

[InputSoldatcc]

NaN tends to propagate all over the place. It's likely that the same division by zero is causing the head to be positioned incorrectly.

I found out that the FistFight method isn't the one causing NaN, its actually UnarmedProtective from what I'm seeing. Both pos1 and pos2 are fine same for the Hands PosePosition vector2s, untill the very end of the FistFight method where UnarmedProtective is called. It causes the Y value of both hand pose positions to become NaN.

edit: also it might be just the .Lerp function since many functions use it

[InputSoldatcc]

Update: After removing (commenting out) the part where FistFight calls UnarmedProtective, the hands are now visible and correctly positioned. However, the direction issue persists, and I still dont know what is causing the Y value of the hand vector2 to get messed up ):

[InputSoldatcc]

I am mainly confused by the inconsistency of this NaN. Why does it only happen on some systems?

Many I've talked with about this bug have mentioned that they have a Pentium CPU or some type of Intel CPU.. Knowing intel it might be the issue.

[InputSoldatcc]

Utilities.Lerp (or the Vector2 b value which in UnarmedProtective's case is targetPos) causes the Y value of the Hand pose position vector2 to become NAN.

[leycarnet]

I am mainly confused by the inconsistency of this NaN. Why does it only happen on some systems?

Many I've talked with about this bug have mentioned that they have a Pentium CPU or some type of Intel CPU.. Knowing intel it might be the issue.

I have amd
Amd athlon ii x4 645, its also an old one

[InputSoldatcc]

I am mainly confused by the inconsistency of this NaN. Why does it only happen on some systems?

Many I've talked with about this bug have mentioned that they have a Pentium CPU or some type of Intel CPU.. Knowing intel it might be the issue.

I have amd Amd athlon ii x4 645, its also an old one

Thanks for your input man :D

[InputSoldatcc]

Alright so; It all ties up in the end so keep reading

CharacterComponent.AimDirection.Y is set to PositiveInfinity.

yOffset var in UnarmedProtective is set to the Y value of AimDirection, and it plays a major role in calculating the Y value in the targetPos. Since AimDirection.Y is infinite, you probably know where this is going. targetPos.Y is going to be infinite, common sense.

I believe that the Utilities.Lerp function does not know how to (obviously...) interpolate a normal Y value (position's Y value) to an infinite Y value (targetPos's value) , which in the results in a NaN Y value for the final interpolated position Vector2.

And even after taking out the Utilities.Lerp function from UnarmedProtective, it still going to launch the position of the hands into oblivion, since the Y value is infinite, unless you do not redefine position.

In summary;
The true mastermind property that causes Utilities.Lerp, and many others to leave scratching their heads is the one and only CharacterComponent.AimDirection.Y. I will investigate WHY AimDirection.Y is infinite and I will report back. Thank you for reading.

[mestiez]

CharacterComponent.AimDirection cannot be set because it is a getter property. It's

Vector2.Normalize(
        AimTargetPosition - 
        new Vector2(Positioning.GlobalCenter.X, Positioning.Head.GlobalPosition.Y)
    );

and now everything makes sense because trying to normalise a vector with no length is a bad idea. Is it possible that AimTargetPosition is equal to new Vector2(Positioning.GlobalCenter.X, Positioning.Head.GlobalPosition.Y) at some point? I don't remember, but it seems to be so.

[InputSoldatcc]

Ive found this while searching
dotnet/runtime#99391

It seems that the issue is actually CPU related, no wonder its persistent on some systems /:

[InputSoldatcc]

Ive found this while searching dotnet/runtime#99391

It seems that the issue is actually CPU related, no wonder its persistent on some systems /:

This only applies to Vector2.Normalize(). I have manually normalized the AimDirection Vector2 and now melee combat is working. However I am not done, theres still some stuff left to be fixed.

[InputSoldatcc]

Everything related to the hands (well in MY build, which I have been working on since 0.48.7, i have to update my local repo) has been fixed. The only issues that remain are:

No weapon collision
No bullet tracers
Ragdolls snap into the middle of the map
Lag when someone has a gun

As for the hands, I don't know what to do, create a fork with handfix? maybe I should, I may get some feedback off of it and see if the issues i listed are persistent and not dependent on the CPU.

The choice is for you to make zooi

[InputSoldatcc]

Everything related to the hands (well in MY build, which I have been working on since 0.48.7, i have to update my local repo) has been fixed. The only issues that remain are:

No weapon collision No bullet tracers Ragdolls snap into the middle of the map Lag when someone has a gun

As for the hands, I don't know what to do, create a fork with handfix? maybe I should, I may get some feedback off of it and see if the issues i listed are persistent and not dependent on the CPU.

The choice is for you to make zooi

On another note: I don't think manually normalizing the Vector2s instead of the built-in method is going to cause much performance issues (on older systems), because only CPUs that support SSE4.2 are the only ones that are going to benefit from the performance improvement with Vector2.Normalize.

[InputSoldatcc]

I have made a public fork for everyone to try, it fixes AimDirection and other properties using Vector2.Normalize.

However there is still a problem. VerletPhysics system. It tries to Normalize a NaN Vector2 (m vector2). I don't know why this happens, and if it has to do with the CPU.

[InputSoldatcc]

It just came to my mind that walgelijk probably probably has some built in methods using Vector2.Normalize, if you could tell me what they are I would be grateful :D

[mestiez]

this is a bit worrying

[mestiez]

it goes without saying that the game and game engine use Vector2(and friends).Normalize all over the place. it being broken on obscure CPUs is kind of scary.

i dont think using a local implementation of Normalize is a great solution. it seems like the dotnet team have already solved the issue and the fix is now in staging. i think its better to wait for this update, or even update to .NET 9 (i know its not ready, but it might be worth it).

[InputSoldatcc]

Lets just hope .NET 9 or the next .NET 8 update fixes this.. Untill then I don't think there is any other actual solution.

[leycarnet]

Lets just hope .NET 9 or the next .NET 8 update fixes this.. Untill then I don't think there is any other actual solution.

should i update it myself or?? the problem is still there on the last version

[InputSoldatcc]

as i said i DO have a public fork which does fix the problem at (depends on your cpu) performance losses, I probably wont be maintaining it any longer but feel free to try it out

https://github.com/InputSoldatcc/madness-handfix

[InputSoldatcc]

The newest .NET 9 preview SDK fixes all issues mentioned here, I guess we can wait untill its fully out then, so this issue is just going to fix itself pretty soon.

[mestiez]

.NET 9 is published and the game & engine have been updated!

[InputSoldatcc]

Awesome!