Text Entry System

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. :smiley:

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
0 voters
20 Likes

This looks good!

3 Likes

Oh wow! This is :sparkles: excellent :sparkles:

5 Likes

nice guide this is a good remix of @Apoll02 guide.

2 Likes

This is quite rad!

1 Like

What is the the first processing option and the second?

Also, this is really useful for maximal data capacity.

4 Likes

First one was a trigger signal splitter, one output to a hooked counter to set the current property to whatever, and then one trigger to take current and append it to the actual message.

The other was counter stacking, which would look something like this:

5
4 4
3 3 3
2 2 2 2
1 1 1 1 1
A B C D E
and so on

this is to save the data by having a value of 1 for e, 2 for d, and so on, but it’s way less efficient in every even semi-large system.

What about counters default x and target x+1 and they reset on target? They would receive on “a”, “b”, “c”, and so on. There is a delay on the trigger that adds to the total property.

1 Like

yeah, that’s what the trigger splitter uses. OH WAIT!
Then you could just have the reset signal also hit the processor. NICE!
Alright, it’s now down from 105n to (25 + however much buttons cost)n

As for the thing about the reset signal changing the property as Rithek said, that’s not a problem. He meant that all the counters would reset at once and possibly skew the current property, but that’s not an issue. (just tested it.)

I’m a bit concerned that the reset signal counts as “changing” the property.

should this be in Community Made Guides?
Also this is amazing.

I would seem like there is quite a liking for a technical tag.

Nice guide, @Shdwy! :grinning:

1 Like

I was going to make a Keyboard guide too, but I have a way just with. popups and one property, and not much else…

1 Like

noice now i don’t have to make a large not-memory-efficient keyboard

tbh

speaking of tags and stuff like that, the devices section should probably be renamed to the wastelands/off-topic posts bc the majority of the posts here are off-topic and has been reguarded several times as the “wastelands”

1 Like

I’ll add a technical tag if people want it…

2 Likes

It seems that people want it.

lol

Also, how does your popup thing work?

Adding it, then.

One property, CTAs edit the property, thousands of triggers and popups