Quoting from your drawing:Quote:
Originally Posted by Ghallo
AllAttack
Heal1
Heal2
Heal3
Heal4
FrostNova
Printable View
Quoting from your drawing:Quote:
Originally Posted by Ghallo
AllAttack
Heal1
Heal2
Heal3
Heal4
FrostNova
It's necessary for some very simple things in the script language. For example, making a hotkey that causes movement in a game. I won't work on the script language for a while, but the trigger code I wrote last week is the same code that will be used for the script language.Quote:
Originally Posted by Fursphere
Actually there are three known bugs now. Somebody told me one last night in a game.Quote:
Oh? I haven't notice them yet. What are they? :D
1. When you close a Mojo, a connected Mojo may not close both its socket connections. Then when you reopen the closed one, the connection may not get fully reestablished.
2. If you close a Mojo whlie moused over, one or both cursors may get disabled or trapped.
3. Last night somebody reported that remote mouseover cursor gets trapped in a window belonging to Dark Age of Camelot.
Omg you're going to mod again! :)Quote:
I was considering doing this myself. Let me talk to Svper and see if I can get some mod access to clean things up a little on this forum.
That's kinda what I was thinking too. Except with the nesting idea maybe the entries should be color coded to show whether they are inherited (defined in a parent setting) or overriden in the current setting. And maybe there should be tabs to look back at parents from which the current settings are inherited.Quote:
I dont' know where the term came from. As far as a UI goes... hmm.... with the amount of keys available on a keyboard, the UI could get HUGE. I'm almost thinking some sort of spreadsheet type layout with a list of "input key" in one column, then multiple "output" columns on a per WoW basis (multi PC aware). So you can just type in what key you want output based on the input key.
And then I think -- this is too complicated for Mojo.
I never counted but the OS probably defines something like 150 or 200 key codes.. In addition some hardware devices (by mistake) use non-existent key codes so in a way there are 512 because the codes are defined by nine bits.
We can draw the boundary between "broadcast" and "hotkeys" anywhere we like.Quote:
Maybe even a dynamic hotkey system like you do in the other menus - that add boxes as you use them?
Broadcast is just a subset of hotkeys, and it can include as much hotkey stuff as we want.
I'm thinking that the input to broadcast (the trigger) should always be a single key press or release. Whether the output can be a combination... I dunno, that's something to decide.
Certainly, the program will be able to do that, but I dunno which part of the program should do that ... which screen the user does it on, whether it's called broadcast or something else.
Edit:Quote:
Originally Posted by Ghallo
I just realized:
Your first screen defines the key(s) that the user presses with his fingers.
Your second screen defines the key codes that Mojo sends to WoW.
Is that right?
I personally fell that you should do this in two seperate stages.
1) Do not pass list. This is _very_ handy and should be built.
2) Keymaps - these IMO should only be used for things you CAN NOT DO ANY OTHER WAY. (which seems kinda like cheating to me? meh - vehicles mostly). if you can move buttons around IN GAME - you should do it there. Vehicle buttons cannot be moved, so thats where keymaps shine.
Keymaps are also used _AS_ do not pass lists in Innerspace, simple because they can be toggled on and off with a hotkey, where do not pass lists in innerspace cannot be toggled in that fashion.
Quote:
Originally Posted by Ghallo
When you open a folder and see a bunch of files, that's a one-to-many relationship. . One-to-many doesn't mean anything more complicated than that.
I have three daughters. They each have one father. That's a one-to-many-relationship.
The hard thing about designing a simple screen that lets the user map physical key presses to Mojo's output is that the user has to specify conditions under which different output gets generated. But specifying conditions has nothing in particular to do with one-to-many.
Quote:
As Fur is saying start with Whitelist/Blacklist - that's the "master" and the bare minimum necessary to get a multiplexer working in a meaningful way. From there an "advanced" setting could be available to take the user into a config that would allow them to do the complex mappings. Marking it as "advanced" would have the advantage of detering users from that section that would really only get them into trouble.
Most of Mojo will probably be designed with progressive disclosure of increasingly complex features.
If you want to see an example that's already in Mojo, go to Connection Settings and click the first two radio buttons. Also see the "More options" button at the bottom.
(Microsoft advises software designers to say "More options" instead of "Advanced" because it's less intimidating.)
.Quote:
I just had an idea for a new feature request ... If I could just post a mojo.config file that will gracefully import on the user's end (so they don't have their settings lost, etc) then the community will quickly be able to assist on getting new users up to speed - even when there is a good deal of complexity
I think that's a good idea. The data structures and algorithms that are used for Mojo's config info have been designed to make it easy to remove a branch of config info from the overall tree and graft it onto some other tree, so this should be very easy to implement. .
I've officially replaced Keyclone with Mojo. I love you!!
(Still have to use HotKeyNet to launch the windows though... :))
I've been burried by work this week (didn't even play wow at all tonight or previous day!) but I'll see what I can do - I think though that maybe google code or curse have things for voting on features that may be more maintainable than me trying to count who requested what ?Quote:
Originally Posted by Freddie
ps: agree with fur (!) that DNP is high on priority - a way to launch wow and resize/reframe would be next (and the pause/unpause/broadcastall toggles) - I haven't tried the latest build though, so maybe all that is already in :-)
, I can't believe it! It has so few features at this point. :) That's great.Quote:
Originally Posted by Akoko
It's very fun to hear this. It's a shot in the arm to crank up the compiler and work on it. Thanks.
Launch is coming soon. (It would have been today probably except I ran into a problem and have to rewrite some stuff. So it wil be a few days.)
Whatever you think is best. My two cents would be, it's better if people can give all their feedback in one forum. If they have to go to another website, that discourages a lot of people.Quote:
Originally Posted by Moorea
I'd like to do DNP next but for technical reasons there are three pre-requisites that have to be done first. Here's the schedule for the next couple of weeks:Quote:
ps: agree with fur (!) that DNP is high on priority - a way to launch wow and resize/reframe would be next (and the pause/unpause/broadcastall toggles) - I haven't tried the latest build though, so maybe all that is already in :-)
1. Rewrite the underlying data structures for config info.
2. Finish "launch WoW" because DNP and choosing particular output key combinations for particular WoWs is the same code, and I can't write it unless the program can identify particular WoWs, and its method for doing that will be launch.
3. Make a spreadsheet kind of control that will be used for the DNP/key-assignment screen.
4. Write the DNP/key-assignment screen.
I might throw in a few little things whlie those four big things get done.
Which toggles? Different from the existing predefined hotkeys in which way?Quote:
Originally Posted by Moorea
Edit: oh sorry, never mind, you say you haven't tried the lastest build. This went in a few days ago.