PAC doesnt follow lag compensation in TTT

[Earu]

To reproduce this issue, have a player wear an outfit with model parts parented to any bone of a player. Hit the player while they are moving, notice how the part are desync'd.

[homonovus]

related source links
https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/sp/src/game/server/player_lagcompensation.cpp#L410
https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/sp/src/game/server/player_lagcompensation.cpp#L611

[CapsAdmin]

related garrysmod issue
Facepunch/garrysmod-issues#884

[wrefgtzweve]

If i understand the issue correctly whats shown in the video is what you mean right?
Did a test with this, seems like only GetBonePosition is affected while GetBoneMatrix + GetTranslation doesnt

gmod_erEwwfLhcl.mp4

The test code:

hook.Add( "HUDPaint", "BoneExample", function()
    for _, ply in ipairs( player.GetAll() ) do
        if not ply:Alive() then continue end
        if ply == LocalPlayer() then continue end

        local bone = ply:LookupBone( "ValveBiped.Bip01_Head1" )
        if not bone then continue end

        local matrix = ply:GetBoneMatrix( bone )
        if not matrix then continue end

        local pos = matrix:GetTranslation()
        local toScreen = pos:ToScreen()

        draw.SimpleText( "GetBoneMatrix", "DermaDefault", toScreen.x, toScreen.y, color_white, TEXT_ALIGN_CENTER, TEXT_ALIGN_CENTER )

        local pos = ply:GetBonePosition( bone )
        local toScreen = pos:ToScreen()

        draw.SimpleText( "GetBonePosition", "DermaDefault", toScreen.x, toScreen.y, color_white, TEXT_ALIGN_CENTER, TEXT_ALIGN_CENTER )
    end
end )

[TW1STaL1CKY]

Yeah, that is the problem. It looks like PAC does mainly use Entity:GetBoneMatrix, though there are a couple of spots still using Entity:GetBonePosition it seems. Those few instances are likely the cause

[CapsAdmin]

Last time I looked into this, I couldn't figure out how to use GetBoneMatrix without breaking the part placement of old outfits.

[Earu]

Last time I looked into this, I couldn't figure out how to use GetBoneMatrix without breaking the part placement of old outfits.

How about today? Maybe you have more ideas than back then? 😁

[TW1STaL1CKY]

Using GetBoneMatrix seems to work fine for me, I'm not sure how old an "old outfit" would be though, the outfits that I've tried have been fine

Before - pac.GetBonePosAng using GetBonePosition:
https://github.com/CapsAdmin/pac3/assets/1499739/d508cf27-92c8-41fb-9c71-8d5a5d119c94

After - pac.GetBonePosAng using GetBoneMatrix: (the nametags I have use GetBonePosition so you can kind of compare the difference using it)
https://github.com/CapsAdmin/pac3/assets/1499739/babe7b9e-f0d8-4b49-b01d-d4f59f3579b4

I can push/PR this to the develop branch or a new branch for further testing?

[TW1STaL1CKY]

I was told to just push it so I've pushed it to develop😁

[pingu7867]

Sorry for the delay, I didn't find out about it until now because I don't sync my local install. I had a tester reach out to me.

This breaks clips on any valid bone.
Yet static models or placement on invalidbone, as well as special pac bones, are fine. Not so with other bones.

2025-02-14.02-20-50.mp4

Changing this is a serious backward compatibility problem. People do use clips on character models. So until we make a serious attempt (one that doesn't involve micro-edits but rather a fundamental look at the drawtime and bone building algorithms) at solving the whole lagging behind issue (a closely related issue that was only "solved" by trying different combinations of translucent in your hierarchy), it should be an opt-in field in the base_movable or base_drawable class.

2025-02-14.02-58-05.mp4

[TW1STaL1CKY]

Only clip parts seem to have this issue. If they're used on a model part that parents to a bone on that model part, it lags behind for some reason. Calling SetupBones for the model before it applies the clip plane seems to resolve it.

Before:
https://github.com/user-attachments/assets/89e6bc9c-0204-4c5c-833e-452eac97e6c5

After:
https://github.com/user-attachments/assets/746a15ae-d8de-4eb0-a337-864d437dc33d

I've made a fix in a PR you can check out before it gets merged into develop: #1391