Droid Engineer Archive

---

BillyBobthe50th wrote:

Theres some pro's you forgot.

Easier for total non de's to understand: Non DE's can understand how ships work pretty easily, they buy a ship, and some components, and put them together at a terminal. They cant however understand the limitations of what a droid can do, even players that have been playing for almost a year still dont understand whata DE can and cant do. Every DE has gotten an order at one time or another asking for a droid that could "help me kill rancors" or "heal people for me" seriously, if we had a modular type system then it would be practical to put a more detailed description for the modules since they would actually have a chance to read them.

---

This reminds me when a buddy and I were doing missions on dath, hes been playing since thelaunch but left for a while till JTL came out. I have a few levels of scout and made a harvesting droid during the uber correlian insect meat spawn. I went out to hunt with him cause he needed the help, i needed the carbine xp, and the hearbavore meat. Well during the hunt i had my droid out collecting the meat, he noticed my droid harvesting and this was the conversation:

Him: Dude that droids harvesting for you?

Me: Yep made him a few days ago, aint it cool?

Him: Well ya.

I know its off the topic but it was cool none the less.

/getting Back On Topic

The only way I think that the moduler module thing would work is if DE's were only allowed to do it, or that all the components in a droid have a decay. Like the modivaters for one, it would be cool walking thru coronet and a docs bot blows its modivater in a big puff of smoke and sparks, the doc calls out is threre a DE in the house. You hear the call go over fix his droid for a fee and hecontinues doinghis thing.

One more thing we need to have something to vary the numbers of modules ina chassis, I have many ask for a R3 droid with this that and another thing. Unforcenantly im nota MDE yet, and there common responce to that is "Oh nevermind".

Message Edited by Corran950 on 11-05-2004 02:47 PM

---

Straker_Atrella wrote:

While I agree that a system like this would be pretty cool philosophically, yet also as a Master Shipwright, be careful what you wish for.

I am against a system such as this, mostly because it is way to much of a change then we really need. SWG is grossly lacking in content, developers need to start spending more time focusing on that sometime in the near future or the game will start to spiral. JTL bought them some time, but not much.

A total revamp of the entire Droid system is not only a lot to ask, yet more then we actually NEED in my opinion.

Our profession isn't really that broken, two things are what we are lacking. The NEED for droids, and DECAY. Switching to a modular system by itself doesn't do anything to fix either. If you switch to a Modular system as part of Decay, your doing overkill, just add the decay. All that programming just for "coolness" doesn't make sense from a whole game point of view.

We don't need such a huge radical change as this. Tie decay into Battery use, or advance our market in space a lot with Droid decay there and we are fixed. We just need to accept that DE will never be as "cool," as it could be.

Plus with a modular system such as this, in the long run a DE WOULD lose money.

---

QFE

This basically points out a lot of what I was trying to get across with this post. A Modular Upgrade System has a lot of 'coolness' factor, but at what cost?

I was trying to let people understand that if this is truely the direction that the Community wishes to head towards, then we will lose out on a lot of other additions that are actually needed to make Droid Engineer a better profession. Completely revamping the Droid crafting system without addressing the major issues, such as making Droids more valuable to an average customer, would only make a prettier interface for the underlying problems. Maybe someday, after the core problems of our profession are handled, we can revisit this idea, but for now I think that we should put the idea of a Modular Upgrade System on the back burner.

This was the inital intent of this post; however if there is a resounding request from the community to push this forward, above such changes as making Droid functions more appealing, then that will be thegoal that I will move Project: Droid Engineertowards. There simply would not be enough spare production time to effect both issues, without cutting production time from the 20+ other profession that also need attention.

Just a side note for everyone to think about, in regards to production and development time for Droid Engineer. We are 1 of 30 ish profession. Everyone needs to keep this in mind. The Combat Professions are getting a major Revamp right now, and afterwards non-Combat Professions will see the same type of love. Don't fall under the false impression that the Developers used during JtL aren't already working on different projects. The development resources (the people who code) are hard at work with the Combat Balance, and other projects such as the Recursive Macro issue.

Development time is a very precious resource that should be used wisely. If you will notice, now that SOETyrant is running the show, the development cycles have change quite a lot. Much has improved in the short time that he has been given the reigns. He runs a pretty tight ship and is taking this game to new highest. He is alsoa no non-sense kind of guy, when it comes to the answer NO and when he delves out the production time.

There is no magic button, or secret team of developers that can be called in to increase the amount of production that can be done in a development cycle. The biggest thing that everyone needs to consider is that stacking features together does not cut down production time. Adding X, Y, and Z feature all at the same time does not equal the same amount of time needed to add only X, Y, or Z feature. It doesn't work that way.

Drashk,

