What do you guys/gals think? Yea, yea, Java is big fat and slow, but J2ME is much more compact and speed shouldn't be an issue because only scripting will be performed in Java, everything else will happen in C++ via JNI. I already have a rough Object layout in mind and rough ideas on how to build this on top of what already exists (it would be a parallel scripting language to the now existing one).
I am new to MQ aside from reading the manual and some minor experimentation. However, I have experience with ShowEQ and EthernalQuest.
Xith
BTW, since this is my 1st post on this forum, EXCELLENT JOB on MQ guys!
Proposal: J2ME API Interface
Moderator: MacroQuest Developers
Scripts
If I had to rewrite genbot in java I'd probably shoot myself instead hehe.
Thanks
Thanks
When they come to me, they're in trouble, or they want some. I bust people out of prison, hunt down vampires, fight alien gods -- All the fun jobs people are too squeamish or too polite to do themselves.
Call me a mercenary. Call me an assassin. Call me a villain. I am all that and more.
My name's John Gaunt, but out on the streets of Cynosure, I am called...
GrimJack
Call me a mercenary. Call me an assassin. Call me a villain. I am all that and more.
My name's John Gaunt, but out on the streets of Cynosure, I am called...
GrimJack
Holy Moley!
no, no, we're not talking about re-writing anything. This would be a parallel scripting language to the existing one. There are advantages and disadvantages of *using* java for scripting but neither advantage or disadvantage if you do not use it.
It's sorta like this. Theoretically, you have some basic layers here:
The advantages are this:
For compilation, java files can be edited using the now existing and awesome commands that let you edit MQ scripts now and the compilation and running of java MQ scripts (JMQ?) can be done with... what? .... macros commands! (in their existing format and structure).
It's sorta like this. Theoretically, you have some basic layers here:
- 1. eqgame.exe
2. hooks (detours, dx, maybe more here)
3. code that sucks data out of eqgame.exe that we want and spits stuff back into it (thus the MacroQuest window, controlling mouse, UI, sending keys, retrieving items you’re your inventory, etc)
4. scripting language interface
The advantages are this:
- * Much of the scripting language features perform basic functions that existing languages already perform. (file access, looping, mathematical functions, etc)
* The java language adds many more programming constructs that would simplify the MQ scripting process and allow for greater reusability of scripting components. So you might have a script that performs some useful function (in your class) and then people like it so much that they use it in their scripts without having to cut and paste.
* There are benefits to using standardized languages on the learning curve for those who have either used java or C++ before or those who end up using it later after having first been exposed to java from MQ.
* It will not affect users who do not wish to use it.
- * Java has to be compiled
* A Java Virtual Machine would have to be created, probably within the process, which can be expensive on resources
* Java commands wont be able to be used from the EQ command line (chat window) as with the original scripting language since they have to be compiled into .class files or objects.
* Some separation of code may be needed between layers 3 and 4 as described above to isolate the script language implementations from the underlying functionality
For compilation, java files can be edited using the now existing and awesome commands that let you edit MQ scripts now and the compilation and running of java MQ scripts (JMQ?) can be done with... what? .... macros commands! (in their existing format and structure).
Xith
Actually a lot of the current scripting language mirrors C/C++, I'd guess because that was what Plaz was familiar with when he wrote it.
Current code is reuseable without cutting/pasting by use of #include. For some reason people don't do that much. I've been a proponent of OOM (object oriented macroing) for a long time, and use it quite a bit in my scripts. I pick and choose from a library of modules I keep in an include directory for that purpose.
That's not saying a lot of folks wouldn't like to utilize an existing language such as Java. An attempt to do that was made with PERL, but it never flew. The MQ language wasn't developed in a set of white papers, it kind of grows organically, and yes, that can be a disadvantage that could be overcome by the use of an existing language.
However, do you want to add a VM to the already resource intensive EQ? I run a pretty heavy duty machine and even with the fps limiter now in MQ I get periods of bad lag. I'd hate to add something else in that would slow me down even more.
I can see how users could benefit from being able to use a different "script interface language" so to speak. But I'd think a better idea would be to overhaul the existing language and "standardize" it a bit more, the way I did with the now defunct /rclicktarget and /lclicktarget.
Current code is reuseable without cutting/pasting by use of #include. For some reason people don't do that much. I've been a proponent of OOM (object oriented macroing) for a long time, and use it quite a bit in my scripts. I pick and choose from a library of modules I keep in an include directory for that purpose.
That's not saying a lot of folks wouldn't like to utilize an existing language such as Java. An attempt to do that was made with PERL, but it never flew. The MQ language wasn't developed in a set of white papers, it kind of grows organically, and yes, that can be a disadvantage that could be overcome by the use of an existing language.
However, do you want to add a VM to the already resource intensive EQ? I run a pretty heavy duty machine and even with the fps limiter now in MQ I get periods of bad lag. I'd hate to add something else in that would slow me down even more.
I can see how users could benefit from being able to use a different "script interface language" so to speak. But I'd think a better idea would be to overhaul the existing language and "standardize" it a bit more, the way I did with the now defunct /rclicktarget and /lclicktarget.
MQ2: Think of it as Evolution in action.
-
dont_know_at_all
- Developer
- Posts: 5450
- Joined: Sun Dec 01, 2002 4:15 am
- Location: Florida, USA
- Contact:
I don't think it's a bad idea to standardize the existing scripting lauguage and you are right about the includes. I am still not intimately familiar with the scripting language yet so it would be wrong of me to make any brash assumptions.
As to the VM, this is at least an area that I have good knowledge. I will have to research the j2me more as most of my work is with j2se, j2ee. The major cause of what people describe as "lag" (which is actually poor frame rate) is caused from a combination of processor usage, memory movement and video hardware optomization. When you have insufficient memory, there is also the component of disk usage for swap file and the speed at which you can retrieve and write data to the disk. I'm thinking about a footprint of 1MB to 2MB tops (possibly in the KB range). You know that embedded devices don't have a lot of memory to chunk around. As for processor usage, this should be fairly light as well -- I estimate perhaps double what the existing scripting lauguage uses. From looking at the source code, that isn't very much at all compared to what EQ is processing to render sceens with literally updwards of 250 MBs worth of graphic data. (with all graphic settings maxed out EQ consumes around 720 MBs of total memory)
I think that the VM will certainly be a factor but I don't expect it to be a large one.
As to the VM, this is at least an area that I have good knowledge. I will have to research the j2me more as most of my work is with j2se, j2ee. The major cause of what people describe as "lag" (which is actually poor frame rate) is caused from a combination of processor usage, memory movement and video hardware optomization. When you have insufficient memory, there is also the component of disk usage for swap file and the speed at which you can retrieve and write data to the disk. I'm thinking about a footprint of 1MB to 2MB tops (possibly in the KB range). You know that embedded devices don't have a lot of memory to chunk around. As for processor usage, this should be fairly light as well -- I estimate perhaps double what the existing scripting lauguage uses. From looking at the source code, that isn't very much at all compared to what EQ is processing to render sceens with literally updwards of 250 MBs worth of graphic data. (with all graphic settings maxed out EQ consumes around 720 MBs of total memory)
I think that the VM will certainly be a factor but I don't expect it to be a large one.
Xith
There's no reason to specify java or any other language. If you integrate with Windows Scripting Host, and expose a nice set of interfaces to be used by the scripts that you run, you can write your scripts / macros in any scripting language you want (or in higher level languages as well).
A good example of this model is the Skunkworks project for Asheron's Call. People write their macros in jscript or vbscript, and manipulate the game throught a set of interfaces exposed by skunkworks.
Integrating a scripting language into a project like this is very easy. However, creating the necessary interfaces to make it useful is much more involved. The payoff is pretty big though. Javascript is very easy to get the hang of for java / c++ / c# programmers, and of course vbscript is easy for vb programmers. Other scripting languages are supported as well, just not directly out of the box. (I'm pretty sure this includes perl).
Madar
A good example of this model is the Skunkworks project for Asheron's Call. People write their macros in jscript or vbscript, and manipulate the game throught a set of interfaces exposed by skunkworks.
Integrating a scripting language into a project like this is very easy. However, creating the necessary interfaces to make it useful is much more involved. The payoff is pretty big though. Javascript is very easy to get the hang of for java / c++ / c# programmers, and of course vbscript is easy for vb programmers. Other scripting languages are supported as well, just not directly out of the box. (I'm pretty sure this includes perl).
Madar
There are any number of useful things you can do if you are integrated with WSH, as you get access to any COM object on the machine if you let the script run trusted. This would allow you to (for instance) activate the windows messenger scripting objects, and send a message to yourself at work if something specific occurred (or allow you to send an IM from work asking your macro for its current status).
It would allow you to connect to your SQL server and log information about whatever you want there (spawn information, item information, where your character has gone, whatever you want).
It would allow you to link macros together - establishing a link between your tank and your healer so that they both have more information available about their surroundings.
Last but not least, it increases the accessibility for programmers since often they won't have to learn a new language to write macros.
Madar
It would allow you to connect to your SQL server and log information about whatever you want there (spawn information, item information, where your character has gone, whatever you want).
It would allow you to link macros together - establishing a link between your tank and your healer so that they both have more information available about their surroundings.
Last but not least, it increases the accessibility for programmers since often they won't have to learn a new language to write macros.
Madar
Actually, we kindof like the fact that it takes time/energy to learn MQ. This is not a valid reason.Last but not least, it increases the accessibility for programmers since often they won't have to learn a new language to write macros.
The other reasons make me want to shrug, honestly. It would be a big pain in the ass and a lot of trouble for something that really isn't that valuable. Besides that, EQ is past it's prime and isn't going to last forever....it's too much of an investment, in my opinion.
MQ was designed to help a player play the game through a variety of tasks being simplified and/or automated (at least, after a year and a half of being in this project, that's my observation of Plaz's intent). What you are wanting is a utility application.
We're not asking you to implement any of this I don't think. Being that it's in sourceforge, I was assuming this was a GPL project (maybe I haven't read it that closely).
Maybe I'll put one together and submit it to see what people think.
The only problem I see with WSH is that it from what you've explained it sounds like it locks you fairly securely into vb script and javascript (which has nothing to do with java except that Netscape decided to cash in on using that name).
I don't have a problem wit it being a "utility application", that's essentially what bots are, complete AI applications. I'm also curious why you want it to be hard. I understand that people often like hacking projects to be obscure to reduce their usage and thus visibility, but I still miss the point of obfuscation. Maybe it's my background that teaches me to make things simple, accessible, flexible, etc, etc.
I think that a descent marriage of some of the ideas posed here is the alteration of the existing application to separate the scripting layer from the functionality layer (as in my previous post) so that any number of interfaces could be written by whomever wants to write them. If this idea is not acceptable then you shouldn't have open sourced the project in the 1st place! It doesn't mean that the changes get integrated into what is current. However I feel that if it can be done in such a manner that a.) does not impact the applications functionality performance or stability, b.) does not interfere with future development and c.) brings more power to the table, I then I can't see why not. With all due respect to the masterful work that has been done here, I hope there will be openness to new ideas.
In fact, my proposed java interface can be a completely separate dll that gets loaded as a plug-in, or a proposed Windows Scripting Host interface (as well as perl or whatever for that matter). I think that the most important part is exposing a nice standard C++ API.
Maybe I'll put one together and submit it to see what people think.
The only problem I see with WSH is that it from what you've explained it sounds like it locks you fairly securely into vb script and javascript (which has nothing to do with java except that Netscape decided to cash in on using that name).
I don't have a problem wit it being a "utility application", that's essentially what bots are, complete AI applications. I'm also curious why you want it to be hard. I understand that people often like hacking projects to be obscure to reduce their usage and thus visibility, but I still miss the point of obfuscation. Maybe it's my background that teaches me to make things simple, accessible, flexible, etc, etc.
I think that a descent marriage of some of the ideas posed here is the alteration of the existing application to separate the scripting layer from the functionality layer (as in my previous post) so that any number of interfaces could be written by whomever wants to write them. If this idea is not acceptable then you shouldn't have open sourced the project in the 1st place! It doesn't mean that the changes get integrated into what is current. However I feel that if it can be done in such a manner that a.) does not impact the applications functionality performance or stability, b.) does not interfere with future development and c.) brings more power to the table, I then I can't see why not. With all due respect to the masterful work that has been done here, I hope there will be openness to new ideas.
In fact, my proposed java interface can be a completely separate dll that gets loaded as a plug-in, or a proposed Windows Scripting Host interface (as well as perl or whatever for that matter). I think that the most important part is exposing a nice standard C++ API.
Xith