Construction Streamlining.

This has probably been suggested already but I'd like to see what the split is. Would people prefer having construction queues as objects to which fabbers are assigned rather than objects that fabbers create? Holding shift would display all the different "projects" which could be colour coded.

Another thing I'm curious about is the automation of mass extractor production. At the moment it's not that micro intensive as you are on only one world but once more get involved it would be handy to let your engineers run free on the planet building mass extractors as they go. This would cut down on so much tedious micro.

Simply having construction orders exist on their own would be incredible useful and enough for me to avoid lots of micro.

When I give an engineer 10 building projects having to redo them because I misclicked on the engineer (double click bug for example, or it got destroyed, I run into an energy stall and had to reasign him, etc.) is pretty annoying. Being able to preplan my base (during the game) with construction orders and then assign idle engineers to it (by hand) would be great too.


So yeah, orders as first class entities as they've been called in this forum a lot is still something I really want.

I'll refrain from voting since I don't have alpha access.

But I'll express my opinion in a post instead. I'd prefer to have the current system where fabers select the objects they're going to create. You have to select the faber first anyway.

I think my issue with 1b is that it would end up too complicated. Would stopping a fabber disable a construction queue? Or would you have to select the queue and delete it?

And for 2b, I wouldn't mind this for planets you have entirely conquered. Or maybe a button for it, but I like to know where my fabbers are and are going to be.

Stopping a fabber would stop that fabber from building. You could re-assign that fabber to the queue again to resume building. You would have to click on the construction queue to destroy the construction queue. It would make base construction much simpler if you could set out your layout in the downtime and just assign more fabbers to complete it as the game progresses. As it stands you constantly have to remake queues when a fabber dies , bugs out or has to build an emergency building like a wall or turret.

That's the trade off. You could turn it on and the fabbers could be destroyed in stupid ways or you could do it manually and trade micro for fabber safety. After a raid destroys your mexes you could just drive a fabber into the destroyed zone and set it to auto build rather than re-clicking on every mex point.

why do you have to select the fabber first?

wouldn't it be cool if you could select and place the building at any time without selecting a fabber and the closest idle fabber grabs the job or is queued for build.

The buildings you cannot yet build (adv) could be greyed out until you build some adv fabbers from a factory.

Currently switching between bots, vehicles, adv bots and adv vehicles the build menu is different every time and a little confusing. Would be nice to have a consistent build menu

Bumping this thread due to a post I just made about not being able to cancel a fab bot's build order. It was incredibly frustrating!

I also am not in alpha, so my opinion may be void.

To simplify building I think an 'omni-potent' structure selection could be beneficial. A UI in which you can place buildings (be it adv. or standard) and as you're placing in on the map the game highlights the nearest fabbers so you can see how long it'll take to get started.

Once placed you could select the building's importance (Primary, Secondary, Tertiary...)/(1,2,3,4...) and fabbers will prioritize the most important structure you've placed. Additionally there could be an option to determine how many you want working on it maximum (as many as possible, 1,2,3...). This may require more AI to be programmed, but I think this would have a greater benefit than a 'queue'. What if something came up and something farther along in the queue needed to be built? You'd run into a similar issue where you'd need to restart the whole queue.

So buildings would be constructed as the AI deemed, and you'd be able to supersede this with manual control. This would allow you to plan out a whole base, and not worry about it. Just stick some fabricators in the vicinity and it'll get done.

An example of this idea would be the construction system in Prison Architect (although the ability to prioritize or supersede does not exist presently). The general idea of planning and constructing being done by the worker AI allowing you to move on works well. If workers die or something comes up it gets handled.
Also in this system buildings can be 'paused' if an area is too dangerous. That could be good to implement as well.

1.b for me and apparently the majority.

I don't think you should remove all mex building micro by having them automatically roam, but I'd like to paint a rectangle around mex I want built so that sending them to do it would take only a second rather than a very time consuming individual click + wait for build lag to queue up multiple mex.

