Suggestions for New Macroquest (MQ2)

A forum for feature requests/discussions and user submitted patches that improve MQ2

Moderator: MacroQuest Developers

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Suggestions for New Macroquest (MQ2)

Post by Mckorr » Wed Mar 05, 2003 7:46 am

1. Use a freely available compiler. Currently MQ requires the use of Visual C++ and is set for .NET. As an open source program why should it be dependant on a commercial development environment (and I hate giving Microsoft money :D ). GCC 3.2 is free (well, GNU Public License), as is the WinAPI environment Dev-C++ (available on Sourceforge, http://sourceforge.net/projects/dev-cpp/).

2. How about implementation of a language similar to LISP, instead of PERL. Macros could almost be written in plain language them instead of the sometimes cryptic code MQ currently uses.

3. I'm still in favor of a more object oriented approach to macros (Object Oriented Macroing - OOM). Macros should be able to easily reuse source code without cutting and pasting, either through a better implementation of the #include function or some similar system. Especially /do_events! I hate rewriting that for every macro.


Just some ideas to throw around since we are working on major rewrites here anyway. Flame away!

Cheese
a lesser mummy
a lesser mummy
Posts: 39
Joined: Fri Aug 09, 2002 6:42 am

Post by Cheese » Wed Mar 05, 2003 9:05 am

1. Moving from VC for this project would be dumb IMO, it would be over complicating things when it's not needed.

2. The current script language was probably used because it was simpler for Plaz to write a parser for.. As for using LISP, how is that less retarded a language for the situation? I agree we could use a more flexible language and maybe some nicer syntax but LISP is never the answer for functional scripting.

3. I also think we should have plugin DLL's with C code to provide extra script functions and which has access to current offsets.. i.e. a plugin which can read some data which the main MQ program doesnt know about, you add an offset to your .ini and this plugin can read it from there on load and provides the scripting language with some extra functions to get this extra info out.

User avatar
L124RD
Site Admin
Site Admin
Posts: 1343
Joined: Fri Jun 14, 2002 12:15 am
Location: Cyberspace
Contact:

Post by L124RD » Wed Mar 05, 2003 9:49 am

Salutations,
We're keeping MQ#. also, um... VC++ is fine with me, I personally prefer it as we have msdn.microsoft.com for all our 'htf do we do this' questions :p

Clawed
a ghoul
a ghoul
Posts: 105
Joined: Mon Jan 20, 2003 6:17 am

Post by Clawed » Wed Mar 05, 2003 12:55 pm

I also prefer VC... the IDE is insanely better than TextPad + GCC~
Clawed

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Wed Mar 05, 2003 2:24 pm

LISP was just the first thing that came to mind when trying to think of a more simple scripting language, something closer to plain English. I wasn't thinking of replacing PERL with LISP. We just need a simpler syntax. All them strange variables get confusing late at night.

Investigating Dev-C++ now to see how the IDE looks, but if y'all want to stick with VC++ so be it... but how 'bout we use 6.0 instead of .NET? Seems from the various posts here that most folks have or have access to 6.0, and very few to a full version of .NET. I'm guessing Plaz works in the IT field and so had access to it without spending a couple hundred bucks... which would also explain why he implemented PERL.

Either way PERL should go, so we don't have to worry about PERL and Non-PERL versions and compiles. The non-PERL version just gave me fits anyway once Plaz incorporated PERL into MQ :)

Not sure about plugin DLL's. I write a lot of my macros with #includes to keep from rewriting or cutting and pasting code. Currently MQ doesn't handle this in a very robust fashion. Passing variables to included subroutines can be a pain, and events don't carry across to an #included file since they are declared outside the "sub Main" loop, which appears to be where a called external function begins execution. I'd like to see a better implementation of the whole function.

L124RD's MacroKit is a good example of what you can do with #include. In fact I use it quite a bit to simplify my melee and autohunting scripts. Try this in a hotkey:

Code: Select all

#include routines.mac
#include macrokit.inc
sub Main
/call Melee
/endmacro
And never have to press that annoying Bash, Kick, etc. hotkey again once you have a target in your sights.

Expanding on the #include function would allow a much easier exchange of code snippets. Macros then become modularized:

Code: Select all

#include routines.[color=red]inc[/color]
#include melee.inc
#include health.inc
sub Main
:loop
/if $char(hp.pct) < 50 /call Healme
    else /call Fight
/goto loop
/endmacro
Melee.inc would define fighting routines for melee classes, and Health.inc would take into account sitting, binding, healing spells, etc. New macros wouldn't require rewriting those routines, and events would be handled by the external modules instead of being declared in the main macro.

Sorry if I'm rambling, been up since 3am. You know the Army: "We waste more time before 9am than most people waste all day."

One question I did have: How many of us are using DX9 instead of the 8.1 EQ requires, and what impact does this have on the code?

younglove
a lesser mummy
a lesser mummy
Posts: 38
Joined: Fri Jul 26, 2002 3:17 am
Location: Jacksonville Fl
Contact:

Post by younglove » Wed Mar 05, 2003 7:59 pm

Mckorr wrote:One question I did have: How many of us are using DX9 instead of the 8.1 EQ requires, and what impact does this have on the code?
Well up until the Patch of LoY I was using DX9 and I had no problems with MQ.

Cheese
a lesser mummy
a lesser mummy
Posts: 39
Joined: Fri Aug 09, 2002 6:42 am

Post by Cheese » Wed Mar 05, 2003 8:34 pm

Whichever version of the DX DLL's use doesnt effect code at all, your code just uses the version of the DX LIB's which you link in to your project..

You could have DX9 installed and write an application for DX7..

As for VC6 / VC.NET, you dont need to use convert project bullshit the .cpp files last I tried compile fine with both compilers.. the only major changes were to do with for loop declarations (and I moved across hundreds of thousands of lines of code from one to the other with ease..)

User avatar
L124RD
Site Admin
Site Admin
Posts: 1343
Joined: Fri Jun 14, 2002 12:15 am
Location: Cyberspace
Contact:

Post by L124RD » Wed Mar 05, 2003 10:30 pm

Salutations,
well, I only have access to VS.NET, lol. I have used bloodshed in the past and am fine with it. VC++.NET seems to use basically the same syntax as VC++6, I'm curious, if we made two project files, one with vc++6 and one with vc++.net which both used the same .cpp files, would we have to change anytihing between the .cpp files?

Valerian
a grimling bloodguard
a grimling bloodguard
Posts: 709
Joined: Sun Jul 28, 2002 3:29 am

Post by Valerian » Thu Mar 06, 2003 5:35 am

L124RD wrote:I'm curious, if we made two project files, one with vc++6 and one with vc++.net which both used the same .cpp files, would we have to change anytihing between the .cpp files?
Nope, no change to the source files at all. In fact, I have a VC6 project file zipped up, which I can simply extract into the MQ source folder, and it compiles everything no problem.

Cheese
a lesser mummy
a lesser mummy
Posts: 39
Joined: Fri Aug 09, 2002 6:42 am

Post by Cheese » Thu Mar 06, 2003 7:10 am

Are my messages cryptic? seriously heh

There ARE changes you'd need to make in SOME codebases, but in MQ last I checked and it seems recently Valerian has checked / used them without change.

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Thu Mar 06, 2003 8:39 am

Then I must be doing something wrong, cause it won't compile for me. I get 10 errors, a bunch of warnings, and no DLL's just the intermediate files.

I'll go back and take a look at what I'm doing. Valerian, could you post/link your VC6 project file? I might get better results from that, since converting the .NET file is apparently eluding me for some reason.

eqjoe
a grimling bloodguard
a grimling bloodguard
Posts: 984
Joined: Sat Sep 28, 2002 12:26 pm

Post by eqjoe » Thu Mar 06, 2003 11:19 pm

MQ is dead. Its time to retire this project. Any new development effort does not need the attention of this userbase or the attention that the MacroQuest name would bring to it.

Flame away if you are a looser ... this is my just my opinion and its valid.

Work on this project will simply prolong the "cat and mouse" game between this development and the developers at SoE. If you have not noticed.. over the last 3 months, MQ has sent more time broke than working while Xylobot never saw an update. Do I like Xylobot? Not at all.. it sucks. It sucks but it works. Its time to ask ourselfs why that is.. why does Xylobot suck... and why is it that it still works.

Dirtface
a lesser mummy
a lesser mummy
Posts: 39
Joined: Tue Nov 12, 2002 2:43 am

Post by Dirtface » Fri Mar 07, 2003 2:37 am

Hate to say it, but hes right

MQ is dead, guys. As much as I would looooove to keep using it, its dead.

Valerian
a grimling bloodguard
a grimling bloodguard
Posts: 709
Joined: Sun Jul 28, 2002 3:29 am

Post by Valerian » Fri Mar 07, 2003 5:27 am

I'll gladly send the project files via email to anyone that requests them... just send me a private message with your email address, and I'll send you the zipfile with project files

Vaft
a lesser mummy
a lesser mummy
Posts: 69
Joined: Fri Mar 07, 2003 6:39 am

Post by Vaft » Fri Mar 07, 2003 6:54 am

From Magelo's website:
03/05/03 update from Jelan: Very good news guys, made some very interesting research this afternoon, you will be able to use magelo update like before and it will be even better! (Character / item updates will be detected in real time, no need to zone to refresh magelo update and you will be able to start magelo update at any time.)

I will start to work on the code of this new magelo update, it will take few days but at the end it should be really cool.
Seems as though he has figured out a way to read data from EQ after the LoY patch.. Now I realize that isn't even half of what macroquest does, but that alone should be evidence that the project isn't dead or hopeless.

Maybe tradeskilling will never happen in MQ anymore, but many people didn't even use MQ for doing combines. Some people just used it for botting other characters.. Heck, I mostly just used it for /target and /face. (made finding yew leaves and whatnot much easier, along with coth, doing spawn checks on tov mobs, dain, tormax, etc.. Theres a lot of uses for MQ besides tradeskilling.)

I would love to try to help keep the project going, even if it would be a crippled version of the previous MQ.