Droid Engineer Archive

Many have read the first two installments of this thread and many of you have not. The idea behind the creation of this thread was to give the developers a source of information that they could look upon for possible concepts that could be implemented into the game, that have been provided by the DE community. So far a number of people in the DE community, as well as a few non-Droid Engineers, have submitted feedback and have helped to shape the direction of this thread and its future versions. This is a work in progress and is open for discussion, however the only request is that if a debate starts, we try and provide new content in each point/counter-point and that the over all goal is to find a compromise to the items in question. Community feedback is a must in order for this project to keep moving onward. On that off chance that even one item in this list crosses the DEV teams agenda, the work and determination of those that have helped, and will help, to shape this thread have paid off.

This thread, for the most part, does not include current issues that are already listed in Gorantoth's Centralized Droid Issues threads. Many of those issues in section 2) of Gorantoth's list need to be addressed first before any of the suggestions here are even taken into consideration. Here are the previous incarnations of this thread. (Please let me have coded the links correctly)

<a href="http://forums.station.sony.com/swg/board/message?board.id=droid_engineer&message.id=35920" target="_blank">'Having a problem with your Droid?' 'No. No problem..Why?' </a>
<a href="http://forums.station.sony.com/swg/board/message?board.id=droid_engineer&message.id=37192" target="_blank">'Having a problem with your Droid?' 'No. No problem..Why?' Version 1.1</a>

Much has changed in this version from the last. I'm not going to list the changes since this thread is already long enough, so without further ado.

1) One of the biggest issues that currently have an extremely large impact on the Droid Engineering profession is the General Droid Module Socket. The General Droid Module Socket, also simply known as a Cluster Module, as I've seen it referred to before are currently 'broken' in three ways. (For those that don't know, a Cluster Module is a module that can be built with three other modules inside of it.) This issue is already included in Gorantoth's Centralized Droid Issues threads; however I want to stress the importance of fixing this issue to anyone that reads this thread, due to its destructive nature to the entire Droid Engineering Profession.

a) Cluster Modules can be used in any module slot on any droid. A few will argue that this is how it was intended to be, since it hasn't been fixed, but a Cluster Module was only intended to be placed in Cluster Module slot on the droids that are equipped with such a slot. Currently, a DE can place a Cluster Module with three different Level 6 Modules on an Advanced Probot and a crafting station; effectively make all other droid types pointless.

b) Directly related to item 1a), a cluster module can be placed inside another cluster module, during a crafting session, which means that you can have an finite number of cluster modules that are imbedded in each other, depending on how much patience a DE has. (I.E. Using the method of stacking modules. I place two Level 4 Storage Modules and any one crafting station in to Cluster Module 1. I then build Cluster Module 2 which contains two Level 4 Data Storage Modules and Cluster Module 1. Next, I build Cluster Module 3 which contains two Level 4 Medical Modules and Cluster Module 2. What I end up with is one module that has 1 crafting station, the equivalent of a level 6 Item Storage Module, a level 6 Data Storage Module, and a level 6 Medical Module. Many are extremely certain that this in not meant to be how the Cluster Modules where intended to be used, just like Data Modules were never intended to store missions or extra creatures, of which both issues were quickly fixed.)

c) Lastly, Cluster Modules have an effect on the end quality of a droids production, even though with the current HAM/Damage cap it is not easily perceived. Each and every module has a Mechanism Quality rating when it is built. This rating dictates how well the droid turns out in the final build of a droid. The same applies to a Cluster Module; however when a Cluster Module is built using high end resources and other installed modules are built with high end resources, the end Mechanism Quality comes out considerably higher than any other module's rating combined. If the HAM and damage cap, which was placed when Probots were nerfed in order to tone them down, were to be removed, a DE that used the stacked Cluster Modules, like in the above example, could produce droids that would be far superior to any other DE's creation, that did not use this Exploit. (By definition, stacking Cluster Modules is an Exploit since it was not meant to be used in this manner, similar to how data modules were not meant to hold extra pets.).

(I.E. In the above mentioned example, if all of the normal modules had a Mechanism Quality of 5 and each Cluster Module was experimented with Great Successes, Cluster Module 3 could, theoretically, end up with a rating of 30-50, when experimentation is increased to 10 blocks for Master DEs.)

