koosemose
commented
5 years ago Fluid does one thing at present, the O2 generator requires water, which comes from the water generator.
And the graphics for utilities have always been placeholders.
There are some decisions to be made for fluids. Do we want a limit to how many fluids we have (i.e. should more be moddable)? If we have multiple fluids, do we want fluid pipes to represent all possible fluid connections (i.e. if I have fluid connections and 3 different fluids, do I need 1 set of fluid pipes for each, or does one set transport everything between whatever they're connected to?)?
Graphically, on top of just better actually images for them, optimally we need a way that they can be appropriately offset, so that if we have 3 different types of utility connections running through a tile, they don't overlap, or alternatively we just let them overlap, and instead highlight the appropriate ones when you are placing something that interacts with the that utility (but that becomes a problem since things like O2 generator connects to both power and fluids). While we could just have the graphics designed in such a way that they are offset in a nonoverlapping fashion, this becomes a pain for anyone adding a new utility type, as they have to offset them in a way that doesn't overlap any currently existing, and even then if a player adds two different mods that add utilities, there is a decent chance they overlap. One possible solution would be, rather than having the sprites as they are now (showing every possible configuration of connection), it instead has component parts (1 full tile piece, 1 half tile piece, one end cap, a 2 way corner, 4 way cross and 3 way t section, possibly more if we want logical shading and highlighting on them), and construct the tile sprites from those on game start (having that automatically do the offset, such that the first might be in the middle, 2nd is up and to the right and so on). Of course, any offset based solution has the downside that it creates a limit on the total amount of utilities possible (though perhaps that isn't that huge a thing, perhaps there isn't a need for a huge number of utilities).
On plugging stuff in, I kind of have a preference for keeping wiring cheap, and sticking to the current system of requiring wiring be ran directly to a machine, and it seems pretty obvious to tell if a machine is plugged in (have you ran a wire to it, if not then it's not plugged in, and also it should be showing an error mark with an appropriate symbol, of course we need a way to tell players what those symbols mean).
Though I've also always like the idea of on top of direct plugin, having a something that is placed on a wall that is basically a socket, and it can have that distant connection type function within that room (possible within some range, possible not). But that also optimally would want to have the ability to have some kind of thing that can be built on top of furniture (particularly walls), because you don't want to have to tear down an entire wall to install a electrical socket (and there are other uses for such a system, vents and such things would honestly function best in such a way).
To the best of my knowledge, crew should be picking up every available inventory that is on the ground to deliver to a single job (honestly beyond what is reasonable, they will walk all the way to the other side of the map, even if they have 49 steel in hand, just to pick up one final one, rather than a much more reasonable dropping off those 49 so they can pick up 50 more from the other side of the map). Though perhaps they aren't doing this with stockpiles (I haven't tested that particular aspect) in which case there is an issue with there "is there more inventory of this type to pick up" up check, that it doesn't check stockpiles even if what they're picking up for allows them to pick up from stockpiles. Alternatively, it could be, depending on what exact job is issuing the request for inventory, if 2 crew both have a job to pick up some inventory, that the second crew has a claim on the other bit of inventory, in which case the first crew won't touch it.
As far as stockpiles go, what we need (as I've mentioned in various places) is what we've called "metastockpiles" in the past (I'm not sure that name really makes sense, but it differentiates from what we currently have called stockpiles, and for whatever reason it's the name that's been used), essentially have stockpiles that actually link to each other similar to utilities, and essentially work together (could be as simple as the first stockpile in a group of linked stockpiles "thinks" for the rest and "knows" it has room for x different things of y different types, and so on, and can issue multiple jobs). Or stockpiles could be a new Buildable type (areas?) that are naturally grouped together (functioning similarly to Rimworld stockpiles).
Though to be honest, I think we need to move beyond rimworld style stockpiles (or at least have the options for players to, depending on needs). These are crew on a well funded (hopefully) space station, not some crashlanded survivors doing whatever they can to get by, they should have storage options beyond just piling things on the floor, they should have cabinets, crates and so on. I'll just call these containers for the sake of simplicity in conversion. A container of course should be able to hold multiple types of things and more than just piling things on the floor. Of course, for them to function most sensible, we would want to have inventory have weight and volume (these don't have to be exact, particularly volume, which could just be some number roughly representing how bulky it is), with containers having a max volume and weight (though weight might be effectively unlimited depending on exact type of container, a box on the ground isn't going to have a different weight limit than the floor, whereas a shelf might), and possibly a maximum single unit volume (so for example you couldn't put a crated piece of furniture inside a box). Lots of other potential added play from having weight and volume (stronger characters get more functionality through higher weight capacity, since melee combat isn't as likely to matter in a space based game, and characters could have backpacks or similar things to increase their volume capacity).
Of course pretty much all of these potential choices and ideas have further follow through ideas and questions, but no need to lay out absolutely every consideration when I don't know where others stand.
phoave
Going forward, I want to see milestones be no more then 3 major features that we are going to focus on if possible. They should be issues that are going to take about a month to resolve, and be single focused if at all possible. No major changes should be done that aren't in the milestone if possible.
I propose for the 0.4 milestone that we make these areas our focus. These might be edited at a future date, per comments below.
Stretch goal:
UI
The UI is currently in a very poor state. We have at least 4 very different types of menus, all of which are quite complex and difficult to manage. I propose that we take a look at the game and re-think it all. Right now the look of the UI is less important than the functionality, but we should give at least a thought to how it looks. In other words, UX over graphics.
There will be several parts to this. One of these is the Dialogs box being created from JSON. A second will be how the menus are organized. Some thought should be given for different resolutions.
Temperature/ Room improvements
This is really resolving the issues expressed in #240. That says it all.
Fluids/ Utilities
Right now these aren't particularly consistent. The graphics are horrible, and it is very difficult to know if you even have connections. The fluid connections don't do anything that I can find. We should discuss things like how many tiles away you can have something plugged in and still work, or anything along those lines.
Stockpiles
Right now stockpiles are a mess. Stuff gets deposited anywhere, often taking up the space. A character will often grab 4 things when more are available, and dump them in to a machine, while it could take more. The next tax the character will grab practically an entire stack. Let's think about this some more.