EVE Information Portal

exactly THAT way of thinking is the root cause of all problems, i could climb up the walls reading this!!! being a dev myself and having filed and processed many bugs myself i can tell you, that just because a bug cannot be reproduced easily or the steps to reproduce it are not visible, the bug hasnt vanished - the bug is still there. often the reason for the bug appearing are side conditions, a different environment,... sure, but there is no excuse for lazy programming, bad QA or false management decisions. many problems would not be built in first place if the programmer started thinking and tried to handle all conditions (instead of "i assume things are like this when my method starts").

let me assure you, if you put more time into thorough development, maybe employ practices like extreme programming, the rate you spam bugs will drop rapidly - it is hard to think of all possible conditions yourself, i know. just because a bug does not appear for 1 month doesnt mean it is not there. sometimes you do not need reproducible steps to find a bug, plain hard thinking might also help.

if people put their own time in to do QA for you - then you should honor that and not dismiss those reports as non-reproducible, unimportant or something else.

maybe you should also think about fixing existing bugs first before implementing new functionality. for weeks i am seeing really annoying bugs in tranquility like the following:
- assets window freezes after some time
- warp tunnel effect sometimes not there
- speed display freezes sometimes
- no drag and drop between quickbar and chat

...not to speak of some simple UI changes which would improve usabilty very much.

when you file a new bug, first you are told to delete the cache and all settings (understandable, but feels a bit like first level support handling your case - "you plugged the power chord in?!"). while deleting the cache is no problem, deleting your settings every time you file a bug is unacceptable, because many settings are not saved server-side and cannot be imported/exported client-side (among them being bookmark structuring, quickbar, shortcuts, ...). how about rolling out some consistency checking for the settings? enable users to edit settings manually?

sorry for the hard criticism, i do believe there has been much valuable work done and improvements implemented behind the scenes. you just need to work on those things.

i was very happy when i read weeks ago top management wanted to listen more to the community and put quality first. sadly it seems that people in development und people responsible for the release decision have not yet heard or felt those changes. i just hope there will be a change in the future...

Glad that it helped at least 1 person

and btw...im having some minor graphical glitchs since the patch, not gamebreaking but anoying, one is the warp tunnel, either non existant or heading an extremelly wrong direction (70 degree from where im heading as example)...the other is a small black box in the top center of the screen when i open the game (its like 1x12mm), this last one is maybe my graphic card acting up and about to die or something, but the timing was strange, i mean...this appeared after a patch and also it goes away as soon as i close the game...and...the black box is not all the time black...sometimes it copy the background color in the game...and i play in windowed mode, if i move the game window the black box stays in the exact same position...

I can also not spin my ships. Before CQ was released I had disabled load station environment aka I had a static screen. My fiance who didn't turn this off on her laptop can spin her ships now.

Does it maybe have to do with if load station environment was disabled prior to updating to CQ only?

I'm beginning to see just how little the opinions of testers mean to them.

The opinions of players investing their own time in helping us improve the game means the world to us. The issue here is that for specific client side bugs, in this case the window location code, erroneous behaviour can be tough to verify/reproduce. This is because you guys have us outnumbered and are running on more diverse hardware. As CCP Gangleri detailed earlier in this thread the window placement bug, was reproducible in house but in a more benign form, thus we decided to go ahead with the patch.
A fix for this issue is coming next tuesday, and a refactoring of the window position code is coming in the winter release.

And what about other fixes?

Client update not downloading. What the word on that?

I don't give #$%& if my ship spins or not, I want to get back to playing game.

Worked perfect thanks

Normally I don't post on these, but this one is REALLY ANNOYING!

The window conflict issue noted previously is exactly what is happening -

When I docked, I happened to notice that the station spin environment was loaded BEFORE the overview / selection window was removed & position saved. This causes the station services window to be 'forced' ? to the lower right area - subsequently messing up the entire in-space overview window areas.

It was rather interesting for about 1 second to see the in-space overview windows in my station environment. lol

Hopefully this will help in debugging that dratted bug!

Does your "Test Environment" include offsite testing? Connecting through an ISP and having to handshake through multiple connections to get to your server produces far different timings than connecting through your local connection in house.

As well as the annoying window bug, I still have a bug from 4+ patches ago (reported muliple times already by multiple people).

Loading ammo into missile bays (grouped) gives an error popup for each launcher (some crap about not being able to fit a float value into each of the launchers).

Should I expect this to be fixed in the next 6 months? It was reported months ago now, in multiple patch threads.. It seems feedback is being ignored for a bug that should be a simple fix.