Droid Engineer Archive

---

Sylow wrote:

The stimpack dispenser looks like a nice feature to me. From searching the forums i found out:

- an advanced R3 can be built to hold a max. of aprox. 500 stimpacks

- it can be made to deliver 1 stimpack per second

Those things sound fine with me but some questions i wasn't able to really answer:

- What happens if i only put in 5 instead of 6 modules? Will only the capacity suffer, or will also the delivery speed be lower?

Capacity and speed will both suffer. However, this is one of the few modules that being a 12pt DE actually helps.

- Does the quality of the dispenser determine how much healing is done per stimpack? If not, does it depend on the quality of the stimpack? (I know it's only Stim A, but one each second, that can add up quickly...)

No, the healing properties are completly dependent on the pack that is inserted. Stim-A's pretty much cap out at healing 100 points of damage though.

- If the quality of the stimpack is important, can you still see what stimpacks are currently loaded? And, can you unload old stimpacks if you want to insert better ones? (Or do you have to use them up? Anyways, this doesn't seem like a problem, just curious...)

The highest power stimpack will be used first. So if you've found higher quality stims, you can use them first before reverting back to the "poor ones."

- Is it possible to load the droid with complete factory crates? In a very old post i found a "one stimpack a time" statement. That sounds tough. I know i can persuade a medic to make me 500 stim a in a factory, but i guess persuading the medic to individually load those 500 into my droid is quite another thing.

No, each stim must be loaded individually. However, the "capacity" is actually charges of stims, not "packs." Example: a 7 charge Stim-A will take up 7 capacity in the module. Therefore, the higher number of charges per stim, the fewer stims the medic has to load individually.

- a stimpack a has something like 8 or 10 uses. Do you get that many uses out of a stimpack or do you get 1 use per stimpack? (Or could it be that the capacity of 500 is in fact 500 uses? So loading the droid with something like 50 stimpacks gives you 500 uses?)

I believe you should be satisfied with the answer from the previous question in order to answer this one. If not, just say so.

- Is there an acceptable way to use the droid in combat? The 'request stimpack' on the radial menu doesn't cut it. (Something like "/tellpet stim" would be fine for me, this can be put on a button and can be hit whenever healing is needed. If necessary even in a macro so one buttonpress would request 10 stimpacks within the next 10 seconds...)

Actually, yes. You can use the command: /requestStimpack WITH THE DRIOD TARGETED and it will dispense a stimpack. This is easily macro-able as long as you can get your droid targeted.

Thanks for the info already

---

---

As a helpful reminder: When we were told about the development of this module the key premise would be that it is not intended to replace a medic, but to suppliment them. Which is why there is the limitation on the stim-A.

---

The limitation to Stim A is not that much of a problem. The uncomfortable loading (i still don't think that it's easy to persuade a medic to load 50 or more Stimpacks into the droid individually...) and the unpractical use in combat spoil it, though.

[It's really a pain... just like with the harvester droid, why can't the thing simply be switched "on" and harvest the corpses around? That's probably another issue of DE, the droids are no more intelligent than the average piece of rock... ]

---

Sylow wrote:

The limitation to Stim A is not that much of a problem. The uncomfortable loading (*snip*) and the unpractical use in combat spoil it, though.

---

How can the limitation of stim-A'snot be a problem if theyare impractical to use in combat?

---

[It's really a pain... just like with the harvester droid, why can't the thing simply be switched "on" and harvest the corpses around? That's probably another issue of DE, the droids are no more intelligent than the average piece of rock... ]

---

Part of the problem in this case is that the droid cannot tell what corpse it has already harvested from on it's own.Or if a corpsehas been killed by a player that haspermission to harvest from (meaning was notkilled by another player which is not in the same group).That is just one of those decisions that the player has to make.

---

JavelinCatcher wrote:

How can the limitation of stim-A'snot be a problem if theyare impractical to use in combat?

---

It's a simple mathematical thing. I currently use Stimpack Bs with healing capacity around 300 points but i can only use one every few seconds. (And then i am more busy with healing than with fighting...) If the droid can dispense one Stimpack A every second, his healing capacities are on par or probably superior to mine and would at the same time allow me to concentrate on the fight instead of healing.

My reference to "impractical in combat" was not about the Stim A, it was about the Stim-Droid.It seems like requesting stimpacks can not be automatised and put on a button. I also don't manage to switch between my target, issue commands, switch to the droid, request a stimpack and switch to the target again in less than a second. Considering how long the radial menu sometimes takes to come up and how hard it is to get when you're just swarmed by enemies, i dare to doubt that i'd manage to come even close to the "1 stim per second" if i concentrate on nothing else than requesting stims. Would there be a simple thing like "/tellpet stimpack" and the droid would heal you, it would work without problems, as long as there's no easy way to get the stims, it's actual value is close to zero. (The way it's currently described the droid can only help when the fight is over. But in that situation i can as well sit down and wait for half a minute and heal by myself...)

Another droid i won't buy because it lacks practical use.

---

Part of the problem in this case is that the droid cannot tell what corpse it has already harvested from on it's own.Or if a corpsehas been killed by a player that haspermission to harvest from (meaning was notkilled by another player which is not in the same group).That is just one of those decisions that the player has to make.

---

I dare to say, this is not really a point. The routine would actually be very easy, anfirst loop would run and create an array containing all corpses within 50 meters of the player. (Selecting targets like this is implemented in the commands for the macros, just the array is not possible.) The functions to tell if a corpse can be harvested or if there's no allowance to harvest or if it already was harvested already exists. (As far as i observe, each corpse at all times has those status flags. The only small problem is, those flags are updating slowly, so the droid might at some times have an invalid target. More about that later.) There's no functional difference between a player sending the request and a function sending it. Only those corpses where harvesting is actually possible will be added to the array. If the resulting list is empty, the loop puts itself to sleep for 10 seconds, then starts again. If the array contains elements, the loop calls another loop. That loop just goes through the list of selected targets. If gives the harvesting command to the droid and waits till the droid is finished with harvesting. It's no big problem to implement this, the routine just needs one failsafe: It can be that a corpse times out while the droid is just going there or the status in harvesting status came a bit too late and the first loop still took it as harvestable while it in fact is already harvested. That would result in the droid not reporting a successful harvest. The easiest fix is, if a droid doesn't report a successful harvest5 seconds after the harvest command is issued, the next target will be selected. As soon as the routine reaches the end of the array-list, the first loop is called again, creating a new list of corpses to harvest.

The functionality is rather easy to implement. Considering how many harvest-requests i send right after a fight when i harvest by hand (and how often i select a corpse which already was harvested) i dare to say, the automatical routine would not lead tosignificant increase in bandwidth useage or processor time on the servers. (The auto-harvest routine could be put into the client software where it would do it's job very well... the information about the corpses around it needs anyways...)

The only thing which would require some attention and testing would be, how much detection range does the droid really need? Too little and players dislike it. But the more range you give it, the higher the timeout for a harvest must be. (I gave 5 seconds there... could be that with 50 meters you actually need more already.) But that's something to be tested in game, i can't say which timer a player accepts for maximum time when the droid is waiting and pondering what target to take next. [Of course, the harvest routine could also be made to report back when not being able to work, so the timeout would only be there in case of a strange failure which nobody is able to forsee... it's simply the question, how much effort the Dev's are ready to put into this. I personally think, every little bit would help....]

Message Edited by Sylow on 02-24-2005 02:41 PM

---

Sylow wrote:

---

JavelinCatcher wrote:

How can the limitation of stim-A'snot be a problem if theyare impractical to use in combat?

---

It's a simple mathematical thing. I currently use Stimpack Bs with healing capacity around 300 points but i can only use one every few seconds. (And then i am more busy with healing than with fighting...) If the droid can dispense one Stimpack A every second, his healing capacities are on par or probably superior to mine and would at the same time allow me to concentrate on the fight instead of healing.

My reference to "impractical in combat" was not about the Stim A, it was about the Stim-Droid.It seems like requesting stimpacks can not be automatised and put on a button. I also don't manage to switch between my target, issue commands, switch to the droid, request a stimpack and switch to the target again in less than a second. Considering how long the radial menu sometimes takes to come up and how hard it is to get when you're just swarmed by enemies, i dare to doubt that i'd manage to come even close to the "1 stim per second" if i concentrate on nothing else than requesting stims. Would there be a simple thing like "/tellpet stimpack" and the droid would heal you, it would work without problems, as long as there's no easy way to get the stims, it's actual value is close to zero. (The way it's currently described the droid can only help when the fight is over. But in that situation i can as well sit down and wait for half a minute and heal by myself...)

Another droid i won't buy because it lacks practical use.

You obviously didn't read my last answer to your questions above.

There is a /requestStimpack command. Granted, it only works if you have the droid targeted. So, lets assume a hypothetical situation: You own a R3 with 6 stimpack dispenser modules named "Bud".

The macro would simply be:

/target Bud; /requestStimpack; /ui action cycleTargetOutward;

Not only would this request a stimpack from your droid, Bud, but would also return you to your nearest attacking target.

---

Part of the problem in this case is that the droid cannot tell what corpse it has already harvested from on it's own.Or if a corpsehas been killed by a player that haspermission to harvest from (meaning was notkilled by another player which is not in the same group).That is just one of those decisions that the player has to make.

---

I dare to say, this is not really a point. The routine would actually be very easy, anfirst loop would run and create an array containing all corpses within 50 meters of the player. (Selecting targets like this is implemented in the commands for the macros, just the array is not possible.) The functions to tell if a corpse can be harvested or if there's no allowance to harvest or if it already was harvested already exists. (As far as i observe, each corpse at all times has those status flags. The only small problem is, those flags are updating slowly, so the droid might at some times have an invalid target. More about that later.) There's no functional difference between a player sending the request and a function sending it. Only those corpses where harvesting is actually possible will be added to the array. If the resulting list is empty, the loop puts itself to sleep for 10 seconds, then starts again. If the array contains elements, the loop calls another loop. That loop just goes through the list of selected targets. If gives the harvesting command to the droid and waits till the droid is finished with harvesting. It's no big problem to implement this, the routine just needs one failsafe: It can be that a corpse times out while the droid is just going there or the status in harvesting status came a bit too late and the first loop still took it as harvestable while it in fact is already harvested. That would result in the droid not reporting a successful harvest. The easiest fix is, if a droid doesn't report a successful harvest5 seconds after the harvest command is issued, the next target will be selected. As soon as the routine reaches the end of the array-list, the first loop is called again, creating a new list of corpses to harvest.

The functionality is rather easy to implement. Considering how many harvest-requests i send right after a fight when i harvest by hand (and how often i select a corpse which already was harvested) i dare to say, the automatical routine would not lead tosignificant increase in bandwidth useage or processor time on the servers. (The auto-harvest routine could be put into the client software where it would do it's job very well... the information about the corpses around it needs anyways...)

The only thing which would require some attention and testing would be, how much detection range does the droid really need? Too little and players dislike it. But the more range you give it, the higher the timeout for a harvest must be. (I gave 5 seconds there... could be that with 50 meters you actually need more already.) But that's something to be tested in game, i can't say which timer a player accepts for maximum time when the droid is waiting and pondering what target to take next. [Of course, the harvest routine could also be made to report back when not being able to work, so the timeout would only be there in case of a strange failure which nobody is able to forsee... it's simply the question, how much effort the Dev's are ready to put into this. I personally think, every little bit would help....]

Message Edited by Sylow on 02-24-2005 02:41 PM

---

You'll also notice that you can re-tell it to go harvest a corpse you've already harvested(not that you'll get anything). The only indication that you've already harvested a corpse or that you cannot harvest at all is that nothing happens. Your method depends on several things:

1. The flags for harvesting are available to the droid (which they may not be since you are able to tell it to attempt to reharvest a corpse). They may be in fact only be given to the player in which the player needs to supply the droid with which corpses need to be harvested.


2. A high memory requirement. (What about the size of the object you are adding to your array?)


3. A timeout procedure. Even here you admit that it might actually be faster for the human to decide which corpses to harvest.

This also speculates a lot about how the actual program is written, which we don't know. Give these guys some credit though. They're smart, really smart. If there was a simple way to do this, don't you think it would have been done when it was introduced back in publish 8?

---

There is a /requestStimpack command. Granted, it only works if you have the droid targeted. So, lets assume a hypothetical situation: You own a R3 with 6 stimpack dispenser modules named "Bud".

The macro would simply be:

/target Bud; /requestStimpack; /ui action cycleTargetOutward;

Not only would this request a stimpack from your droid, Bud, but would also return you to your nearest attacking target.

---

Oki, my fault... i read that at that moment and then forgot about it again as it's not cutting it for me. I am carbineer and my choice of target is quite often not what's directly whacking at me but whatever i just consider most important to do. For a melee-class, this macro probably would be helpful. Thanks, anyways. For other people your suggestion can work perfect, your pointis very valid andi'll try to keep it in mind.

---

The flags for harvesting are available to the droid (which they may not be since you are able to tell it to attempt to reharvest a corpse). They may be in fact only be given to the player in which the player needs to supply the droid with which corpses need to be harvested.

---

Not really an issue. The information is available to the player, which means it's available to the client, thus the information can also be available to the droid. I really don't think they'll store that info in the player-object, makes sense to have the flag in the corpse-object.

---

A high memory requirement. (What about the size of the object you are adding to your array?)

---

Minimal. Each corpse is one object, so the list would be an array of object identifiers. Assume that the programmers for some reasons went a bit overboard and assigned6 byte per object number (281474976710656 objects, anybody? ), you'll end up with 300 bytes for 50 corpses, which is nothing. Now show me when you see 50 corpses around. And if that's still too scary, the routine can be limited... after getting 10 or 15 corpses into the array, it stops and starts processing them. The droid will take a while to go to all of them, the small delay for rearranging the array won't be an issue.

---

A timeout procedure. Even here you admit that it might actually be faster for the human to decide which corpses to harvest.

---

I admit that the droid might seem "clueless" for the watcher occasionally, if you use that simple procedure. You could do a lot of improvements on the whole thing, e.g. when you assign a corpse for harvesting, you every second do another "harvestability" check while the droid is going there. If for some reasons the status of the corpse changes from harvestable to unharvestable, the droid will move to the next item in the list. Would increase traffic a bit. No issue for the player, but on the servers you might notice it if many players are using those droids. Would have to be checked, the frequence for those "on way checks" could perhaps use some manual finetuning when the thing is active.

---

This also speculates a lot about how the actual program is written, which we don't know. Give these guys some credit though. They're smart, really smart. If there was a simple way to do this, don't you think it would have been done when it was introduced back in publish 8?

---

I give the current Dev's some credit. What i saw the last months is pretty good. Though, i also have to say, there were many great changes and bugfixes done lately, which were on the slate for a very long time. Some of those fixes now seem to have been done "easily and on the fly". This massive increase of improvements comes now, some time after more people were hired for SWG. Thus my personal impression is that for a long time the SWG-staff was short of the necessary manpower which again means that "luxury"-features had to stand back as "more dire" fixes and changes had to be made. And that functionality of a harvesting droid falls into the "luxury" department, it is working, it can be used, just requires some attention and action of the player. While outshined in the intelligence-department by a small puppy and thus falling far behind of what i expect of a droid in SW, it does the job, so the urge to fix it seems low.

Anyways, lately there seems be be more Devs working and some seem to have time for beautiful little upgrades... this would be one which i really would like to see.

Message Edited by Sylow on 02-24-2005 05:22 PM

---

Lukos wrote:

[...]

Try this and it'll become your favorite droid Maybe should i mention againthere is an exploit with these droids, so Gorantoths updates his list of bugs.

---