The original thread suggested the complete removal of the cluster module, however a number of those in the community suggested that this item be removed and instead suggested fixing the Cluster Modules. If items a) & a) could be corrected, item c) would still need to be address, since the Cluster Modules Mechanical rating would still cause an overall effect on many droids.

2) Many DEs, and droid owners, have expressed a need to make Droids more useful by adding additional modules that a DE can add to each droid. I will list a few module concepts for consideration; some of which have been posted on other threads and a few of which are 'original' ideas. With the exception of the items e), f), and g) these module concept modules are standalone ideas and could be implemented by themselves.

a) Crafting Station Package - Currently, droid crafting stations do not have a function rating, like their Architect built counter parts. Either this was an oversight by the DEV team, or they were not intended to have a function rating. I will list a two part concept. The first part is to give all basic droid crafting stations a function rating that is on scale with a Private crafting station that has been made with out the optional parts installed; between -15 and +15. The second part of the proposal is for a new module type that would use the normal Droid crafting station and other optional parts, in order to prove the function rating and give it other options as well. I'll call this new module a Crafting Station Module Cluster. This module could only be installed in specific droid types, which I will expand upon in a separate area. This module could be added to the Droid Refinement Tree, since it could be considered a non-essential improvement. The Station cluster would have 1 required Droid Crafting station (any ) and 4 optional parts that can be installed, which can raise the overall function rating on the Droid installed crafting station, similar to a Private Crafting station. The optional parts that would be needed are 2 similar Micro Sensor Suites, 2 similar Control Units, 1 Droid Item Storage Module (any level), and 1 Droid Data Storage Module (any level). The Crafting station module cluster would gain an increased rating over the basic droid crafting station module and could integrate the two storage modules installed.

The integrated Item Storage Module would function similar to the input hopper function on a Private Crafting station, but on a smaller scale, due to the storage capacity is limited by the level of the Item Storage Module that is installed. Where this idea diverges from the Private Crafting station is the inclusion of the Data Storage Module. When ever a factory schematic is created, instead of the schematic going directly to the droid owner's datapad, the schematic would be stored in the Droids Data Storage Module instead. This would increase the usefulness of the Data Storage module a little bit. Both of the Storage modules could be still accessed in the normal manner from the droid's radial, but the droid storage could also be accessed through the appropriate crafting tool, just like the hopper on a Private station, with its optional parts installed. The Data and Item storage installed in a Crafting Station Package counts towards the maximum storage space allowed. (I.E If Level 6 Item and Data Storage was used then the droid would have the maximum Item and Data Storage possible.)

b) Entertainment Module - This module would function similar to the Medical version, but instead would affect an Entertainer's ability to heal Mind wounds in and out of the Cantina. This module could be added to the Droid Production Tree in the same level progression as the Medical module, with a 10% bonus being added to the cantina's effectiveness when a Droid with a Level 6 module is used. Entertainment Modules would also follow the same stacking progression defined above for Medical Modules.

c) Slicing Module - This module is a bit trickier to implement than the previous 2 modules, but I will include this one as well, for a concept idea. A droid with this module would assist a Smuggler when ever slicing weapons or armor, by granting the user a percentage based chance to picking the outcome of the slice. This module would be level based, with a Novice DE starting with a Level 1 Slicing Module and could be part of the Droid Construction Techniques Tree; following the same level progression as other level based modules. At level 1, the module would grant a Smuggler a 0 -10% chance of successfully choosing the out come of any slice made on weapons and armor. The percentage at each level is based on the quality of the module produced. A Level 6 Slicing module would allow for a 0 - 60% of success at choosing the outcome of a slice.

d) Droid Armor Modules (Revamped)) - The concept behind this idea is to include experimentation values on all droid armor, similar to the way Armorsmith armor is experimented on. Currently Droid Armor Modules have the same stats depending on the module's level. Allowing experimentation values to effect all Droid Armor Modules will reduce the 'cookie cutter droids' and allow for improvements to each droids armor rating. Level 5 and 6 Droid Armor Modules could even be made with Composite Armor Segments that contain Krayt Tissues and actually improve the armor rating even higher. To balance out this 'improved' droid armor, I would suggest placing a maximum armor rating on certain droids, such as the Probot, and increasing the resources needed to produce Level 3,4,5, & 6 Droid Armor Modules. Such changes would help to balance out a few different issues, if this concept was used.

