Droid Engineer Archive
Thread: DE Goodies for Publish 6
You mean 'have only one droid active at a time', perhaps?
Fortunately, it sounds as though that particular problem will be less of one when they begin allowing us to call our droids anywhere outdoors.
None of us know what the code looks like and how many different facets each line of code touches upon. What if the reason that we lost the ability to build certain droids a few months back was due to trying to increase the length of the customization or make it stick?What may appear to be an 'easy fix' may not be as easy as some would think. Thats part of what I've been repeating here lately. Everything takes time to fix and nothing can happen overnight. Be happy that we are getting some issues addressed, which is not the same as saying be complacent that they are happening.
As to the Cluster Module issue that is being brought up....
The problem with this one is the fact that many people did use the Cluster bug in non-cluster designed droids without the realization that there was anything wrong with it. Look how many people have come to the forums, found out that it is a known bug and then walked away saying 'Ohhh...' That is another of the issues that I am trying to find out from TH, I'm guessing that the droids will still be in existence, much like the 3k HAM Probots are still kicking.
Drashk wrote:
None of us know what the code looks like and how many different facets each line of code touches upon. What if the reason that we lost the ability to build certain droids a few months back was due to trying to increase the length of the customization or make it stick?What may appear to be an 'easy fix' may not be as easy as some would think. Thats part of what I've been repeating here lately. Everything takes time to fix and nothing can happen overnight. Be happy that we are getting some issues addressed, which is not the same as saying be complacent that they are happening.
That had to do with getting pre-patch R droids (and a few others) to hold their colouring.
I have to say that i am quite pleased. Aside from naming isssus (droids named R2L9 instead of artoo-elnine) and not being named at all, how many of our origonal bugs still exist.
Keep up the good work Drashk. I can imagine how much pestering of Thunder you had to do to get clearance to post what you did
It never has changed. The cap has always been 5 droids in the datapad. Sounds to me like the person had his droid out when you were trying to make the trade.
Malitevv wrote:
can non-DE's have more than on droid in there data pad now? when did that change? The last customer I tried to transfer a droid to told me he had to destroy the one droid in his data pad before he could have it.
Did they change that?
Drashk wrote:
None of us know what the code looks like and how many different facets each line of code touches upon. What if the reason that we lost the ability to build certain droids a few months back was due to trying to increase the length of the customization or make it stick?What may appear to be an 'easy fix' may not be as easy as some would think. Thats part of what I've been repeating here lately. Everything takes time to fix and nothing can happen overnight. Be happy that we are getting some issues addressed, which is not the same as saying be complacent that they are happening.
As to the Cluster Module issue that is being brought up....
The problem with this one is the fact that many people did use the Cluster bug in non-cluster designed droids without the realization that there was anything wrong with it. Look how many people have come to the forums, found out that it is a known bug and then walked away saying 'Ohhh...' That is another of the issues that I am trying to find out from TH, I'm guessing that the droids will still be in existence, much like the 3k HAM Probots are still kicking.
Drashk, you keep bringing up the GDMSC in non-GDMSC slots as a bug. Have you gotten any word from TH or the devs about this specifically? Yet again, it seems that they had an opportunity to address/fix this and they didn't. I'm starting to think that it might not be a bug at all. In fact, it might be that the placing of clusters in clusters is a bug caused by the fact that they were supposed to be put in normal slots, but not normal slots in other clusters. Until we have a definitive answer from the devs on this, you, of all people, shouldn't be refering to this as a bug.
Right now, I don´t know how to feel. I´m overwhelmed and underwhelmed at the same time.
Underwhelmed, because only 2 of the 5 issues were important for ME (everybody´s got his own pet issues).
Underwhelmed, because my favourite bugfix - being able to name biped droids - isn´t in it.
Overwhelmed, because I never thought that they would add module sockets to BLLs soon.
Thanks very much for the info, Drashk, it must have been horrible not being able to talk about it.
GnomeAd wrote:
Drashk, you keep bringing up the GDMSC in non-GDMSC slots as a bug. Have you gotten any word from TH or the devs about this specifically? Yet again, it seems that they had an opportunity to address/fix this and they didn't. I'm starting to think that it might not be a bug at all. In fact, it might be that the placing of clusters in clusters is a bug caused by the fact that they were supposed to be put in normal slots, but not normal slots in other clusters. Until we have a definitive answer from the devs on this, you, of all people, shouldn't be refering to this as a bug.
It is very clearly a bug, and we don't need confirmation from Thunderheart to know that. All you have to do is compare the existing droidschematics and think it through.
If a cluster is supposed to be legal in a non-cluster slot, then the R4-ADV is a better droid than the R3-ADV. The R4-ADV has three normal slots while the R3-ADV only has two cluster slots. Which means that if it is legal to put clusters in non-cluster slots, the R4-ADV can carry 9 modules while the R3-ADV can only carry 6.
Clear enough for you now? Or shall I do the same comparison with a MSE droid and an R3?
GnomeAd wrote:
Drashk, you keep bringing up the GDMSC in non-GDMSC slots as a bug. Have you gotten any word from TH or the devs about this specifically? Yet again, it seems that they had an opportunity to address/fix this and they didn't. I'm starting to think that it might not be a bug at all. In fact, it might be that the placing of clusters in clusters is a bug caused by the fact that they were supposed to be put in normal slots, but not normal slots in other clusters. Until we have a definitive answer from the devs on this, you, of all people, shouldn't be refering to this as a bug.
I would like this issue to be settled once and for all. I'm really tired of hearing about it. Drashk, can you talk to TH and educate him on the difference between cluster stacking and clusters in "regular" module slots and get the definitive answer?
Pls don't quote his previous response as your only reply. The way the question was posed, its unclear if he is being asked about stacked clusters being loaded into general slots or un-stacked clusters being loaded into general slots.
Its interesting to me, but not conclusive, that they have only addressed cluster stacking with these patch notes.
Whether the bug was introduced during design or coding may be a real question, but in my mind there is NO question that cluster modules simply should not fit into general sockets.