Input Prompt Events

[Niliscro]

In short, an event which prompts the user for input in the form of a string.
Detailed description:
An event with two parameters.  The first parameter would be for the title of the input gui, and the second would be the text to display on the input gui.  See MessageBoxOK for clarification.

When this event is called, a gui similar to the prompt guis would appear on the user's screen.  It would have a title and message depending on the two parameters, and a text input box where the user can type in their input.  There would be a "submit" button immediately under this.

Also, there would be an "ifUserInput" output event, an "onInputValid" and "onInputInvalid" input event, and an "onInputReceived" input event.  Preferably, the ifUserInput and onInputValid/Invalid events would not be enabled if the server is using VCE.  However, this would require a VCE_ifInput event.

Uses:
Cleaner user input, rather than using the VCE_ifLastMsg (Or whatever it is called) which requires the user to publicly say their input and can be the antithesis to making a successful "speak to control" challenge.

It can also be used to make better shops in RPs; whereas we currently need to have display cases that can be selected or numerous buttons to press, the Input Prompt events would allow for a simple, compact system that lets the user simply type the item they wish to purchase.  Mind you, this does not merely apply to CityRPs, it can also apply to other types of themed RPs.
Of course, those are only two common-use suggestions, and I am certain that more uses would be found if this is ever made.  Feedback is appreciated.

[Ad Bot]

[Dapizzanator]

That sounds like a good idea; I'd download it.

[Devvy]

I second this

[Niliscro]

Bump.

[Demian]

Events (Output)

• Name pending |textbox|

Here's an example.

You have made a password protected door for your clan. You have told the password to your clan members so they can enter it. You click the door and it asks for a password. But. You can't type the password into chat because there are people on the server who are not in your clan and they would see the password.
For this situation you need a "private chat" event.

You add that event to the door and click it again. It asks for a password, you type it into the chat and send it. Now, because the door has VCE parameter "<var:client:lastmsg>" and the variable is the password, the door opens and nobody but you saw the password in the chat. Now you can chat freely as the "private chat" event is disabled after one chat message. Optional feature to the event is the textbox, where you can type the amount of message to be private. E.g. "6", so the next 6 messages written to chat can only be seen by you and the events.

What happened is that the "<var:client:lastmsg>" read the latest message you sent, in this case the door's password, regognized it and opened the door. Because of the "private chat" event, only you and the events saw that message. Nobody else.

I'd like this one too.

[lilboarder32]

The reason prompt events and messageBoxOk work so well is because everyone has the gui's by default. The problem with this is that everyone would need to download a custom gui for it to show up for them. You could easily do this with the RTB Gui downloading, but not everybody has RTB. You might also be able to find some way to "hack" up the admin password gui, though.

[Niliscro]

You might also be able to find some way to "hack" up the admin password gui, though.

When I created this topic I had that in mind, considering that it's a gui everyone has.

[AGlass0fMilk]

The reason prompt events and messageBoxOk work so well is because everyone has the gui's by default. The problem with this is that everyone would need to download a custom gui for it to show up for them. You could easily do this with the RTB Gui downloading, but not everybody has RTB. You might also be able to find some way to "hack" up the admin password gui, though.

There's most likely a not-so-hacky way to do this that is easier.

For example, have it set so when the door (or whatever you're using) is activated, the player has a specific amount of time to say the password, and if they say the keyword the object is looking for, the message gets intercepted, not shown to everyone, and the object does whatever happens when the person inputs the correct password.

You people seem to believe that you need GUI's for everything, but the truth is GUI's usually make things way more complicated than they actually need to be.

[Niliscro]

There's most likely a not-so-hacky way to do this that is easier.

For example, have it set so when the door (or whatever you're using) is activated, the player has a specific amount of time to say the password, and if they say the keyword the object is looking for, the message gets intercepted, not shown to everyone, and the object does whatever happens when the person inputs the correct password.

You people seem to believe that you need GUI's for everything, but the truth is GUI's usually make things way more complicated than they actually need to be.

I would prefer a gui, I never said it was needed.  It gives the player plenty of time to type their choice without the question being lost as more people chat.

[Niliscro]

Bump.

[AGlass0fMilk]

Having a GUI would cause more trouble than it's worth.

[Demian]

My suggestion doesn't use a GUI.

[Niliscro]

Even without a GUI, the concept in of itself is something that I find useful.  The main reason that I wanted a GUI was to have it blend with the other prompt events.

[Niliscro]

Bump