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

The first build of Mojo (the new open source boxing program) is ready to download and test.

Wanna help test? Here's how.

In this early build, we're testing the installation and automatic connection code.

Edit: You cannot use this build for multiboxing. This build is for testing basic parts of the program, not for playing.

Go here and click the link to install the program.

Installation should be completely automatic (aside from security prompts). If it's not, please let me know.

If you install the program on multiple PC's on your network, they should connect to each other when they launch. On every copy of the program, all the other copies should be listed like this:

http://mojoware.org/art/test-build-1-1.gif

Every line should end with "AC." If not, please let me know.

The second thing to check is whether the program identifies all your key presses and mouse movements correctly. Play with the keys and mouse and make sure the program displays the correct key or mouse event.

http://mojoware.org/art/test-build-1-2.gif

The third thing to check is whether the program correctly uses a different IP address when you tell it to. To test this, you need multiple IP addresses in one of your computer. This is the case, for example, if the PC has both wired and wireless adapters.

If your PC has multiple IPs, go to the main menu, click Settings, then click Connection Settings, then click "More options."


http://mojoware.org/art/test-build-1-3.gif

You want to tell the program to use a different IP address from the one it has been using by default. How do you know which one it was using? From picture 1 above on the other computer.

Make sure you pick a "real" IP address. It should belong to an Ethernet adapter, LAN adapter, etc.

After you change the IP address, close the program on both computers and then restart. The computer should now be using the new IP address.

Thanks in advance for the help!

I will be a lab rat... if it runs on Win7x64 and works for single system multiboxers? If so, I will mess around with it this weekend.

Quote:

---

Originally Posted by offive

I will be a lab rat... if it runs on Win7x64...

---

It should run on any version of Windows as long as its XP SP1 or higher.

Quote:

---

and works for single system multiboxers?

---

Let me make very clear that you cannot use this build for multiboxing.

This build is for testing, not multiboxing.

This is an extremely early build. It does not yet have code built into it that allows multiboxing.

As I explained above, the only features that can be tested in this very early build are:

-- installation code which you can test on a single PC

-- connection code which you cannot test on a single PC

-- keyboard and mouse recognition which you can test on a single PC

Hey Freddie more than happy to help test
I'm on one pc so i cant test all the functions for you but I'll do all i can
The installation was all auto as you intended
It identifies all key and mouse input
(It did crash once and asked to send a file in an email and i closed the window without reading the filepath so i dont know where it is as i expected to be able to crash it again it crashed when i was testing the g keys on my G15 i have a text input bound to a key and the first time i pressed it i was not sure if it read the whole input or just the last key of the text so i pressed it again and it crashed i expected to be able to duplicate this but i cant i can press that button all day now and it wont crash)
And i cant test the ip address thing as i only have one

Hope any of this helps you let me know i will be happy to run further tests of this build and the future builds
I'm a HKN user and semi recognize the program look and hope to be using it to box soon

Awesome so far, everything works as described.
I have two PCs and both IPs were automatically recognized.
I like the logo in the Help-About.
On my second PC I have a Targus USB keypad (cheap X-keys), Mojo recognizes those key presses fine.

Keep up the good work!

It installs and seems to recognize everything just fine. I can't test multiple IPs, sorry.

Thank you all for testing! :)

Quote:

---

Originally Posted by Boogieman

