OK first and formost for this to work the following MUST be set up.
An OPTION in the GRAPHIC settings to ALLOW the USER to SEE CUSTOM weapon COLOURS.
A Simple yes or no option, there DONE.
Then I belive it would take ONE person all of 12 hours to make a quick customization section <near the shipyards> to design and implement this.
The reason I belive it would be done so fast is BECAUSE ALL THE CODING IN THE GAME IS DONE, hell we had the base code to change all our own weapons, we just needed the other number's/commands to change different weapons.
This way those that WANT to see custom colours and have custom colours CAN.
Those that do not want to see these light shows do not have it forced upon them.
EVERYONE WINS
And if anyone can come up with ONE GOOD reason as to why this is unacceptable I will fly my ship into the nearest SUN.
Colour probolem SOLVED.
Edit sorry I hijacked someone elses thread, just got in and have been thinking on this most of the day.
I am all for that. I don't want to see the coloured weapons, but I am all for letting people change them if they want, just as long as I don't have to see it
No objections about that, but I doubt the Dev team have the inclination to do such a thing (although they said the game would be player driven, and developed around player suggestions)
I would like my ground avatar to replace my photon torpedo's so I can watch myself flying headfirst through space, and exploding in a huge meaty eruption against the side of my enemys hull.
You mean not allow a whiney minority to crucify something that actually has some limited amount of canon behind it AND allows for creater levels of customizability? Perish the thought. No, PowerHue MUST be crucified. It's the only way to take peoples attention away from more glaring issues of canon such as the way if you do a first contact in a deep space exploration mission, the policy is "We come in hostility, shoot to kill." Or the way you can never even attempt to talk your way out of a fight. It's just always "set phasers to murder" and "PEW PEW PEW! YOUR SHIP ASPLODE!"
I would like my ground avatar to replace my photon torpedo's so I can watch myself flying headfirst through space, and exploding in a huge meaty eruption against the side of my enemys hull.
You mean not allow a whiney minority to crucify something that actually has some limited amount of canon behind it AND allows for creater levels of customizability? Perish the thought. No, PowerHue MUST be crucified. It's the only way to take peoples attention away from more glaring issues of canon such as the way if you do a first contact in a deep space exploration mission, the policy is "We come in hostility, shoot to kill." Or the way you can never even attempt to talk your way out of a fight. It's just always "set phasers to murder" and "PEW PEW PEW! YOUR SHIP ASPLODE!"
Its set phasers to genocide.
It would be nice to have some non violent options in some missions. Even if it was a 30 option deep dialog tree that took some time I'd sign up for that.
Another massive assumption on how the original code was written
yes its a simple solution however it may be extremely difficult to implement under the curren archetecture
Consider that colours are probably handled server side which would make sense if you want everyone seeing the same colours to chage that to the client side is not a simple matter.
Another massive assumption on how the original code was written
yes its a simple solution however it may be extremely difficult to implement under the curren archetecture
Consider that colours are probably handled server side which would make sense if you want everyone seeing the same colours to chage that to the client side is not a simple matter.
If the colours are server side then everyone that used the /powerhue command was hacking the server.
This game USES the SAME engine as Champions online, and they can set there power colour so it shouldnt be too hard.
I would like my ground avatar to replace my photon torpedo's so I can watch myself flying headfirst through space, and exploding in a huge meaty eruption against the side of my enemys hull.
I really like this option. Not to be put in the game but maybe as an april fools day joke. the strain on the server would probably be a bit intense. Still funny.
OK first and formost for this to work the following MUST be set up.
An OPTION in the GRAPHIC settings to ALLOW the USER to SEE CUSTOM weapon COLOURS.
A Simple yes or no option, there DONE.
Then I belive it would take ONE person all of 12 hours to make a quick customization section <near the shipyards> to design and implement this.
The reason I belive it would be done so fast is BECAUSE ALL THE CODING IN THE GAME IS DONE, hell we had the base code to change all our own weapons, we just needed the other number's/commands to change different weapons.
This way those that WANT to see custom colours and have custom colours CAN.
Those that do not want to see these light shows do not have it forced upon them.
EVERYONE WINS
And if anyone can come up with ONE GOOD reason as to why this is unacceptable I will fly my ship into the nearest SUN.
Colour probolem SOLVED.
Edit sorry I hijacked someone elses thread, just got in and have been thinking on this most of the day.
Holy Cow. And there was me thinking they had resolved it already by saying no.
I suspect we will see colored lasers/phasers/photons/disruptors etc again (unfortinitly), but as DLC content. I think making that command available was a mitake, hence they removed it. I think it was ment for the DLC at a later date.
While I know that it will take much more than 12 hours to do, as the OP states. I am in favor of being able to weapon colors.
Last night I went into a fleet action, where almost every one enemy and friendly was using disruptors, I could not tell who was shooting at who. Everything was green, Federation and Gorn. One person had an single aqua color beam (not sure what it was) but tended to follow him because I knew I could regonize the ship quickly. While weapon colors were live, it was very easy to see friendlies by the rainbow of colors, while the enemy had a single color. Any one that knew how to change the colors, would quickly change disruptors from green to some other color to identify it as friendly fire Versus something from the enemy.
While I can see many arguments to why complete color adjustment need to be avoided. would it be possible to at least make weapon colors different when fired from federation ship that when fired from a klingon ship. Example: disruptors in a Kilingon ship would be green, but on a fed ship they would be red. Phasers on a fed ship would be orange but on a Kingon ship would be yellow, etc. Simply so we can tell side.
I cannot think of a single battle in Star Trek that both sides used the same color weapons. Even when ships where captured and used against thier former side, the beams were different colors.
You know, for one i know that this can't be done because this sort of thing is hard coded in the game engine, and they can't add anything else to it. But at least we could get someone like coderanger or rekhan to come in threads like this and say that it is impossible to implement this.
This idea won't work for the same reason that they cannot make some people see shield rings and some dont.
to all the people saying "this cant be done" "they cant add" etc, we could do it 2 days ago, it can be done, nothing needs to be worked on, the facilities are already there which is why i was firing pink phasers a few days ago
OK first and formost for this to work the following MUST be set up.
An OPTION in the GRAPHIC settings to ALLOW the USER to SEE CUSTOM weapon COLOURS.
A Simple yes or no option, there DONE.
Then I belive it would take ONE person all of 12 hours to make a quick customization section <near the shipyards> to design and implement this.
The reason I belive it would be done so fast is BECAUSE ALL THE CODING IN THE GAME IS DONE, hell we had the base code to change all our own weapons, we just needed the other number's/commands to change different weapons.
This way those that WANT to see custom colours and have custom colours CAN.
Those that do not want to see these light shows do not have it forced upon them.
EVERYONE WINS
And if anyone can come up with ONE GOOD reason as to why this is unacceptable I will fly my ship into the nearest SUN.
Colour probolem SOLVED.
Edit sorry I hijacked someone elses thread, just got in and have been thinking on this most of the day.
+1 from me.
However, being slightly negative, I wouldn't want this prioritised over other "more critical" bugs.
Other than that, yeah, I think this is probably the only solution that will keep everyone happy.
12 hours of coding? I'd rather they spent it on something that's for everyone, it's not like they've nothing else to work on. Sorry!
/facepalm.
12 hours to make the UI, the coding is already there, THATS why we could chance all our beams/disruptors to blue/pink/purple or whatever.
How long would it take to create an NPC in the shipyards that you talk to and say I would like my beams to be blue, my cannons pink my torps Yellow and disruptors to be red.
Considering the CODING is already done < the /powerhue is used to set the colour of phasers ect, it wouldnt take much effort and if they did the idea <or close to it> it would show us that they listen to EVERYONE and try to find common ground for all.
I'm not saying do it now, or next week, but deffinatly in the near future.
Still yet to see a valid reason for a NO <so I aint flying into a sun yet>
After all Cryptic is all about the CUSTOMIZATION.
/facepalm.
12 hours to make the UI, the coding is already there, THATS why we could chance all our beams/disruptors to blue/pink/purple or whatever.
If it was really just a UI for an existing feature then a few hours for development and testing would be fine, easily done in a day - but it could be more complicated than that. Code to actually support this as a configurable option isn't there yet, it's not just a GUI to the existing /powerhue function, what you are asking for is bit more than that.
For example, we know the colour is sent by the server so a default colour would have have to exist for the weapon in the client for those who have the option turned off, and it would have to be able to identify the weapon type firing in order to look it up. This /may/ or /may not/ fit it with how things work already (the required info might be passed back, but in a way that's inconvenient to access by the rendering engine, and so might need code modifications beyond just the UI).
So, ultimately we don't really know how much work is involved to make it a configurable option, only someone familiar with the codebase could possibly call that.
Personally your idea is a sound one I think though. I am surprised this issue is a big deal for anyone really, I can see both sides of the argument, but the option you describe would seem to solve the problem.
I think it's something to park for now and to look at when it comes time for "raids" (as that's where I can see it would have the most practical use).
If it was really just a UI for an existing feature then a few hours for development and testing would be fine, easily done in a day - but it could be more complicated than that. Code to actually support this as a configurable option isn't there yet, it's not just a GUI to the existing /powerhue function, what you are asking for is bit more than that.
For example, we know the colour is sent by the server so a default colour would have have to exist for the weapon in the client for those who have the option turned off, and it would have to be able to identify the weapon type firing in order to look it up. This /may/ or /may not/ fit it with how things work already (the required info might be passed back, but in a way that's inconvenient to access by the rendering engine, and so might need code modifications beyond just the UI).
So, ultimately we don't really know how much work is involved to make it a configurable option, only someone familiar with the codebase could possibly call that.
Personally your idea is a sound one I think though. I am surprised this issue is a big deal for anyone really, I can see both sides of the argument, but the option you describe would seem to solve the problem.
I think it's something to park for now and to look at when it comes time for "raids" (as that's where I can see it would have the most practical use).
I would guess that you do not work with computers in a live evironment. while the code may only take a couple minutes, there are hours tied up in updating documentation, peer reviews, change testing, regression testing, Then beta evaluation then finally shipping with package and controls.
Outside the 12 hour change, the OP's argument has merit
I would guess that you do not work with computers in a live evironment. while the code may only take a couple minutes, there are hours tied up in updating documentation, peer reviews, change testing, regression testing, Then beta evaluation then finally shipping with package and controls.
Outside the 12 hour change, the OP's argument has merit
Well I'm a Software Engineer so yeah I do. 8)
I estimated a few hours (e.g. ~ a day) for a change /if/ all that was being asked for a sliderbar / radio button interface to an existing API, and that included testing. If it was just that (and the entire point of my post was to point out it's likely to more complicated that assumed) then I stand by that.
A change of that nature (which is different to what we are actually asking for here, and which we all seem to agree sounds fine if people really care about enough) shouldn't take a couple of paired programers, half a dozen unit tests, regression testing, formal documentation outside of code/wiki or tie up QA for more than half a day ... Vogon-style processes for even simple changes are something I associate almost exclusively with the enterprise Java universe, or the financial sector.
Comments
I would like my ground avatar to replace my photon torpedo's so I can watch myself flying headfirst through space, and exploding in a huge meaty eruption against the side of my enemys hull.
just LOL
8,9,10 happy now
Its set phasers to genocide.
It would be nice to have some non violent options in some missions. Even if it was a 30 option deep dialog tree that took some time I'd sign up for that.
I just had to point out....ROFL....this game is FAR from that design philosphy.
yes its a simple solution however it may be extremely difficult to implement under the curren archetecture
Consider that colours are probably handled server side which would make sense if you want everyone seeing the same colours to chage that to the client side is not a simple matter.
If the colours are server side then everyone that used the /powerhue command was hacking the server.
This game USES the SAME engine as Champions online, and they can set there power colour so it shouldnt be too hard.
oh and bump back to the top.
I really like this option. Not to be put in the game but maybe as an april fools day joke. the strain on the server would probably be a bit intense. Still funny.
Holy Cow. And there was me thinking they had resolved it already by saying no.
Note, this is what i think. I may be wrong.
Last night I went into a fleet action, where almost every one enemy and friendly was using disruptors, I could not tell who was shooting at who. Everything was green, Federation and Gorn. One person had an single aqua color beam (not sure what it was) but tended to follow him because I knew I could regonize the ship quickly. While weapon colors were live, it was very easy to see friendlies by the rainbow of colors, while the enemy had a single color. Any one that knew how to change the colors, would quickly change disruptors from green to some other color to identify it as friendly fire Versus something from the enemy.
While I can see many arguments to why complete color adjustment need to be avoided. would it be possible to at least make weapon colors different when fired from federation ship that when fired from a klingon ship. Example: disruptors in a Kilingon ship would be green, but on a fed ship they would be red. Phasers on a fed ship would be orange but on a Kingon ship would be yellow, etc. Simply so we can tell side.
I cannot think of a single battle in Star Trek that both sides used the same color weapons. Even when ships where captured and used against thier former side, the beams were different colors.
Well if the option will only take twelve hours to code why don't you visit memory alpha and make the mod yourself?
This idea won't work for the same reason that they cannot make some people see shield rings and some dont.
+1 from me.
However, being slightly negative, I wouldn't want this prioritised over other "more critical" bugs.
Other than that, yeah, I think this is probably the only solution that will keep everyone happy.
/facepalm.
12 hours to make the UI, the coding is already there, THATS why we could chance all our beams/disruptors to blue/pink/purple or whatever.
How long would it take to create an NPC in the shipyards that you talk to and say I would like my beams to be blue, my cannons pink my torps Yellow and disruptors to be red.
Considering the CODING is already done < the /powerhue is used to set the colour of phasers ect, it wouldnt take much effort and if they did the idea <or close to it> it would show us that they listen to EVERYONE and try to find common ground for all.
I'm not saying do it now, or next week, but deffinatly in the near future.
Still yet to see a valid reason for a NO <so I aint flying into a sun yet>
After all Cryptic is all about the CUSTOMIZATION.
If it was really just a UI for an existing feature then a few hours for development and testing would be fine, easily done in a day - but it could be more complicated than that. Code to actually support this as a configurable option isn't there yet, it's not just a GUI to the existing /powerhue function, what you are asking for is bit more than that.
For example, we know the colour is sent by the server so a default colour would have have to exist for the weapon in the client for those who have the option turned off, and it would have to be able to identify the weapon type firing in order to look it up. This /may/ or /may not/ fit it with how things work already (the required info might be passed back, but in a way that's inconvenient to access by the rendering engine, and so might need code modifications beyond just the UI).
So, ultimately we don't really know how much work is involved to make it a configurable option, only someone familiar with the codebase could possibly call that.
Personally your idea is a sound one I think though. I am surprised this issue is a big deal for anyone really, I can see both sides of the argument, but the option you describe would seem to solve the problem.
I think it's something to park for now and to look at when it comes time for "raids" (as that's where I can see it would have the most practical use).
Outside the 12 hour change, the OP's argument has merit
Well I'm a Software Engineer so yeah I do. 8)
I estimated a few hours (e.g. ~ a day) for a change /if/ all that was being asked for a sliderbar / radio button interface to an existing API, and that included testing. If it was just that (and the entire point of my post was to point out it's likely to more complicated that assumed) then I stand by that.
A change of that nature (which is different to what we are actually asking for here, and which we all seem to agree sounds fine if people really care about enough) shouldn't take a couple of paired programers, half a dozen unit tests, regression testing, formal documentation outside of code/wiki or tie up QA for more than half a day ... Vogon-style processes for even simple changes are something I associate almost exclusively with the enterprise Java universe, or the financial sector.