MacroQuest64

I was just wondering what the benifits are with the new system vs the old system. The only one i came up with is:

• 1. limit the MQ population even more than only to those who take the effort to learn how to compile it.

I was around when the MQ1 system was changed, then MQ1 became MQ2. I took a little time and learned them little by little and was finally able to write semi-complex macros now i have to start all over again.

2. It is better, faster and more intuitive.


Seriously,
If you can't figure out how to convert a macro with the information Lax has posted you probably aren't cut out to make macros and whatnot anyways. Also, who says you have to be the one making them and that you have to get them done immediately? Take your time, learn.

I can assure you of this, comparing the performance of every single one of my complex macros with what they were before, it isn't even close. The new system runs ALOT faster and never bogs down my machines.

The benefits are given all over, read mq2data related threads... particularly the one in the development general linked from most of the mq2data posts I've done.

The only reason you think that the old system is good is that it is how it was given to you. If you were using MQ2Data for a year, and then were shown MQ2Parm, you would say "what the hell is this thing, why are we using it, HOW do i do it.. this $char(hp,cur) crap makes no sense... how can i ${Spawn[gm].ID}? Is there a replacement for ${InvSlot[pack1].Item}?" and so on. The new system makes it a million times easier to get what you want out of it.

The new system is exactly as ml2517 put it. Speed-wise, MQ2Data vs MQ2Parm.. MQ2Parm used 1000ms of processing time in roughly 30 seconds with a fairly simple UI. MQ2Data with the same UI used 1000ms of processing time in ... about 8 minutes last I clocked it. It's a few degrees separated from MQ2Parm. Intuition-wise, MQ2Data calls everything an object... if you can get something out of one object, you're going to get it out of another object of the same kind -- as opposed to MQ2Parm, where every parameter had to be created for every possible way you might find the same object. e.g.. $target might give you different things than $spawn, even though you might be looking at the same NPC.

MQ2Data also separates the variable and non-variable portions of your query.. For example... $spawn(1,id) .. the 1 part is variable, but there is no clear indication of this. The same thing with MQ2Data looks like ${Spawn[1].ID}. Any portion in brackets you know is variable, any other portion is not.

Internally, MQ2Data is actually a lot easier to work with than the MQ2Parm system (meaning, to people who are creating new "parms" in the old system or data types/objects in the new system). Other than the variable portion, no parsing is left up to the developer. Plop in the names of your "members", specify what kind of object you're giving in return and set the value... thats about it.

MQ2Data replaces an increasingly inadequate system. What benefits are there for keeping the old system other than not having to convert to the new system? Any reason will do, think of one

Well here's an easy answer for people that don't like technical reasons for why MQ2Data is better. MORE system variables, with the old system, with each variable requiring a new $name the names were starting to get ridiculous and it was getting harder to figure out what you wanted to look at, some $ were for you, some others gave you the same info about your groupmates, and some other totally different ones worked for spawns. Now you, your groupmates and spawns all are the same kind of objects so you can get the same info in the same way for all of them, and it's easier for the devs to add more info for you to access in your macros. And they only have to add it 1 place for you to get it in all the related objects, rather then having to code in the same info 6 places.

The MQ2Data format is alot more friendly to those who already know how to code using VS.NET as those users have goten use to object coding.

Trust me if you are smart enough to make a simple macro then you are smart enough to figure out how to use the data system in about 30 mins. Most of the objects names make sence where alot of the old stuff was a guess at best.

poll was hijacked

whats wrong with people vocing if they like the new system or not? heh

there was a poll? someone voiced not liking the new system?

"I was just wondering what the benifits are with the new system vs the old system."

We answered... i dont get it, what is your question now?

This is not a democracy.

why cant we all get along.






... i like mq1 better

i know its up to the devs where MQ goes and whats built in i was just wondering how many like it and how many dislike

i love it.

If you wanted a poll, why did you ask "what are the benefits" rather than asking how many people dont like it

Object based datatypes rule.

They're intuitive and fast, what more do you need?

/cheer OOP

Other than a bit of time finding some bits and pieces (which you only need to do once), Data >>>>>>>>>>>>> Parm

Been a few years since I hacked away at database programming, but the OOP model has always been a million times easier to understand.

These guy are the creators of this magnificent program. As such, they can create it into anything they like, whether anyone likes it or not. Especially if it makes it easier for them. If somebody doesn't like it, then they should create their own third party software and tailor it how they like.

Seeing as I am pretty much a leech and have had the brain power to create one macro in the past three or four months (have modified a bunch), I am on board with anything that you guys say. Except, of course, jumping off of bridges.

P.S. I love $parm, it makes my spaghetti taste good.