Oct 20 2013, 12:08 pm
|
|
Kaiochao
  |
Let's talk about what happens when you scroll quickly. It's very easy to be sending more than one scroll input per game tick/frame, so how should it be handled? As an argument for "scrolls in the last tick?" Or maybe the proc is called multiple times in one tick?
|
Generally I think trying to tie into the current parameters would be ideal - but I'm not quiet sure, if I understand correctly the wheel makes a series of inputs as it scrolls. Perhaps it could be handled the same way with scroll as the parameter -1, 0, and 1 as the values? I don't know.
| |
Perhaps it would be best to have a separate proc entirely. Scrolling behaves totally different than buttons - it's a one time thing (i.e. there's no release or dragging, just a single click) and it is numerical (it just bugs me to be converting the text parameters to numbers all the time)
like this: Scroll(location, control, direction, amount, icon_x, icon_y) | |
How would you find amount of a scroll? that would indicate a start and end - what the scroll wheel is doing internally is sending a signal repeatedly just as if striking a button multiple times.
| |
I think the direction and the amount can easily be included in one signed number.
The only really important thing to know is the object or control the mouse is scrolling through. client/MouseScroll(object, amount, location, control, params) "amount" would be a signed integer showing the number of scrolls received. Lag would make this look pretty bad, as it does for every mouse proc, but it's better than nothing. | |
Jittai wrote:
How would you find amount of a scroll? that would indicate a start and end - what the scroll wheel is doing internally is sending a signal repeatedly just as if striking a button multiple times. The importance of the "amount" of scroll is that you can scroll much faster than once per tick. If in a game you scroll really quickly and you only see one line move (for instance), that would be bad. | |
Well, I threw that in there because of what Kaiochao mentioned about scrolling multiple times in a single tick. I guess you could leave that out and just allow the developer to decide whether the instant setting is necessary...
EDIT: Yeah I'm slow, and also I'm not sure why I didn't combine amount and direction because I previously thought that there could just be a "scroll" parameter that acts just like that... | |
Would it be too much to add mouse input as macros in the skin editor?
MOUSELEFT --> SomeCommand edit: The only thing I believe would be conflict is Click(), DblClick(), and other mouse control procs, but could be overridden. Also, clicking and the mouse wheel wouldn't work with the "repeat" option. | |
Having basic mouse functions in as macros would be extremely problematic though?
| |
I'm mostly looking at it in the perspective that users will be mostly focused on a map control. But mouse procs would normally handle these anyway, so I guess my request is slightly redundant.
| |
Jittai wrote:
Having basic mouse functions in as macros would be extremely problematic though? https://docs.google.com/document/ pub?id=1HGkCp4eQU8Jp14Srh8Isuv_liehzV_XB6IcSUbVFFiY&embedded =true&revision=latest#701ed56ed4bc33b6be5cdacbe89fa7e73487f69 1 You can do fun things with setting the verb name on mouse procs, btw. | |
Super Saiyan X wrote:
Jittai wrote: This is close to what I would like, but these are built-in commands that would have to be bound primarily with keys and not mouse input (NORTH --> .click). It's pretty handy to have though. | |
Makeii wrote:
Super Saiyan X wrote: I do recall (or maybe hallucinated) something about something internal letting us theoretically set commands bound to the mouse...that'd probably better suited for a different feature request? | |
Super Saiyan X wrote:
Makeii wrote: Might have been that you are thinking about my InputHandler library? It processes Mouse Commands just like it does keypresses at the front end of implementation. | |
Ter13 wrote:
Super Saiyan X wrote: Nah, it was probably just me floating around the idea of mouse macros....since the mouse clicks do actually call .mousedown and such. (if you override client/Click's set name to something else, and then click on something, it'll call default click(), rather than the overidden procedure. basically, the mouse control procedure names are explicitly tied to the mouse [the mouse literally calls ".click"] therefore I assume mouse macros are theoretically possible.) | |
I'm going to, eh, bump this.
| |
Nudge. :>
| |
Let's get motivated to add scroll wheel access.
| |
^Scroll wheel binds would honestly be one of the best things we could add in the meantime.
| |
Do we have any hope of scroll wheel access any time soon? Scrollwheel support is absolutely something that can currently be emulated through browser controls, but doing so would formally break the way that BYOND's macros would work because the browser would have to forcibly be given focus 100% of the time.
Scrollwheel support is just something that pretty much all modern games, even casual games pretty much require. | |