I respect your opinion and have no doubt that you have what is best for the profession at the heart of your words and actions, but I have to tell you that this seems like you are taking the "glass half empty" approach to this particular issue. You've listed Pro's which aren't all that strong and used potential negatives, some of which already exist in the game, to drive home the point that this wont work. I'd like to offer the following observations on the Con's you have listed.

• 
  
  Price Cutting - We already see this as an issue in our current market. If droids were redesigned, it is likely that we will see a greater increase in price gouging by other Droid Engineers. Such a system would cut back on the work load and make Droid Engineering a lot easier. Doing so would allow anyone the ability to factory run massive amounts of modules and chassis', and place them on a vendor. Since a number of the Chassis' and Modules do not need experimenation, many would be tempted to sale our product at 3-5 cpu.

This occurs on almost every server currently, and it was even worse when sub par items were being dropped on the market by hologrinders or people who didnt understand or care about the profession. I strongly disagree with the conclusion that the introduction of modular chassis will greatly increase price gouging. In fact, I see it as a more competitive market place for the Droids and the modules. Kind of like the "after market" parts market for cars. Tell me that none of you have ever bought after market stuff? I believe that this would allow specialization and allow for more DE's to participate in the market, including at the entry level, where they currently have almost no market value.

• 
  
  Loss of Sales - With the addition of a Modular Upgrade system, the potential for lost financial gain is increased. Allowing a customer to simply upgrade the modules on a droid reduces the need to sale additional droids down the line. Since modules cost less to produce then chassis, the overall pricing of modules will be lower then that of a current droid.

Again, I have to strongly disagree with this conclusion. I don't see this happening at all. The simple fix for this is to make the ability to upgrade the droid a DE only task, similar to Droid reconstruction kits. That way, instead of losing money, you actually turn this into a positive value task. Since I had a standard pricing for new modules, I would most likely take a percentage of the full cost when looking at upgrading or swapping out modules. I beleive that this ability, as long as it was DE only, would also increase customer interaction and promote a more personal relationship with your client. As their playstyle changes, their droid can change with them. I can't think of a better way to have continuity than to havea droid that you have had for years and take him to your local DE down the block to have that new widget making module put in. Besides, as we all know, people get attached to their droids. Why make them give them up just so that they can get an upgrade?

• 
  
  Increased DE Interaction - A Modular Upgrade System would lead to the need of increased interaction between DE and Customer. Imagine the number of times we are asked the same questions by different customers under the current droid design. Now imagine the number of times we will be asked the same question, if the same people are given the ability to install their own modules. Everything from 'Why doesn't my droid have more storage with 2 Level 6 modules?' to 'Why does my LE tank keep running away?I put 3 Auto-Repair Modules in it'.

Drashk, gotta say that this is a weak argument against the Modular approach You know we get all kinds of tells form people asking those exact same questions now. Explaining to the customer prior to the sale is an important part of customer relations. No, not every sale goes well, but I always try my best to make them understand exactly what they are getting. I don't see how the modular system changes that in any way at all.

• 
  
  Loss of other Development - The time that would be taken to revamp Droid Engineer would mean that time on other projects was sacrified. Each team of programmers is given a set number of tasks to work on for a Publish. If a Modular System was pushed for, it would cut into the time needed for other projects such as Decay, new Modules, new Droid Chassis, and other cool stuff.

This is the key argument against changing over to the Modular system, and it is a strong one. But what's to prevent us from having the things that NEED fixing be fixed while we hash out the improvements to the modular system? I agree we have too many items that require attention now to get off track, but lets not throw the baby out with the bathwater on this one. I believe the modular system may be a very important part of our future, and I don't think we can afford to ignore it and possibly lose out on the chance to get a much more flexible and interactive profession. I think we are one of the best professions now, so I start drolling thinking about what it could be with the modular system .

• 
  
  Information Overhaul - Many of the issues that we know about our profession would likely change after the introduction of an Upgrade System. Not only would we have to update ourselves on the different issues, but we would also have to update our customer base on the issues as well. Droid Engineers finding out the information is rather minor, since we have a handful of really great testers around. Its keeping our customer base informed, as well as updating local Droid Engineers that don't read the forums. Most of us have already run into damage control, by having to explain to a customer of a Droid Engineer that was not up-to-date on the issues.

I don't agree with this assessment either (go figure :smileyhappy. What you are saying here is that a modular system would change the context of our knowledge, but I dont see how? A combat module will still be a combat module. A crafting module will still be a crafting module. Our customer already know scant little about what we can do for them, so I'm not sure how this is really a negative. I see increasing the effectiveness and configuration potential of our droids as a huge positive step in getting players to know more about droids. Imagine that instead of the "dood" coming back and asking for a refund because he says it wasnt what he wanted and he wanted "this or that", we offer to pull out the old modules and give him "exactly" what he asked for and provide a CLEAR demonstration of why it isnt a good idea to have all auto repair in a combat Adv R3 Heck, I can even picture DE's doing demonstrations of the module functions for their clients. Kind of like the Fuller Brush man going door to door