e) Analysis Module - The Analysis Module would give Scouts and Miners the ability to find out information about a certain resource, without actually harvesting the resource. For Scout based professions, this module would allow a player to target a creature and command their droid, with this module installed, to scan the creature. The player would then be able to examine the creature an find out what type of resource could be harvested, what the stats are on the resource, and how long the resource has been present. This module would also benefit Bio-Engineers, by giving the BE information about the DNA that can be harvested from each creature. This data could then be stored in the droids Data Storage Module, to a Data Storage Disc - described in section 3), or transmitted to a Data Terminal, via a Communications Module, covered in section 3) and item h).

The Analysis Module's second benefit would be that it would allow a player the ability to ascertain the stats of any given resource in their direct vicinity. Similar to the function it would provide for the Scout, the Analysis module would list the stats of a chosen resource and the length of time that it has been present. It would not give the density of the resource, nor would it list resources that are not located in the spot that command was given.
Both functions would need a balancing mechanism such as a time limit between each command.

f) Holorecorder Module - The concept behind this module has a number of functions. First, it would give the player the ability to record holographic messages that could be stored on a droid, when a data storage module was installed, copied to a Data Storage Disk, or transmitted to another location, through the use of a Communications Module. This message would have a 1 time only playback, but could allow for the SWG community to create messages for each other to increase the overall Star Warsy feel. Holovids would open up new doors for RPers, as well as the average player, by allowing for a new form of messaging. With the Holorecorder Module one would be able to play and record Holovids that could be traded via disc, or transmitted through the use or a Communications Module, listed in item h).

The second function of this module would allow Novice Musicians and Dancers the ability to create Holovids of themselves performing. The concept here is that a Novice Musician or Dancer would gain a new droid command such as Record Performance, with a droid that was equipped with the Holoredorder Module. This droid would either be their own droid, or a droid that has been Befriended to them. The Entertainer would target the droid, issue the Record Performance command, and record a performance that could later be played back by anyone that has the appropriate droid, or Holosuite, listed in section3). This Holovid performance could offer healing, just like a live performance, but at 75% effectiveness to anyone that watches the holographic performance. This performance would be 1 time play and would open up a new market for the Elite Entertainers. Only a Novice Dancer, or Musician, would be able to create a functional Holovid by following the steps listed above. The Holorecorder would allow for up to 5 discs to be recorded at one time, but each disc would allow for multiple performances, depending on the quality of the disc. Holovids that are stored in the data storage module could only be accessed one time, to cut down on using the same performance over and over as a recording template. The Holo would be 1/3 of the actual player's size. This module would become accessible at Intermediate Droid Refinement.

g) Holoplayer Module - The Holoplayer Module would be the lite version of the Holorecorder. Available at Novice DE, the Holoplayer Module would allow a Novice DE the ability to make an inexpensive Holovid playing capable droid. It would allow all of the playback features of the Holorecorder, but would not be able to create Holovids. The Holoplayer Module could playback Holovids either stored in the Data Storage Module, if installed, or from a Data Storage Disc. The Holoplayer would allow for 1 Data Storage Disc to be inserted and stored, until the disc was ejected, via a radial command, or until all of the Holovids on the disc were used.

h) Communications module - This module would be used in conjunction with the Holorecorder/Holoplayer Modules and another module that is related to data. The Communications module would allow for Holovids to be sent via a 'live' stream, as in the case of a HoloNet communication, or a 'live' performance from an Entertainer. Data could be sent from the droid to another droid or a Data Terminal that has a communications module. When used in conjunction with the Holorecorder Module and installed in a Advanced DZ70 or Advanced Probot, a new function for the module combo is created, the Surveillance droid. The surveillance function would give players the ability to have a new perspective in the game, from that of their droid. When the Communication/Holorecorder combo is installed into an Advanced DZ70 or Advanced Probot the player would have the ability to remotely command either of these two droids by using another droid with the same features installed, or through the use of a Data Terminal. The commands that the player could remotely issue would be limited to Follow other, Stay, and Pan right/left. When the surveillance function is used, a new window is opened with a first-person POV from the droids perspective.

