Droid Engineer Archive
Thread: Gorantoth's Centralized Droid Issues (10/17/04)Updated
TheRealTK421 wrote:
I just tested (twice) this tonight on Live and was unable to make it happen.
Drashk wrote:
General Issues
6. EXPLOIT: By telling a droid to stay, running approximately 800m (zone boundry?) away and calling another droid, you can effectively call all your droids at once. You can also call multiple instances of the same droid as well.
I tapped someone to watch for me and on both occassions that I tried to pull my Probot, the Merchant BLL I had out barking was auto-stored the moment I hit the Call command.
At least for me, I couldn't make this happen. I'd say it might be dead. Anyone else still seeing this?
OckVofad wrote:
Merchant Barker module - The vehicle/pet/droid autostore bug hurts the effectiveness of this module. The droid autostores itself randomly (sometimes this can be avoided if grouped)
More on this is available on a great thread in the Merchant forum (don't have link to hand, sorry).
To summarise: If you leave your Barker Droid doing its thing and head off into the wild blue yonder, you're fine... unless and until you have your vehicle autostore on you. This will immediately autostore your droid as well. Don't know if this is limited to Barker Droids or more general. Grouping with your droid does not help with this -- though of course you know immediately that your droid has stored because you get the 'Group has disbanded' message!
Please push for a fix on this (as the Merchants are doing, though it's not really in our area) ASAP. Barker droids would be fantastic if they worked properly...
...And were allowed to say more than 128 characters -- though that's a different issue!!!
Ethalsar wrote:
To summarise: If you leave your Barker Droid doing its thing and head off into the wild blue yonder, you're fine... unless and until you have your vehicle autostore on you. This will immediately autostore your droid as well. Don't know if this is limited to Barker Droids or more general. Grouping with your droid does not help with this -- though of course you know immediately that your droid has stored because you get the 'Group has disbanded' message!
Please push for a fix on this (as the Merchants are doing, though it's not really in our area) ASAP. Barker droids would be fantastic if they worked properly...
This is actually a boundry issue and deals with pets, vehicles, and droids. This could also be related to the problem with items in your inventory disappearing, that was running wild around August of last year, and stat shifting PSG and droid armor. When you cross certain boundries, you basicly lose sync for a short amount of time, which could be the cause of auto-storing. This is one of those issues that pops up because of the sheer size of the game and one or two hotfixes will never take care of it. The DEVs have been working on this issue, though it could be considered a clump of related issues, with each publish.
At least this is from what I know of the issue.
Message Edited by Gorantoth on 07-20-2004 09:30 PM
Test 2:
Straker_Atrella wrote:
Try it pulling the SAME droid a second time.
Pulling the same droid didn't fly for me. I only go the Store option. I was able to call a 2nd, different droid though.
/bow
Respectfully,
I agree with this in a big way. I have 4 accounts ALL using as many harvesters as I can run and I can't keep up now. If I had to have top-rate resources for every single sub-component, I'd give this profession up. I already spend WAY more time than I want trying to find those "leet" resources.
Straker_Atrella wrote:
-General Items and wish list.Everything else you have there looks good, but1 thing I do have issue with. You hint at it in a couple of places.You seem to want experimentation on subcomponants to have an effect on the final droid. I am not sure that the DE community agrees on this as a whole. If they do, I wonder if they really realize what they are asking for.
Already DE's use more resources and more parts in general then other crafters, some quality and some not quality. By saying that "experimentation should matter" on everything, you are also saying that resource quality should matter on everything as well. Think about that. I run 18 Harvestors constantly, harvesting "good" stuff, as well as "filler" stuff. If I need "good" stuff for everything that I make, I could never keep up. "Good" stuff simply does not spawn all that often.
Now if we could continue to use current "crap" resources and keep our Droids the same, yet use "better" resources, then make them better that is different. However, by just "making experimentation matter" on subcomponants, in general, droids will get worse.
The issue is even bigger then that. If every Motive system, EGM, EMM, Manipulator Arm assembly now requires premium resources, the cost to make a droid will go up. We will be forced to charge more. Customers simply will not understand why they are paying double for a droid then they did before, and with "experimentation mattering," the Droid may even be worse.
While I totally agree that if Experimentation DOESN'T matter, just take it out. I don't agree that it should matter on everything. I have enough stuff to harvest already.
I guess this thread isn't really the place to debate this, I just don't agree that the community as a whole wants this, and it should be on our wish list.
Except /detonatedroid, and harvest.
AFAIK.
On Personality ship, what are the use of those?
Droids almost never speek.
Even in combat, an LE will say somethine about once per hour.
Droids should speek more.
Message Edited by Gavvot on 07-28-2004 12:32 PM
Maybe it's screwed with special commands like Trap, Detonate and Harvest? I can't imagine a reason the Trap command couldn't be added to befriend...
So, with 10 droid befriend, you'll max your xp pretty fast.
Even if it only give half the xp of what you'll get by trapping yourself.
Well, I think it's why.
I maxed out my trapping XP, I just want my friend to be able to use it when a giant spat come charging down on him. The solution is not to elimate the commands, just eliminate the exploit. Another instance of lazy programming.