Page 1 of 3
Any requests for MQ?
Posted: Fri Oct 03, 2003 5:10 pm
by Amadeus
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.
Posted: Fri Oct 03, 2003 7:45 pm
by Kint
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.
Posted: Fri Oct 03, 2003 8:45 pm
by Plazmic
the /who part should work after my spawn searching changes
Posted: Sat Oct 04, 2003 4:05 pm
by prh
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...
Posted: Sun Oct 05, 2003 12:38 am
by Amadeus
You want someone to re-write the macro parser?
Hold me....
Posted: Sun Oct 05, 2003 3:18 am
by prh
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...
Posted: Mon Oct 06, 2003 4:20 am
by Curious
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).
Posted: Mon Oct 06, 2003 5:00 am
by motd2k
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
Posted: Mon Oct 06, 2003 5:13 am
by wassup
The $hp() suggestion would be great and simplify macro's quite a bit.
Posted: Mon Oct 06, 2003 5:15 am
by Ohmz
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.
Posted: Mon Oct 06, 2003 1:46 pm
by MacroFiend
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.
Posted: Mon Oct 06, 2003 4:41 pm
by CyberTech
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.
Posted: Mon Oct 06, 2003 7:20 pm
by Nanan
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.
Posted: Mon Oct 06, 2003 7:24 pm
by dont_know_at_all
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
Posted: Wed Oct 08, 2003 7:49 am
by fryfrog
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.