Mojo build 1 is ready to test ** Testing Closed **

[Freddie]

I am just curious as to where you are going with this...? I've been talking to a friend of mine about what we would like in a complete solution for multi-boxing and how we would design it. We are thinking along the lines of an I/O module dealing with keyboard and mouse hooking, application management and network communication.

Mojo aleady does many things on your list and it will do all of them (and much more) in the near future.

Mojo consists of two parts, an engine and an application. The engine presents an API to the application. The API is defined in a file called mojo_engine.h in the source code.

For more information about the program's architecture, see

Overview for Programmers

Any plans to link in a scripting language like LUA, Python, JScript? The scripts can be linked to the I/O events in the I/O module.

Eventually, after Mojo has a powerful graphical interface, Mojo will have a script language but it will probably be the language from HotkeyNet 2 which is described here:

http://www.hotkeynet.com/hkn2/ref/LanguageOverview.html

http://www.hotkeynet.com/hkn2/ref/ref_index.html

The reason I wrote a language from scratch is that the language for this program needs some peculiar things that don't exist (so far as I know) in any drop-in script language:

-- distributed processing

-- hotkey definitions

-- key lists

[Boogieman]

Dude im chomping at the bit for this
Its Killing me I love HKN and I know this is gonna be awesome
I was thinking what could i possibly want then HKN cant already do
Then I thought well if Freddie is building it it must be better or he would just stick with HKN
You probably are gonna give me something that i haven't even thought of but will not be able to live without once i have it

Good luck

[Freddie]

Thanks. The early versions of Mojo will be very different from HotkeyNet because they wil be extremely easy to use with practically no configuration or instructions.

Just download, watch it install automatically, and start multiboxing.

Edit: From the features in this first build, you can get an idea of how I'm trying to fix all of HotkeyNet's problems in Mojo. For example:

1. From the Connection Settings you can see that all references to client and server have been removed. Why? Because with HotkeyNet, people were constantly jumping to the wrong conclusion that they can only send hotkeys from the server. I'm fixing this misunderstanding by not having clients or servers in Mojo.

2. People often complained that they couldn't set the IP address for the local PC. This is changed in Mojo.

3. People often complained that they had to use IP addresses instead of names of PCs. This is changed in Mojo (as suggested by the Connections window in the bottom left corner of the main window).

Etc. etc.

[Freddie]

Let's end this thread and switch over to the new one for build 2:

http://www.dual-boxing.com/showthrea...067#post247067

[thinus]

Mojo aleady does many things on your list and it will do all of them (and much more) in the near future.

Mojo consists of two parts, an engine and an application. The engine presents an API to the application. The API is defined in a file called mojo_engine.h in the source code.

For more information about the program's architecture, see

Overview for Programmers

I'll take a look at the source sometime soon. Sounds really good and the overview was quite informative.

Eventually, after Mojo has a powerful graphical interface, Mojo will have a script language but it will probably be the language from HotkeyNet 2 which is described here:

http://www.hotkeynet.com/hkn2/ref/LanguageOverview.html

http://www.hotkeynet.com/hkn2/ref/ref_index.html

The reason I wrote a language from scratch is that the language for this program needs some peculiar things that don't exist (so far as I know) in any drop-in script language:

-- distributed processing

-- hotkey definitions

-- key lists

I've used HKN before and I turned a friend onto HKN for LOTRO. We both found that the scripting language was a beast to work with as soon as you tried doing something out of the box.

Wouldn't it be much easier to just plug in an established scripting language and extend it by providing the required application specific functionality?

[Freddie]

I've used HKN before and I turned a friend onto HKN for LOTRO. We both found that the scripting language was a beast to work with as soon as you tried doing something out of the box.

Wouldn't it be much easier to just plug in an established scripting language and extend it by providing the required application specific functionality?

I'm talking about HotkeyNet 2's language, not HotkeyNet 1. HotkeyNet 2 has a real language. Here's an overview:

http://hotkeynet.com/hkn2/ref/LanguageOverview.html

