1911 replies to this topic

[Heffay]

Karl Berg, on 04 June 2014 - 09:26 AM, said:

I've tried a few times in the past to get things included. Every time I've tried, publisher legal simply denied the request.

Since they were denied, care to share with us what they were? We can fill them in in-game in our imagination, and at least they will be there in spirit.

[Karl Berg]

evilC, on 03 June 2014 - 06:36 PM, said:

Hi Karl, are we ever going to see a proper 6DoF implementation of TrackIR?
Yes, 6DoF movement was implemented, but it is not properly usable, as translations affect the crosshair.

So, at the moment, only 3DoF is really usable.
No biggie, I can live with 3DoF, just wondering like...

Also, will we ever see support for open source / homebrew trackers (ie Freetrack protocol / Disabling the security check in the TrackIR API / Allowing head to be controlled by joystick)?
What about other ways of controlling the head? If you do not allow players to control the Y axis via other means, then TrackIR owners have an unfair advantage.

Loving it so far though. Now if I can just stop swiveling my head around like a tourist, I can actually play again instead of just admiring the view while my team dies

Can you provide me a good example of the negative interaction between translation and the crosshair? A video from training grounds for example, or just really easy to follow steps to reproduce the issue.

If there are alternative drivers that allow interaction with other pieces of hardware, just point them out! Hooking Oculus into the system we've put into place for TrackIR proved to be relatively simple.

Glad you're having fun with the new input mechanism I spent quite a while simply looking around myself. I'd never used TrackIR previously, so I was pleasantly surprised with how fun it actually turned out to be.

[CeeKay Boques]

Quote

