ZDoom

This is on my extended "things to look at when I get a ZDoom coding spurt again" list, since it would indeed be a useful modifier for playerclasses in particular for exactly the reason mentioned.

Is there an open request for this anywhere, though? This is a rather old thread so I wouldn't be surprised if there's an unclosed version somewhere.

So, did the idea go anywhere?
I see the ability to change weapon sway but not head bobbing. I made a playerpawn with speed 0.5 and headbob looks ridiculous. Also, it prevents some weapon partcile effects from spawning at the proper place on the screen, they'd look much better if the bobbin was decreased.
Also, as for console commands, movebob always looks exactly the same to me of it's larger than 0. Is it just a toggle then?

I agree with this request, Both Movebob and stillbob.

For Movebob, have it as a multiplier, 0.5 for half of your set value, and 2 for double, 0 for disabled, etc.
Though, for Stillbob, I'd like it to be a definitive value, overriding what you may have set, though, it doesn't actually alter your saved setting in your config, it's just a simple override, mainly because a Multiplier for Stillbob wouldn't be that useful since it defaults to 0.

both would be excellent for the Goldeneye TC, since you move slower in it, and the massive amount of movebob looks extremely exaggerated. As for Stillbob, it would make it like real GE as in you kinda drift your view when you are standing still, as if you were breathing.

As important a discussion as this is, I'd appreciate it if we could focus on the feature request at hand rather than this becoming another debate thread that eventually falls off the radar.

Hazardous meaning that such WADs can nuke your config. Do you want that to happen?

[quote]I agree. Unless the nature of console commands/CVARs are completely changed, which I understand not wanting to do, it's too hazardous just to allow free reign to them by authors.[/quote]

Hazardous? Come on now. This is freakin' Doom. I can name about 50 WADs made for *vanilla* Doom that are "hazardous" off the top of my head. People making shitty levels and doing dumb, shitty things in those levels has been part of the scene since the day DEU came out. I'd like to think we could all deal with this by now.

Now if what we're all trying to say here is that there's no way to *temporarily* set the viewbob, and have it revert upon exit, I can understand why there might be some opposition. If that's the case, I'm perfectly fine with putting a note in the textfile, or having it print onscreen at startup. OF course, this still prevents dynamically changing viewbob, which would be useful for say, in-WAD vehicles. Which is unfortunate. I'm sure there could be some way around this, though. Is there some way that a script/ZDoom could note the player's original settings, and re-state them on exit?

Or how bout taking control of the viewbob out of cvars entirely?

How about supporting additive config files, ie., putting a small config file inside a .pk3 that just changes one or two settings. It would be loaded only with the WAD and then never otherwise bother the player.


The point is, this is a feature that would be *very* good to have, all obstacles related to which could easily be over come we just stop and think for a moment instead of getting all OH GNOES ITS TOO POWERFUL .

[quote="CaptainToenail"]The custom setting needs to overwrite the person's setting, a multiplier is just useless in this case really[/quote]
How is it useless? A setting of 0 will disable bobbing in any case, which allows for player classes that move on wheels or tracks. (Mech, for example) And a setting of 0.5 will cut the bobbing in half so that slowing the player doesn't make people sick. You can even increase the bob by using values over 1.0, though I can't think of much use for doing so.

[quote="CaptainToenail"]The custom setting needs to overwrite the person's setting, a multiplier is just useless in this case really[/quote]
No.

If it's in, it has to be relative to the default setting.

The custom setting needs to overwrite the person's setting, a multiplier is just useless in this case really

There are a few other obvious candidates too - eg FOV. Provided changes to these via ACS/DECORATE only get applied at run time and not saved, I don't see there being much, if any harm, other than people not playing WADs that do silly things with it as HW said.

[quote="Graf Zahl"]No, it can't. With free access to console commands someone can do real damage. That's an entirely different matter.[/quote]
I agree. Unless the nature of console commands/CVARs are completely changed, which I understand not wanting to do, it's too hazardous just to allow free reign to them by authors.

However, for a few CVARs, a multiplier could be useful. So instead of directly overriding the user's movebob setting, how about just a property that will factor it?

Ex: User's movebob is 0.25 (the default), the custom class has a MOVEBOB setting of 0.25, so the resulting movebob is 0.0625. If the user were to change their movebob to 0, this would take precidence because 0 * 0.25 is still 0.

[quote="Graf Zahl"]No, it can't. With free access to console commands someone can do real damage. That's an entirely different matter.[/quote]
Couldn't there be two versions of the cvar settings, one for general use and another that is only used inside a wad? So for instance, if someone did what Cutty gave for example, the settings would automatically revert once you exit out of Doom. That way, no permanent damage could be done and the vast majority of people who wouldn't abuse the access could work with them.

I'm not requesting console access again, by the way, as I know you hate the idea, I'm just trying to get my point across that it could be a good thing as long as people can't [b]really[/b] screw things up. :|

[quote="Cutmanmike"]I think SOME cvars need some expanding so that authors can fiddle with them (although maybe not [i]actually[/i] changing the cvars), like fov and this.[/quote]
Then they'd be ratio (1 is user setting, 0.5 is half user setting, 2 is twice user setting and so on).

Script 1 (void)
{
consolecommand("unbind all");
Exit_Normal(0);
}

I think SOME cvars need some expanding so that authors can fiddle with them (although maybe not [i]actually[/i] changing the cvars), like fov and this.

I disagree 100% with giving authors access to everything in there though. Imagine this sort of thing hidden in wads:

[code]Script 1 (void)
{
consolecommand("unbind all");
Exit_Normal(0);
}[/code]

[quote="Penguinator"]
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.[/quote]


No, it can't. With free access to console commands someone can do real damage. That's an entirely different matter.