What Everybody Wants: Shorter, Simpler Macros

Quote:

---

Originally Posted by Laraul

Macros are stored in UTF-16 format... All combined it's less than 300Kb for every possible Macro, Map marker, etc... and these aren't fetched from the HDD until needed...

---

If macros are stored in UTF-16, then every macro book is ~288KB, so storing all macros would take ~2.7MB. This shouldn't be any issue at all for the PS2 to handle (and makes my calculations on a previous mage even more feasible, since I assumed 8-bit encoding).

Quote:

---

Originally Posted by Laraul

I would just like an /optimize command... for equipping the optimal gear for a specific job or level. I would also like to cycle thru multiple ways of inventory sorting... like name, job, level, slot, type, etc...

---

If I understand it correctly, it would be hard to implement. How do you even define optimal? For so much situational gear.. I believe it would require quite some computational power and would only give approximate results. Equipment description is stored in text form, so either it would have to be parsed (which is not possible to do correctly, due to translation errors and hidden/unclear effects) or every item would have to be stored as some sort of struct with all its stats stored internally, which would require a lot of space.

On the other hand, if you wanna do the computation server side, it would be nearly impossible to manage with thousands of active players spamming spells all the time. Or did I misunderstand what you said?

Thought.
Most of the macro issuing is because of equips. So;
Have a toggle switch. Flip the switch, this maco now has 16 spaces, but now can only be used for equip specific lines. This would allow people to have thier equip macro sets in any spot they want.

Been waiting for more macro lines for years now, hitting 2 macros to change gear is very annoying. Please SE make this happen.

I think the /equipset idea is pure genius.

Not really...I'd love to be able to access more complex commands. Shorter is definitely good though.

Quote:

---

Originally Posted by Twille

I think the /equipset idea is pure genius.

---

same...would be a shame if this wasn't explored

I also agree, this thread has some great ideas, i will be intrested to see if SE would implement such a macro system.

Quote:

---

However, allowing the /wait command to be placed on the same line as the previous command is, to use an analogy that has particularly amused me, "like applying a bandage to a severed head."

---

Since I came back i heard they changed the /wait macro system. I use macros frequently and usually have a /wait in each one..

I remember before it had to be /wait for like 3 seconds? idk. How is the /wait command used in macros?

They changed it so you can do <wait 5> in the same macro line as the previous command. Like this

/ja "Provoke" <t>
/wait 15
/echo Provoke ready in 15.
/wait 15
/echo Provoke ready.

This can now be done this way:
/ja "Provoke" <t> <wait 15>
/echo Provoke ready in 15. <wait 15>
/echo Provoke ready.

oh so you just use the <>'s, i see.
what does /echo do? tell it to your pt?

Quote:

---

Originally Posted by Kits

oh so you just use the <>'s, i see.
what does /echo do? tell it to your pt?

---

Echo is the yellow reminder text like when it gives you a timer. Only you can see it.
Also remember that anything you put after the <wait #> wont work. It has to be in a second line.

I agree with OP.

/sign

Thank you!!!!

Quote:

---

Originally Posted by Kits

oh so you just use the <>'s, i see.
what does /echo do? tell it to your pt?

---

I don't want to promote /p macros, so /echo was the best I could offer.

Quote:

---

Originally Posted by Arcon

I don't want to promote /p macros, so /echo was the best I could offer.

---

Yes, don't be like me and have /em in all of your SMN macros. ^^

May I request that this thread be moved to the "Other" forum under the "GAMEPLAY" category (or possibly the "Battle Content" forum, depending on which seems more appropriate)?

(. . . and while I'm at it, may I request that something be done about Tsukino_Kaji's eyesore of a signature? >_>; )

Quote:

---

Macro system really needs an overhaul

---

The whole reason the <wait #> was introduced was because they wanted to help us in a way that was reasonable for them to implement. According to them, totally revamping the macro system is not feasible.

I had the idea of equip sets long ago. I don't think it would require alot more memory processing since they can handle it mostly like how macros are stored : client side. You could essentially equip yourself, use something like /equipset ## save and it would essentially save what you have equipped into a macro-like data file. Since the game uses ID numbers for equipment, it probably wouldn't take alot of space either on a HD.

I don't think it will be possible really, not because of the PS2 but the overall design of the game. Each video game computer or console is built up on a game engine. A game engine contains all the neccessary code to run and operate the game, proccess files, actions, ect.

When SE add's something like a sword, they would run through the simple process of giving the object a type: weapon, wepon Type: sword, graphic, stats, if its crafted, what its made from, skill needed, ect. and it gets saved as a file in the database on your computer (Similar to a RPG maker type program). Because of that most things in the game are created in a similar manner from pre-exsisting data methods that the game engine uses. Dynamis for example, is just being revamped with pre-exsisting methods, so there would likely be nothing done we haven't seen somewhere in the game already.