this is a very intersting solution. Yes, this needs to be given a try

well not in the idea of drag and drop queue : an idea where while holding shift you can drag a structure off the build menu onto the queue path between the two other structures you want built and it would 'sticky' to the path then you could drag it to where you want it to be built. Delete queue item would be shift-alt-left click just like in supcom. this of course goes with the build queue path idea and the shift queue edit idea.

My god, this. I was going to suggest this myself at some point. Some sort of command to send a bot to a selected area and get them to build on all the mex spots on that area would be fantastic. I hate the furious clicking on all the mex spots!

I believe this is something that might occur when 'Area Commands' are added.

'Area Commands'? this was a term Uber used? do you have a linky??

Area Commands like this?
https://forums.uberent.com/threads/ideas-from-zero-k.34222/#post-506682

So in this vision of the system is your 'queue' like a queue when a structure is listing the things it's going to build? Like a UI on the bottom showing the list of things on the to-do list, and maybe they fill up as they're getting built? So you could drag a structure into order on this list, and then you place it on the map?

I may not be completely grasping it, but it sounds more complicated than a more AI-driven system... (Or maybe it's just my aversion from pressing too many keyboard commands at once, haha)

I can't confirm exactly what 'Area Commands' will look like, what they will do, or how you will control them... because I just don't know what Neutrino has in store for them.

I'll I know is that Neutrino has mentioned them as a way to cut back the tedium of having to individually click a whole bunch of things in a given area. What those 'things' are, and if they include Metal Extractor placement has yet to be seen; hence

oh yeeeeeeeeeeeeeeeah

no when you hold shift you see white "ghosts" of the structures to be built in the future right? well in supcom you could click on these and drag them around to where you wanted them and yes you did have a list of what you were going to build in a bottom ui bar and no, you couldn't drag and drop on that list but you could delete, and you couldn't drag things from the build command to the build queue. there was no "build this anywhere" function but there was a path drawn between each "ghost" showing what order they would be done in. I'm thinking of utilising this path in PA and making it also clickable as well as the "ghosts" (not currently the case) you could then drag and drop a structure in the build menu to the path in between two structures, indicating (before the builder gets there) that you wish to add this in the build queue at that point.
this mechaninc would avoid you having to remake an entire long build queue because you changed your mind on what order you needed things in.

Ok, I think I'm getting it. SupCom's system wasn't too different from most build queue systems, but your suggestion would be to allow for live editing of that build queue.

But what if you want to build something temporally between build order A and B, but locationally it happens over by D. You wouldn't then drag and drop it between the two structures because that's not where you physically want it, though it is the order you want it in.

I suppose I should stop picking nits. You could easily assign a fabber to go build the new thing, and then assign it back to the queue (or multiple fabbers even). Problem solved. I'm just a little partial to my idea because it requires less micromanagement (my undoing in RTS games), although yours is definitely viable too.

Pretty much as long as there's a system so we don't have to restart an entire build queue I'll be happy

Edit: I'll be happy regardless. This game will be awesome.

see that's what I'm suggesting. You drag it to the path which represents an "in between" moment between two structures. It snaps. it stays in the build queue, to delete it you now have to shift-alt-left click it or right click it in the build queue bar. Now you can hold shift and drag it to wherever you want. You wouldn't even have to let go of shift first when it first "snaps". you just snap it to the build path for what "time" you want it at, then continue to drag it around for what place. let go of shift or left mouse button or both to set your decision. press shift and left click drag to correct again. it won't unsnap.

If you play with supcom build queue, this makes a whole lot of sence. I find the combination of the two supcom UI elements : the build queue bottom ui bar and the graphically represented build queue on the map a super-efficient combo for editing to what you want.

I use the shift-alt-left click on graphical build queue to cancel a structure smack dab in the middle of the build queue loads. I also edit the position a bunch. misclicks happen a whole lot so it's really practical.