Keypads

[Edymnion]

Okay, as I build ever bigger and better things, there is something I have repeatedly wished I had.

A keypad block.

As in a single block that when you hit it brings up a little screen with a standard numerical keypad. Way I envision it working is you slave activators to it, and the number of slaved activators determines how many numbers show up on the interface. You slave 3 activators to it, you get buttons for 1, 2, and 3. You slave 10 to it, you get a full number pad.

When you press a button, it would then turn on the corresponding number of activators that are slaved to it. As in if you had a full number pad 0-9 and you pushed 4, it would activate 4 out the 10 slaved activators.

Why?

Multiple floor elevators get very cumbersome when you need multiple control buttons on any given floor, while having a wall full of buttons to create a password keypad for logic based rail door locks is awesome, but annoying.

I could also see it being useful for controlling fighter bays where you punch in which bay you want to launch instead of having an entire room full of buttons.

 

[Alphajim]

It can even be useful to modify easily a sensor's trigger percentage.

You can use screens to make passwords.

 

[Cluwne]

So basically you want a system that allows custom-built GUI, is that right?
Because being able to wire most of ship's logic to a single terminal with said GUI and have it be all neatly laid out, with buttons, indicators, labels and text fields that interact with display blocks would be freaking awesome.
And if it supports shield and power commands from displays in labels, and can be accessed from hotbar when connected to core, it's going to be a boon for everyone, from RP crowd and logic enthusiasts, to PvPeople and station managers that enjoy micromanaging docks and factories.
And like armor blocks, this "terminal block" should have various shapes, like the decorative console we have now, small keypad and so on.

Though facilitating input and output of multiple signals might be tricky. It would do the game good in the long run to finally add multiplexing for logic signals. If anything, it will reduce the amount of wiring we'd have to do whenever we're (re)building something with lots of logic circuits.

 

[Edymnion]

It can even be useful to modify easily a sensor's trigger percentage.

You can use screens to make passwords.

You can, but its less useful for elevator controls.
[doublepost=1531319047,1531318617][/doublepost]

So basically you want a system that allows custom-built GUI, is that right?
Because being able to wire most of ship's logic to a single terminal with said GUI and have it be all neatly laid out, with buttons, indicators, labels and text fields that interact with display blocks would be freaking awesome.

Especially if we could get fleet commands hooked into logic. Make a keypad that you can hotbar and bring up to have your most used commands there on the screen in an easy to click fashion.

Especially if we could rename the buttons in the GUI like we do an inner-ship remote. For elevators, "Floor 1", "Floor 2", for fleet logic "Mine", "Defend", etc.

Lots of logic controls in one simplified interface. You still have to build all the controls via blocks, this would basically just give you an easier way of selecting which "do this" button you press without having to physically walk around a room to push them.

 

[NTIMESc]

I love this suggestion for an interactive screen, but I would like to see the existing Display Module get an upgrade to allow this sort of interactivity, so it behaves more like a touchscreen display that you would expect on a starship. (I'm imagining it like the screens in PULSAR: Lost Colony, except customizable) Then, new variables, like [keyPad], or [radar], or [targetInfo] could be added. Throw in a few more basic tags (<div>, <table>, etc) and formatting attributes (id, align, etc.) and voilà! As a bonus, avid Citizens are learning the basics of xml/html while they play

For naming the controls, it would be like <div id="Main Elevator">[keyPad]</div>
Mockup:

 

[Cluwne]

I suppose interactive display elements and display programming is better than nothing. In that case I would appreciate if display's display side couldn't be used to access the block, so you wouldn't accidentally open up it's menu if you miss the button.

Two things I would like to see if Schine went with display programming - "holographic text" bug/oversight fixed, and a proper holographic projection mode added. so we can have the futuristic displays we want, preferably scaleable, so we can have tiny nameplates as well as ship path markers in hangars, and have the background color tag for the main "screen" and the various elements.

 

[Alphajim]

Two things I would like to see if Schine went with display programming - "holographic text" bug/oversight fixed, and a proper holographic projection mode added. so we can have the futuristic displays we want, preferably scaleable, so we can have tiny nameplates as well as ship path markers in hangars, and have the background color tag for the main "screen" and the various elements.

Yes please, it would be infinitely better than the actual "bug" holo screens !

 

[Lone_Puppy]

Nice!
A number pad I have been wanting a long time now, but this idea is even sweeter!
I want number pad block for locking control over systems, doors, storage or whatever.
You use of activators makes it more versatile for me even more.

 

[DrTarDIS]

mmm would be nice to have "smaller" logic blocks for sure. Still can't figure out why we can't compress 27 logic blocks into a 1m space occupied by 1 regular block...

 

[Edymnion]

mmm would be nice to have "smaller" logic blocks for sure. Still can't figure out why we can't compress 27 logic blocks into a 1m space occupied by 1 regular block...

I'm guessing the main reason is I/O.

If its all one block, how do you link it up to everything else?

The usefulness of compressed logic dwindles quite a bit when it comes down to "Can only have one input/output". There's still stuff you can do with it, but generally speaking by the time you need that level complexity that it would be worth shrinking, its doing more than one thing.

 

[DrTarDIS]

I'm guessing the main reason is I/O.

If its all one block, how do you link it up to everything else?

The usefulness of compressed logic dwindles quite a bit when it comes down to "Can only have one input/output". There's still stuff you can do with it, but generally speaking by the time you need that level complexity that it would be worth shrinking, its doing more than one thing.

...Same 1/0, same c->v, just compressed logic down a step. Logic/connections already functions as it's own "layer" there's very little reason it can't be "shrunk" and given equivalent coordinate mapping. I'm not following single input-output, since that's never been a thing with logic...just look at button-> n+1 activators -> all n+1 activators into single flip-flop -> that flip-flop to a flip flop chain "counter"
That's a signal-booster or frequency multiplier, depending on how you want to name it, and it's been a thing since logic was introduced(also a core part of jump-drive/inhibitor technology for higher-end builders till the devs limited activation states on modules).

Several other voxel games already do this or equivalent. EG Empryon, Avorion, Skywanderers, etc...

Really, having a small "button" the size of the button shape ON the block texture, with up to 26 other logic blocks inside the area would be a huge boon. Heck, I'd be just as happy with a "logic node" block as "anchor space" for collision-checks that had a solid center and just let you fill the rubix-cube faces of it with the other logic. Most of my circuits come out to 15-25 blocks in any one area to be "useful."
EG: auto doors: Area triggers or gates-> their controller -> activator <->button(auto-reset) -> delay chain (how long open state) -> delay-chain and button -> OR (blue as long as anything activated in time-frame, can be "kept open through repeated trigger events like n+1 astonaughts passing through doorway) -> optional "and" for a "lock" -> rail logic
Same can be said for elevators etc...
Your keypad is a prime example: Being able to have 9 buttons on one face, link 3 lines to 3 OR, 3 columns to 3 more OR, and still have 10-11 more blocks left to cross-poll towards your output logic.

Right now the dirty workaround is a display, activate, type a preset command and have a sensor trigger off it, but that's just a workaround.