Do the recent EQ1 network changes (and probably other stuff, what do I know?) affect Inner Space in the same way they affect MQ2? I'm wondering this because it seems that IS is under active development still while MQ2 is in maintenance and a fix is more likely for IS. If so it would probably be a huge push for community support around IS if fixing MQ2 is not only difficult but annoying because it's a legacy codebase. I realize that EQ specific functionality comes from plugins, I was just wondering if it was IS or a plugin implementing MQ2's functions that determines if I get my leet haxxor skillz* back.
* jargon added for humor
P.S. I couldn't think of the proper programming way to word this basic question: Where should my (our) resources be? IS or MQ2?
IS vs. MQ2 development
Moderators: Lavish Software Team, Moderators
Well.. there isnt a real easy answer for this one 
MQ2 is free and popular, though yes its codebase is now legacy and the overall architecture wont be updated, and in my opinion won't really need to be updated before its use runs out. I requested some time ago in the MQ2 VIP forum for interested people to begin converting various EQ stuff from MQ2 to ISX form. Lavish subscribers that use MacroQuest would definitely benefit from having things converted.
Also, any IS extension for EQ1 can use most of the same stuff, including source files, from MQ2. In fact, the memory protection plugin example uses eqgame.h from MQ2.
Stuff that would have to change:
Command functions: MQ2 commands had to do their own parameter parsing. IS's interpreter does that, and uses the same function prototype for commands as is used in console programs -- int main(int argc, char *argv[]) -- with standard shell support (e.g. pipelining, redirection)
MQ2Data functions: MQ2Data also had to do their own parameter parsing. IS's Data parser does that, and also uses argc, char *argv[] instead of the old character array sent to the data functions (this applies equally to the top-level object retrieval function and the type member retrieval function).
Stuff that should be changed but dont have to be:
Detours: Add services for each detour so custom extensions can take advantage
Past that, an ISX project for MQ2 can basically be kept alongside it and use the same code for EQ-specific stuff
Oh. and the answer to "which should i spend time on" I would say converting to IS. I'm not just saying that to be bias, because theyre both my projects and IS isn't likely to solicit subscriptions from MQ2 users... I believe for the current subscribers that use MQ2, IS would benefit greatly.
MQ2 is free and popular, though yes its codebase is now legacy and the overall architecture wont be updated, and in my opinion won't really need to be updated before its use runs out. I requested some time ago in the MQ2 VIP forum for interested people to begin converting various EQ stuff from MQ2 to ISX form. Lavish subscribers that use MacroQuest would definitely benefit from having things converted.Also, any IS extension for EQ1 can use most of the same stuff, including source files, from MQ2. In fact, the memory protection plugin example uses eqgame.h from MQ2.
Stuff that would have to change:
Command functions: MQ2 commands had to do their own parameter parsing. IS's interpreter does that, and uses the same function prototype for commands as is used in console programs -- int main(int argc, char *argv[]) -- with standard shell support (e.g. pipelining, redirection)
MQ2Data functions: MQ2Data also had to do their own parameter parsing. IS's Data parser does that, and also uses argc, char *argv[] instead of the old character array sent to the data functions (this applies equally to the top-level object retrieval function and the type member retrieval function).
Stuff that should be changed but dont have to be:
Detours: Add services for each detour so custom extensions can take advantage
Past that, an ISX project for MQ2 can basically be kept alongside it and use the same code for EQ-specific stuff
Oh. and the answer to "which should i spend time on" I would say converting to IS. I'm not just saying that to be bias, because theyre both my projects and IS isn't likely to solicit subscriptions from MQ2 users... I believe for the current subscribers that use MQ2, IS would benefit greatly.
MQ2 can be used by anyone, which is too bad because it is a powerfull tool. Stupid players use and abuse that software to the point where I wish it would simply go away. Ok, that is not gonna happen, but if MQ2 did go away and with it all the freeloaders that abuse that software, IS would have a lot more support from the community of suporters that have kept MQ2 a viable working project for years.
The one thing that IS has going for it is simply the fact that it is not free. That makes all of us contributors. That is how it should be.
-j
The one thing that IS has going for it is simply the fact that it is not free. That makes all of us contributors. That is how it should be.
-j
It seems easier to setup offset hacks with IS than with MQ2, at least with MQ2 the pre-programmed featres block most people from messing with the memory directly. Nevertheless, IS is obviously more powerful.
Does the memory protection plugin do what is currently broken in MQ2 (the memcheckers)? Are the UI plugins (map, HUD, etc) dependant on those command changes? Is the MQ2 VIP forum the only place work on IS migration is being tracked? (this last bit is important as I hate hate duplicate work)
Does the memory protection plugin do what is currently broken in MQ2 (the memcheckers)? Are the UI plugins (map, HUD, etc) dependant on those command changes? Is the MQ2 VIP forum the only place work on IS migration is being tracked? (this last bit is important as I hate hate duplicate work)
No, there are no MQ2 subscribers only Lavish subscribers. However, I did mention "Lavish subscribers that use MacroQuest". People that donate to MacroQuest are VIPs and the only mention of that was about the MQ2 VIP forum request. There's nothing in the MQ2 VIP forum about IS other than that request. Everything for IS is here or on ismods.com
The memory protection plugin is not updated for the latest patches (yesterday or today).
HUD support is built into IS already, so that's not something that needs to be converted.
The map would be dependent on command change yes, as would anything else that provides a command in MQ2. Also, the map system does provide data items that would have to be converted as well.
The memory protection plugin is not updated for the latest patches (yesterday or today).
HUD support is built into IS already, so that's not something that needs to be converted.
The map would be dependent on command change yes, as would anything else that provides a command in MQ2. Also, the map system does provide data items that would have to be converted as well.
I'd love to convert the project to work with IS, but I don't know where I'd begin. A couple other things I wouldn't be sure about are things like:
- Would it be one singular extension? Like an ISXMQ2 or would it have to be multiple exensions? Maybe an ISXMQ2Main and then the rest as seperate extensions?
- How extensions (if multiple) would use services of other extensions (if they would need to).
- Loading. Load a Main extension that loads the rest or loads a set based on what's specified in an ini file (like Macroquest.ini)?
- Injection. Since we wouldn't be using macroquest.exe
- Where to start. Which plugin or specific file to start with for conversion? Like maybe first concentrate on getting MQ2Main to work, then work from there.
- Would it be one singular extension? Like an ISXMQ2 or would it have to be multiple exensions? Maybe an ISXMQ2Main and then the rest as seperate extensions?
- How extensions (if multiple) would use services of other extensions (if they would need to).
- Loading. Load a Main extension that loads the rest or loads a set based on what's specified in an ini file (like Macroquest.ini)?
- Injection. Since we wouldn't be using macroquest.exe
- Where to start. Which plugin or specific file to start with for conversion? Like maybe first concentrate on getting MQ2Main to work, then work from there.
It could be a single extension, but it should be many in the same way MQ2 is many .. one main one, and other plugins/extensions. MQ2Map, etc can just be turned into IS extensions. ISXMQ2 is kind of silly, you'd want to call it ISX-EQ or something.- Would it be one singular extension? Like an ISXMQ2 or would it have to be multiple exensions? Maybe an ISXMQ2Main and then the rest as seperate extensions?
They would definitely want to. Services provide a line of communication between extensions. When a client connects to or disconnects from a service, the master receives notifications and that information can be used to clean up stuff that the client failed to (for example, the detour service will automatically un-detour anything you forgot to). From there it's just a matter of having a header file with information about the service, just like is in ISXDK.h with the system services. Extensions that provide services can even provide functions or define macros to access them easily, also as seen in ISXDK.h- How extensions (if multiple) would use services of other extensions (if they would need to).
Code: Select all
// System Service "HTTP"
#define HTTPSERVICE_REQUEST ((ISXSERVICE_MSG)+1)
#define HTTPSERVICE_FAILURE ((ISXSERVICE_MSG)+2)
#define HTTPSERVICE_SUCCESS ((ISXSERVICE_MSG)+3)
struct HttpRequest
{
char *URL;
void *pData;
};
struct HttpFile
{
char *URL;
char *pBuffer;
unsigned long Size;
void *pData;
};
static bool IS_HttpRequest(ISXInterface *pClient, ISInterface *pISInterface, HISXSERVICE hHttpService, const char *URL, void *pData)
{
HttpRequest Temp;
Temp.URL=(char*)URL;
Temp.pData=pData;
return pISInterface->ServiceRequest(pClient,hHttpService,HTTPSERVICE_REQUEST,&Temp);
}Sort of the second part. You really dont need to worry about the loading (nor do you have to worry about the MQ2 "plugin" handling), that can be 100% up to the user. Inner Space provides a system that the user can run commands automatically at startup, via autoexec.ice and other methods. Your autoexec.ice can contain the following, for example:- Loading. Load a Main extension that loads the rest or loads a set based on what's specified in an ini file (like Macroquest.ini)?
Code: Select all
ext isxeq
ext isxeqmap
ext isxeqlabelsInner Space takes care of that for you- Injection. Since we wouldn't be using macroquest.exe
Really doesnt matter to be honest. As long as ISXEQMemory is updated to work with your patch, you have access to detours with memory protection.- Where to start. Which plugin or specific file to start with for conversion? Like maybe first concentrate on getting MQ2Main to work, then work from there
MQ2Main would probably be the best place to start, and you really dont need to do an "all or nothing". For example, use a couple header files and you can convert half the commands in a matter of minutes. What's more, you dont even need most of the MQ2 commands, particularly not scripting ones.
Really, it's just going to be a matter of cutting out major portions of MQ2Main, and then changing a few things to fit into Inner Space. Once there's a new MQ2 zip up, you could make a copy of all of the .cpp and .h files, rip out command api, data api, datavars, detours api, dinput, macrocommands, mouse, parse api, plugin handler.... that's about it.
Nice. Thanks for the input. Can you elaborate on this?
Obviously, I don't have such a grasp of the C++ language as you do, so I'm not sure what that would entail.use a couple header files and you can convert half the commands in a matter of minutes. What's more, you dont even need most of the MQ2 commands, particularly not scripting ones.
The next MQ2 zip (I'll probably put one up in a minute) has a bunch of stuff in it for ISXEQ. I added a VS .net project file (ISXEQ.vcproj) and did a bunch of prep work. Currently it'll compile, but will not link, and does not have any datatypes, top-level objects, or commands. It DOES of course have all of the utility commands, EQ structs, classes, etc. The reason it doesn't link is some things have to be replaced or removed yet, but if you want to play with it you can certainly try to figure out what needs to happen to get it to link
This way, ISXEQ can share most of the MQ2 code.
This way, ISXEQ can share most of the MQ2 code.
besides all those other reasons you listed.
wineq/mq2 is easy to use.
Been trying to use IS since you first posted it. Your a good programmer, but your skills in 'help' and "easy to use" sucky
(I don't mean helping people, you do great job helping people on this site)
wasn't for Amadeus asking how to get to main command window, I would have never found it (` key, which alot people use that key to switch in wineq/eqwindows )
Oh well probly just me, being stupid, others got it working.
( I find it easier to manually search though eqgame.exe for all of mq's offsets, then trying to make IS work like wineq, profiles, fullscreen, and setting switch keys)
wineq/mq2 is easy to use.
Been trying to use IS since you first posted it. Your a good programmer, but your skills in 'help' and "easy to use" sucky
(I don't mean helping people, you do great job helping people on this site)
wasn't for Amadeus asking how to get to main command window, I would have never found it (` key, which alot people use that key to switch in wineq/eqwindows )
Oh well probly just me, being stupid, others got it working.
( I find it easier to manually search though eqgame.exe for all of mq's offsets, then trying to make IS work like wineq, profiles, fullscreen, and setting switch keys)
Thanks for the chuckle.
WinEQ is easy to use because it is designed to be used by people who are not technically minded. Inner Space is designed to be easy to use by people who are technically minded, or are familiar with MQ2. That being said, if you have any experience whatsoever with MQ2 beyond simply loading it, Inner Space shouldn't be a long shot. In fact, it's almost identical to the user and to potential developers, aside from a few obvious differences.
With all that in mind, the main focus of Inner Space has been to get features developed and accessible, not necessarily to make it something as easy to use as WinEQ. If you'd like to make some requests for features that you think would make it easy to use for you, feel free to do so. Nearly all of the changes coming to Inner Space right now are from bug reports or feature requests -- the changes in 0.68 all came as a result of a single email I received. Inner Space is still in Beta, and the only reason it is not out of Beta is the documentation is not complete, and I have not yet addressed "ease of use".
The idea and function of the in-game console is derived from the consoles in nearly every first-person shooter (which all use the ` key), with emphasis on acting like a normal command shell (e.g. DOS, Linux, UNIX).
As far as finding it... Inner Space does have a manual, and as it says on the first page... please let me know if you need more information on a particular subject, and it will get filled in. The page in the manual referring to the console window is called "Console & Commands" and is found in Session->Systems->Console & Commands. If you don't know about something and dont care to read through the basic parts of the manual, what do you suggest I do to make the information more available to you? I have actually been planning on creating some sort of tutorial.
I'm a busy guy, and I put priority on things that people ask for... I appreciate the post saying that you don't find it easy, but it would be far more helpful to both of us if you could give specific things rather than tell me I suck at making it easy to use
As far as WinEQ-type hotkeys, this is the thread you want: http://www.ismods.com/forums/viewtopic.php?t=25
I do plan on having the installer give you an option of automatically setting that stuff up for you.
WinEQ is easy to use because it is designed to be used by people who are not technically minded. Inner Space is designed to be easy to use by people who are technically minded, or are familiar with MQ2. That being said, if you have any experience whatsoever with MQ2 beyond simply loading it, Inner Space shouldn't be a long shot. In fact, it's almost identical to the user and to potential developers, aside from a few obvious differences.
With all that in mind, the main focus of Inner Space has been to get features developed and accessible, not necessarily to make it something as easy to use as WinEQ. If you'd like to make some requests for features that you think would make it easy to use for you, feel free to do so. Nearly all of the changes coming to Inner Space right now are from bug reports or feature requests -- the changes in 0.68 all came as a result of a single email I received. Inner Space is still in Beta, and the only reason it is not out of Beta is the documentation is not complete, and I have not yet addressed "ease of use".
The idea and function of the in-game console is derived from the consoles in nearly every first-person shooter (which all use the ` key), with emphasis on acting like a normal command shell (e.g. DOS, Linux, UNIX).
As far as finding it... Inner Space does have a manual, and as it says on the first page... please let me know if you need more information on a particular subject, and it will get filled in. The page in the manual referring to the console window is called "Console & Commands" and is found in Session->Systems->Console & Commands. If you don't know about something and dont care to read through the basic parts of the manual, what do you suggest I do to make the information more available to you? I have actually been planning on creating some sort of tutorial.
I'm a busy guy, and I put priority on things that people ask for... I appreciate the post saying that you don't find it easy, but it would be far more helpful to both of us if you could give specific things rather than tell me I suck at making it easy to use
As far as WinEQ-type hotkeys, this is the thread you want: http://www.ismods.com/forums/viewtopic.php?t=25
I do plan on having the installer give you an option of automatically setting that stuff up for you.