Currently experiencing an issue where reloading the UI or relogging (log out and back in on a character) causes all Dynamic Pitch settings to be ignoring and keeps the character centered on the screen.
Only a full game reboot fixes the issue.

Hi! So to reproduce this, you have to do this?

• start the game, log in (everything is fine)
• /reload
• pitch not working any more

Please enter this into the console while pitch still works and when it does not work any more:

/run print(GetCVar("test_cameraDynamicPitch"), GetCVar("test_cameraDynamicPitchBaseFovPad"), GetCVar("test_cameraDynamicPitchBaseFovPadFlying"), GetCVar("test_cameraDynamicPitchBaseFovPadDownScale"), GetCVar("test_cameraDynamicPitchSmartPivotCutoffDist"))

Is the output the same in both cases?

Hi! So to reproduce this, you have to do this?

• start the game, log in (everything is fine)
• /reload
• pitch not working any more

Correct.

Please enter this into the console while pitch still works and when it does not work any more:

/run print(GetCVar("test_cameraDynamicPitch"), GetCVar("test_cameraDynamicPitchBaseFovPad"), GetCVar("test_cameraDynamicPitchBaseFovPadFlying"), GetCVar("test_cameraDynamicPitchBaseFovPadDownScale"), GetCVar("test_cameraDynamicPitchSmartPivotCutoffDist"))

Is the output the same in both cases?

Yes, output is the same (settings used: 1 0.4 0.5 1 10)

Sorry, but I cannot reproduce this.

Also, if the cvars are set correctly (as confirmed by your print output) then there is nothing else, DynamicCam can do.

One last thing you should try is to disable all Addons (including DynamicCam).

The pitch cvars should still be set afterwards and you should get the warning window that you are using experimental variables. Otherwise, you can always set them via the console command:

/run SetCVar("test_cameraDynamicPitch", 1) SetCVar("test_cameraDynamicPitchBaseFovPad", 0.4) SetCVar("test_cameraDynamicPitchBaseFovPadFlying", 0.5) SetCVar("test_cameraDynamicPitchBaseFovPadDownScale", 1) SetCVar("test_cameraDynamicPitchSmartPivotCutoffDist", 10)

If you still experience your issue then (even with all addons disabled), you could file an in-game bug report. But be polite, we don't want Blizzard to "fix" this by taking away these "test_" cvars. :-)

Glad that you got it fixed.
But looking at https://wow.gamepedia.com/CVar_cameraView I don't understand how this variable should have had any effect on your issue. Can you reproduce it again, setting cameraView back to 0?

I did indeed reproduce it when I fixed it.

EDIT: I used the addon "AdvancedInterfaceOptions" to view and modify all cvars while in-game to verify. It did require a reload after each change.

I just did a great deal of testing. On a starter account I had, there were no issues at all.
I tried cleaning my entire WTF folder and it still did not work on my primary account but worked fine on the starter still.
Could the Shadowlands upgrade itself do something to mess with the camera workings? It is the only thing I can think of that is different between the two accounts.

That's a real mystery. You could try:

/console ActionCam off
(https://wow.gamepedia.com/CVar_ActionCam)

and then again.
/run SetCVar("test_cameraDynamicPitch", 1) SetCVar("test_cameraDynamicPitchBaseFovPad", 0.4) SetCVar("test_cameraDynamicPitchBaseFovPadFlying", 0.5) SetCVar("test_cameraDynamicPitchBaseFovPadDownScale", 1) SetCVar("test_cameraDynamicPitchSmartPivotCutoffDist", 10)

Or you could even do this:
/console cvar_default
(https://wow.gamepedia.com/CVar_cvar_default)

But you will have to go through all your settings again after this.
Or make a backup of your config.wtf file.

But these cvars should be global for all your accounts. So it would be odd if this changes anything.

Ah, I found the issue thanks to your links. I didn't know about how cvars were also server synced so I took a look through all of them that weren't default using another addon.
The issue was my "cameraView" cvar which was apparently set to 0 on my primary account whereas the default is 2. It might have happened a long time ago when I was messing around with the fancier views of DynamicCam and close-ins, which I don't use anymore but I am not sure.

Thanks for the quick feedback and help resolving this =D

Cause of CVar modification found, MayronUI is changing the CVar unnecessarily upon AFK or entering combat.

Bug has been reported at https://github.com/Mayron/MayronUI-Official/issues/193#issue-804407890

I just tried it myself and it is really like you described it:
Setting cameraView to 0 and reloading breaks pitch until the client is restarted.
Thanks for finding this out! I will put a mechanism into DynamicCam that prevents this variable setting.
What is this variable ever used for anyway??

From what I could see on wowpedia about the cameraView, it seems to be a mechanism to store different setups and quickly switch between them. 1 is reserved as first person view, 2-5 seems to be user variable (but unused in game client, maybe for addons?). My guess would be that while 0 is not mentioned, it could be the hardcoded view for camera centering when you enable that setting in the client. Pure speculation though.

I think this would also be worth a bug report to Blizzard.
Have you already filed one or should I do it?

I have not filed anything. I was unsure how to word it to begin with and I didn't want Blizzard to mess with the code too much.
I would much rather have a semi-working (now fully working) DynamicCam than no DynamicCam =)

From what I could see on wowpedia about the cameraView, it seems to be a mechanism to store different setups and quickly switch between them. 1 is reserved as first person view, 2-5 seems to be user variable (but unused in game client, maybe for addons?). My guess would be that while 0 is not mentioned, it could be the hardcoded view for camera centering when you enable that setting in the client. Pure speculation though.

The storing and restoring of the views is done with SaveView() and SetView(). But why would one store which was saved last?

Is only cameraView = 0 causing the error or any value other than 2? Have you tried this?

I just tried it myself and it is really like you described it:
Setting cameraView to 0 and reloading breaks pitch until the client is restarted.
Thanks for finding this out! I will put a mechanism into DynamicCam that prevents this variable setting.
What is this variable ever used for anyway??

I think this would also be worth a bug report to Blizzard.
Have you already filed one or should I do it?

Hm, I think you are not supposed to set the cameraView using SetCVar() at all.
It is set automatically whenever you use SetView({1,2,3,4,5}) to the number of the view you just set.

The error you discovered seems to occur, whenever cameraView is not {1,2,3,4,5}. Just tried it with 6 and it is the same as with 0.

Hm, I think you are not supposed to set the cameraView using SetCVar() at all.
It is set automatically whenever you use SetView({1,2,3,4,5}) to the number of the view you just set.

Makes sense. Only reason why I did it using SetCVar/console was that it was the way MayronUI did it. It is also the only place in the entire MUI code where they change that CVar, so it is most likely a bug or old workaround for their AFK camera effect.

The error you discovered seems to occur, whenever cameraView is not {1,2,3,4,5}. Just tried it with 6 and it is the same as with 0.

Yup, my list above your reply is the cameraView numbers I tested, so your test matches what I discovered.

In the end it seems that it is a bug combination of a CVar that allows values out of valid range and an addon that changed the number to be out of scope, the combination of which broke ActionCam functionality.

From testing:
0. Centered. If zoom is non-default, zooms in quadratically quickly to roughly halfway, then linearly slowly the rest.
1-5. Pitched (correctly). Zoom as above.
6-7. Centered. Zoom as above.
8. Unknown, most likely centered. Zoom is locked very close (upper body visible only) and camera rotation is limited to front hemisphere only.
9+. Defaults back to 8 on reload.