A few balance features that would need to be addressed would be the use of this function. Suggestions would be that when the surveillance function is activated, the droid, and/or the droid owner, earns a TEF, when used by a member of a faction. This would help to alleviate Faction Griefing. Another suggestion would anytime the droid is commanded to follow someone, remotely; the droid would earn a TEF against that player that was targeted. The Communications module would become available at Intermediate Droid Refinement.

3) This section deals with spin off ideas that were inspired during the creation of new module concepts.

a) Data Terminal (Revamped) - Currently, the Data Terminals, craft able by Architects, is nothing more than another piece of furniture. The revamped concept of the Data Terminal would turn it into an actual functioning item that could provide services like the name implies. A few of the possible uses have already been listed, such as a different form of data storage, such as Holovid storage or resource analysis data. Another function that the Data Terminal could provide is the ability to create text documents to be saved to either a Data Storage Disc, or onto the Data Terminal itself. Many throughout the game have commented on wanting a place that they could keep some kind of journal or other text document that could be saved somewhere else besides their E-mail. The template for the Data Terminal could be changed to allow of an optional component, the Communications Module, to allow information to be transmitted either from a droid, or another Data Terminal

b) Data Storage Disc - The Data Storage Disc would be a small version of a Datapad, but allow for a larger variety of data to be stored, such as a Holovid, or Text document. This item would be part of the Artisan Tree and would have a certain number of storage tracks that would be determined by the resources used and experimentation. This item would be useable in a Data Terminal or any droid that has a Holoplayer/recorder installed.

c) HoloNet Suite - The HoloNet Suite, craft able by a Master Architect, would be a stationary platform that would allow for all Holovid recording and playback. It would have the same functions as the Holorecorder, allowing for the creation of Holovids and the playing of Entertainers performances. When used in conjunction with the Communications Module, an optional installable component, the HoloNet Suite would even allow for 'live' transmissions between two parties. Instead of s 1/3 size playback, the HoloNet Suite would offer a life size version of the Holovid target.

4) The stacking of droid modules needs to be re-thought out and changed from its current system. A number of people have voiced that they like the current ability to stack modules, but see that there is a need to change the current linear system or to change the benefits of stacking. With the current stacking rules on all modules, 2 Level 4 Modules can produce the same results as a Level 6 Module. The following chart shops the relationship between the module level, module rating (based on projections of 10 Experimentation blocks) and module function rating.

Module Level Module Rating Medical Rating Items Stored Data Stored
1 1 - 3 55 1 20
2 3 - 5 65 2 40
3 5 - 7 75 4 70
4 7 - 9 85 6 110
5 9 - 11 100 8 125
6 11 - 13 110 10 150

This proposed change is that stacking be based upon the module rating and not the level of the modules used. This will take into account an overall increase on the emphasis given to experimentation. By changing the stacking formula to something along the lines of this - Highest Module rating + 1/2 (rounded up) Second Module = Overall Module rating - experimentation will impact the final product. Along with this change, the cap on each module could be changed slightly to add benefits for stacking higher level modules. Please note, with the proposed changes to the Armor Module, (listed below) Armor stacking should be removed due to its overpowering nature.

a) Medical Module Rating Stacking Benefit
13 - 15 10% Mind cost reduction
15 - 17 10% Usage time reduction
17 - 19 + 10 Medical Rating.

b) Item Storage Module Rating Stacking Benefit
13 - 15 +1 Item Storage
15 - 17 +1 Item Storage
17 - 19 +1 Item Storage

c) Data Storage Module - Due to the limited usefulness of Data Storage Modules, there are no suggestions at this time.