• 
  
  Complete Droid design Overhaul - Completely pulling the code on an existing system isn't the easiest of jobs, nor is it the always 100% effective. Unlike the Ship upgrade system, Droids were not designed with this intent in mind.

While droids may not have been designed with the interchangeability that is currently in ships, failing to realize this as an important future step will doom our profession to stay in the virtual backwater of the game. I can imagine nothing worse than not following up on this and placing it in the "someday" category.

• 
  
  Droid Built before the Upgrade System - What would happen to droids built prior to the introduction of a Modular Upgrade System? It is apparent that the database does not track the number of modules installed into a droid, nor the rating of each individual module. If it did, then the issue of being able to stack Module Custers would have never been an issue. Designing a method of disassembling the droid from its modules is one thing. Not having a way to break apart the 6 Combat Modules, so that you end up with 6 modules instead of 1 overpowered module is another thing. Even this is a simplified example, since some droids that have stacked modules installed will more then likely not have the full number of possible modules installed. The potential for problems in the back engineering is a daunting task in itself.

I don't see this as being a very serious issue at all. Every nerf has it's "pre-nerf" remainder. Droids made prior to the upgrade would simply become obsolete, just like the FWG-5's and the first month Probots. Why back engineer it? Why not just realize that there will be a major shift in the way that droids are made and used and move on? Will they all disappear? Probably, over time. But because so many players keep their droids now, I can envision some old fogey pre-change droids hanging around for a while.

• 
  
  Increased Database Requirements - There would bean increased database requirement for upgrading droids to a Modular system.

Yes, this is a concern. But are we going to bypass this issue just because it "may" require too much space? I don't think that is a wise move.

• 
  
  Removal of Cluster Modules - Cluster Modules would more then likely need to be removed, to allow for a Modular System, so that each individual module could be installed, instead of a lumped together module. Leaving the Cluster Modules in would reduce the upgrade freedoms.

Disagree. Why would cluster modules have to be removed? Why can't you have nesting modules, such that you can pull the cluster module, open it up, swap out a single module in the cluster and slap it back in? If that wont work, why couldnt we just remove the existing cluster, File 13 it, and place a new one in where it was? I see no reason to totally do away with a system that works well. There is a work around for any item.

• 
  
  Revamp Module Listings - Majority of the listed information on the would need to be updated, so that non-Droid Engineers would understand the system.

We need to do this anyway. Noone really understands, no matter how many times I tell them, what the Module Rating on the Item Storage Module means. The majority of the listed information provides no value as it currently exists, so this is a non-issue in my view of the world

• 
  
  Removal of Level based Stacking - To help with Database tracking issues, and reduce confusion by non-DE, Level based stacking would need to be removed. A check would need to be placed on each droid that would only allowed one level of each level based module to be installed.

Again, I'm not sure why level based stacking would have to be removed if we moved to a modular system? Database tracking could be set to allow a maximum rating in any single value for the droid, no matter what you put in it. Or, conversely, the database could be set to recognize module levels and assign a maximum value based on the droid chassis, which also would effectively take care of the level based issue. Advanced droids would be allowed to have more modules than non-advanced, thereby allowing stacking of modules in some droids but maybe not all.

• 
  
  Revamping non-Level based Stacking - This would need to be addressed, to cut down on database requriements.

Not sure how this applies, can you give me an example??

• 
  
  IncreaseDroid ChassisRequirements - To off-set the changes made, Droid Chassis requirements would need to increase.

Why would this need to occur? If we use more resources in creating new modules and are not allowed to reuse cluster modules that are removed, arent we in effect increasing the resource requirements for the droid anyway? I don't concur that resource values need to be increased just to offset our ability to make changes. They can be built into this in other ways, such as special tools that would be required to make the module removal possible or a no-reuse option that once you remove the module, you cant replace it in the droid.

• 
  
  Removal of Basic Models - It would be easier to remove the basic model of each droid, instead of having to program 26 seperate droids. Though nota major issue, since most DE do not bother with the basic models, it cuts down on what a Droid Engineer can build.

I guess I see this another way. Why couldnt we keep the basic models of the droids, but make it so that they are the ones that cannot be upgraded or have modules swapped out? The basic models, in my view, would be more like the off the shelf "Yugo" versions of our droids and the Advanced models would be the BMW's You therefore increase your market and clearly differentiate your products and services. Modular droids would cost more, but you would be getting what you pay for

---

I'm not saying here that we should run out and start begging the Dev's to give us the Modular System, I'm saying that we can't take the approach that because we have other stuff that needs to happen NOW, we should abandon a very promising future. I think the modular system has some very real possiblities for expansion of both my business and the value of the DE to the community as a whole. Lets not just forget it Ok, I've typed too much and its late anyway, but I hope you can understand that I see this as a VERY important part of our future.