Since Macros are literal game engine code, they are likely built in the game engine. When you are using a macro you are basically writing game engine code telling it what to do. And when it comes to programming a game engine no matter how good or experienced a programmer you are, they dread editing source code. Why you might ask, because any time you edit code you have to edit all the refrences associated with that code. Let me give an example.

Say you got an item in the code thats called "Bacon" that holds a value. Now the value of "Bacon" may change but there may be 50 different math formulas in the program use Bacon.

Simplified Quick Visual Refrence:

Before Change:

Program Bacon
{
main Bacon = 20

Bacon = 4 + 3 <--- Refrence to where the value of "Bacon" changes, and "Bacon" takes a new value.

End of Bacon
}


Now let's say someone decided they wanted to change "Bacon" into "Pie". While "Pie" has replaced "Bacon" the formulas that used "Bacon" are now useless because there is no "Bacon" item anymore. So when the computer does the math it doesn't have any place to put the new value.

After change:

Program Bacon
{
main Pie = 20 <----- Pie is useless because it's not used in the program.

Bacon = 4 + 3 <----- Formula is now useless because the program is saying "There is no Bacon refrence to hold the formulas value."

End of Bacon
}

Now in order to fix this problem you have three choices. 1. Change "Pie" back into "Bacon", 2. Rewrite the program entirely to use "Pie", or the most painstakingly difficult choice 3. Go through every part of the program and edit every refrence of "Bacon" into "Pie" which is what example Fixed is made after.

Fixed:

Program Bacon <---- Merely the Title of the program.
{
main Pie = 20

Pie = 4 + 3 <---- Formula now works because it's looking for "Pie" instead of "Bacon" to store the value.

End of Bacon <----- Merely the End of the Program
}

Now the cons of those choices.
1. Changing everything back defeats the purpose of editing the program at all.

2. Rewriting the program from scratch requires a great deal of time and effort debugging and fixing the new program.

3. Just like 2, it requires a good deal of time and effort. The thing thats sets choice 3 apart from 2 however is you have to search out potentially hundreds or thousands of refrences, maybe rewrite entire sections of code, and the more editing you do to the core program the greater potential you have for errors and bugs and fixing them.

The change to the <wait #> command might leave what I explained up to interpritation, however all it did was allow already exsisting code to be on the same line. Which is significantly different than changing the code or adding new code.

/sign

I've been hoping for something like /equipset #, or /macro "Name" for years.

I never buy the "not possible" arguments. I've managed a programming group for 12 years. Techs want to come into my office with long explanations of why something can't work. I smile while I ignore what they're saying. Then I tell them to think more creatively. Most of the time, they come in a week or less later with a working solution, from a different angle. If they don't someone else does.

Quote:

---

Originally Posted by Swords

I don't think it will be possible really, not because of the PS2 but the overall design of the game. Each video game computer or console is built up on a game engine. A game engine contains all the neccessary code to run and operate the game, proccess files, actions, ect.

[..]

Since Macros are literal game engine code, they are likely built in the game engine. When you are using a macro you are basically writing game engine code telling it what to do. And when it comes to programming a game engine no matter how good or experienced a programmer you are, they dread editing source code. Why you might ask, because any time you edit code you have to edit all the refrences associated with that code. [..]

---

That's not quite accurate. Macros are abbreviated code, often easily human readable/writeable, that, when processed, expand into the actual code that's being used by a compiler/engine/whatever.

So /equipset xx could simply look up which set xx is, then put all the items in an associative array. Example:

Set=25 {

neck=Stone Gorget
hands=Stone Mufflers
waist=Siegel Sash
legs=Haven Hose

}

This would put all the items in an array where array[slot] = piece. Then you just have to iterate through the array, and for every key => value input the following line:
/equip key "value"

The result is this:
/equip neck "Stone Gorget"
/equip hands "Stone Mufflers"
/equip waist "Siegel Sash"
/equip legs "Haven Hose"

Now these are several lines of normal commands and they can be executed as such.

How SE would execute the actual code depends on the structure of their program, if the sets are all stored client side it could be done by a simple function that catches the macro before it's sent to the server and formats it to proper commands (like the equip commands just now). If it's done server side, it could be either done with the preprocessor, that expands the macro into proper code, or the engine could even transform the code itself, also by a simple function. Either way, this is a very elegant and feasible solution, both to implement and use. And unlike most other suggestions, it doesn't enable/encourage cheating/botting in any way, so that's a major plus.

Would love to see it at least considered.