6) The next suggestion is pretty important to the entire profession and needs to be handled with the utmost care. The cap that was placed, when Probots were nerfed, needs to be removed. Right now, when ever a droid is built a Droid Engineer can only produce a 0.005 to .015% increase to HAM, even if he/she is using the very best resources available. This HAM increase appears to only effect the displayed information while in Deed form and in the datapad. For instance, I have an Advanced Probot that has 823 HAM, according to the datapad, but when I call the droid and look at its HAM bar (by selecting the droid and performing a mouse over on the HAM bar) it only reads as having 820 HAM. The combat damage values have a bit higher percentage increase, but even this percentage increase is lower than what is seen in other crafting professions. I suspect that even the damage increase follows suit with the HAM increase and only displays an increase, with out better performance.
The difficulty with removing the current cap is that we could see the return of the Pre-Nerf Probots, with their 3200 HAM and 200 damage. What I suggest is a change in the cap placement, so that experimentation actually makes a difference in droid construction. This item alone would make many Droid Engineers happy, until new content can be added. One of the largest complaints, besides new combat droids, is that each and every droid comes out looking virtually the same. If experimentation actually had a play in each droids construction, many DEs would be able to offer their customers something not seen since the days before Probots were nerfed; a little variety in their work. Currently, only 2 droid types would see a major effect if the cap was removed; the Probot and the DZ70. This is what I suggest for each droid.

DZ70 - Both the HAM and the damage on the DZ70 need to be changed; in order for experimentation to actually have balanced effect on this seldom used droid. The HAM needs some major rethinking, since it only takes 2-3 hits by a creature that most Newbies can kill in as many shots with a CDEF Pistol. I suggest that the base HAM on a DZ70 be raised to 200 and have a maximum around 600, through experimentation, with the Advanced DZ70 being 250 to 650. I also suggest that the damage be reworked so that the base damage starts at 30, with a maximum damage around 75. With the average price of a DZ70 currently being about 3-5k, depending on the server, this change would open up a market for some Novice DEs as well as provide a combat droid to the beginning players, with out unbalancing combat; as in the case of many non-CH pets. The HAM and damage may look low, compared to the current CL15 pets, but consider that an Advanced DZ70 with Medium 25% Armor and 650 HAM would be able take about the same amount of damage as a Cowardly Guerreck.

Probot - With Medium 40% Armor, the current Probots actually make fairly good tanks, compared to many of the non-CH pets available, if you do not think include the fact that you can heal a creature pet during combat. I actually like the way that the Probot is currently set up, but I have never seen a Pre-Nerf Probot in action. What I suggest is a less dramatic change, then what I proposed for the DZ70. I suggest the base HAM for a Probot start at 600 with the maximum HAM capping out at about 1100, for heavily experimented results. For the Advanced Probot I suggest the base starting at 650 with the maximum result capping out at 1200. For the damage on both droids, I suggest a base of 45 and a maximum damage of 140. This could put both Probot models on par with the damage of CL15 creatures. Both changes give enough room for experimentation improvements, but at the same time doesn't make either droid overpowering enough to warrant the need for a certification. Both Probot versions, with their maximum allowed armor could take more damage than any of the current non-CH pets that are available, healing not included.

7) The biggest request from many DEs, and droid owners/enthusiasts, is for new combat droids. The problem with adding new, more powerful combat droids is that there really does need to be a system in place that will limit the number of combat droids running around, besides the Probot. With the recently proposed changes to non-CH pets droids will more than likely fill the need for a tank-able pet. If combat droids are implemented without a cert system, the same problems that are occulting now with non-CH pets will occur in the future. I'll share my ideas on the cert system after I list the proposal for new combat droids, one of which is a DE specific droid
Before I list the droids, I need to point out something to some of the people who claim that Battle Droids and Droidekas should not be craftable by DEs. Most of the comments that I have seen regarding the reasons behind not being able to craft these two combat droids have been either that these droids don't belong in this time line, or that combat droids have been banned by the Empire. Both reason don't hold any weight in the Star Wars galaxy, if you take into consideration how large the realm of space we are talking about is and how old some of the equipment is that can be found throughout the galaxy. Take the R2 series for example. For those that say the design of the above mentioned combat droids are too old, might I remind you that the R2 series is supposed to be quite a bit older than any of the Battle Droid designs and should by all rights be out of production, since 3 additional R units have replaced it; the R3 series, the R4 series, and the 'youngest of the bunch' the R5 series.
By some accounts, the R2 series is well over 200 years old, since the time that the first R2 unit rolled of the assembly line. As for the ban on Combat Droids, this ban did not effect everyone, since many Imperial corporations were given licenses to own and produce combat droids, not to mention the large number of droids that are bought and sold on the 'Shadow Market' in such places as Corellia. The 'ban' argument doesn't hold any water due to the fact that anyone can run around carrying a weapon the size of a LLC, when any weapon larger that a Scout Blaster shouldn't be allowed on the streets. I apologize if the last sounded like a rant, but I felt that I needed added it before the so-called 'Traditionalists' come out of the wood work. The two most truthful reasons why we only see two combat droids in the original trilogy are a) Good ol' George hadn't even thought of Episode I yet b) There wasn't a budget or special effects to have them in 1977, 1980, or 1983. Now, on with the show

