An Update on Additional Macro Slots

[Canadane]

That bit's never going to be fixed because it was a concious design choice on their part, they considered it as people using macros to play for them.

Yup, you're exactly right. But a lot of people missed the memo, I suppose.
A macro is intended to be worse than executing skills manually. They'll never let you put variables into it (if x happens then do y, else do z). They'll probably never allow them to use the lag-reduction queue that abilities have. They'll probably never increase the accuracy of the wait delay. They'll never allow you to do something beyond normal human apm.
You all that are requesting such can take a look at the macro policy they are following: http://forum.square-enix.com/ffxiv/t...88#post1520788

[Shem]

Since people have been concerned by the relevance of some of the provided information, here is my attempt at a point-by-point justification. Know that this is just me speaking from some personal experience, and not with any more information about the game than other players have (so it might not be correct!):

Issue 1: Redundancy
Currently your macros are stored using a specific format, apparently on a per-character basis. The goal is to migrate this system to something that is both account wide, and more efficient.

Your current macros would have to be taken from one model, and merged into a different model. When this happens there needs to be measures in place so that if the transfer fails you do not loose your old data. In databases this is enforced through requirements such as 'atomicity', which means that if the transaction fails the data is left unchanged. If a transaction gets stopped part way through it is as if it never happened at all. Additionally, transactions need to be 'consistent' meaning that what you end up with after this upgrade needs to be valid. This is important because they'd be taking data in one format on a per character basis and converting it to a different format for the entire account. And your macros still have to be accessible and work just the same, regardless of whether you had two macros to merge or 800. Macros go in, macros come out. There are other considerations, but this should help explain why the developer isn't just trying to confuse you here.

2: Memory

I assume there are multiple parts to this. He explains the problem, but maybe not the reasoning behind why it exists. It is explained that there are both local storage and cache limitations, the latter affecting how resources, like UI elements, are displayed. The reason why these are limited resources is *probably* due to a few different reasons. The biggest likely candidate, however, is that memory usage (as we are all aware) is a limited resource on the console versions of the game. Even if they can easily make a bit more room available to store local data, it still has to be loaded with other game resources, so it isn't as straight forward as saying 'Well, my PS3 has 20gigs of additional storage space!', and they seem very keen on keeping all versions of the game running with similar features, so even if your PC is beastly you aren't going to usually be allowed to take advantage of something they cannot provide others. Making a change here for certain clients only would not only make it harder to maintain the game going forward, but since these are macros, it could even be argued that doing so might give some players an edge, especially if the new system was somehow more optimized than what console players were using.

[Marveth]

explanation

I seriously hope people read this before answering further. Some of the replies in this thread are scary.

[dvoraen]

As a healer I use dps macros that do this:

and during ANY time I'm dpsing as a healer I get a constant error message on my screen. "Invalid Target" Yes, I am aware I'm targeting a party member; thanks you macro >.> Any way we can get rid of that?

May I introduce you to the following command (assuming your macro/-s has/have space for it)?

/? macroerror <- do this in game and read the result. Should be self-explanatory.

[Sida]

May I introduce you to the following command (assuming your macro/-s has/have space for it)?

/? macroerror <- do this in game and read the result. Should be self-explanatory.

→Display or hide text command errors within a user macro. Any errors are displayed upon macro execution. Setting resets to on after macro is executed.

While the explanation is explanatory to a degree, it doesn't do what we want it to do. It does not remove the onscreen chime+text for things like "you can't do this as you're already doing something else" which is one major way to use the fall through quality of the macro interface. I have tested that particlar command thoroughly and can say it's useless at last for my macro error woes. It removes the error messages generated during the macro, but displays them in the end anyway. For short macros the difference is unnoticeable, in practise the command doesn't work.

[EinherjarLucian]

→Display or hide text command errors within a user macro. Any errors are displayed upon macro execution. Setting resets to on after macro is executed.

While the explanation is explanatory to a degree, it doesn't do what we want it to do. It does not remove the onscreen chime+text for things like "you can't do this as you're already doing something else" which is one major way to use the fall through quality of the macro interface. I have tested that particlar command thoroughly and can say it's useless at last for my macro error woes. It removes the error messages generated during the macro, but displays them in the end anyway. For short macros the difference is unnoticeable, in practise the command doesn't work.

Try /recasterror and /actionerror, the three together (with /macroerror) are probably what you're looking for.

[Sida]

Nope, tried through them too. Recast error does nothing for overloaded macros as im not recasting anything and actionerror actally sets the game setting that's related to them. Which is off on me in te first place. At this point me and multiple other people have come to conclusion that you simply can't remove the pesky errors so while I would welcome you to offer a working and tested solution, would be overjoyed in fact, just listing vaguely error related commands from the documentation is something we went through already by ourselves.

[EinherjarLucian]

Nope, tried through them too. Recast error does nothing for overloaded macros as im not recasting anything and actionerror actally sets the game setting that's related to them. Which is off on me in te first place. At this point me and multiple other people have come to conclusion that you simply can't remove the pesky errors so while I would welcome you to offer a working and tested solution, would be overjoyed in fact, just listing vaguely error related commands from the documentation is something we went through already by ourselves.

For the thing I was using it for, it worked fine. Tested it before I posted it. Perhaps it doesn't work for your specific application. Ah well, YMMV!

[Sida]

For the thing I was using it for, it worked fine. Tested it before I posted it. Perhaps it doesn't work for your specific application. Ah well, YMMV!

Can you post the macro you were using it for? Maybe there is something then that can give some idea how to make it work. Mine is

/micon "Company Chocobo" mount
/ac "Mount Roulette"
/mount "Company Chocobo"
/ac Sprint

To summon random mount if in mountable area, to mount my chocobo if my companion is out and to use sprint if in city or dungeon (or in fight, in essence unable to summon mount). It works to what I want it to work, but if I'm summoning mount it throws error "already using an item" and if using sprint it says "unable to mount" adding the aforementioned macro error commands in any configuration to it has not been working to remove them.