mouselook speed

I've looked all over the net and found really really old posts about this; but does anyone know how to speed up mouselook? Even with the sensitivity maxed out, it's still extremely slow. I mainly play in 3rd person now, and turning the camera is like an act of congress.

Go into options, then Display. Click the Advanced button. Slide the Max Fames per Second down to around 50 fps or so.
Viola!
(Something odd with the video coding, it works though, good enough for me i guess)

There's something else weird with mouselook steering outside of frame rate dependence. If you take your 'rolled back' 3rd person view and look around with the LMB it's nice and fast and responsive. But then when you steer your character with the RMB it's significantly slower horizontally while vertical speed is similar to LMB mouselook. This gives your mouse movements a 'vertical oval' shape and makes handling your character very awkward. Mounts are even worse. Maybe the devs play in 9x16 aspect ratio? Lol.

I basically have to do all my 'looking' with the LMB these days and 'update' my character's heading with a click of the RMB because of this issue. It's really terrible design for a modern game to handle something as basic as mouse movement so poorly. When I'm first person going through a dungeon or whatever it's totally impossible to steer with the mouse and find myself using the arrow keys like it's 1993.

From the old forums. SKlugs had responded to the thread and put it on his list but like some things was not a high priority item. Unfortunately they also took Sklugs from us for other projects. He is missed.

http://forums.station.sony.com/eqold/posts/list.m?topic_id=175018

The reason for that is mouselook is tied inversely to the framerate (using delta time for each frame),and more noticeable with wider and larger display screens. This has been in the game for years.

Devs - Please change mouse motion to be FPS independent

A few options

Enable Vsync in system's video/display properties which will reduce game's framerate.

Or to make it game specific, make sure system vsync is set to program specific (not disabled). Then open eqclient.ini w/notepad, look for vsync=false change to true. If line is not present then add line to default section.

Without doing any of that, reduce the FPS slider to 60 or 30.

Message edited by Sarkaukar-Povar on 03/21/2011 04:20:39.

*****************

Heya devs,

I have a request. Please decouple the movement of the player camera from the delta time per frame. That is to say, when calculating the change in rotation of the camera (ie motion model), please do not use the delta time for that frame. Instead, just take the logical x-y change in mouse position and do your calculation without the delta time.

Why?

It's a user experience problem. An experienced user has an expectation for how the camera should move based on lots of practical experience. When the frame rate drops, the camera appears to 'fly past' where they want to go. Here's the simple test case. Use a system/settings that gives you < 10 FPS in the Guild Lobby. Stand near the statue. Look at the ground. Now, move your mouse slowly so you look toward the people. When your frame rate drops, your camera will shoot up to the sky. That's bad and it can happen anywhere, anytime frame rate drops. On raids, in the lobby, in groups, .... It happens because the code looks something like the following:

double change = mUpDownMouseAxis * mMaxTurnSpeed * deltaFrameTime;

The theory - delta time has become associated with motion models based on the incorrect assumption that mouse movement is the same logic as joystick movement. It's not. A joystick is a bounded position input device. Your position is always between [-x,x] and [-y,y]. The only possible logic is to use the length of time that the joystick is not in the default x/2, y/2 position. In a FPS game, the mouse has no actual bounded position while moving (although sometimes, the turn rate is capped to prevent 'mega fast turning' or turn-hacking), but for some reason, people still assume deltaFrameTime is relevant. It's not.

Anyway, thanks for considering this simple, albeit hard to explain, request.

Wyndaria,

Nameless

*******************

trouble wrote:

Chanus wrote:

Wouldn't you then need to have pre-loaded all the graphics in a 360° and spherical rotation in order for this to work (also constantly updating all position changes as far as your clip plane is set in every direction)?

Would that make anything better?

You're missing the point of the post, it is not the loading of the graphics, it has to do with camera speed with the mouse being tied to the FPS. You walk into a zone with 20 people, and do a full 360 spin with the keyboard to make sure you have all the graphics loaded, then attempt to spin in a circle with your mouse, if you move the mouse at the same speed, the camera speed increases with the reduction of the frame rate and slows down when the frame rate climbs back up.

That's it exactly. It's a common problem caused by using the delta time for each frame as part of the calculation for how far to rotate the camera. Players expect user input to generate a reasonably consistent behavior.