Droid Engineer Archive
Thread: Using cluster mods in non-cluster slots
IMJennifer wrote:
The reason I don't use clusters where "they don't belong" is I'm concerned that someday the devs will notice and fix this 'bug' - leaving me with a lot of rightfully irate customers on my hands.
I don't understand why people think that making droidsthat usethese current 'exploits' or 'bugs' will possibly have those same droids break or stop working properlywhen the module issues are fixed. From what I'd imagine on how droid properties are stored, we don't need to worry about having these droids 'broken' in the future.
The reason why I think so is simply because of how I would code it in order to save memory. If you possibly need to store thousands of these stupid droid data files it would make sense to just have some integers which state the medical, item, and data storage ratings and also some flags saying what type of are the other capabilities of the droid (repair, type of crafting station). It simply wouldn't make sense to store a copy of the data file for each module that was put into the droid (along with the mechanism quality, item effectiveness, etc) since it would just be a waste of memory. I'd figure that there really would be no way to not make a grandfather clause for these droids, so there is really no reason to worry if you stack modules or put cluster modules in 'improper spots.'
Not that I advocate stacking modules and such, just saying why it probably won't matter in the future if you do it now.
> youMy opinions:
Yes it's an exploit -- that's why there are "Cluster slots" and "Module slots" -- two different slots and two different items...hmmmm, not rocket science to do the math on that one 
As for it breaking droids when they finally fix it, very unlikely. A droid with MR 110, SR 15 and DR 15 is just that, the final product doesn't care how it got to the final results, it just knows that those are the final results. It would be much too complex for the deed/droid to store information about the individual modules installed into it (and we've already seen how badly their DB sucks as is.
So, in summary -- Yes, I think it is most obviously an "exploit" but no, I don't have even the slightest belief that it will be retroactive when they fix it.
This debate is pointless. The only way to resolve the issue (are clustersworkingin standard sockets by design, or by mistake) is for a developer to make a post somewhere telling us so.
Neximus wrote:
(Why would anyone buy an R3 over an R4 other than looks, if they can get it loaded up with the same stuff?
Because I charge a crapload for R4s when the customer wants a lot in them 
to make it worth it to spend 10k extra on an r3. The only thing I don't touch is MSE's and Treadwells, I don't put any medical in them, and would never think about a socket cluster.
The cluster evens the field for lesser DEs to make worthwhile droids. It takes 3-2-0-4 before you can start filling out normal orders of droids and not have to explain why you can't satisfy the customer.
AdamSteele wrote:
The only way to resolve the issue (are clustersworkingin standard sockets by design, or by mistake) is for a developer to make a post somewhere telling us so.
My kingdom for a Dev post (in the DE forums)!
Of course it's not working as intended!
If it were why on earth would there be cluster-slots and module-slots?
It's quite obvious that you're not supposed to be able to multi-stack clusters indefinite in a droid with one module-slot.
Is it an exploit? ... Well, considering that an exploit is to use a bug in-game I'd say yes.
Does anyone care?
Not many. Not even the development team cares so why should we?