Battle Droid - Known by many as the Rodger-Rodger Droid, the Battle Droid should become part of any combat professional's line-up. With a suggested maximum armor rating of Medium 50% Armor, HAM that could range from 850 to 1700, and damage in the range of 60 to 180, the Battle Droid would be a nice upgrade from the Probot, but wouldn't add to the over balancing situation, due to the certification needed to 'command' one. The Battle Droid would be limited to few modules, due to its specialized role and would only accommodate 1 Service Module and 1 Armor Module. The suggested Service Modules are Item Storage, Data Storage, Repair Module, or Medical Module. This Droid would become available at Blueprints III, along with the Adv. Battle Droid Chassis, and would require the following components during construction.

120 Steel
100 Chemical
1 Droid Brain
1 Manipulator Arm
1 Droid Sensor
2 Advanced Droid Motive System #
1 Blaster-Rifle Barrel (Weaponsmith Firearms Crafting 1)
1 Droid Armor Module (Optional)
1 Service Module (Optional)

Advanced Battle Droid - A slight upgrade to the Battle Droid, the Advanced Battle Droid would be acquired at Blueprints IV, and would have the following stats; 2 Droid Service Modules chosen from Item Storage, Data Storage, Repair Module, or Medical Module , 1000 to 2000 HAM, 70 to 190 damage, and a maximum armor rating of Medium 60% Armor. The suggested components are:

1 Adv. Battle Droid Chassis
120 Steel
100 Chemical
1 Droid Brain
1 Manipulator Arm
1 Droid Sensor
2 Advanced Droid Motive System #
2 Blaster-Rifle Barrel (Weaponsmith Firearms Crafting 1)#
190 Chemical
90 Chemical
1 Droid Brain
1 Droid Armor Module(Optional)
2 Droid Service Modules (Optional)

Droideka - The Ultimate in combat droids, the Droideka, or Destroyer, would make a great addition to the DEs repertoire of droids. Acquired at Blueprints IV, the suggested stats for the Droideka are as follows; 1200 to 2500 HAM, 75 to 200 damage, and a maximum armor rating of Medium 75% Armor. Due to the extreme dedication, this module of the Droideka doesn't have any room to spare on Service Modules. The suggested components are

500 Duralloy Steel
500 Duranium Steel
500 Fiberplast
500 Metal
1 Advanced Droid Brain
2 Advanced Droid Motive Systems#
2 Droid Sensor#
1 Micro Sensor
2 Manipulator Arms#
2 Advanced Droid Frames#
2 Blaster-Rifle Barrel (Weaponsmith Firearms Crafting 1)#
1 Droid Armor Module (Optional)

*Advanced Droideka - Available at Master Droid Engineer and only useable by those with the correct droid cert the Advenced Droideka is the ultimate in combat droids. The suggested stats are as follows; 1500 to 3000 HAM, 85 to 225 damage, and a maximum rating of Medium 80% Armor. Besides the upgraded HAM, damage, and armor, three other features make the Advanced Droideka a worth prize to any who qualify. 1) 2 Droid Service Module slots 2) Optional Shielding, which could either increase the armors maximum value to Heavy 20% or max out the Medium armors resistances to 100% 3) A slightly larger appearance than the basic module. The Advanced Droideka Chassis for this droid would appear in the Blueprints IV box. The suggested components are:

