New "Macro Strings", Macro's Reborn!

[Selzak]

Yeah there's nothing too complex about it on paper, but you have to consider other things like, "Can a command execute multiple, separate commands?"

Obviously it's possible, but depending on how the game is written who knows how hard it would be to actually implement it at this point. The syntax isn't much of an issue, it's the actual process that might be difficult to handle. The difference is more like teaching it to say "wait" in Spanish vs. teaching it how to draw.

I don't know that it would be difficult, I don't even think that it would be lol...just trying to help answer your question. What I'd assume is that a macro could be "taught" to execute another by reference very easily, but that begs the question: Why can't we call macros from within a macro already?

Whatever the reason; technical, balance, etc. is what your Strings would want to address. I can't imagine that it's anything other than a balance concern.

[kingfury]

Yep, All I can do is speculate as well ^^;
Just gonna have to wait for one of the cool Community Reps like Camate or another to bless us with a bump to the Devs to see what the low down would be lol. /waves to Camate Thanks in advance ^.~

[kingfury]

I don't know that it would be difficult, I don't even think that it would be lol...just trying to help answer your question. What I'd assume is that a macro could be "taught" to execute another by reference very easily, but that begs the question: Why can't we call macros from within a macro already?

----------
A valid question. I would assume the answer would be the same for the question of: Why couldn't we have the <wait #> command that sits on the same line with other stuff from the begining? I would just think it's that some things take time to focus on and re-think the possibilities of how best to accomplish it.
Not to say that it's not possible, but rather, perhaps they haven't considered the possibilities of doing so yet. The same can be said for every enhancement made to the game thus far as well. Job adjustments, Trial of the Magains, the Exp leveling curve, etc. and the list goes on.

The unfortunate thing is, with MMORPG's, there's thousands of systems going on all over the place. Development teams have to put out the most pressing fires one by one before addressing the small ones.

[Flarez]

You should interview to work on the FFXI Dev Team!

[kingfury]

Actually it could be programed to read:

/macrostring group <"Group String Title">

Which would get rid of the possible syntax strangeness of the "(1-3)" lol. It would still be calling up to 3 macros to play one after the next, but this may be a cleaner approach.

[kingfury]

You should interview to work on the FFXI Dev Team!

-------
>< How does one go about doing this?! Camate!! Get me adopted please!! lol

[kingfury]

**EDITED ORIGINAL POST**

Macro String Groups:
A Macro String Group would allow up to 3 Macro Strings to be called on one Macro data line. The line data would appear as this:

/Macro String <"Macro String Title (1-3)">
Or this:
/macrostring <"Macro String Title (1-3)">
Or this:
/macrostring group <"Macro String Title">

[kingfury]

This is overly complex for the PS2 and almost certainly couldn't be implemented due to memory constraints on that platform.
And while we would all like for them to just drop PS2 support realistically that's not going to happen.
A solution that could be implemented on the PS2 would be to just add a command that jumps to the next macro pallet down and continues running lines similar to how /set jumps to a different macro pallet. The /set command would be used to return to the original macro pallet.

---------
Well I'm hoping to hear from an actual programmer to actually explain WHY this would be "overly complex" ^^; And in reference to the memory constraints, again, this would be essentially adding just a new level of macro management and control. Nothing more than list data and titles(a set amount of titles, not infinite amounts). That can't be that memory taxing... can it? o.o

in regards to a command that jumps to a different macro pallet and runs the next macro, there would definitely have to be stop gates to such a command to prevent endless looping. But I'd be happy with anything that would allow macro consolidation and efficiency.

[Dallas]

It's definitely within the game's reach (the basic code for something like this would take all of a couple of hours), but I think the first problems that would arise would be:

1) Exploitation
2) Complexity (on the user end)

I like the idea a lot, but from an objective standpoint I just can't see it fitting into the game.

Another way to handle this would be some kind of Moogle service where they took "snapshots" of what you're currently wearing. Instead of adding a whole new series of code for us to manipulate, a Moogle could take "snapshots" of what you have on and let you name them (up to a finite amount) to use in macros.

You could go to the Fashion Moogle wearing nothing but subligar, have him take a snapshot of you, name it "Nakey", and then use /equip snapshot "Nakey" to revert to that equipment set. If any single piece of equipment from the snapshot is not available when the macro is used, it would fail. If you had the subligar in your bag, it would make you "Nakey" wearing only subligar. I think something like this might be a lot easier to implement.

I only support this version if after using the command, a moogle comes out and takes a picture.

[kingfury]

lol, I'm sure that would be fun to see ^^

Honestly, when you think about it, if we could have two ways to accomplish these types of macros, Manual set ups(the player inputs the data manually) and Assisted set ups (using the photo Moogles), that would actually be ideal!

Manual would be for the Macro professionals that already are well verse and proficient in the art of creating and managing Macros.

Assisted would be this option for those not so proficient in the use of Macros and would just want to quickly create their macros.

I'm sure this would help with the learning curve for a myriad of players with different experience levels.