Blocking fov_desired creates a million problems when it comes to Particle Use.

[MagentaIris]

fov_desired being anything but the default 75 makes View Model Particle Effects render incorrectly on view models.

If i cannot set a players fov_desired to 75, then compensate for their change via an in-game custom FOV modifier via Calc View (Which correctly makes view models particles appear) then everything is fucked sideways.

Either please do not block this command, or do everyone and favour and fix fov_desired causing View Model Particle Effects to disjoint and become placed incorrectly.

[robotboy655]

Do you have a test case for the particle issue you are describing?

It is not acceptable to force player's desired FOV (which persists across sessions/servers/gamemdoes) as a workaround for issues you may have. There are plenty of methods to change FOV of a player, including CalcView and Player:SetFOV.

[MagentaIris]

Do you have a test case for the particle issue you are describing?

It is not acceptable to force player's desired FOV (which persists across sessions/servers/gamemdoes) as a workaround for issues you may have. There are plenty of methods to change FOV of a player, including CalcView and Player:SetFOV.

Head into Temporal Assassin (https://steamcommunity.com/sharedfiles/filedetails/?id=3258426988) and set your fov_desired to 100.

Pull out the Phone in-game with P or whatever bind you want and type gimmegimme in the chat for all the weapons.

You can see the Roaring Wolf has some particle mis matching due to FOV_Desired.

Here's some images anyway.

FOV Desired set to 100:

FOV Desired set to 75, as it should be:

ply:SetFOV() does absolutely nothing to fix this issue either (Although SetFOV does not mess up the particles). Calcview cannot overwrite the players fov_desired either.

So, thus my case of either, Unblock it or, for the love of god, fix fov_desired shitting all over view model particles.

TL;DR Anyone who's fov_desired is higher than 75 fucks view model particles up and I can't do shit about it.

[robotboy655]

Hmm, so from what I can see, the issue is that you are specifically NOT attaching view model particles to a view model, but rather to a clientside model. I think simply not having the particle effect being set as "viewmodel effect" in the editor would fix the issue for you.

I don't know why you say "CalcView cannot overwrite the players fov_desired either", it has an FOV parameter that works very well, including the viewmodel-attached particles.

From what I can see you are doing a lot of weird stuff in your gamemode to put it mildly, including completely breaking Weapon:CalcView and any other CalcView hook, I am not going to mess around with your obfuscated code more, but it could be an issue on your end.

There's also SWEP:TranslateFOV which is what Sandbox's Camera SWEP uses.

I didn't find the weapon in your pictures, but the crossbow weapon seems to have the same issue and here it is working as expected on a simple SWEP with no extra shenanigans from your code.

On a sidenote, why is your gamemode changing convars like sbox_noclip and all the limits (which save across sessions) instead of using proper hooks such as https://wiki.facepunch.com/gmod/GM:PlayerNoClip? This creates a poor user experience, and may warrant blocking any FCVAR_ARCHIVE convar from being modified by Lua.

[MagentaIris]

Yes this is because normal View Models in source engine are jank.

Creating my own was the only way to get past the trashy animation interpolation issue in the Multiplayer Realm.

Removing the "View Model Effect" bool from the particle effect just makes it draw Infront of the client side model all the time so it looks like trash.

As for SWEP:TranslateFOV(), that causes the cviewmodel itself to get effected to, so that's fun.

So that also, is not a fix.

The gamemode does utilize PlayerNoClip, There's so many CVars left over that I honestly completely forgot existed.

[datae-git]

I don't know why you say "CalcView cannot overwrite the players fov_desired either", it has an FOV parameter that works very well, including the viewmodel-attached particles.

On a sidenote that parameter and the clipping plane are passed as numbers instead of in an object so changing them requires going through returning a viewdata table. This breaks most if not all other CalcView hooks in the process no matter how much you're actually changing, making it a terrible choice for modifying FOV

If I had to make a breaking change it would be removing all 6 arguments of CalcView and replacing it with 1, a view data table. People would finally realize they can just edit the contents of that table like they can right now with the Vector and Angle objects. No more returning and breaking everyone else's stuff + being able to edit the FOV without having to.

[MagentaIris]

If anything, just give us a hook that lets us return a value that fov_desired should copy if it exists. This way we can modify it via gamemodes and not have to force change the clients value.

So many people are reporting bugs of "Mis-aligned particles" because i can't change their fov_desired, and any other work around DOES NOT WORK.

[robotboy655]

How exactly are you rendering your viewmodels? Manually (SetNoDraw) or letting the clientside models render themselves? If manually, which hook exactly? I am testing this and it seems that the issue does not appear if you parent the clientside models to the view model, but the viewmodel FOV is not applied in this case.

[MagentaIris]

How exactly are you rendering your viewmodels? Manually (SetNoDraw) or letting the clientside models render themselves? If manually, which hook exactly? I am testing this and it seems that the issue does not appear if you parent the clientside models to the view model, but the viewmodel FOV is not applied in this case.

Parenting the models to the view model just makes it even worse for how I work. Like i said before the View Model entity is dog shit and inconsistent in MULTIPLAYER, which is why I made my own view model system to get around its stupid limitations.

I create my Client Model, No draw it, then manually draw it via calling a function inside of SWEP:PostDrawViewModel()

The exact call is

if ViewModel_DrawViewModels then

    DO_DRAW_DRAWS = true

    ViewModel_DrawViewModels()

    DO_DRAW_DRAWS = false

end

Apologies again for my late reply.

[robotboy655]

Ok, I think I understand what is happening here now.

So your "view model" is completely detached from the actual view model. The particles are rendered by the game separately from the model they are attached to. To account for the viewmodel FOV the game has a method on the viewmodel entity to transform the attachment positions from the normal FOV to the viewmodel FOV. Since your entity is obviously not a view model, this code does not run. Furthermore, since your entity is not parented to the viewmodel there is no direct link to the view model entity, so there can't really be a hack added for this, not that I'd want to do that tbh.

it makes sense that it "doesn't work" for you, because it's not supposed to.

There are 2 options that I see to solve your issue: 1) You render your viewmodel particles manually, just like you render the model manually. You can achieve this with https://wiki.facepunch.com/gmod/CNewParticleEffect:Render and https://wiki.facepunch.com/gmod/Global.CreateParticleSystem 2) I could maybe add some sort of hook/callback to the anim type entity to transform the attachment positions in anyway you wish to. You could then apply the same code the normal viewmodels use there and use an anim type entity for your viewmodels, you should be able to create them clientside only. It is worth mentioning that anim type entities are not CBaseFlex, like ClientsideModel entities are, so access to flexes may be limited. I am not sure I entirely like this idea, as it adds yet another frequently called hook to all entities, raising performance concerns, even when it is not used.

