Chat/Macros

ID:260429
 
Sep 14 2007, 9:27 pm
there are old games nobody wants to change, and i wanna be able to use my macros on them, but every time im trying it doesnt work right, cause the macro thing wont stay in the chat area, i suggest u can edit the chat area to show anything you want, so that if u press enter, like say does, it just stays in the chat area...
Sep 15 2007, 2:43 am
Super Silly Stuart wrote:
there are old games nobody wants to change, and i wanna be able to use my macros on them, but every time im trying it doesnt work right, cause the macro thing wont stay in the chat area, i suggest u can edit the chat area to show anything you want, so that if u press enter, like say does, it just stays in the chat area...

Keyboard macros won't work alongside an input control unless they use keys the control won't need. Enter, backspace, space, and I think tab won't operate as macros when you have text in the control, which is a good thing. People have actually requested that even standard letter-key macros behave this way, but in reality even BYOND 3.5 never supported that. (It had macro mode instead, which is actually still available.)

Why not use a different macro like Alt+enter or Ctrl+space or some such that won't interfere with the input?

Lummox JR
Sep 16 2007, 7:30 am
In response to Lummox JR
i need to enter macro mode.... on 4.0 ... the button for macro isnt even here.... also, without anything in the chat area, macros half the time dont work, and when u type in the macro thing, if u press enter, even though the macro thing is typed, it will still make it what the default is (nothing at all typed) so i need to enter a macro mode in 4.0..

also, one more thing.... i was asking it to be so u can make whatever show up u want in the text area by default, so like Say " could become Wsay " or some macro like .alt and such like this, so that u can do stuff easier, such as macros, and talking, via wsay, and stuff like that.
Nov 23 2007, 9:19 pm (Edited on Nov 26 2007, 12:20 pm)
In response to Lummox JR
In my current predicament, I'm using an interface window as an alternative input(). Everything works well now EXCEPT that normal input()s use the enter macro as an alternative to pressing the "Okay" button. This is something I apparently can't simulate because my window uses input elements.

Rather, when people open my window, see that the default choices are acceptable, and hit Enter as they habitually do, the input clears. Kind of annoying. Worse, if you hit Enter twice, since the input element has already been cleared, it registers the Enter macro and "Okay"s the window. Whoops, you just sent the wrong information, because the first input element thinks you emptied it on purpose.

It would be really nice if input elements came with an extra little checkbox which determines whether they override macros or not.
Nov 26 2007, 4:15 pm
In response to Foomer
Your input should have a default command even if a button is used to submit the text. That command can be made to submit the the text as well, in case the player hits enter when it has focus instead of the button.
Nov 26 2007, 7:28 pm
In response to Xooxer
Yay, that works. At least so far as I can tell, without any notable side effects.
Nov 26 2007, 7:49 pm
In response to Foomer
It should be fine, since DS sees the same command no matter if the button was clicked or the text input was Entered. There is a side-effect of not including a default command. Actually, a few side-effects. One of them being that the player can enter commands into an input with no default command like they could for a default input. Also, you can't type a space if no default command is set. This just harkens back to it treating the input as a default, but it can be bothersome if you're not aware of the problem.

~X
Nov 26 2007, 8:29 pm (Edited on Nov 26 2007, 8:36 pm)
In response to Xooxer
Actually I found a problem with this.

I'm using my custom interface window which has three inputs, and the player is supposed to fill them out and okay it. Now, I'm setting the input's default command to something that looks like this:
command='byond://?src=\ref[src];confirm=true'

Now, when the window first opens, one of those inputs is going to be selected - whichever one was modified last. When the window is read, it checks to what the values for each of the inputs are, and if they're not all numeric values then they are considered to be 0.

So the player enters three values and hits 'enter'. Two of the inputs are read as numbers, while the third runs its default command (which okay's the window), but then clears the input since a command was entered. Next, the inputs are read to see what their values are, and they all have acceptable numeric values except for the input which was selected and is now cleared... That one's blank, and always 0. So its basically impossible to fill out the entire window while pressing 'enter' to OK it.
Nov 26 2007, 8:43 pm
In response to Foomer
Each input should submit it's value when entered. I usually use a command for this, but it should work the same for Topic(). When the command is executed, I check to see what value was passed with it, if any, and use it as the input for that element.

So, each input would have the submit command, and a parameter that's passes it's value with that command. The command would accept a value, and if none is passed (the button was clicked), winget() the values as normal. Otherwise, assign the passed value to the proper element and winget() the others.
Nov 26 2007, 9:05 pm
In response to Xooxer
This is the reason why decent games on BYOND are so darn rare. :P
Nov 26 2007, 9:07 pm
In response to Foomer
Yeah, greatness does not come easy. Just be glad to know that the more thought you put into a game, the less likely it will be that anyone will come close to matching it.
Nov 26 2007, 9:10 pm
In response to Xooxer
Yeah but having things that should be relatively simple in concept, like reading the values from a bunch of inputs elements to create your own input window, turn out to be ridiculously complicated isn't going to encourage anybody to use them, which is a shame.

I'd still just like a little toggle on the input elements to determine whether they respond to 'enter' this way or not.
Nov 26 2007, 10:13 pm
In response to Xooxer
Incidentally I don't really follow what you're saying here.
Nov 26 2007, 10:29 pm
In response to Foomer
This will not work with Topic(), now that I think about it. You'll need to use a hidden verb. And some way to tell which input the text is coming from.

// t is the value of the input     ie: "5"
// input is the name of the input  ie: "input1"

mob/verb/GetInput(input as text|null, t as text|null)
    set hidden = 1
    var/input1
    var/input2
    var/input3
    if(!t)
        input1 = winget(usr, "input1", "text")
        input2 = winget(usr, "input2", "text")
        input3 = winget(usr, "input3", "text")
    else
        switch(input)
            if("input1")
                input1 = t
                input2 = winget(usr, "input2", "text")
                input3 = winget(usr, "input3", "text")
            if("input2")
                input1 = winget(usr, "input1", "text")
                input2 = t
                input3 = winget(usr, "input3", "text")
            if("input3")
                input1 = winget(usr, "input1", "text")
                input2 = winget(usr, "input2", "text")
                input3 = t
    // continue as normal...


Then, set the default command for each input to the above verb with the name of the input in quotes:

Default Command: <code>GetInput "input1"</code>

The button would simply call <code>GetInput</code> with no parameters.

That passes the "input1" to the GetInput() verb as the first parameter. The text entered into the input will be passed as the final parameter, t. If t was not passed with the command call, then the button was pressed instead, so winget() the values from the inputs, as I assume you currently do.

Otherwise, t is the value of the input named in the input parameter, so set it accordingly and grab the other two values with winget.

You can make the verb part of the input datum, and add and remove it from the mob's verb if you like, but it must be a verb accessible by the player.

~X