Droid Engineer Archive
Thread: An update nothing exciting.
Just an update. There really is no news to give but I thought I would post anyhow because I know how it is to wonder what is going on.
Thunderheart has been busting his ass getting details from us concerning our state of the profession, our top issues, and I also turned in a huge list of over 20+ questions that you guys asked in a thread I made last week. All of which have been taken by Thunderheart and are being processed. I know that Th has read our concerns about the plan as well.Since we have gone thruogh numerous "top issue" posts these are the issues I presented as our top issues currently. I limited it to five as per the standards. They keep asking for five because for some professions those five change each patch. Unfortunately ours havent that much.
These are the top issues I posted:
1.) Fix all of our bugs that have been here since release. The release has only grown and has been maintained since beta. See it at the top of my forum. I cannot, nor will I, choose five and post these. They all should be fixed as one. The order in these bugs do not matter. Your choice -- fix easiest to hardest
2.) Our modules and final product are somewhat useless. Crafting stations and medical modules do not a good business make. We should be makingas muchmoneyas a combat class running missions. We want new modules.
Here are just a few examples. See the thread at the top of my forum asking for new module suggestions.
- Slicing modules that give a big boost to smugglers slicing. Slicing modules that allow low level slicing of mission terminals or similiar for non smugglers.
- Merchant modules, turning a droid into a portable vendor/ad barker
4.) At Master level we only get 5 experimentation points. Not that it matters. Pouring all of our experimentation into a droid and using 999 quality resources gets us an extra 20 HAM on a probot. Experimentation should give us a very nice product at the end. right now I can use "grind" metal and make a probot that is no worse than a high quality metal droid. And this leads us to the next one ...
5.) Being a Master DE does not matter. Plain and simple. Experimentation is broken. Master voice chips seldom work, and level 6 modules? Did you know there is a bug that you can put in two level 4 modules and make a level 6 equivalent droid? so no reason to be Master.
Aside from that there isnt much else profession related to talk about. As mentioned TH is working very hard. In fact in my opinion too hard, he will burn out one day. I still remain confident we will be fixed and we as a whole will have input into that direction.
My favorite analogy right now is using a pizza. No matter how hard I work, Thunderheart works, and you guys work in answering my threads and posting your own ... the pizza wont get to our doorstep any faster. It still has to bake. And there is no shortcut there. It will take as long as it takes no matter what is done.
Now if you want to argue that the design is off, that's a whole different story. My feeling is that if the situation were that if the entire thing were a geometric progression so that it took 2 level 4 modules to equal a level 5 and four level 4 modules to equal a level 6 we probably wouldn't be having this discussion. Likewise, if we weren't capped at level 6 so that 2 level 6 modules had an effect then people would probably be happier.
Is it a niggling point to argue that its not a bug and that it's bad design? I don't really think it is. While it may seem a fine distinction if we call it a bug and it lands on a designers lap that we are complaining about a bug when that's how they intended it to work they will most likely just brush it off as 'we don't understand what they intended'. On the other hand if we call it bad design (in essence saying 'we understand what you intended but we think it's wrong) they are more likely to consider what we are saying.
Icarus-6 wrote:
The only thing I would say to this is that the stacking of modules is most likely not a bug...
Or it wouldnt be deemed a bug if you couldnt infinitely nest cluster modules and put cluster modules in normal module slots.
If there were actually limited module slots on droids then stacking of lower level modules to get higher end effects wouldnt be a problem as they would be paying a price for using more modules...
Thanks for the update and your continued hard work and patience.
What I heard here is..."TH asked me to come post this list to make you all think that they are listening and will actually do something, someday".
How many more information gathering exercises will we need to go through here?
How many more times can you post the SAME information to them? By my count, we've send them basically the same information no less than 4 or 5 times since the start of Beta 3. It's ridiculous.
If you hear jadedness and cynicism in my post, I'm sorry. However, the Dev team has earned it.
I call it like I see it.
Note to Sintrosi: Please understand...I'm not berating you, personally. You have done a marvelous job given the circumstance under which you are forced to operate.
I'm beginning to wonder if it's even worthwhile to try posting my other DE Focus Threads. The first one hasn't really produced any kind of positive or constructive discussion.
/sigh
/bow
Respectfully,
What I heard here is..."TH asked me to come post this list to make you all think that they are listening and will actually do something, someday".
Hehe - no, I did this on my own. I dont like to be in the dark and I know you guys dont. So when possible I like to bring you all up to speed.
Also, if you can't put a socket cluster into a general module spot the whole nesting problem goes away.
What I -can't- decide is whether it is a true bug (i.e. code not doing what it is suppose to) or just phenomenally bad design.
The reason for this is that it is within the realm of possibility that some designer came up with the concept for a Socket Cluster module that would let you put three modules into the space normally occupied by one. He never thinks of the recursion problem and simply tells the programmer to let general sockets accept socket clusters. Later on someone decides to make these mandatory for the more advanced droids to avoid the problems of giving them 6 separate general module slots, not realizing that by mandating socket clusters they are actually weakening the more advanced droids.
Technically these aren't bugs. The code is chugging along exactly as it was designed to. It is just monumentally bad design. Do I think people were asleep at the switch like this? Not really. I think there's a bug in the code and socket clusters aren't suppose to go into general module slots. I'm just admitting to the possibility that it is something else.
TheRealTK421 wrote:
Sintrosi,
I'm beginning to wonder if it's even worthwhile to try posting my other DE Focus Threads. The first one hasn't really produced any kind of positive or constructive discussion.
/sigh
/bow
Respectfully,
Please post 'em... I've been looking forward to reading 'em.
Icarus-6 wrote:
I think that the bug is that you are not suppose to be able to put cluster modules into general module sockets, but the code is goofed and it lets you.
I think another element to this "issue" (bug or no) is the built in function caps. If stacking 2 level 3's give as much functionality as 1 level 6, but 2 level 4's 5's or 6's don't give any more functionality, where is the incentive to use the better modules?
In my personal opinion, stacking multiple modules should give diminishing results. Say just for argument that the only two modules can be stacked, and the second (or lower rated) module always gets its functionality cut in half.
Say for example, Storage6 gives has 10 storage units (just guessing... allmy time as MDE, I've never built one) two Storage6's would give 15 storage units. And THAT's where it should cap out.
There should be an upper limit, but itshould cap out only when the top qualitymodulesare used.