(It did crash once and asked to send a file in an email and i closed the window without reading the filepath so i dont know where it is...

---

No problem, the file should still be there. It would help if you would send it. If you're on Vista the file is here:

c:\Users\ACOUNTNAME\AppData\Local\mojo\Mojo.1.dmp

If you're using XP it's here:

c:\Documents and Settings\ACCOUNTNAME\Local Settings\Application Data\mojo\Mojo.1.dmp

Quote:

---

I'm a HKN user and semi recognize the program look and hope to be using it to box soon

---

Yep the current window evolved from HotkeyNet but the way the program looks now is mostly for development and debugging ... there are going to be other windows, more graphical. With this new program I'm trying to make everything automatic and easy.

Using a single PC, running Win7 x64

The file is called setup.exe It would be easier to find if it was called mojosetup.exe
(I have Firefox set to download everything, not autolaunch)


Launching the file I get the unknown publisher warning, I don't remember getting it for HKN but maybe I did. My very limited knowledge on this is that the fix is lots of money to do something clever to do with registering certificates (so as intended)?
http://img109.imageshack.us/img109/8...blisher.th.jpg

I also get a windows firewall security alert.
Default was to allow communications on public networks. I made a guess, and changed it to only allow on private networks.
http://img410.imageshack.us/img410/6...tyalert.th.jpg

None of this was a problem for me, reported since you are trying to make it as easy as possible.


Unable to test connections only got the 1 PC, sorry.


Correctly identified all keystrokes.
If mouse pointer is hovering over the title bar of the Mojo window, there is a half-second delay before it displays the LButton Down info. Under same conditions, RButton down does not display at all. Instant for all other windows and body of Mojo window, so don't see a problem?
Any mouse movement over-writes last key action with mouse position info (probably as intended).


Looking good :)

Quote:

---

Originally Posted by Flekkie

The file is called setup.exe It would be easier to find if it was called mojosetup.exe

---

Good idea. I just changed it. Unfortunately Windows is going to change the name back to "setup.exe" every time I republish. Maybe I can write a utility to rename it back automatically when it gets FTP'd to the website.

Quote:

---

Originally Posted by Flekkie

Launching the file I get the unknown publisher warning, I don't remember getting it for HKN but maybe I did. My very limited knowledge on this is that the fix is lots of money to do something clever to do with registering certificates (so as intended)?

---

There's no warning with HotkeyNet 1 because it doesn't use this type of installer (or any installer). My understanding is that I'd have to pay about $250 per year for a certificate to prevent the warning. Plus I think I'd have to incorporate or file a DBA to get a certificate.

Quote:

---

I also get a windows firewall security alert.

---

That's happening because by default, the program is searching for copies of itself on the local network. I see two choices for preventing this.

(1) Set connections off by default. I don't like that idea because then the program won't connect to other copies of itself automatically when the user starts it for the first time.

(2) Display a one-panel setup wizard when the program runs the first time. It would ask a single question, "Are you using one PC or several?" If the answer is one, the program doesn't try to connect and there isn't any firewall popup.

Quote:

---

Default was to allow communications on public networks. I made a guess, and changed it to only allow on private networks.

---

Yeah it's only looking for PCs on your local network. The program could pop up a preemptive window before launching communications for the first time, saying, "In a moment you may see a firewall message. If so, Mojo only needs access to your local network to search for other copies of itself." Maybe this cure is worse than the disease.

Quote:

---

None of this was a problem for me, reported since you are trying to make it as easy as possible.

---

I'm glad you did, that's right. If you have any further thoughts about making this easy please let me know.

Quote:

---

If mouse pointer is hovering over the title bar of the Mojo window, there is a half-second delay before it displays the LButton Down info. Under same conditions, RButton down does not display at all. Instant for all other windows and body of Mojo window, so don't see a problem?

---

Good catch! You really tested! I appreciate it.

I just checked in the debugger, and those delays are only occuring in the main window's GUI thread (the thread that draws the info in the window). However there is no delay in the important threads that see the clicks and react to the clicks and take actions based on the clicks -- they all react instantly -- so there isn't any real problem. The GUI thread is probably hesitating because the OS uses it in connection with dragging and clicking window frames.

Quote:

---

Any mouse movement over-writes last key action with mouse position info (probably as intended).

---

Yep. If anybody needs a persistent list of actions, there will be a way (for debugging purposes etc) to accumulate a scrolling list of actions in the main monitor window.

Quote:

---

Looking good :)

---

Thanks a lot. And thanks VERY much for the thorough testing. It's an enormous help. I can't tell you how much this helps. :)

If you (or other people) continue to test this thoroughly and make these kinds of suggestions, the program will be significantly better. It really makes a difference.

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.

The API of the module would be something along the lines of:

Keyboard Events

• KeyDownEvent
• KeyUpEvent

Mouse Events

