Obsidian Conflict Bugtracker - Obsidian Conflict
View Issue Details
0000092Obsidian Conflict[All Projects] Feature-Requestpublic29.07.2011 17:4516.08.2011 23:11
Davidos 
 
normaltweakalways
assignedopen 
nonenone 
0.1.3.5 
 
0000092: Different way to modify Ironsights- Angles, instead of origin?
I'm wondering if it's possible to make the ironsights more editable (SMOD/Tactical), as in that it doesn't count on the origin, but that the angle/yaw/pitch can be changed seperately.

As it is now, editing the Y-origin will cause the weapon to sway left and right while aiming up and down with a weapon, thus making the ironsights redundant and non functional when aiming in any other way than up and down if the Y origin is more than 0.5 different from 0.

Another possibility is removing the view sway when looking up and down in the ironsights...
1. Take a weapon.
2. cl_ironsight_test_wpn_ori_offset_y -1.0 > x > 1.0
3. Aim up and down in ironsights, notice that the weapon sways off right and left depending on if you are aiming further upwards or downwards than center screen.
Makes ironsight command and half of the weapons with ironsights (Designed for) practically useless.
No tags attached.

Notes
(0000143)
Davidos   
29.07.2011 17:58   
I just noticed that a post was placed about this, THREE YEARS AGO, on the forums.
(0000144)
z33ky   
30.07.2011 00:55   
Yeah, that was made by me :3
I remember really pulling my hair out on this one. I did all kinds of stuff, messed with the viewmodel-code breaking in several times in fancy ways that didn't help.
Spamming all kinds of origin- and angle-information to the console didn't help either.

I'll take another look at it, perhaps I've gained better debugging-skills in that time.
(0000146)
Davidos   
31.07.2011 13:34   
(edited on: 31.07.2011 13:37)
Well, I know that several mods (SMOD TACTICAL and INSURGENCY) for example, fixed this problem already, maybe they removed some yaw/roll script when looking up and down?

Can't you counterscript that if it's hardcoded? Just force it to move to the left depending on view angle? o.o;;;

Gawd I wish I was developer smartz >.<

(0000148)
z33ky   
31.07.2011 17:22   
Oops, misunderstood this bug-report.
I don't have this problem, so it is probably already fixed in the most recent code.

However, modifying yaw makes problems and that I cannot figure out :S
The yaw gets translated into roll somehow (while the roll stays roll). This is not due to some special rendering or such - drawing a bunch of debug-lines shows the same thing happening.

I tried all kinds of rotation-functions, doing the calculations using vectors or matrices instead of angles, combinations thereof, but it was either the same problem or it broke somehow.

If you try the same thing with point_viewcontrol in Hammer (by 'hard-coding' the values), the result is the same (yaw gets translated into rotation). If you, instead of writing the values of the angles, rotate it in the 2D views (first down or up, then to the side) it does some magical math and gets it working, so if you want to tackle this, that is certainly a thing to try.
(0000153)
Davidos   
01.08.2011 22:55   
I'm talking about weapon models in first person, I'm not sure how hammer would change that...
(0000154)
z33ky   
02.08.2011 01:43   
The point_viewcontrol exhibits the same problem when altering the yaw while it points up or down.
But if you rotate it instead of setting the value of the yaw by hand, the values are getting adjusted so that the actually desired rotation is achieved; I am unsure of the mathematics behind that, but observing the values might give a clue about that.
(0000155)
TESLA-X4   
02.08.2011 03:01   
Interesting find, z33ky. Just to clarify, specifying the angles in keyvalues exhibits the issue (on the viewmodel), and rotating the actual point_viewcontrol entity with Hammer settles the roll issue?
(0000156)
z33ky   
02.08.2011 12:55   
Might just have been faulty wording, but setting the keyvalues of the point_viewcontrol to say (90, yaw, 0), setting the yaw rolls the camera. Setting the roll will also roll it, so it's the same as when you look down and try to set the yaw of the viewmodel.

Rotating the point_viewcontrol via the mouse makes it possible to adjust the angle, of what you think would be the yaw, but looking at the keyvalues afterwards yields a result different form (90, yaw, 0). You should probably try it out yourself to see what I mean.
(0000157)
Davidos   
02.08.2011 21:21   
Well, if it helps, I'm in good standing contact with the creator of the original developer of the TACTICAL weapons mod, the one that later used SMOD. He incorperated this fix, somewhere, perhaps I could ask him? With your permission, ofcourse.

Doesn't necessarily have to be copy pasta :p
(0000161)
z33ky   
03.08.2011 11:16   
Like I said, I misunderstood your bug report and though it was about the yaw, not translation on the y-axis.
The code for the ironsights were recently upgraded, this might have fixed this since I can't reproduce it with our current codebase.

I am, however, encountering problems when modifying the yaw, a problem that I also observed in SMOD and also SMOD Tactical.
(0000162)
Davidos   
04.08.2011 17:43   
Hmm, well, that could be it... isn't that equivalent to what the Y axis does when changing the origin on the Y-axis, like the command says (ori_offset_y)?

Any chance it could be edited out? x.x Some models hate my ironsight settings x3
(0000167)
z33ky   
16.08.2011 23:11   
Yes indeed, my bad. After all, your problem is the same I am having.
I thought the ori-part of the ConVar would stand for origin, but it seems to be orientation.

Well, like I said I observed the same problem in SMOD, but I will take a look at the Insurgency sights at an opportune time. Or perhaps someone else. If the problem is reproducible there contacting the devs is a viable option.