EVE Search - Problem convincing BHs that this is a bug....

All Channels

Test Server Feedback

Problem convincing BHs that this is a bug....

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] :: one page
Author	Thread Statistics \| Show CCP posts - 2 post(s)
Robdon	Posted - 2007.12.12 19:42:00 - [1] Hi, Can anyone recomend how I can convince the bug hunters that this is a bug, and NOT 'game design'. Surely this is a bug, and nothing to do with game design... I would say the cursor sticking in 'pan' mode and you being unable to get it out of that mode and having to shutdown the client and restart it .... is a BUG. Bug Report: Right click & moving the cursor around gets ¦stuck¦ and will not release. // This is actually how it is supposed to work. When you move you mouse outside the eve window, eve will no longer get the "mouse up" event when you release the button. Therefor when the mouse reenters the window, it still thinks the right mouse button is pressed - BH Berstuc Update: Errr, you gotta be joking me. This is a classic UI bug that gets missed quite easily in GUI applications. It certainly is NOT how the game is supposed to ¦work¦.... Althought its nothing ground breaking, its annoying as hell once the cursor is stuck. Shrug...If you dont think its a bug, then fine, just let your app have a 2nd rate UI. // This is how the code in eve is written. This means "by design". If you feel that this should be changed CCP provides a forum section for players to input suggestions about changes. I would urge you to consider posting there. BH ShadowSavior // Reproduction Steps: 1) Make sure the client is in window mode, and is smaller than your windows desktop size. 2) Right click the background in eve, and start dragging the cursor. This makes the view scroll. 3) Keep the right button down and move the cursor off the eve window. 4) Release the right mouse button, while off the eve client window. 5) Move the mouse back over the eve client (without pressing any mouse button) 6) The cursor now behaves as if you have the right button pressed all the time, and the view scrolls around.
Sioluk Minmatar Oser's Shipping and Manufacturing Inc. Endless Horizon	Posted - 2007.12.12 19:46:00 - [2] that's the nature of running in windowed mode. when you release the buttons while the mouse is off the screen the game does not recognize that you released the button, therefore you should only have to right click and release once within the window to correct this issue on your screen and would NOT require a client restart. [-Sio-] Oser's Shipping and Manufacturing Inc., CEO Endless Horizon
Katana Seiko Gallente	Posted - 2007.12.12 20:05:00 - [3] Edited by: Katana Seiko on 12/12/2007 20:05:41 Yeap... The game just gets the "button press" event that instructs it to switch to an other modus. If it doesn't get the "button release", it doesn't break completely if you give it the "button press" a second time (since it already IS in that modus and doesn't expect the "button press" event. However, when it finally gets it's "button release" event, it goes back to the previous state. Think of that: If the game would check with every frame if one of your 102 keyboard and 5 mouse buttons is pressed, you can't play the game anymore! for that, the code usually looks like that: JUMP to :start :button REPEAT do_something_else() UNTIL #Release_Event RETURN :start REPEAT do_something() IF #Press_Event JUMP to :button UNTIL #App_Close_Event Okay, it's pseudocode, but who cares - you get the idea. --- This is your Captain speaking. Thank you for flying with our spaceline. Please remain seated until the ship has completely burned out. Thank you.
Robdon	Posted - 2007.12.12 20:51:00 - [4] Hi, Yes I realise that. I dont think you have to monitor for the keypress all the time, though. When the cursor leaves / enters a window, there are windows messages that can be intercepted and used to control this sort of thing, as I do it quite often in coding. I must admit I dont know Python etc, but I'm sure that it must be able to interupt the windows message queue. When the mouse leave message is sent to the window, then they could cancel any loop that involves a mouse down action.... Rob.
Robdon	Posted - 2007.12.12 20:54:00 - [5] oh, and BTW... They have it working for Left Click, so I dont see why it cant be done for Right Click???? Rob.
FireLord Minmatar Octavian Vanguard RAZOR Alliance	Posted - 2007.12.12 22:30:00 - [6] an easy fix for this, and in my opinion a better way of handling the right mouse button view system is make the right mouse button and move the cursor event a toggle until the right mouse button is pressed again instead of relying on keeping the right mouse button pressed. this would make it easier to keep your view on something too. just a thought.
Liang Nuren The Avalon Foundation Knights Of Syndicate	Posted - 2007.12.12 22:34:00 - [7] Is it fixed if you right click again?? -Liang -- Retired forum *****. Plz tell me to STFU. Yarr?
Victor Ivanov Minmatar The Fated Interstellar Alcohol Conglomerate	Posted - 2007.12.12 23:02:00 - [8] Some people are missing the point. I've had this bug numerous times as well. It's not fixable through a simple right click. Camera goes into pan mode and the entire background of space distorts slightly. No way to get out of it, generally. Although a session change has fixed it for me once or twice. ----------------------
Aronis Contar Caldari Independent Manufacturers	Posted - 2007.12.13 01:18:00 - [9] This issue could be remedied simply by using SetCapture(HWND); and ReleaseCapture(); which cause the window identified by the handle to continue receiving all mouse events even when the mouse leaves said window. (read up on it here: http://msdn2.microsoft.com/en-us/library/ms674721.aspx ). No idea why they aren't using it. Ciao, Aronis!
Gner Dechast Gallente Flashman Services	Posted - 2007.12.13 01:37:00 - [10] Edited by: Gner Dechast on 13/12/2007 01:39:30 Edited by: Gner Dechast on 13/12/2007 01:39:14 My memory isn't what it used to be... isn't there also an event sent to the application when cursor leaves the program window? I seem to think there would be. A handler for that message could potentially send button up messages to the app itself to reset mouse button states. Ofcourse that would mean that a window being dragged would drop there and that if your mouse re-enters the app window, you would have to release and repress the button again, but it would beat getting a state stuck. ...just throwing random thoughts here, might be that I didn't even understand OP correctly EDIT: Aronis seems to be in the generally same ball park - I had this thread open in it's own tab for so long that I didn't see that ^^
Zeph Solaris NYIT Gangstaz SMASH Alliance	Posted - 2007.12.13 02:25:00 - [11] Quote: // This is how the code in eve is written. This means "by design". If you feel that this should be changed CCP provides a forum section for players to input suggestions about changes. I would urge you to consider posting there. BH ShadowSavior // I'm sorry, but that's the worst thing I've ever heard. By saying that if the code is written that way it is supposed to be that way by design, then you have no bugs whatsoever. That boot.ini deletion, that would have been by design. POS's down for the count after the Trinity update, that's by design since that's what the code does. Same thing for rate of fire running down to zero......
Ghaelsto Kakram	Posted - 2007.12.13 14:01:00 - [12] That persons name actually is BH Berstuck.
Matthew Caldari BloodStar Technologies	Posted - 2007.12.13 14:30:00 - [13] Originally by: Aronis Contar This issue could be remedied simply by using SetCapture(HWND); and ReleaseCapture(); which cause the window identified by the handle to continue receiving all mouse events even when the mouse leaves said window. (read up on it here: http://msdn2.microsoft.com/en-us/library/ms674721.aspx ). No idea why they aren't using it. Ciao, Aronis! Of course, one of the main reasons why you use windowed mode is because you have other windows you'd like to interact with. Eve stealing full mouse control, or responding to clicks I was trying to issue to another application's window would really suck, and render windowed mode pointless. Originally by: Victor Ivanov It's not fixable through a simple right click. Camera goes into pan mode and the entire background of space distorts slightly. No way to get out of it, generally. Although a session change has fixed it for me once or twice. This is the key bit that needs adding to the BR, and is what makes it a bug. If returning the cursor to the eve window and right-clicking solved the issue, then the BH's response is completely correct, it's simply not getting the "button up" event because that event was not issued to the eve application, but to whatever other application (or windows desktop) the mouse had moved onto. The fact that 2 "button down" events in a row appears to put it into a broken state is a bug, and something that a windowed application should be able to handle. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Shereza	Posted - 2007.12.13 20:46:00 - [14] On the subject of bugs, so far as I know a bug is only a bug when a section of code, either by itself or when in interaction with specific data and/or other pieces of code, malfunctions. If it is working exactly as coded and is working poorly then it is not a bug, it is poor code, period. Example, in college I set up a routine to modify the super shotgun in Quake 2. I wanted to give it a random number of rounds fired with each shot just for a lark so I set up a random number generation, did a for loop to control the number of firings, and went about my business. The code worked and worked quite well doing everything it needed to. One small problem. After reviewing the code not only had I messed up the code (the counter would have exceeded the upper boundary of the cutoff for the loop) but the random number wasn't even being taken into account. Instead of the code firing off at max every time it was called it was somehow managing to loop a random number of times within the set boundaries. Despite the code working exactly as intended I had a bug. Years later while working on an Air Force project due to my complete lack of understanding with some aspects of how the code I was using worked I had a bad case of GIGO (Garbage In Garbage Out) with a data mining application. The fact that the program had a decided tendency to spout out garbage instead of the useful information that, so far as I knew, it should have been putting out wasn't a bug, it was, due to my ignorance, poor coding. So yeah, if it was coded in a ****-poor fashion (sentry drones, logistics drones, etc.) but is working as it's coded then it's not a bug, it's just bad code. If EVE's code is hanging onto mouse clicks only when they happen inside the game window and not when they occur outside then it doesn't seem to be a bug if the code used is only supposed to do that. Of course this would also be symptomatic of a couple other areas of the game where the makers apparently put the least possible effort into it.
Aronis Contar Caldari Independent Manufacturers	Posted - 2007.12.13 21:18:00 - [15] Originally by: Matthew Of course, one of the main reasons why you use windowed mode is because you have other windows you'd like to interact with. Eve stealing full mouse control, or responding to clicks I was trying to issue to another application's window would really suck, and render windowed mode pointless. Dude... trust me a bit that I'm not talking out of my butt here :P The "standard" procedure for handling persistant mouse input to any window is to capture the mouse input in the WM_xBUTTONDOWN event, react to it in WM_MOUSEMOVE, and release it again in WM_xBUTTONUP. As long as no mouse button is held down, you can do whatever you want in and out of the window. If you click your button and hold it down, all mouse events are captured in the window where you started. Here a code snippet from a recent program I wrote (a volume renderer): Quote: // this is inside the window procedure case WM_LBUTTONDOWN: case WM_MBUTTONDOWN: case WM_RBUTTONDOWN: SetCapture(hWnd); break; case WM_LBUTTONUP: case WM_MBUTTONUP: case WM_RBUTTONUP: ReleaseCapture(); break; case WM_MOUSEMOVE: if (GetCapture() == hWnd) { GetCursorPos(&mpos); if ((wParam & MK_LBUTTON)) // lots of blah } break; If you click the left mouse button in my app's window, and keep it down, you can move the camera around as much as you want, even when you move out of it. As soon as you release the mouse button (no matter if inside my window or not), the mouse is released again. Ciao, Aronis!

CCP Explorer	Posted - 2007.12.14 22:51:00 - [16] I'll talk to our Senior UI Developer after the weekend and get his opinion on if this is a bug or not. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games

Matthew Caldari BloodStar Technologies	Posted - 2007.12.14 23:31:00 - [17] Originally by: Aronis Contar If you click the left mouse button in my app's window, and keep it down, you can move the camera around as much as you want, even when you move out of it. As soon as you release the mouse button (no matter if inside my window or not), the mouse is released again. Fair enough, I stand corrected. That would indeed be a nice way of doing it. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Chruker	Posted - 2007.12.15 05:37:00 - [18] Despite following the reproduction steps I can't replicate this. I my case when the mouse is moved back over the EVE window, the view continues the pan around with the mouse movements. However any additional mouse presses (either left or right key) makes the view snap back to normal. Originally by: Victor Ivanov It's not fixable through a simple right click. Camera goes into pan mode and the entire background of space distorts slightly. No way to get out of it, generally. Although a session change has fixed it for me once or twice. Not sure what is meant with 'pan mode'. I've found it easier to just grab a small video clip of the issue, if I feel it could be difficult to understand. ----- http://games.chruker.dk/eve_online ----- Top wishes: - No daily downtime - Faster training on sisi - Speedup IGB table rendering
Minmatar Citizen 4521577	Posted - 2007.12.15 09:08:00 - [19] Originally by: Zeph Solaris Quote: // This is how the code in eve is written. This means "by design". If you feel that this should be changed CCP provides a forum section for players to input suggestions about changes. I would urge you to consider posting there. BH ShadowSavior // I'm sorry, but that's the worst thing I've ever heard. By saying that if the code is written that way it is supposed to be that way by design, then you have no bugs whatsoever. That boot.ini deletion, that would have been by design. POS's down for the count after the Trinity update, that's by design since that's what the code does. Same thing for rate of fire running down to zero...... You don't file bugs, do you? :)
PhamNuwen Caldari Bungee Jumper	Posted - 2007.12.15 10:03:00 - [20] Originally by: Zeph Solaris Quote: // This is how the code in eve is written. This means "by design". If you feel that this should be changed CCP provides a forum section for players to input suggestions about changes. I would urge you to consider posting there. BH ShadowSavior // I'm sorry, but that's the worst thing I've ever heard. By saying that if the code is written that way it is supposed to be that way by design, then you have no bugs whatsoever. That boot.ini deletion, that would have been by design. POS's down for the count after the Trinity update, that's by design since that's what the code does. Same thing for rate of fire running down to zero...... :) I hope the statment of "BH ShadowSavior" is not copyrighted - because I wish to use it also, if I deliver not working software ___ BH ShadowSavior: "This is how the code in eve is written. This means "by design". " Unkown: "It can't be wrong, it is calculated by a computer." ---
Qui Shon	Posted - 2007.12.15 12:52:00 - [21] Originally by: Victor Ivanov Some people are missing the point. I've had this bug numerous times as well. It's not fixable through a simple right click. Camera goes into pan mode and the entire background of space distorts slightly. No way to get out of it, generally. Although a session change has fixed it for me once or twice. If it's the same bug I've had a few times (dunno about any space distortions), when a single right click didn't work, clicking wildly with all buttons all over the place did after a bit. Maybe something like right/left/middle clicking overview or something.
Inspiration	Posted - 2007.12.15 18:29:00 - [22] Edited by: Inspiration on 15/12/2007 18:32:37 Window events are notorious for these kind of things and it occurs in web application development as well. One trick is to have a timer running that periodically checks where the mouse is according to windows or the browser. If it is outside the game window then just internally process it as you wish, be it as a mouse release or an undo of the action in progress. The problem you describe is caused by keeping an internal flag that says the right mouse button was pressed, but the event from windows that says, hey....its unpressed never arrives after leaving the EVE client window. Hence when you move back, EVE still thinks the right mouse button is pressed. In the earlier days of web application development you often saw 'stuck' pull down menu's and such (its a similar thing, not receiving an event), but these days timers are used to auto close menu's when they are no longer navigated. Most sites simply avoid the mess altogether by adopting other UI design principles (pull downs aren't the friendliest thing). Hope this input helps, sometimes you just have to 'work around' imperfect programming interfaces and event models.
Imhothar Xarodit Minmatar Wolverine Solutions Interstellar Alcohol Conglomerate	Posted - 2007.12.15 19:58:00 - [23] The fix is out there and it is called SetCapture() and ReleaseCapture(). Windows API functions that you can use when a mouse button was pressed to tell Windows that you want further events to be directed to your window. (Excluded are mouse pressed events on windows of other threads, which are always directed to the window the curser is located in). I have tested it right now to be 100% sure of what I write here ;) Simply put SetCapture(hWnd) in your button down handler and have the mouse move handler check if the selected mouse button is down, does all the magic. Don't forget ReleaseCapture() in the mouse up handler or other windows in your current thread won't receive mouse events anymore, but EVE only has one window so meh.
Brixer Dai Dai Hai	Posted - 2007.12.15 23:32:00 - [24] I agree on the SetCapture() windows API function to be used. However. It's easy to 'unstick' it.. Just press right button again and realease it.. This time inside your client. You don't have to shut down windows and start in safe mode to fix this problem..
Viper G	Posted - 2007.12.16 00:47:00 - [25] Yeah i have sent in petitions and they reply it's not a bug. for instance, sometimes i don't get engine thrust/trails from my ship, weather just flying around, or while in warp, so sometimes my engines are 'on' and other times my engines are 'off' but the ship fly's the same. It's simply a graphical bug and it looks silly. But again, it's not a bug, its a cool feature right? kinda like when your ship warps side ways, or upside down, or undocks sideways, all cool features.
Zeph Solaris NYIT Gangstaz SMASH Alliance	Posted - 2007.12.16 05:38:00 - [26] Originally by: Minmatar Citizen 4521577 Originally by: Zeph Solaris Quote: // This is how the code in eve is written. This means "by design". If you feel that this should be changed CCP provides a forum section for players to input suggestions about changes. I would urge you to consider posting there. BH ShadowSavior // I'm sorry, but that's the worst thing I've ever heard. By saying that if the code is written that way it is supposed to be that way by design, then you have no bugs whatsoever. That boot.ini deletion, that would have been by design. POS's down for the count after the Trinity update, that's by design since that's what the code does. Same thing for rate of fire running down to zero...... Last time I tried to file a bug, the bug filing system was broken. You don't file bugs, do you? :)
Undead Rogue	Posted - 2007.12.16 07:28:00 - [27] Yes it is a bug.
Inspiration	Posted - 2007.12.16 10:37:00 - [28] Originally by: Viper G Yeah i have sent in petitions and they reply it's not a bug. for instance, sometimes i don't get engine thrust/trails from my ship, weather just flying around, or while in warp, so sometimes my engines are 'on' and other times my engines are 'off' but the ship fly's the same. It's simply a graphical bug and it looks silly. But again, it's not a bug, its a cool feature right? kinda like when your ship warps side ways, or upside down, or undocks sideways, all cool features. GMs are not responsible for identifying and knowing all bugs. Overloading them with graphics abnormalities that they can do nothing about while you don't gain a lost item either will not help you nor them. But it will hurt everyone else waiting on their valid petitions getting answered.

CCP Explorer	Posted - 2007.12.17 22:13:00 - [29] Edited by: CCP Explorer on 17/12/2007 22:15:05 Originally by: Robdon Reproduction Steps: 1) Make sure the client is in window mode, and is smaller than your windows desktop size. 2) Right click the background in eve, and start dragging the cursor. This makes the view scroll. 3) Keep the right button down and move the cursor off the eve window. 4) Release the right mouse button, while off the eve client window. 5) Move the mouse back over the eve client (without pressing any mouse button) 6) The cursor now behaves as if you have the right button pressed all the time, and the view scrolls around. This is a bug. A defect will be created on this issue. What is supposed to happen is that you shouldn't be able to move the cursor outside the window with the mouse button pressed. Try with the left button to see what should happen. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games


Pages: [1] :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.