[MagentaIris]

Ok, I think I understand what is happening here now.

So your "view model" is completely detached from the actual view model. The particles are rendered by the game separately from the model they are attached to. To account for the viewmodel FOV the game has a method on the viewmodel entity to transform the attachment positions from the normal FOV to the viewmodel FOV. Since your entity is obviously not a view model, this code does not run. Furthermore, since your entity is not parented to the viewmodel there is no direct link to the view model entity, so there can't really be a hack added for this, not that I'd want to do that tbh.

it makes sense that it "doesn't work" for you, because it's not supposed to.

There are 2 options that I see to solve your issue:

1. You render your viewmodel particles manually, just like you render the model manually. You can achieve this with https://wiki.facepunch.com/gmod/CNewParticleEffect:Render and https://wiki.facepunch.com/gmod/Global.CreateParticleSystem
2. I could maybe add some sort of hook/callback to the anim type entity to transform the attachment positions in anyway you wish to. You could then apply the same code the normal viewmodels use there and use an anim type entity for your viewmodels, you should be able to create them clientside only. It is worth mentioning that anim type entities are not CBaseFlex, like ClientsideModel entities are, so access to flexes may be limited. I am not sure I entirely like this idea, as it adds yet another frequently called hook to all entities, raising performance concerns, even when it is not used.

CNewParticleEffect has it's own issues from what i've used and tested.

I don't see why adding a hook to modify fov_desired temporarily is such a "BAD" thing. It's only active during the gamemode, There's already options in the gamemode to modify your fov in ways that don't fuck my methods over and its only temporary.