Switches Shouldn't Require Dupe Interaction

[Rebrait]

Could be like the real world where there is a sensor and a control panel for automation!

You place the sensor in the area to be measured and connect it to the control

 

[Craigjw]

18 hours ago, beowulf2010 said:

It's not that I want it, but that it makes sense that the dupes have to set the sensors. 

If dupes have to flick a switch, set a door's permissions, stand on a floor switch or make a change to the flow rate on a valve, the why would sensors magically set themselves? 

How's this for a middle ground. All sensors, valves, doors, switches, etc have to be dupe set for consistency's. But, there is a new building that takes plastic and refined metal that costs at least 800W called an Automation Control Console that removes the need for dupe interaction, just like turning on debug mode. 

All in all, it needs to be consistent. 

It sounds to me that you are having a difficult time realising that ONI is not a real physics simulation.  The salient point to consider is that play-ability is king, not sensibility.  If something makes for good game play, it doesn't matter if it makes no sense.

I don't see a problem in making the switch player controlled, we've already accepted that sensors work the way they do and I don't hear uproar to contrary to make them dupe controlled.

In general people don't want to play a game that has obtuse or awkward game play mechanics, the difficulty should come from mastering an emergent complexity arising from simplicity of game design.

[beowulf2010]

I am seeing this from a game play perspective. For me, ONI is a cross between Terraria and Lemmings. There isn't room for Populous/Dungeon Keeper style divine direct control which is pretty much exactly what player controlled sensors are. 

Me, the player, is just a representation of the collective consciousness of the dupes trying to survive on their own. 

Note: Because of this, everything I build is dupe accessible via (at most) deconstructing a couple tiles after building a liquid airlock. 

Anyway, like I said, it's not that I'm actively campaigning for it, just that I believe that it should be this way. In the long run, what Klei decides is fine with me either way. 

[UberFubarius]

I think this is the case where a compromise would be great. 

Having dupe walk up to a sensor to update it is tedious. However the current system is a bit "cheaty".

Maybe have it behave like a remote control system? Have all sensor require dupe operation. However dupe can "operate" sensors at a range of 10 blocks and doesn't need line of sight.

 

 

[beowulf2010]

19 minutes ago, UberFubarius said:

I think this is the case where a compromise would be great. 

Having dupe walk up to a sensor to update it is tedious. However the current system is a bit "cheaty".

Maybe have it behave like a remote control system? Have all sensor require dupe operation. However dupe can "operate" sensors at a range of 10 blocks and doesn't need line of sight.

 

 

Yeah. That seems like a reasonable middle ground and is something I mentioned earlier in the thread. 

[greggbert]

I think the current setup is a reasonable middle ground TBH.  I create switches because I like the immersion of them and the visual on/off cue.   I don't feel the need for dupes to manually adjust sensor settings, but then I don't tweak sensor settings in order to avoid dupe interaction.  IE  I don't use my ability to change sensor settings as a hack to avoid enabling or disabling something manually or flipping a switch.  I see it more like setting the preferences of a container.

I guess if I don't have a problem with dupe not interacting with a container to change settings, then I don't have a problem with changing sensor settings manually.