Hi Imagine having 10 engineers, your eco is booming and you want to build a huge base. you could either select them one by one and build stuff in parallel, or select them all and speed build in serial...etc I could go on and list advantages and disadvantages of both methods but no need. I am suggesting a more intelligent way of building. what about selecting all 10 engineers as a single group and for *the example*simplicity I give a build order for 25 walls (while pressing ctr to active this mode), the engineers will spread out automatically to do them all in parallel, 1 engineer per wall for the first 20 walls, then they will automatically form a 5 mini groups of 2 engineers assisting each other to build the last 5 walls. The advantages of this method: 1) removes the micro management of parallel building. no time wasted in looking for an idle engineer, giving build order, then looking for another idle engineer...etc. just select them all, tell them what you want and they will spread out and do it for you. 2) no queue is lost when pulling an engineer out of the group. They will automatically rearrange and do the job with 9 engineers the same way 3) when the queue list is less than the engineers, then the engineers will assist each other so no engineer will stay idle. a problem faced in parallel building. no one will remain idle until the queue is done. in short. this method combines all the advantages of parallel and serial building together. a bonus feature on top of this would be if we are able to add more engineers to the group dynamically. what do you think?
IDK about super smartness, but a way to parellize buildings with multiple engies selected sounds awesome
ya better fabs are in the works i have seen several conversation on this show up but it seems like something thats going to be seen much later.
Sometimes you don't want this. For example, you might queue up a set of defensive fortifications, and want to get the first few turrets up as fast as possible so you have some defenses, rather than having every single engineer scattered around building different bits of wall or something.
but in many other cases u might want to do what I am proposing. at the end of the day, This will be an added feature, which should not replace what is existing.
In a situation like that you could just select like 10 engineers to build the first 4 turrets, and then 1 more to build the rest. Then queue in an assist order for the first 10 engineers to assist the last engineer and they will do what you want.
If this were to happen, I'd like to see it used when you slave a number of fabricators to a single host. That way you can add or subtract them on the fly. Also a toggle for this behaviour would be good.
You can already do this. Just take a single engi and queue up some buildings. Then grab a bunch of other engis and tell them to assist the first. In supcom you could always see which engineer was the primary one by holding down shift, and that way you could add more engi or remove some from the group without affecting the build queue. That system worked great there, and I have no reason to believe they'll change it up here.
That still does sequential processing though. I'd like to see it do parallel processing when you order them around like that. Or at least have the option of parallel processing.
I don't think I'd dislike this function, but I imagine I also wouldn't use it very often. In effect, what I use(d) most in TA and Zero-K and the like are management functions that help me focus building efforts (like priority buttons for resource distribution, nanolathing towers, ...). Because then you get buildings and units that do something, ASAP.
I think the suggestion was: Shift + click = sequential group construction as you describe above Ctrl (or Alt?) + click = parallel construction I think this would work exceedingly well, and is a very good idea to reduce micro if it can be implemented well.
Make that a +2 on this. Might even be possible to have it so you can mix them in the same queue. They'd run parallel for all the Ctrl clicks, but when the queue came to a sequential (shift) entry every unit would join in as their parallel job finished.