One of the main reasons why I wrote a language from scratch instead of, e.g., adapting Lua was the following paragraph from the page I just linked:

Distributed processing is built into the language. You can put almost any statements inside a "sendto" block, and the local copy of HotkeyNet will send that code (in compiled form) to a remote copy of HotkeyNet where it will execute.

To make the language do that, every internal piece of the language had to be designed for it. The data structures that represent variables, the binding method for functions, the syntax of the language, the way strings of byte code are fed into the interpreter ... everything had to be designed for it. Maybe it would be practical for some people to retrofit that into a complicated program written by other people, but for me, it was easier to start with a clean sheet of paper.

[thinus]

I'm talking about HotkeyNet 2's language, not HotkeyNet 1. HotkeyNet 2 has a real language. Here's an overview:

http://hotkeynet.com/hkn2/ref/LanguageOverview.html

One of the main reasons why I wrote a language from scratch instead of, e.g., adapting Lua was the following paragraph from the page I just linked:

Distributed processing is built into the language. You can put almost any statements inside a "sendto" block, and the local copy of HotkeyNet will send that code (in compiled form) to a remote copy of HotkeyNet where it will execute.

To make the language do that, every internal piece of the language had to be designed for it. The data structures that represent variables, the binding method for functions, the syntax of the language, the way strings of byte code are fed into the interpreter ... everything had to be designed for it. Maybe it would be practical for some people to retrofit that into a complicated program written by other people, but for me, it was easier to start with a clean sheet of paper.

How will this be used and what is the benefit? I am struggling to wrap my head around it. I would have thought that each instance of the software will take keyboard and mouse input, process the input and send keyboard and mouse messages onto the registered applications.

The networking aspect would simply receive keyboard and mouse input from a network connection as well as from Windows keyboard and mouse hooks. Why is it necessary to send pre-compiled scripts across the network?

[Jafula]

How will this be used and what is the benefit? I am struggling to wrap my head around it. I would have thought that each instance of the software will take keyboard and mouse input, process the input and send keyboard and mouse messages onto the registered applications.

The networking aspect would simply receive keyboard and mouse input from a network connection as well as from Windows keyboard and mouse hooks. Why is it necessary to send pre-compiled scripts across the network?

I have two machines, one for my master and a second for my four slaves.

In HKN1, I have a script on my master machine that is not on my slave machine. The script on the main machine has a section that launches WoW, resizes, enters username and password, etc. HKN1 sends this part of the script accross to the second machine and runs it.

By changing the one script on the main machine, I can control what happens on the second.

Without "pre-compiled scripts" this would not be possible.

[thinus]

I'm talking about HotkeyNet 2's language, not HotkeyNet 1. HotkeyNet 2 has a real language. Here's an overview:

http://hotkeynet.com/hkn2/ref/LanguageOverview.html

One of the main reasons why I wrote a language from scratch instead of, e.g., adapting Lua was the following paragraph from the page I just linked:


To make the language do that, every internal piece of the language had to be designed for it. The data structures that represent variables, the binding method for functions, the syntax of the language, the way strings of byte code are fed into the interpreter ... everything had to be designed for it. Maybe it would be practical for some people to retrofit that into a complicated program written by other people, but for me, it was easier to start with a clean sheet of paper.

I have two machines, one for my master and a second for my four slaves.

In HKN1, I have a script on my master machine that is not on my slave machine. The script on the main machine has a section that launches WoW, resizes, enters username and password, etc. HKN1 sends this part of the script accross to the second machine and runs it.

By changing the one script on the main machine, I can control what happens on the second.

Without "pre-compiled scripts" this would not be possible.

Why not just push the text script to the 2nd machine and pre-compile it on the 2nd machine instead of sending compiled code over the network?

[Jafula]

Why not just push the text script to the 2nd machine and pre-compile it on the 2nd machine instead of sending compiled code over the network?

Meh. No idea. Maybe it does that, I could be wrong in my assumptions. Freddie might be able to answer that one.