Blight 384.105

Greetings Blight Players.

The current client on Blight is potentially a release candidate. The only change from the 384.98 client are camera related fixes / adjustments.

Blight is now a release candidate. This is scheduled for release July 9, unless something critical comes up.

Here's the official change release notes:

• FEATURE: Mouse Over Descriptions on hot keys
• FIX: Resource Targeting Commands - Fix for SelectNearest and no other items around deselects
• FIX: Many adjustments to camera controls and click functionality
• FEATURE: Right click on entity selects entity

Before making any comment, please ensure that you are running the 384.105 client, as the various different versions recently released all have different camera behavior as the developers have been tweaking the various releases. You can see your current build by typing:
/window fpswindow

Your feedback is very much appreciated and will help to ensure a solid release.

As always, we appreciate you playing on Blight and hope that you find all the changes as exciting as well do.

<Updated release to 384.101>
<Updated release to 384.102>
<Updated release to 384.105>

Istaria Developers

The turning/steering is still limited to basically 180 degrees.

Click and hold the mouse button assigned to turn/steer the character. go as far as it will in one direction, turning stops, then turn back the other direction. At 180 degrees from the prior stopping point it stops in the opposite direction.

Patching back to live. This still needs fixed. I cannot run my biped out of a lair with this change without having to stop and start over the steering.

Blight has been updated with client 384.101 - which fixes the steering issue. This is a release candidate, so if there's any more feedback, please reply to this thread or submit feedback at https://support.istaria.com The developers are really trying to get this release stable and out the door as soon as possible.

Thank you,

Yfelvik
- Istaria Customer Support

Steering issue fixed!

Just in case someone else is going to report, Raptress submitted the following through support:

Is it possible to disable the activation of camera-related functions on the mouse buttons when the cursor is clicked over a UI element (like hotkeys, the inventory, etc.)? The current system of having a delay before the camera functions activate works all right, but I feel it would be better if the camera stuff simply didn't activate when clicking the UI and activated instantly when clicking the render window. The current delay behavior could then be reserved for when the player clicks on a mob or other selectable entity on the render window.

While holding the left mouse button and panning the camera, the player character will be selected when moused over, even though the cursor cannot be seen. (For easy reproduction, log onto a dragon, hold left mouse with nothing selected, then point the camera straight to the ground.)

Hmm, steering is fixed, but it appears the cursor is still moving in the background as you steer in one direction continuously.

The fix appears to be that the cursor gets bounced back about 40% the screen width once it hits the edge. Workable solution I suppose (far better than the steering hitting a wall) but you can see a small tick in the turning movement when the cursor gets kicked back.

Not a big deal really, but however the client on live does the turning, you don't see the tick. It releases the cursor back on screen when you stop steering, wherever it was when you started. It's like when you click to start steering, the actual cursor stops moving and the mouse info goes to steering. When you let go, the cursor comes back. Seems like a bit better behavior. (but i'm no programmer, so no idea why it got changed from the way it works on live).

Client Release 384.102 now has these updates:
1. Disabled Mouse/Free look starting when mouse is over a UI element (hotkey, inventory)
2. Reduced startup time for Mouse/Free look
3. Fixed player char getting selected during Mouse/Free look

You can see your current build by typing:
/window fpswindow

Your feedback is very much appreciated and will help to ensure a solid release.

As always, we appreciate you playing on Blight and hope that you find all the changes as exciting as well do.

Istaria Developers

Might have found a new really bad bug in the 384.105 client.

Twice now, when the client closes itself while I am afk, my hotkeys.def gets wiped out. Log back in, hotkeys all gone.. Normal logout doesn't wipe the hotkeys...

Hi Guaran,

Your hotkeys are stored in the following file:
\prefs\<shard_name>_<character name>\UIHotkeys.def

For example, if your shard / character is chaos / bobby, then your hotkeys would be stored at:
\prefs\chaos_buddy\UIHotkeys.def

The next time your hotkeys are reset, could you check if that file is missing - and if it is there, could you please submit a support ticket with your entire prefs folder attached as a zip file please? I'll have a quick look in case I see something that helps in reproducing the issue, and then forward to the developers.

Thank you,

Yfelvik
- Istaria Support

I haven't been able to reproduce the issue. Only have had one client crash since this morning on a different toon, and hotkeys were ok. I'll let you know if it happens again.

On live, I am able to bind MOUSE_RIGHT to 'Popup Window' and 'Mouse Look (hold)' and get the proper camera rotating effect whilst having context menu on release of right click. Is it intended that the context menu happens on release? Also, using aforementioned binds without the 'Use Mouse Left/Right buttons to Mouse/Free Look' checked under Camera tab, the cursor still maneuvers in the background, often times ending up nowhere near the initial button depression. I know this has been an ongoing issue, however, it seems to happen randomly and I am unable to reproduce it. Sometimes the cursor will show up in the exact same spot, other times it will appear to have moved approximately the same distance of the mouse.

On Blight, I am not sure what exactly has been done for these camera controls, or whether or not the binds are necessary anymore with the camera option checked. Although the cursor no longer appears to move off screen, it still does indeed move and depending upon the stroke of movement, often times ends up on opposite side of screen nowhere near point of depress.

I've definitely noticed the cursor moving in the background thing while steering. I think this is why its now so much easier to then click on some unintended part of the UI.. and drag a window you didn't mean to, close a window you didn't mean to, click a hotkey you didn't mean to, drag a hotkey you didn't mean to....

Really wish the cursor didn't move in the background while steering. Whats trying to be fixed with all the changes? The client on live seems to steer better to me.

The developers are looking into the mouse movement. The client release scheduled for tomorrow has been postponed until next week.

Thank you everyone for your feedback and helping avoid a release that would appear broken.

It is easy to see this invisible mouse moving in my setup. I have about 6-8 hotbars open (horizontally) towards the bottom left side of screen. When I engage free mouse look (with the camera option right/left to use Mouse/Free Look unchecked). When I engage mouselook, and stand still, and start looking around (left or right). As I'm looking left, you can see the various hotkeys light up (as they're being hovered). But can not see the mouse cursor, but know where the mouse is as its highlighting various hotkeys I have. If I was to left click, while one of these hotkeys was hovered, it will execute the hotkey (even though the mouse cursor is invisible).

Maybe the solution would be to force the mouse cursor to go to the center (or say the top left corner, maybe) of the screen and not move, when free look is enabled, shrug. So if you want to reproduce, just open a bunch of hotkey bars (don't need to add anything, just open the bars) and plaster them all over the place. Then start mouse looking around, you'll see them get highlighted.

Client release 384.108 is coming down the release pipe and is expected to fix all reported issues. I'll post the final release notes just as soon as I have them!