1 Advanced Droideka Chassis
500 Duralloy Steel
500 Duranium Steel
500 Fiberplast
500 Metal
2 Advanced Droid Brain#
2 Advanced Droid Motive Systems#
2 Droid Sensor#
2 Micro Sensor #
2 Manipulator Arms#
2 Advanced Droid Frames#
4 Blaster-Rifle Barrel (Weaponsmith Firearms Crafting 1)#
250 Chemical
250 Chemical
1 Droid Armor Module (Optional)
2 Droid Service Modules (Optional)
Any Medical, Data storage, Item Storage, Repair, basic Crafting station, and/or Crafting Station Package.
2 Power Conditioner (Optional - for shield)#
2 Energy Distributors (Optional - for shield)#
2 Deflector Shield Emitter Assembly# (Armorsmith - Deflectors I)
#Denotes Factory Items

I noticed that I forgot a number of things in this addition of the thread, such as the addition of personality chips being listed in all the current droids, the Battle Droids, and the Advanced Battle Droids. There are also a few minor editing issues that need to take place, to make the thread a little easier to read as well as cutting down on my rather verbose descriptions.

Besides the entire re-write of section 8), especially the last line, since this is a community effort, I forgot to add a section listing the names of those that have already helped out, or offered support so far. This list of names comes from the previous two versions of this thread and is surprisingly a small number of people, when you consider the number of views that both threads have already seen. I ask that anyone, that sees anything that they disagree with or would like to see added, post your constructive comments here, so that the list of names can grow. By adding this list to each and every future version of this thread, we give a list of those that either support, or wish to show support, in this project and see it reach its ultimate goal; Community created ideas that the DEV team can chose from and implement.

ChrisF0001 SinjenRandall
Traigus Droid_Engineer_Rho
Ki-Odo Sodan-droiddreamer
JediYak Ockale_MDE
Sintrosi CapnSteve
Grimjakk DaHumAn
Drem Awol80
Kollos YamYam
progman63

Update to section 1c) Out of curiosity, I stacked 2 Level 4Item StorageModules and a Weapon Crafting station into a Cluster Module. All three of the orginal module had a Mechanical Rating of 11. The Cluster Module turned out having a Mechanical rating of 46 when I built it. I then proceded to stack that Cluster Module into a second Cluster Module with 2 Level 4 Medical Modules, both with a 12 rating. I ended the 'uber' stack with 2 Level 4 Data Storage Modules, that the best I could get was a 1 Mechanical Rating on since after 24 builds I was only able to acheive a Moderate Success on the Experimentation process. The final Cluster Module ended up with a Mechanical rating of 102. The example that I mentioned was way off. Instead of being able to produce a 30 - 50 rating the rating would look more like 80 - 120.

---

Droid_Engineer_Rho wrote:
Anyway, what you were saying about crafting packages made a lot of sense to me, and seems like a good reason to package crafting, item and data storage in one droid.

Now let's take it one step further: You use the droid to make five schematics, hook it up to an equipment factory, and say 'go'. It extends it's computer interface arm, and gets to work.

Two days later, without further intervention on your part, your factory output hopper is filled with 500 GP modules, 500 Memory modules, 250 Control units, 100 Droid Brains, and a partirdge in a pear tree.

---

Ok, as I stated, I have thought about the section 8) a little more and think that a better idea has been formed. The last version was a little less straight forward than I had envisioned and really needed a better solution, especially if DEs wanted a way to sell stronger combat droids to the general public. Instead of basing the combat droids on combat only professions, they could instead be based solely on the overall 'age' of the character.

The cert system would still be consistant with the 'upcoming' change to now many pets that I character can call, as mentioned in Thunderheart's post a few weeks back.When a character is created, they are able to call upon 1 droid of any that are available at this time, including the Probot and DZ70. This droid counts towards the 1 pet/droid/faction perk maximum. When a character Masters a Starting profession, or gains a Novice Elite profession, they gain the ability to call an additional non-combat droid.

The newly porposed Drod Cert system would be based on a ranking system.Each rank would give access to the one of thefour new combat droids listed in this thread. A character would gain a droid cert as aNovice Eliteprofession, Master starting profession, a second Novice Elite profession, a third Elite profession, ora Master Elite Profession. So, in order to call an Advanced Droideka a character would need to have a) 2 Elite professions, Master a starting profession, and a Master Elite profession b) 3 Elite professions and a Master Elite profession, or c) 3 Elite professions and a Master starting profession. This system would allow anyone that has spent time leveling up their character the ability to call a stronger combat droid, instead of limiting such a droid to only combat professions. DEs would be handled a little bit different. Instead of only 1 droid cert rank being gained at Novice, they would gain 2 ranks.

