Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 46

Thread: Blight 384.109

  1. #21

    Default Re: Blight 384.108

    I'm running two instances on two screens and it's really annoying that the mouse jumps around, please fix this soon...
    Mouse jumps always to screen, sometime top left corner, sometimes down right
    Terao (Gnome, Grand Master Crafter, Order [Unity])|Draigourn (Ancient, Master Lairshaper, Lunus, Order)|Echentrial (Ancient, Lunus, Order)

  2. #22

    Default Re: Blight 384.108

    When I get home from work, the client with the odd cursor behavior I will try re-patching to blight again. Is it possible it is just one toon with the cursor moving to the corner? I will also try it with a different toon on that install.

  3. #23

    Default Re: Blight 384.108

    Double check your installation folders. Use a dedicated Blight directory. Don't shuffle files or folders between the two. Keep both isolated.

    It's been possible to log into Chaos with a Blight server client with the no-patch option on launcher, so keeping directories separate will help in conflicts stemming from this.
    rip

  4. #24

    Default Re: Blight 384.108

    There's a known issue with the 384.108 client (rolled to live today) that if mouse/look being disabled and the right mouse button being bound to either Mouse or Free look. The developers are investigating this issue.

  5. #25

    Default Re: Blight 384.108

    I patched the misbehaving client to blight again today (no files updated), same behavior on both blight and live. Cursor appears in very upper left after letting go of the mouse button when steering.

  6. #26

    Default Re: Blight 384.108

    Quote Originally Posted by Guaran View Post
    I patched the misbehaving client to blight again today (no files updated), same behavior on both blight and live. Cursor appears in very upper left after letting go of the mouse button when steering.
    Ok, more info. The issue I was having was when the "Use mouse Left/Right to Mouse/Free look" box in options was not checked (One client had it checked, one didn't). middle mouse was bound to mouse look hold, left mouse bound to nothing, but both could be used for steering (right mouse is bound to popup). Left mouse shouldn't have been doing any steering but it was. Cursor would go to some random place on screen when using either left or middle for steering.

    Checking the box seems to have fixed it. Cursor appears where it was when steering was started.

    Right mouse is still bound to pop-up window, but this only works on ui elements or inventory windows. Right clicking a character such as for inviting to group, or to follow, no longer appears. Right clicking on a structure to "Browse storage" also no longer appears.

    Using middle mouse to steer, still results in cursor appearing at some random spot on the screen after you release the button. Using right or left mouse buttons for steering or camera rotating, releases cursor back where it was when you started.

    You're getting close...
    Last edited by Guaran; July 10th, 2013 at 03:41 AM.

  7. #27

    Default Re: Blight 384.108

    FYI, working obsidian yesterday after startup and crashed twice at same spot. I finished making obsidian blocks at lunas stoneworking ped and headed outside SE to the field and locked up at 22140/28269 each time. Wonder if there is a glitch in that spot. I jotted down the coords to post here to help in checking it out.

  8. #28

    Default Re: Blight 384.108

    Is the new selection process also applicable to right clicking? It seems in Yew Forest, that more often than not, I have to double click a corpse with left click than right click using lootall because of larger trees that get in the way. Also, when dealing with a pile of corpses around my feet, same thing. I am able to finely select corpses with left click but with right, it appears to select like before. Difficult to differentiate.
    rip

  9. #29

    Default Re: Blight 384.108

    always when I make rightclick for free look my mouse cursor is placed in the lower right corner which is a bit disturbing for me

  10. #30

    Default Re: Blight 384.108

    Quote Originally Posted by Guaran View Post
    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...
    Ok, this bug came back last night. It has been intermittent enough that I have not been checking the hotkeys.def file each time. As the client was logging in, it appears the file was either zero'd or deleted. As it booted it creates a fresh file thats 1kb, then a bit later 11kb, which is 20 banks of hotkeys with each one blank.

    I'm running the 384.108

  11. #31

    Default Re: Blight 384.108

    Quote Originally Posted by Guaran View Post
    Ok, this bug came back last night. It has been intermittent enough that I have not been checking the hotkeys.def file each time. As the client was logging in, it appears the file was either zero'd or deleted. As it booted it creates a fresh file thats 1kb, then a bit later 11kb, which is 20 banks of hotkeys with each one blank.

    I'm running the 384.108
    This happened to me on Order last night. All my hotkeys went blank after I closed down and switched to another character. Luckly I have them saved in a seperate file on my computer and was able to reload them.

  12. #32

    Default Re: Blight 384.108

    If you can get the issue to happen reliably, please submit a support ticket with your hotkeys file. I usually triage the technical support requests and will try to reproduce with your hotkeys file.

    Blight is being updated today with a fix for the mouse bindings / camera controls:
    Fix: Camera Feedback When mouse/Free look is disabled but the mouse click is bound to Mouse / Free look key, the behavior should be the same

  13. #33

    Default Re: Blight 384.109

    Blight has been updated with a minor fix if you have the mouse/free look disabled in options, but have your mouse buttons bound to the mouse/free look key anyway. There were problems with camera / mouse feedback. This update will be released to the live servers on Tuesday's maintenance if no issues related to this fix are reported.

    This is release 384.109

  14. #34

    Default Re: Blight 384.109

    Been running 384.109 since last night.

    Seeing the hotkey problem again, this time it has happened and the client has not crashed.

    Noticed a hotkey was not working, so I right clicked, edit. and it was blank, still had the correct icon tho.

    Went to look at hotkeys.def, the file is zero'd out. completely empty. I edited the hotkey I noticed was blank, saved it, and now it is the only thing in the hotkeys.def file. Tried doing /saveui, didn't affect the hotkeys.def file. Not all hotkeys in the active game I am playing are blanked, but the hotkeys.def doesn't list them anymore. I edited and saved a few more hotkeys (made no changes), no additional lines are saving themselves back to the file. Edited another one again, made a small change, saved, the hotkeys.def still has no additional info save for the very first key I saved.

    I think I might be seeing the pattern that is causing the issue to appear... A few minutes before I noticed a hotkey was not working, I decided to add another hotkey bar to my UI. I think the other night when it happened the last time, I had done the same thing. I have 14 open and active hotkey bars now. and last time I added one I went from 12 to 13. Perhaps the client needs to be allocating more memory space for they active hotkeys? The addition of the extra 10 bars is recent, perhaps some more tweaking is needed.

    I will try patching back to chaos, see if I can replicate it there. I hadn't noticed it there but I also have only recently added the extra bars while also testing the new blight client (it might not specifically be the blight client). Both characters seeing issues have 14 bars active currently. Also, it seems that once the bars are added to the UI layout and you relog and then repopulate them, or replace the def file with a backup, they don't wipe themselves again until you decide to add another active bar to your layout.

    My dragon which only uses 6 active bars at once hasn't seen the issue at all.

    Edit: While still logged in with the toon experiencing this issue, I decided to copy the hotkeys.def file back from a backup. Then I edited one key and saved it, and it wiped the file out again, back to a nearly empty file that only contains 1 edited key in it. Gonna have to relog I guess, then copy the backup file back in.

    Didn't have any issues until I went above 12 total bars. And/or, a hotkey file size of 71.5kb. About 22 hotkeys are equip macros for all the various crafts, each one equips 20 to 22 pieces of gear/jwl/sack/tool. So they are a pretty big part of my hotkeys.def and why it is likely larger than a typical one might be.

    Edit 2: Just patched back to Chaos, and was able to replicate the problem. Just add one more bar to they hotkey layout, then edited one key and boom, my hotkeys.def is wiped again save for most of the info for 1 test key with a simple say command.

    Entire contents of the hotkeys.def is this
    UI_HOTKEY
    {
    int Bank = 0
    int Button = -1


    UI_ACTION
    {
    }


    UI_HOTKEY
    {
    int Bank = 19
    int Button = -1


    UI_ACTION
    {
    }
    }
    }

    which isn't everything, the button was a text command
    /say test hotkey button
    which works even tho it isn't saved right in the hotkeys.def file. Going to patch back up to the current blight client.
    Last edited by Guaran; July 13th, 2013 at 07:14 PM.

  15. #35

    Default Re: Blight 384.109

    Did another test, just tried editing a hotkey on bar 19 and adding the text command, by just arrowing an existing bar to 19, then editing the key and saving, this does not wipe out the file. Only adding a bar seems to do so. Editing all 20 bars worth by toggling around doesn't trigger the problem.

  16. #36

    Default Re: Blight 384.108

    One thing I've noticed about mouse cursor position after steering (or before steering).

    It seems the default location to show the mouse position is upper left corner (mouse coords 0,0) (after using Mouse Look (Toggle) key.

    If the Camera Option (Use Mouse Left/Right buttons to Mouse/Free look is unchecked), you have no choice. When I use Mouse Look (toggle) key to look around, when I toggle it back, the cursor just moves to coordinates 0,0 (always).

    However, if I check the Camera Option box, then its a different set of rules.

    If I never use left or right mouse click to steer, cursor moves to 0,0 (after using Mouse Look Toggle key).

    Else

    If I previously used the left or right mouse button to steer at least one time, then whenever I use mouse freelook toggle key, it remembers that position. Any future usage of mouse look (toggle) key will make cursor appear at last position of last right or left mouse steering click.

    At the very least, should at least set the default to center of screen instead of 0,0

    So to clarify:
    When you use the left or right mouse button to steer, that position is remembered.

    If a position is remembered, then whenever you use Mouse Look (toggle) key, the cursor returns to the last known clicked position.

    If no previous position was remembered, then cursor location goes to 0,0

    If no easy fix to this, I suggest at least using center of screen position as default, instead of 0,0 (upper left corner).

    But its still kind of funky. Some days, when I use Mouse Look (toggle) key it remembers exactly where it was before. That part I haven't figured out yet.


    Any way to make it remember the last mouse position where the mouse look (toggle) key was clicked? That'd be even better.
    Last edited by Cegaiel; July 15th, 2013 at 10:48 AM.
    Death points are temporary, Glory is forever!
    Need game info? Try Istaria Reference or Istaria Lexica Wiki

  17. #37

    Default Re: Blight 384.108

    Quote Originally Posted by Dracillion View Post
    Is the new selection process also applicable to right clicking?
    No. I just looked at the code for this. Right-click popup selection uses whatever the mouseover selection code decided to highlight (even if you can't see the highlight). The right-click selection should use the same selection technique as the left-click selection though -- you have the same selection intent, just using a different button.


    Quote Originally Posted by Cegaiel
    One thing I've noticed about mouse cursor position after steering (or before steering).
    ...
    I just committed a change that should eliminate the corner cases that you and others been having trouble with. It'll probably be a few days before it shows up on Blight, if they're accepted.
    Last edited by Steelclaw; July 15th, 2013 at 12:06 PM. Reason: Stupid auto-format!
    You can get anything you want in life -- just make a lot of noise and bite the right people.

  18. #38

    Default Re: Blight 384.109

    Quote Originally Posted by Guaran View Post
    Did another test, just tried editing a hotkey on bar 19 and adding the text command, by just arrowing an existing bar to 19, then editing the key and saving, this does not wipe out the file. Only adding a bar seems to do so. Editing all 20 bars worth by toggling around doesn't trigger the problem.
    Thanks for the testing! I was able to replicate the weird behavior and refine a test case.
    1. Delete the uihotkeys.def file and uipersonal.def file for the character under test.
    2. Log in, wait for character to load.
    3. Create a 2nd hotkey bar and bump it to a different bank (other than 1).
    4. Drop something on the 2nd hotkey bar.
    5. Log out.
    6. Log in.
    7. Hotkeys are toast.

    Examination of the bad uihotkeys.def file produced at step 5 shows that it is malformed. Off to the code!
    You can get anything you want in life -- just make a lot of noise and bite the right people.

  19. #39

    Default Re: Blight 384.109

    Quote Originally Posted by Steelclaw View Post
    Off to the code!
    And squashed. This bug was introduced in a commit toward the end of May. I just committed a fix to the source repo.

    Replicating the bug is easier than above. Just right click anywhere on the hotkey bar that isn't a hotkey button, then modify/add/delete/whatever a hotkey. As soon as the modification is committed, your UIHotkeys.def file will be corrupted.

    To be fair, the activation path for this bug is pretty obscure (how often do you bring up a popup on a hotkey window by not right-clicking on a hotkey button, the modify hotkeys afterwards?), and the code path that causes the corruption is pretty convoluted. But... that's why dedicated testers are so important.

    Thanks again!
    You can get anything you want in life -- just make a lot of noise and bite the right people.

  20. #40

    Default Re: Blight 384.109

    Glad you fixed it so quickly.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •