ZDoom

We currently have the ability to adjust the viewbob on a user basis using the console. This is great for people who want to customize the game to their own preferences; however, it would be nice if authors could set a viewbob on a per-player class and/or per-weapon basis.

This would be two new actor properties, MoveBob and StillBob, each taking a float that matches what you set in the console.

Reasons why this is a good idea:

- For player classes, if you're trying to simulate the player being some type of mech running on tracks, you may not want any viewbob. Or if you're simply adjusting the movement speed, the default viewbob can appear to be too much or too little.
- For weapons, if the weapon slows the player down (via ACS to simulate a heavy weapon, for example), the default viewbob will be too exaggerated.

Assuming neither the player class nor the current weapon specifies these settings, the player's console CVARs would of course reassert themselves.

This sounds like a good idea, I have a mech playerclass and all that bobbing was just odd.

Thirded. Slowing the player speed down anything more than 25% results in definite motion sickness for the player if he or she doesn't set the viewbob themselves. And why make them go through that trouble?

Grimm wrote:if he or she doesn't set the viewbob themselves

That reminds me...

How do you (HotWax or anyone) see this feature working with people who have already changed their viewbob settings?

I see it as using their modified value as it's 'base' value, if anything.

I'd expect it to either use that as a base value, as just suggested, or simply be overridden. I'm assuming that this would be coded so that the player could still input their own value if they wished.

By far the easiest method would just be to override their setting. I realize Graf's stance on this has typically been that the player should have control over CVARs; however, this is a feature directly linked to player movement that may need adjusting to make sense and/or not give the player a bad case of motion sickness when they use a custom player class. I wouldn't mind it acting like a multiplier to the player's setting instead, but Graf hasn't been too keen on implementing those kinds of suggestions before.

Really think about this though... how many players do you know who change this setting, and how many mods will really need to make use of it? What do we really stand to lose here?

I was more thinking of examples round the other way. eg, what if a player already has it set to zero because of, I dunno, motion sickness or something, and this feature forces class specific bobbing. Could a player over ride it?

I agree, there won't be many who have changed it, but those who have presumably did so for a reason. Maybe it just means the mod in question isn't for them?

Well, perhaps the multiplier is a better idea then. I don't know. But either method is better than the current state where slowing the player down significantly means the viewbob makes him look like he's bouncing on his toes as he walks.

Xthed.

But if we can't override the player's settings one way, how about either only being able to reduce the bob, or having a simple flag that disables it?

The big concern I see about this option is that some goofball is going to increase the bob to some ridiculous extent and make people puke or unable to play. Does anyone actually have serious problems if the bob is reduced below what they have set?

Vaecrius wrote:The big concern I see about this option is that some goofball is going to increase the bob to some ridiculous extent and make people puke or unable to play.

Then "some goofball's" WADs won't get played.

I mean, come on. If you load into a WAD and see that your viewbob is completely screwed up, are you really going to continue playing long enough for you to get nauseous, or are you just going to quit in disgust? I'm tired of the argument "OMG BUT WHAT IF SOME JERK USES THIS FEATURE FOR EVELLLL!!!?" when the worst they can do is make a WAD that nobody wants to touch.

Exactly. And again, I don't see the problem with making this simply a default, mapper-defined setting that the player can override if he or she wishes.

HotWax wrote:

Vaecrius wrote:The big concern I see about this option is that some goofball is going to increase the bob to some ridiculous extent and make people puke or unable to play.

Then "some goofball's" WADs won't get played.

I mean, come on. If you load into a WAD and see that your viewbob is completely screwed up, are you really going to continue playing long enough for you to get nauseous, or are you just going to quit in disgust? I'm tired of the argument "OMG BUT WHAT IF SOME JERK USES THIS FEATURE FOR EVELLLL!!!?" when the worst they can do is make a WAD that nobody wants to touch.

The exact same logic can be used with the entirety of ACS/Decorate controlled console commands; if they won't be implemented, then I don't see why this should be. I'm not saying that I don't want this or console command control implemented, it just wouldn't make since to put this in and still leave the other console stuff out.

Just to add to the justification - if a certain feature in a WAD is so disliked that badly, the player can just edit the WAD and comment/remove the feature...

Yeah. Anyone with the most very basic knowledge of DECORATE could easily get rid of the bob setting, and it wouldn't even break the WAD. At all.