Text entry is a long-awaited feature in the game, with the only current text entry field being questioner kits. Now, these kinda work, but they aren’t very good for a chat system, per se.
Now, @Apoll02 already made a keyboard with their post How to make a Neon KeyBoard, but it used an absolutely colossal amount of memory, and was incredibly impractical in an actual map. However, I have a much simpler alternative that doesn’t require anywhere near as much memory.
This is going to follow a new guide format that I’ve just decided I’m going to use. It first starts out by listing the goals, then concepts, then it lists the building part of it. Let’s call it the shdwyian technical guide format.
LET’S BUILD A KEYBOARD!
This is purposefully not very descriptive as to exactly what you’re supposed to build. You gotta figure it out! If you need help, someone can help you, but this is trying to encourage you to figure something out yourself instead of getting other people to do it for you. Problem-solving skills are useful for everyone.
Have fun!
Goal
We want a way for the player to be able to input text.
Specifically, we want a way for the player to input each individual letter, along with caps, spaces, and punctuation. This needs to be in the most convenient form possible and should use minimal memory.
Breakdown
Here’s a list of the systems we’ll need.
First, we want to be able to choose what letters get inputted
Inputting
This system will be pretty simple. All we need is to a) filter each different letter to a different signal and b) to store the data for each letter.
We start out the same way that Apollo did. Make a buncha buttons. Each button will transmit on “letterA” or “letterB” or whatever.
You can repeat this however many times you want, but for our purposes this is going to use only 3 buttons. (Proof of concept, ey?) A, B, and Shift. All of the other characters have the same exact method of importing, so you don’t really need anything else.
Recap: 3 channels for 3 buttons. “inputA”, “inputB”, and “inputShift”
Processing
Alright, now we’re getting these signals, so we need a way of differentiating them. There are a ton of ways to do this.
However, the most efficient uses counters. Each counter will be set at a different value, so the one corresponding to A will be set to 1, but the one for D will be set to 4 at default. Then, it increments on whatever channel it’s correlated to.
Finally, when it resets, it not only updates the property, but sends a signal out to the compiler.
Now that you have the information, you want to unpack it.
Unpacking
This is the system that appends the text to the property. This section contains all the actual code, so if you’re allergic to that, this is where we part ways.
If not, what you need is relatively simple.
Here’s the psuedo-code:
if shift was pressed, modify the property to make sure you account for it next time the player inputs a letter.
if not, process the number based on what exactly it is. If it’s 3, for example, set a variable to “c”. If it’s 103, set it equal to “C”!
Then, just create text using the previous message and this added letter.
Displaying
This part is incredibly simple. Use a text device, and when the main message updates or when the player says to send out the message, set the text to the message.
You’re done!
If you have any ideas for a more efficient processing system that doesn’t use a TON of blocks, let me know. Right now, the mem efficiency value is 75n + ~1000 where n is the number of input letters. Can we beat it?
SHOULD WE ADD A technical TAG?
- yes
- no