These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
Previous page12
 

Old Neocom Option
Author
Previous Topic Next Topic
HELLBOUNDMAN
Aliastra
Gallente Federation
#21 - 2012-01-27 17:01:19 UTC
Mag's wrote:
If it was customisable as it's meant to be, this wouldn't be an issue. But as always CCP shoot themselves in the foot and give us some half baked hash job. I thought they had learnt from the past and moved on from this.



LOLOLOLOL

it's funny cause it's true
Callidus Dux
School of Applied Knowledge
Caldari State
#22 - 2012-01-28 17:42:24 UTC  |  Edited by: Callidus Dux
OK CCP.. end this farce. You had your fun with annoying your customers with crap that they have never asked for.
Time to roll back the old NeoCom and burn the stupid names of our well known ammunition and modules.

Did your still learned nothing from your last: "CCP's game - CCP's will" diplomacy?
Did you ever heard something about: "The customer is always right?"

Your changes, how noble and usefull you thought they might be, are absolute not helpful. We all know, that your first tryings where never intent to be endproducts! Do as you have promised in your first Dev Blog. Make this BETA a real BETA! Make this first try detachable in the ESC-Menue. This will bring you and your customer time to give useful suggestions to improve your original idea and will lead to a smoother crossover to the new. You have the old codes for the beloved NeoCom.. use it again and use the time to improve your new NeoWhatEver.
Vizvayu Koga
#23 - 2012-01-28 20:10:14 UTC
I think the best solution is to suggest improvements to the new neocom. Having legacy code working on a zombie state is not a good idea, and having two different neocoms to maintain is even worst. So, better let devs know what you think is wrong and how to fix it and hope everybody else's like your ideas ;)
HELLBOUNDMAN
Aliastra
Gallente Federation
#24 - 2012-01-28 21:05:29 UTC
Vizvayu Koga wrote:
I think the best solution is to suggest improvements to the new neocom. Having legacy code working on a zombie state is not a good idea, and having two different neocoms to maintain is even worst. So, better let devs know what you think is wrong and how to fix it and hope everybody else's like your ideas ;)



The don't need to work on the old neocom... All they need to do is allow us to put it back to how it was, and then leave it the hell alone cause it worked just fine for us.
Vizvayu Koga
#25 - 2012-01-28 22:15:45 UTC
HELLBOUNDMAN wrote:
Vizvayu Koga wrote:
I think the best solution is to suggest improvements to the new neocom. Having legacy code working on a zombie state is not a good idea, and having two different neocoms to maintain is even worst. So, better let devs know what you think is wrong and how to fix it and hope everybody else's like your ideas ;)



The don't need to work on the old neocom... All they need to do is allow us to put it back to how it was, and then leave it the hell alone cause it worked just fine for us.


Yes I understand what you want but unfortunately that's not how software development works. If they keep the old code working, they have to maintain it and keep it in mind for every future development. It's not as easy as leave and forget.
Previous page12