Yaw for (A_)SetRoll Discussion

[Major Cooke]

First and foremost, let's have a discussion on this before I do ANYTHING at all, yet. Yes, not including yaw can be problematic especially if one wants to make a jet simulator.

---

SOMEONE better! I wanna blow shit up!

Here's where I stand.

I'll be honest, I think the best way is to somewhat treat it similarly to A_ZoomFactor...

If SetRoll is called with a flag, such as SRF_USEYAW for example, I would think the best way to maintain that is to toggle a little boolean on a player so whenever mouselook and such is taken into acount, it will truly mean turning the screen in any of the four directions. It would remain on until such time where SetRoll would be called again, without the flag, whenever the map changes level, game quits, etc. A map-only scoped lil' boolean value if it's on a PlayerPawn entity.

I'm welcoming your thoughts and suggestions, and I ESPECIALLY would like to hear from Randi/Graf first before I start taking more affirmative action.

Side note: Planning on an A_Shudder mechanic. Think of it like A_Quake but for rolling instead.

And what I've mentioned above doesn't discuss adding any sort of input for rolling. All it does is tell the engine to turn/pitch the camera and factor in their roll. If someone else has any bright ideas on that, all yours. I'm just doing the DECORATE/ACS stuffs.

[Snarboo]

Why not just create a standard actor flag for players? If A_SetRoll determines the behavior of this flag on a map scope level based on a player flag, wouldn't a designer need to be VERY careful about making sure it's set in every instance of A_SetRoll anyway? And if it needs to be set on every instance, why not just make it a flag for A_SetRoll and be done with it?

What you're proposing seems complicated (a flag set both by the player and action function that must work in tandem?), as well as potentially breaking save games if the flag is turned off when leaving a level for any reason. That said, there does need to be a way of either setting it on the player, the action function, or both.

[Graf Zahl]

Doom isn't a flight simulator. The entire physics code is unsuitable for that.

[Snarboo]

I think it can be done, and there are unused commands for yaw in the console, but it needs to be thought about pretty carefully.

[Major Cooke]

Graf: The idea behind this "yaw" was basically to just set a boolean to accomodate A_SetRoll's lacking ability to adjust the camera while rolled. So turning left with like a roll of 2 would also adjust the pitch too. Because right now, give yourself a roll of 180 in gzdoom and all the controls are inverted for the mouse. All this idea would do is just change that around so even with a roll applied, left means turn the camera left regardless of how much it's rolling currently... aka relativity.

And, I didn't mean an actual flight flight similator, that was just referenced mildly. I took a peak at the code already, it really shouldn't be too hard to implement at all.

[Graf Zahl]

I think you don't even begin to grasp the complexities and pitfalls of this suggestion.

[Major Cooke]

Damnit.

Welp, sorry Nash, I tried.

[Nash]

No worries, I was more concerned with wtg62's request to have independant pitch and angle for his Roll mod because his mod revolves around tilting the view 180 degrees.

I guess mod authors can either stick to camera texture hacks or roll out their custom player movement code and use trigonometry to solve the angle/pitch problem...

(The latter being the more realistic and short-term solution if anyone wants to make "flight sims")

[Snarboo]

Would implementing yaw on mouse input (and player input?) really put that much strain on the physics engine? Or is there some behind the scenes technical issue that makes it infeasible?

I'm always confused when any feature is no'd because of "technical wizardry incompatible with the engine." It would help the laydoomer understand why such a feature is no'd if a transparent explanation is given, especially for future reference. For example, it would be nice to know if yaw isn't feasible because it would cause problems with hitboxes, weapon spread, etc.

[randi]

No.

[Graf Zahl]

I'm always confused when any feature is no'd because of "technical wizardry incompatible with the engine." It would help the laydoomer understand why such a feature is no'd if a transparent explanation is given, especially for future reference. For example, it would be nice to know if yaw isn't feasible because it would cause problems with hitboxes, weapon spread, etc.

All these things wouldn't be affected at all by rotations. But that's already a problem. But that's not the reason why it was 'no'd. To handle this properly the entire setup to rotate the GL view (as it makes little sense in the software renderer) needs to be aware of it and frankly, that's something I do not want to think about.

[Nash]

In the imaginary situation where one would want to start working on this, he would also have to put in work on the ZDoom side, right? Even if the column renderer can't support it, that stuff first needs to be serialized (if it's going to be a player property)... and THEN the GL camera would have to be altered to make use of that new data... right?

[HeXaGoN]

Nash: The main reason why I was asking about this was so that looking around with roll angles other than 0° and 180° wouldn't be awkward.
It's quite easy to make it so mouse controls aren't inverted at a 180° roll, but not so much with other angles.

Thank you for trying though.

It is possible to do something like this with ACS, but it will still be awkward to control at angles besides 0° and 180° no matter what you do.
I have yet to figure out how to do it correctly, though.

[sonic_HD87]

Sad thing my Intel chip cannot support GZDoom 2.xx, im stucked on the 1.8 release

[Major Cooke]

And I think this is the wrong thread.