ZDoom

[quote="Major Cooke"]And I think this is the wrong thread.[/quote]

Well, since A_SetRoll is a GZDoom exclusive and has been added recently i assume that only works with GZDoom 2.xx, wich i cannot run :?

And I think this is the wrong thread.

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

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.

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?

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


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.

No.

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.

No worries, I was more concerned with wtg62's request to have independant pitch and angle for his [url=http://forum.zdoom.org/viewtopic.php?t=36575]Roll mod[/url] 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")

Damnit.

Welp, sorry Nash, I tried.

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

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. :P I took a peak at the code already, it really shouldn't be too hard to implement at all.

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.

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

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.