Jump to content

Additional Depth and Customisation for Existing Feature Sets


Recommended Posts

I think that ONI is already a fantastic and rich simulation. Several things that could be nice to see have occurred to me while playing that I (perhaps naively?) believe should be relatively simple extensions. I'm sure some will have mentioned before so I'll be concise.

 

  1. Sensors for Pressure/Temp/Flow Rate - Exactly what they sound like; sensors that read out the given parameter at a particular location. These would provide additional options for automation particularly if comparitors were included (see #2). I think the important thing in implementation is to include user selectable time averaging of the signal to ensure the correct level of stability / sensitivity.
  2. Comparitors - Right now many automation features compare to static user defined values. An extra layer of depth could be added by allowing input signals to be compared to one another; "greater than", "less than" and "equal to" are the obvious choices. Again for slick implementation this should have a user selectable tolerance range, although this could be another object "offset". e.g. A > B by at least 500. e.g. A > B + C
  3. Pre-automation gas / liquid handling.- You already gas / liquid shut offs and it looks like your piping implementation is based on discrete flow so I guess that it might be nice to see a "downgraded" version in pre-automation that would act as a pressure relief valve when a pipe determines that flow is blocked. Similarly while it is possible to automate switchable flow (especially if you included suggestions #1 and #2) a gas and liquid manifold with a duplicant operated switch could be nice to direct flow in direction A or B.
  4. Element Sensor - Exactly what it says; read out what element is present in the tile. Again, I think the important thing in implementation is to include user selectable time averaging of the signal to ensure the correct level of stability / sensitivity.
  5. Med-bed - Seems like this could easily call Dupes to attend when they have health less than a user defined value, the same as for a massage table.
  6. Deconstruction Priority - Seems like this has priority 10. Could you allow users to customise this value?
  7. Red Alert - You could make this a "job" to allow user selection of whether a Dupe will respond to an alert, This would allow players to attempt to repsond to a situation without placing non-essential individuals into danger in order to accomplish whatever this urgent matter was.
  8. Yellow Alert - You could make a separate level of alert with user selectable options for what basic needs will be over-riden. e.g. I don't want a Dupe to choose to suffocate, but I do want them to ignore hunger, stress... etc
  9. Drop off point for Resources - Otherwise known as "deliver here" but without a storage compactor. At present I cannot think of too many uses for this beyond delivery to a hatch area, but I'm sure more experienced / creative players can think of a reason to have a centralised stockpile of resources which is open to the environment.

Anyway - just some thoughts.

-Mike

Link to comment
Share on other sites

10. Status / Running Sensor - This would allow the equivalent of conditional "On Error" automation. You could offer user customisation of which conditions report as error. e.g. default all ticked, but I choose to untick "pipe blocked" because I have a separate overflow system implemented.

11. Alert Sensor - You could add a separate sensor that allows user customisable alerts similar to the "Starvation" / "Suffocation". I could see this being in a separate colour to differentiate them from the default system alerts. This would probably warrant its own automation research, and could require a building ("Broadcasting System" or "Speakers" or "Tannoy" or something) - this could have power requirements to put a cost to not fully automating / safeguarding, or even require manning to receive alerts if you wanted to put a late game cost on it.

12. If you really want to extend the alert system (see  #11), then this could easily become a "radio" overlay, with signal attenuation based on materials and new buildings such as "repeaters" / "signal boosters" to boost the signal. This could provide a mechanism for more social interactions, and an entirely new branch of research (heck it's the basis of an entire "radio" update if you want it to be).

  • Early game could have point to point comms needing separate wiring.
  • Early - Mid game could have broadcast towers
  • Mid - late game could have repeaters and a separate research branch to allow normal wires to also work as comms wires ("comms over power")
  • Late game could tie in with automation (see #11)

The question is what would be the point of this? I don't know what mechanisms you're planning on using for your social interactions, but if the Dupes are required to "call" to initiate certain types of behaviour then this Radio overlay could be a useful direction. Other suggestions of potential mechanisms included:

  • Research required to turn on Dupe in danger system alerts ("Distress beacons" / "lone working alarm" ?) - this would put an additional danger into the world through to the mid-game. Players would have to choose whether they want to prioritise a safety net. I'm not sure if you have a Dupe vision background mechanic implemented/planned, but it could be that personal radios would allow OTHER Dupe's to raise the alarm if they "see" the condition , but not the troubled Dupe themselves unless they had a specific research - along the "Lone Working Alarm" theme. Without vision this could still be done on a proximity basis, providing upgrade research options as well as different atmo suit type potential.
  • Labour KANBAN systems - with what I can understand, currently I think this would only apply to labour. You could make it so that a Dupe doing a priority specific task would not be replaced on that task for a delay period (which allows you to balance this), unless he had other Dupe's a "receiver station" ./ "break room" / **something else?**. This would give a reason to need Dupe's to be idle / on call (potential job? potential room type with own furniture?).
  • Resource KANBAN systems - The above can be expanded to resources. Right now Dupe's just know when a building is out of a particular resource. If a vision mechanic is planned then this one is easy. Otherwise you could just make a labour requirement (which would require higher numbers of Dupe's to ensure smooth running of a colony (incentivising automation, and increasing the difficulty scalability). Either way, this could create 2 new job types: "Janitor" (e.g. going around topping up Algae etc) and "Foreman" who could have his own building type for a "post" that allows him to monitor everything in a new "industrial" room type - requesting resources as they run out. Pre-radio this requires them to leave their post and get those themselves, but after radio they can request one of the "on-call" to do it for them. Late game research could allow potential automation of this Foreman role.

There is loads of additional potential in this concept as I'm sure you can appreciate. I'd be surprised if you didn't have something along these lines in your roadmap already - but if not, perhaps there is useful scope here. Thoughts?

Link to comment
Share on other sites

On 31/12/2017 at 5:25 PM, MykeMyke said:

4. Element Sensor - Exactly what it says; read out what element is present in the tile. Again, I think the important thing in implementation is to include user selectable time averaging of the signal to ensure the correct level of stability / sensitivity.

Time averaging or density threshold can set by other sensors and automation. An element sensor should just do it's purpose. Return a true when the selected element is detected and a false if not.  

Link to comment
Share on other sites

1. Sensors for Pressure/Temp/Flow Rate

  • Pressure sensors are in the game.
  • Temperature sensors are also in the game
  • Flow rate might be nice. Would need both gas and liquid forms.

2. Comparitors

  • This is already buildable from current automation parts, although only by using many sensors and booleans. Might be nice, but it might also be too automated for the game.

3. pressure relief valve when a pipe determines that flow is blocked

  • What would this actually behave like, exactly? If it just dumps liquid into an area when another thing at the end of the line is full, then you're (almost) doing the same thing as just having one pipe that feeds your machine and also a liquid vent.

4. Element Sensor

  • On the one hand, this would be useful.
  • On the other hand, I just want partial gas pressures instead of these discreet blocks of gas (and liquids).

5. Med-bed - call Dupes when they have, same as for a massage table

  • This just seems like small piece of UI that's missing from an item in the game, yes?

6. Deconstruction Priority

  • Is this a bug? You can set priority on deconstruction orders, and it seems to work just fine for me. (Or maybe I never noticed.)

7. Red Alert - make this a "job" and 8. Yellow Alert

  • These both seem really fiddly, very niche, and unnessessary.

8. Drop off point for Resources

  • This would need a range set on it, for minimum distance to gather resources from, otherwise it would instantly result in dupes in an infinite loop, gathering resources from that tile and re-dumping them.
  • Would also need a max range, for usability.
  • Since this is basically just for hatches, maybe just make a feeding trough item that creatures can eat from?

10, 11, 12, and below.

  • This all seems overly complex and very niche.
  • Would be a tonne of work to put into the game, for comparatively little benefit, and the very likely potential to confuse new players.
Link to comment
Share on other sites

On 04/01/2018 at 3:49 PM, Saturnus said:

Time averaging or density threshold can set by other sensors and automation. An element sensor should just do it's purpose. Return a true when the selected element is detected and a false if not.  

I'm sure that's true - it's beyond me, and I suspect the majority of players. I guess it's a personal choice on the barrier to entry for players.

 

On 04/01/2018 at 4:33 PM, AileTheAlien said:

1. Sensors for Pressure/Temp/Flow Rate

  • Pressure sensors are in the game.
  • Temperature sensors are also in the game
  • Flow rate might be nice. Would need both gas and liquid forms.

2. Comparitors

  • This is already buildable from current automation parts, although only by using many sensors and booleans. Might be nice, but it might also be too automated for the game.

Actually this isn't in the game. Right now sensor compare to a fixed value to output true or false. I don't think you can build a digital comparitor for it because you don't have the actual values as an output, just the true or false signals from the sensor.

 

On 04/01/2018 at 4:33 PM, AileTheAlien said:

3. pressure relief valve when a pipe determines that flow is blocked

  • What would this actually behave like, exactly? If it just dumps liquid into an area when another thing at the end of the line is full, then you're (almost) doing the same thing as just having one pipe that feeds your machine and also a liquid vent.

I believe ONI physics doesn't calculate pressure in liquid flow, just volume; that's  why the valve allows you to set a flow rate. So you can't have a pressure relief valve / back pressure valve. This is problematic as the liquid valve there is at the minute is always on at the level you set. So you actually need a valve which assesses a node and detects when the volume in the packet below (limited by liquid type and perhaps in the future pipe type) is less than the liquid transferred to the node above (limited by line physics downstream). This then allows you simulate a check valve without having to break into the physics coding, but just sampling.
 

I did see that CrypticFox found an exploit to solve this where flow preferentially selects a liquid bridge over standard pipe at a junction for no apparent reason. That allows you to put your main path after the liquid bridge and your pressure relief line to a simple vent.

On 04/01/2018 at 4:33 PM, AileTheAlien said:

10, 11, 12, and below.

  • This all seems overly complex and very niche.
  • Would be a tonne of work to put into the game, for comparatively little benefit, and the very likely potential to confuse new players.

Perhaps, but I'm sure the same was said of every feature set! The point here was to come up with something that is neatly defined without interdependency of the existing material that could be worked on as a discrete work package. They have more updates coming after all!

Link to comment
Share on other sites

6 hours ago, MykeMyke said:

I don't think you can build a digital comparitor

You could, but it would require a lot of automation pieces. First, make different pressure sensors so you have enough resolution for your needs. e.g. One that trips at 200 g, 400 g, 600 g, 800 g, 1 kg. Make one set for each thing you're comparing (i.e. room 1's pressure, and room 2's pressure). Next, build the boolean logic such that if room 1 has higher or equal pressure it outputs a 1, and outputs a 0 if room 2's pressure is higher. (I'll leave that as an exercise for anyone with a lot of time on their hands.)

Link to comment
Share on other sites

3 hours ago, AileTheAlien said:

You could, but it would require a lot of automation pieces. First, make different pressure sensors so you have enough resolution for your needs. e.g. One that trips at 200 g, 400 g, 600 g, 800 g, 1 kg. Make one set for each thing you're comparing (i.e. room 1's pressure, and room 2's pressure). Next, build the boolean logic such that if room 1 has higher or equal pressure it outputs a 1, and outputs a 0 if room 2's pressure is higher. (I'll leave that as an exercise for anyone with a lot of time on their hands.)

I hadn’t thought about such an impractical solution, but you’re right that you could approximate it that way! I guess the point of what I was suggesting was to make it easier to set up conditional multi variable automation. After all, I want the functionality for an actual game not dev mode. Good creativity though!

Link to comment
Share on other sites

For the drop off point, I feel like in the UI if you click on a pile of material next to the sweep button should be a “move to” button that works the same way as the one on the dupes does. It could cue a “sweep” that gets dropped where you ask.

Link to comment
Share on other sites

20 hours ago, Cypher-7 said:

For the drop off point, I feel like in the UI if you click on a pile of material next to the sweep button should be a “move to” button that works the same way as the one on the dupes does. It could cue a “sweep” that gets dropped where you ask.

Like... really, we cando this via compactors then why not doing this via move to? if game has got mechanicsthat allow some actions to happen why not adding that action and ease people`s life? or add "drop down point" fo items.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...