• MouseDownEvent
• MouseUpEvent
• MouseMoveEvent

Networking

• EstablishConnection
• DropConnection
• SetConnectionBroadcasting

Application Management

• AddApplication
• RemoveApplication
• StartApplication
• MoveApplication
• ResizeApplication
• SetApplicationAffinity
• SetApplicationBroadcasting

Not a comprehensive list, just spitballing. Once a simple intuitive API is available an interface can be built on top of it to surface most of the features.



SCRIPTING

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.

Quote:

---

Originally Posted by thinus

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

Quote:

---

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

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

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.

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

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

Quote:

---

Originally Posted by Freddie

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.

Quote:

---

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?

Quote:

---

Originally Posted by thinus

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:

Quote:

---

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.

Quote:

---

Originally Posted by Freddie

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:

Quote:

---

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?

Quote:

---

Originally Posted by thinus

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.

Quote:

---

Originally Posted by Freddie

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.

---

Quote:

---

Originally Posted by Jafula

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?

Quote:

---

Originally Posted by thinus

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.

Quote:

---

Originally Posted by thinus

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'll try to illustrate one of the main issues with an example using HKN2 syntax.

Code:

---

function MyFunction ( MyVar  )
{
  sendto ( 192.168.1.102 )
  {
      MyVar = MyVar + " all folks.";
      Print ( MyVar );
  }
}

---

The function executes on the local machine. The instructions in the compound block (inner curly braces) execute on the remote machine. How does the value of MyVar (which only exists in a stack on the local machine, it's not in a script on either machine) get to the remote machine and bind into the code there?

Seems to me that regardless of how this is implemented, the remote machine has to receive the following information in some form. The form doesn't matter -- it can be source code or compiled code -- but the remote has to receive the following info. (I'm making up a value for the variable. In real life the value would be whatever is in the local stack at runtime.)

Code:

---

var MachineGeneratedVar = "That's";
 
function MachineGeneratedFunction  (  MyVar = MachineGeneratedVar )
{
      MyVar = MyVar + " all folks.";
      Print ( MyVar );
}

---

I think it's useful to think of the problem in terms of the above transformation. The transformation is a sort of functional spec for what the program has to do in some way or other.

Quote:

---

Originally Posted by thinus

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?

---

I'm going to skip over the "pre compile" part of your suggestion because it's not the main point, and also because Mojo has to assume that the local PC loaded the script hours ago and only just connected to the remote PC a millisecond ago. I'll just focus on the comparison of text vs. byte code.

The main point is whether Mojo could "just push the text script." Well, it can't simply push the original text script because the fragment of the original script looks like this:

Quote:

---

MyVar = MyVar + " all folks.";
Print ( MyVar );

---

That's just a fragment. It won't compile or run on its own because, for one thing, MyVar isn't initialized. The fragment has to be expanded and transformed in some way before the remote compiles it. It has to be turned into the second example above, or something equivalent.

So we're not really comparing "push as written" to "do extra work." We're comparing two kinds of extra work.

If the program sends text (e.g. the second example above) to the remote, the local copy of Mojo must:

1. At compile time, create machine-generated functions in source form, store them somewhere, etc.

2. At compile time, put instructions in the compiled code that tell the interpreter to fetch the appropriate machine-generated-function-in-source-form and do the rest of the things on this list.

3. At run time, look up the value of MyVar in the stack.

4. At run time, create a new piece of source code that defines MyVar as a global variable and initializes it with a literal which has the same value as the value of the run-time variable in the local stack.

5. At run time, combine the two pieces of source code (variable definition and machine-generated function) and send them to the remote.

Do you want someone to test that on Ubuntu?

Do you mean with Wine? This program can't run natively on Linux even if it's recompiled.

If you don't mind testing with Wine, sure. Somebody at Wine told me three months ago that they are in the process of adding something to Wine that will allow Mojo to run on it. (We were talking about HotkeyNet but it's the same code). I don't know if they've finished this. There's a thread here that talks about it:

http://archives.free.net.ph/message/...cb4d2c.de.html

If they haven't finished, then Mojo will probably work on a single PC but not across a network.