Any requests for MQ?

Amadeus · Post by **Amadeus** » Fri Oct 03, 2003 5:10 pm

It would be nice to have a list of requests for *new* MQ features somewhere that dev types could browse through and code at their leisure. :) I was out of the loop for a few months while at SWG, but now I'm back and looking for something fun to make.

Perhaps someone has ideas for the taskbar icon right click abilites. I have some cool ideas myself that I plan on working on, but would be interested in anything new you would be interested in seeing.

Kint · Post by **Kint** » Fri Oct 03, 2003 7:45 pm

rewrite the parser =p have it ignor white space, max /if X work for /if X and /if n X, and maybe make / lfg 65 war, for example, check for 65 warriors who are lfg, not just all 65 warriors, or warriors who are lfg, etc. That would rock. I'd be willing to help on this too with some direction.

Plazmic · Post by **Plazmic** » Fri Oct 03, 2003 8:45 pm

the /who part should work after my spawn searching changes

prh · Post by **prh** » Sat Oct 04, 2003 4:05 pm

Actually there's a few things that would be REALLY nice to get...

First and foremost....

COM support...
Personally I've got a tonnes of webservices for my guild, being able to do COM clients in .NET for these are dirt easy and would be great for dkp handling in-game etc :)

Secondly, .NET integration... Lets face it, the macro language in MQ is decent, but not really very advanced nor is it a very readable language..

The .NET framework havs a built-in compiler and the ability to compile and run new sourcecode at run-time...

Imagine being able to write your macros in C#/VB.NET/J# or any of the other .NET languages out there..

My idea was to have .NET code able to be compiled as scripts, and have all the built-in variables and methods exposed through an object that you can reference in the base class that we let the "main entry class" inherit from...

I bet it's not easy, but it's in no way impossible.. Alternately VBScript/JScript also has a script engine that is useable, and where you can expose your own built-in objects...

Amadeus · Post by **Amadeus** » Sun Oct 05, 2003 12:38 am

You want someone to re-write the macro parser?

Hold me....

prh · Post by **prh** » Sun Oct 05, 2003 3:18 am

Oh, and another nice to have... :)

I don't know if anybody has really looked into this... But the possibility of getting access to the texts in the UI labels...

Personally I'd like to be able to have a "distance to target" in my target-box for instance...

Curious · Post by **Curious** » Mon Oct 06, 2003 4:20 am

taskbar icon right click abilites...

Perhaps a menu of available macros with single-click activiation/startup?
Or, even better, /endmacro

the macro language in MQ is decent, but not really very advanced nor is it a very readable language

The only problem I have with the macro language is commands like $char(hp,pct) ... which make a few of the commands very complicated. This example might be better as $hp(self,pct) or $hp(target,max) or $hp(ID#,min). This would make $char much easier to use/learn, and add new functionality to the language (I think).

However, modifying the established macro language would create a ton of confusion in itself. Perhaps leave the current command sets active for backwards compatibility and simply add the new $hp (or whatever).

If anyone's interested, I can list all MQ commands that I think are over-loaded (and suggested changes).

motd2k · Post by **motd2k** » Mon Oct 06, 2003 5:00 am

I'd like, and excuse me if it's possible - i cant figure out how to do it - to be able to handle more than one client through telnet. At the moment when i telnet into MQ I get access to the first eqclient to launch, and cant access any others.

MOTD

wassup · Post by **wassup** » Mon Oct 06, 2003 5:13 am

The $hp() suggestion would be great and simplify macro's quite a bit.

Ohmz · Post by **Ohmz** » Mon Oct 06, 2003 5:15 am

I like that idea MOTD, I accomplish the same thing with seperate software I've written but if that functionality were built into MQ it would be nice.

MacroFiend · Post by **MacroFiend** » Mon Oct 06, 2003 1:46 pm

Something I thought of recently that would be nice (and probably require a lot more code for memory checks) would be the ability to run a macro in the background a la unix. i.e. "/mac keepbuffs &" Then you could run your standard other macros on top of that background macro.

CyberTech · Post by **CyberTech** » Mon Oct 06, 2003 4:41 pm

Being able to run macros in a separate thread would be my top choice -- as MacroFiend just mentioned. This would also allow the movement portions of macros to be made much smoother.. Bard bot macros come to mind right off the bat here, but pretty much all class macros would benefit.

Inter-macro variables, would be a kickass godsend along with this feature.

Nanan · Post by **Nanan** » Mon Oct 06, 2003 7:20 pm

Um ok how about these.

Alter /who so it's output depends on your ingame settings for /showname

EX.
If showname = 1 just firstname displays, then the return from /who would be just the first name. If showname = 2 then /who returns first and last name with guild flag.

Id also like to have last names not be used in the /target and /who functions when looking for players or npc.

I often get a return of something like this;
/who bard
[65 ikky war] hangnail bardslayer .......

Um and lastly is there any way to reduce or remove that nasty hang when mac's stop? Iv died more then once because I continue to run forward after the mac is stopped.

dont_know_at_all · Post by **dont_know_at_all** » Mon Oct 06, 2003 7:24 pm

Nanan wrote:Um and lastly is there any way to reduce or remove that nasty hang when mac's stop? Iv died more then once because I continue to run forward after the mac is stopped.

/endm keep keys

fryfrog · Post by **fryfrog** » Wed Oct 08, 2003 7:49 am

How about a real && / || to go with the /if? Case statements would also be great for avoiding evaluating the same variable a bunch of times in a complicated and annoying to read /if statement.

Asside from that I am pretty happy though I do find what others are saying about the almost random use or nonuse of $variable vs. variable (er, now its @var vs. var right?).

It is WAY to late now but... in theory it might be (?have been?) nice if MQ scripting language was based on an existing language. The attempted support of perl was a great idea (though I don't know perl myself) and while Xylobot is no where NEAR as useful in EQ the fact that it is based on DWS means that learning the language was easy due to the sheer amount of resources.

That being said, while the MQ scripting language is "odd" it (like most other languages) tends to follow and behave like many other scripting and programming languages to it isn't THAT hard to learn. The only thing that gets bothersome to me is my first mention of the lack of a true && / || ("and" / "or") statement to go with /if.