[color=#00FFFF]What about other ways of controlling the head? If you do not allow players to control the Y axis via other means, then TrackIR owners have an [/color]unfair advantage[color=#00FFFF].[/color]

TrackIR I would say (well done, btw, good implementation, works perfect, doesn't break anything and is fun to use) is NOT an advantage, anymore than a mouse with macro buttons, or a computer with a better processor.

While I can see down, a little more, I was shooting there anyway, just on feel. Now I have to lean forward and get my head out of position, which is frankly difficult with with way the TIR and crosshair and view work together.

Its a feature, anyone can freetrack/Noir.

In a flight sim, TrackIR drastically increases situational awareness. You can still fly the plane and look without it, its just not as cool. I file this under the same "advantage". It doesn't provide new angles to shoot...

[Grits N Gravy]

Mr Berg,

Now that track IR has been implemented into the game, could you please focus your expertise on implementing better joystick controls so we can have a truly great mech sim.

The current problem lies with how the game handles the positional data from the joystick that it gets from direct input. It uses the positional data as an acceleration speed. Which actually makes using a joystick for aiming and positioning a mech's torso very difficult.

With the mouse when you want to stop the torso/reticule from rotating you simply stop moving the mouse. With the joystick you actually have to recenter the stick, so it's two movements for the same action. It's counter intuitive and very clunky. So much so, that the preferred method for joystick use in MWO is as a throttle and turning with the left hand and the mouse in the right for aiming.

A much more workable solution exists that would allow the joystick to be used as an effective aiming device. This would be achieved by having the torso of the mech mimic the position of the joystick. This could be done by simply using the positional data from the stick to mirror torso position. So the movement code, rather than taking acceleration as the input and lerping to solve position. You take position as the input and solve for acceleration.

It could work on every stick, with no need to build libraries or arrays of various stick's maximum positional values, because you can set the maxium input range of joysticks via direct input and all sticks will report in that format. So even if an user has an 8 bit stick, direct input will convert the lower resolution into an 16 bit format. ie a position of 256 on a 8 bit stick, will be translated in 65,536 in game. Though the max input range should be set to 65,536 and -65,536 or higher, as 16 bit is the highest available resolution for sticks.

http://msdn.microsof...v=vs.85%29.aspx

Edited by Grits N Gravy, 04 June 2014 - 10:38 AM.

[evilC]

Karl Berg, on 04 June 2014 - 09:58 AM, said:

Can you provide me a good example of the negative interaction between translation and the crosshair? A video from training grounds for example, or just really easy to follow steps to reproduce the issue.

If there are alternative drivers that allow interaction with other pieces of hardware, just point them out! Hooking Oculus into the system we've put into place for TrackIR proved to be relatively simple.

Glad you're having fun with the new input mechanism I spent quite a while simply looking around myself. I'd never used TrackIR previously, so I was pleasantly surprised with how fun it actually turned out to be.

Drop into match.
Make sure view is DEAD CENTER (ie set massive deadzone or disable TIR)
Aim at a point.
Enable TIR and lean (translate) to the side.
Notice how the crosshair does not point at the same place (If you lean to the left, the crosshair "moves" to the right)

Diagram to explain:

TOP VIEW

X
Y
Z

X = Subject (point of aim)
Y = Crosshair
Z = Observer

If Z is looking directly ahead at X, it goes through Y - The center line of the view cone is exactly vertical.
However, if Z moves to the left, the center of view line is no longer vertical, so looking through Y looks at a point to the right of X

This problem is unsolvable without either:
Disabling lean
Or
Repositioning the crosshair dynamically such that it always covers the point that you are actually aiming at.
Normally this is not easy as the point you are aiming at is "infinity" distance. However, with MWO's weapon convergence, if you make sure the crosshair was always covering the convergence point, this may prove a neat solution.

Did Naturalpoint not explain this? No wonder so many games make this mistake.

Edited by evilC, 04 June 2014 - 10:53 AM.

[Karl Berg]

Heffay, on 04 June 2014 - 09:53 AM, said:

Since they were denied, care to share with us what they were? We can fill them in in-game in our imagination, and at least they will be there in spirit.

None for MWO. There are so many above board things to work on in this project that the desire to work on 'less functional' features isn't really there. Instead, the spectator system, the telemetry and heatmap generation systems, collision work (unreleased), TrackIR, and Oculus (unreleased), are all examples of things I've worked on during production gaps. These were not requested or scheduled by production. Many of the other devs have their own similar side projects that they have either released, or are hoping to release at some point. I'd place all of those as much higher priorities than adding easter eggs at this point.

That being said, we've certainly discussed adding special modes that would allow staff to randomly invade running games with pre-release clan mechs, as well as adding a few other nifty role playing style elements to the game. Those particular plans went up in flames unfortunately. But in future, who knows..

evilC, on 04 June 2014 - 10:49 AM, said:

Drop into match. Make sure view is DEAD CENTER (ie set massive deadzone or disable TIR) Aim at a point. Enable TIR and lean (translate) to the side. Notice how the crosshair does not point at the same place (If you lean to the left, the crosshair "moves" to the right) Diagram to explain: TOP VIEW X Y Z X = Subject (point of aim) Y = Crosshair Z = Observer If Z is looking directly ahead at X, it goes through Y - The center line of the view cone is exactly vertical. However, if Z moves to the left, the center of view line is no longer vertical, so looking through Y looks at a point to the right of X This problem is unsolvable without either: Disabling lean Or Repositioning the crosshair dynamically such that it always covers the point that you are actually aiming at. Normally this is not easy as the point you are aiming at is "infinity" distance. However, with MWO's weapon convergence, if you make sure the crosshair was always covering the convergence point, this may prove a neat solution. Did Naturalpoint not explain this? No wonder so many games make this mistake.

Thanks! I will investigate as soon as I can.

[evilC]

Video to illustrate issue:

[evilC]

Oh, and Karl, could you also look at the crosshair movement?
The crosshair motion with arm lock on has always been known to be preferable for accuracy, and this seems exaggerated (or just more obvious) when using TrackIR - even to the extent of some people feeling almost nauseous.
I know I myself am having trouble aiming - the view is great, but once you actually start to try to play competitively, it does not quite feel right, especially with arm lock off. It is hard to test empirically as I have not been able to get AutoHotkey to properly control mouse look, so I have been unable to do a frame by frame comparison with identical mouse movements.
I think this may be to do with the fact that with arm lock off, the torso ( + ) crosshair has an "ease in" and "ease out" on it's motion which is not present (or apparent) with arm lock on.
Is there any way you could maybe look into this?
If the problem is a little vague, is there maybe a chance we could work out some way to generate consistent mouse input, so we can get some reliable testing done?

[shellashock]

Karl Berg, on 04 June 2014 - 11:04 AM, said:

That being said, we've certainly discussed adding special modes that would allow staff to randomly invade running games with pre-release clan mechs, as well as adding a few other nifty role playing style elements to the game. Those particular plans went up in flames unfortunately. But in future, who knows..

For the first day of CW with the clan invasion and all, you should make a rule that only devs could drop in clan mechs and you should get the PGI team to drop against all those eager BT vets with clan mechs with 6x regular amour and weapons with a 500% damage increase. After that day/week whatever is done, then you could unlock clan mechs and return the values back to where they were before that special event. Imagine just how many tears of joy/rage would be flowing that day from the Battle Tech Veterans! It would give all those BattleTech Vets who wanted a "real challenge against the clanners" like Joseph Mallan a great time and would give the proper celebration that CW deserves!

Edited by shellashock, 04 June 2014 - 03:49 PM.

[Cimarb]

shellashock, on 04 June 2014 - 03:47 PM, said:

For the first day of CW with the clan invasion and all, you should make a rule that only devs could drop in clan mechs and you should get the PGI team to drop against all those eager BT vets with clan mechs with 6x regular amour and weapons with a 500% damage increase. After that day/week whatever is done, then you could unlock clan mechs and return the values back to where they were before that special event. Imagine just how many tears of joy/rage would be flowing that day from the Battle Tech Veterans! It would give all those BattleTech Vets who wanted a "real challenge against the clanners" like Joseph Mallan a great time and would give the proper celebration that CW deserves!

This is a good idea, but would have to happen the day BEFORE it was released (i.e. June 16th). Otherwise, you will have thousands of very irate people that got their packs delivered and cannot drop in them...

[Rebas Kradd]

Karl Berg, on 04 June 2014 - 11:04 AM, said:

None for MWO. There are so many above board things to work on in this project that the desire to work on 'less functional' features isn't really there. Instead, the spectator system, the telemetry and heatmap generation systems, collision work (unreleased), TrackIR, and Oculus (unreleased), are all examples of things I've worked on during production gaps.

Out of curiosity, how long are typical production gaps? Are specific work items actually scheduled by date, instead of just "start X once Y is finished"?

Edited by Rebas Kradd, 04 June 2014 - 04:48 PM.

[shellashock]

Cimarb, on 04 June 2014 - 04:04 PM, said:

This is a good idea, but would have to happen the day BEFORE it was released (i.e. June 16th). Otherwise, you will have thousands of very irate people that got their packs delivered and cannot drop in them...

I meant the first day that CW with the big shiny interstellar map is implemented. That first day it would be cool to see something like I described. But yeah, definitely would not want to block all those clan pack buyers from using their new mechs on the first day.

[Foust]

Mr. Berg,

First thank you for taking the time to contribute to this thread, it is on my daily reading list.

It was great to see TrackIR get put into the game, yet disappointing that it is locked down to natural point hardware. Are there any plans to support open source tracking applications such as freetrack or facetracknoir?

Grits N Gravy hits the nail on the head regarding joystick control problems. I would like to second his request for this style of control. Currently the best we can do in regards to workable joystick aiming is to use mouse emulation, which while vastly superior to the current joystick control implementation, is not without its own list of ....quirks....

Spoiler

Grits N Gravy, on 04 June 2014 - 10:36 AM, said:

Mr Berg,
Now that track IR has been implemented into the game, could you please focus your expertise on implementing better joystick controls so we can have a truly great mech sim.

The current problem lies with how the game handles the positional data from the joystick that it gets from direct input. It uses the positional data as an acceleration speed. Which actually makes using a joystick for aiming and positioning a mech's torso very difficult.

With the mouse when you want to stop the torso/reticule from rotating you simply stop moving the mouse. With the joystick you actually have to recenter the stick, so it's two movements for the same action. It's counter intuitive and very clunky. So much so, that the preferred method for joystick use in MWO is as a throttle and turning with the left hand and the mouse in the right for aiming.

A much more workable solution exists that would allow the joystick to be used as an effective aiming device. This would be achieved by having the torso of the mech mimic the position of the joystick. This could be done by simply using the positional data from the stick to mirror torso position. So the movement code, rather than taking acceleration as the input and lerping to solve position. You take position as the input and solve for acceleration.

It could work on every stick, with no need to build libraries or arrays of various stick's maximum positional values, because you can set the maxium input range of joysticks via direct input and all sticks will report in that format. So even if an user has an 8 bit stick, direct input will convert the lower resolution into an 16 bit format. ie a position of 256 on a 8 bit stick, will be translated in 65,536 in game. Though the max input range should be set to 65,536 and -65,536 or higher, as 16 bit is the highest available resolution for sticks.

<a data-cke-saved-href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb153252%28v=vs.85%29.aspx" href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb153252%28v=vs.85%29.aspx" class="bbc_url" title="External link" rel="nofollow external">http://msdn.microsof...v=vs.85%29.aspx</a>

Edited by Foust, 05 June 2014 - 05:10 AM.

[evilC]

Hi Karl, found another TrackIR bug.

When using Advanced Zoom, if you ROTATE the view, the crosshair deviates.

In this video, I am rotating the view with the TrackIR Yaw axis.
See what happens with adv zoom on/off.
Mouse is not moved, actual aim point is always the commando's head.


I guess you placed the Adv Zoom elements at a greater z-depth than the regular crosshair?
So if you rotate the view, you are translating the location of the Adv Zoom asset?

Edited by evilC, 05 June 2014 - 11:56 AM.

[DarkonFullPower]

I know this should be ultra low on the priorities list, but I'd like to know that it's still on the list at all.

Is making a toggle for AMS / TAG still on the to-do list?
I understand why TAG toggle might be hard because it works like every other weapon, but what about AMS?

[Cimarb]

DarkonFullPower, on 05 June 2014 - 12:44 PM, said:

I know this should be ultra low on the priorities list, but I'd like to know that it's still on the list at all.

Is making a toggle for AMS / TAG still on the to-do list?
I understand why TAG toggle might be hard because it works like every other weapon, but what about AMS?

My ninja Atlas approves of this question!

[DarkonFullPower]

Cimarb, on 05 June 2014 - 12:57 PM, said:

My ninja Atlas approves of this question!

My 1 ton of AMS ammo firing at a wall / ceiling would also like to know. Also new and old players that don't want to macro TAG might be interested as well.

Edited by DarkonFullPower, 05 June 2014 - 01:17 PM.

[CeeKay Boques]

evilC, on 05 June 2014 - 11:54 AM, said:

Hi Karl, found another TrackIR bug.

When using Advanced Zoom, if you ROTATE the view, the crosshair deviates.

In this video, I am rotating the view with the TrackIR Yaw axis.
See what happens with adv zoom on/off.
Mouse is not moved, actual aim point is always the commando's head.


I guess you placed the Adv Zoom elements at a greater z-depth than the regular crosshair?
So if you rotate the view, you are translating the location of the Adv Zoom asset?

Hey thanks for helping iron out TrackIR!

[Hammerhai]

Am glad to see you are investigating laser hitreg. Thank you very much for that.

[VanillaG]

With the introduction of the static quirks modifiers (IS Mechs) and dynamic quirk modifiers (Omnimech pods) are there any plans for introducing realtime quirk modifiers based on mech heat and component damage/destruction via critical hits? Here are some general ideas about the kind of quirks effects:

• Leg Actuator destruction - decrease acceleration, deceleration, top speed
  
• Arm actuator destruction - decrease arm yaw, pitch, yaw speed, pitch speed
  
• Gyro damage - decrease torso yaw, pitch, yaw speed, pitch speed
  
• Engine damage - decrease heat capacity, heat dissipation
  
• Heatsink destruction - decrease heat capacity, heat dissipation
  
• Sensor damage - decrease lock range, increased lock time
  
• High heat - overall general debuff to all systems.

As it stands right now, mechs work perfect until they lose both legs or the engine. Adding in these kind of quirks adds to immersion and is an indirect buff to weapons that deal critical damage.

Edited by VanillaG, 05 June 2014 - 06:57 PM.