The Innerspace docs are really hard to follow because there's not much documented. Took me quite a while to figure out how to get the extensions loaded then I forgot and when I came back a week later had to figure it out again LOL.
There's actually a SHITLOAD documented, and I dont have near enough time to continue documenting. If you just wanted to know how to load an extension you could have asked anyone
ISXEQLegacy is what you need to run macs, but I'm not 100% whether or not it gets updated anymore. You should join IRC, very knowlegeable people there.
It shouldnt need any updating, it's swiss cheesed directly into MQ2's code. It needed an update at one point because the ISXDK (inner space extension development kit) was updated in such a way that it broke ISXEQLegacy. that's since been fixed.
From what I remember last, ISXEQLegacy will not run the plugins that most of the major botting macros require. ModBot would be hell to convert, and Autobot is way too large.
It's not worth running MQ2 macros. First off theyre trash anyway (no offense whatsoever to the macro developers, its generally NOT your fault, you do the best you can given the circumstances). There's a long list of optimizations that are in LavishScript that will never be available in MQ2.
Just for a simple example... In MQ2, cramming as much shit as possible into one line is beneficial because of the relatively low default "turbo", so you end up with 1-line "if" commands (which is another performance hit, as "if" should not be a command) that have like 500 individual data sequences in them. It is inefficient to break that down into 500 "if" commands in MQ2. Additionally, every last data sequence in the line is processed, regardless of whether any given sequence means that the entire /if ONLY has one possible outcome at that point. for example: 1 || (0 && 0 && 0 &&0).... this if can stop at 1 || because the 0 && 0 is all chained together, and it's saying "if this is non-zero, or that is non-zero" .. well, it can stop at the 1 (this is called short circuiting, and is an optimization in most implementations of most languages that have similar constructs). But with MQ2, the calculator will simply go through and calculate every last detail, and every last data sequence is calculated.
With LavishScript, "if" is part of script structure, not a command. Script structure is evaluated when the script ("macro" in mq2 speak) is loaded, rather than discovered each time a given command is executed (another flaw in MQ2 that has had a little bit of patching up). if statements are automatically split into many if statements, so there's absolutely no performance penalty for splitting your if statements into multiple if statements yourself to make the code readable. short circuiting is also thusly implemented.
I made a small attempt at converting one of the 2 to lavishscript, but the runtime errors (the ones that allow the macro to keep running) did not give line numbers at the time, even if they create bigger problems further on down in the script. Not sure if that's changed, but it made IS hard to write scripts for, and hard to debug.
The problem you probably had is the failure to compile a math sequence. The reason this doesnt give line numbers is kind of technical but it has to do with the part of the code that compiles math having no knowledge of scripts and line numbers. By design, it's actually supposed to work fine if it couldn't compile the math. This is
rarely a problem, if you ran into it so much that it prevented you from coding in LavishScript, then you were doing something seriously wrong from the get go. Most people never run into it at all...
Anyway all of this is technically irrelevant as I actually suggest writing IS scripts in .net rather than in LavishScript. LavishScript is intended to be a command shell (and has always been, though it went through some fun upgrades for scripting). Standard .NET apps (written in C#, VB, etc) can run in process with Inner Space, and they can take advantage of API from IS and its components, as well as ISXEQ (note: you can wrap the LavishScript objects with C# classes deriving from LavishScriptObject, and dllimport any exported API. it's easy to distribute a .NET library for ISXEQ for people to use so they dont have to figure out wrapping the objects themselves, etc). And that's way better than using the MQ2 or LavishScript engines any day.