For those worried that letting a Master DE call two combat droids, how about also allowing those that have Mastered 2 Elite professions have this ability as well. This would allow for more combat droid sales, but at the same time would be limited to MDE and anyone that had a total of 2 Master Elite Professions.

There would still need to be some kind of Max pet/perk/droid call limit, as listed in section 8).

Any comments on the new proposed cert system would be appriciated.

Well thank you to the 1 star bandit who decided to rate every post that I made, but didn't have the ability to actually post the reason why. It is good to know that someone in the community, or maybe even someone from outside, felt the need to 1 star an enitre post that is aimed at trying to help the DE community.

If you don't like something that is written here, then post what it is that you don't like. A list of those that have already done so can be found and because of their responses this thread has evolved.I know that many are unhappy with what the current direction of the DE profession, but please don't take out the bitter attitude on those that are serious in trying to be constructive and optimistic about the future of the profession.

I appoligize if this is coming out as a rant, or even whining, but to have everything that I have written in a post that is meant to offer ideas to the development team that come from the Droid Engineering community is nothing more than a slap in the face to all of those that have taken the time to post here. If you don't like what you see here, then explain why.

Geez man and you ask me why i say you are the best lol

Ok and before you nerf yourself make me a superstacked droid with 100000 intertwined sockets so it can do anything, you know im good moneywise i just hope you have patience lol

BTW i still use my trusty DZ even tho u call them crap hehe i love em they are a floating piece of trash but they are so cool lol

I have to strongly disagree with you, Awol80, about many of the points that you brought up. People, as a whole,will get upset with anything that is implimented in this game, simply becasue that is the nature of being human. The Probots were nerfed becuase of people crying about the fact that Pre-Nerf Probots were so strong. Many asked for a balancing function to be added to the game and instead they were hit with the Nerf bat. Adding a cert system is the only way that stronger combat droid can be introduced into the game and have a balancing mechanism so that a 'noob' can't call upon it from da one. I've heard others mention letting the cost of the droid be this gate; however this will not work like a cert system would.

If you will note, I changed the entire section on droid certs, a few posts later. The new section would allow any profession to call upon one of the newer combat droids, based upon their 'overall' experience as a character. This takes away from the need to be a combat professional only and is based more on the amount of Skill points that one has spent. So, this fills the idea that anyone can use any droid, as long as they have had a little more experience under their belt.

I already covered the ability to call upon 1 droid/perk/pet and 1 utility droid. It would be based on gaining a Novice Elite Profession.

I doubt that many, if anyone, would be happy with a combat droid that is as weak as a Probot with no armor. A CL-10 creature is equal to a Probot with 820 HAM, 50 damage, and no armor. The armor on a droid is what makes it such a great tank at the moment. To ask for all droids to be the equal of a CL-10 pet is to ask for the nerf bat to be swung hard and to kill the idea of any combat droids being sold to the general public. In order for sales to be boosted, a combat droid would need to be more of a draw than pets currently are, then less of one.

Allowing a MDE the ability to call out 2 combat droids is a perk. Making the DE profession into the metalic version of a Creature Handler is not. I believe that a DE is more than 'just a crafting class' but I, and many many more,do not want to see it turned into a Handler profession. I've already stated that I am on the DE-combat side; however I will fight against turning DE into a CH perversion.

Awol80, I know that you mean well, but you need to face the fact that there needs to be a cert system in place to balance out any new combat droids and that turning DE into the droid version of CH is not a way to fix our profession. Being a Droid Handler may sound like a great idea to you, and a few others, but it will only lead to future problems and a whole new set of nerfs down the line.

Drashk once agian I have to say that your post keeps getting better but still i have a problem with section 8. I have come to the conclusion that Cert are not the way to go with limiting droids. Before I get into my idea I have a few reason way cerf are not going to work that good.

Firsr