An Update on Additional Macro Slots

Greetings,

I'd like to share a follow-up comment from Hiroshi Minagawa in regards to the macro adjustments comment made by Yoshi-P during the Letter from the Producer LIVE Part XXIII.

Quote:

---

Originally Posted by Hiroshi_Minagawa

Greetings.

I’d like to give an update on the status of increasing the amount of macros, which Producer Yoshida previously commented about.

Currently, the development team is focused mainly on implementing new elements for Patch 3.1.

We've set plans for the macro improvement task so that we look into the improvement methods and complete the required cost assessment for improvement during Patch 3.1 development time.

Many function improvement related tasks have been placed on a priority list with numbers; however, as a fundamental rule, we cannot start these improvement tasks until we have implementation goals set for all the necessary UI needed for the new content in each patch.
*This is because if there is even one piece of content with an incomplete UI, the release of the patch will be delayed.

For this reason, to determine when we can release the macro improvements we will have to set the following in the Patch 3.1 time frame:

1. Determine the implementation method
2. Estimate the amount of work time needed for that method

Once the above is completed, we will confirm the work assessment of this along with the work assessment for new implementations planned for post-Patch 3.2. Then once we determine whether we can secure the required implementation time from the person in charge, we can determine the estimated release time.

While it may be possible to give an estimate as to which method will work, we cannot give an appropriate comment until the dev. team completes a thorough investigation, so please understand that we require some time for this.

Supplementary information

The current macro functions were built with many restrictions in mind, therefore changing one aspect of this would cause trade-offs where some things will work while others will not. We need to make improvements to aspects that are not difficult to do, but somewhat troublesome.

Yoshida recently explained the direction we're thinking of taking, explaining how the local storage is currently holding 100 macros per character, and that we would be looking into increasing the total amount available by changing this to an account-wide system, as well as decreasing the amount of data used for the storage. However, in order to make this possible, we need to undertake several tasks.

The following two tasks are those that will most likely require the most amount of resources.

1. The issue where we cannot undertake general methods for changing already released format

For things such as a business applications, the saved data is given redundancy so it can be formatted safely; however, in this case we specifically need to change the format in order to avoid the local storage limit. Therefore, adding redundancy to data as a safety precaution will increase the capacity, which results in something that goes against our initial plan, so this won't work.

Consequently, as a general method we will more than likely have to select a procedure for changing high risk data, and in that case it will be necessary to add a multitude of countermeasures for the change process.

For example, we need to assume preventative measures for unpredictable cases* or it may end up damaging the existing data, and may also become unrecoverable.

*Cases such as your mother unplugging the cord during a transfer, etc.

2. Regarding Memory

The main goal of macros is to be able to execute them quickly and precisely as much as possible.

For this reason, even right now, the data for all 100 macros is loaded on the client's memory when a character is logged in so that it can be executed immediately whenever needed.
*Even with this, there are certain situations where some server-side managed actions cannot be executed. 　　

There are limitations on the local storage capacity as well and depending on how much memory space can be allocated for a macro will affect the amount of macros.

We also thought of storing them in cache memory and loading them when called upon, but looking at the icon display speed which also uses the cache method, changing macros to the same method would most likely affect the level of control experienced, and we feel this would be the last method we would use when balancing macro execution reliability and macro storage amount.

In order to acquire more memory space, we will need to optimize other features which do not have any direct relation to macros, and the time needed for this work and the checks for optimizations also need to be taken into consideration for implementation.

*We specifically didn't announce this, but through every update we have been optimizing various internal processes in order to increase the amount of available memory space.

---

Any word on making macros more viable for combat? We really need a way for macros for simple abilities to be queue-able. If you macro all of your combo actions you suffer a DPS loss from latency, because you can't queue abilities.

Side note, FFXIV is seriously the only MMO I've ever played that has this much trouble with memory and network congestion. Seems like everything that other MMOs do, we can't have because of these issues. =/

Quote:

---

Originally Posted by Hiroshi_Minagawa

*This is because if there is even one piece of content with an incomplete UI, the release of the patch will be delayed.

---

TP Bar. <cough>

What is up with Mr. Minagawa? What is he talking about? His fills these comments with a lot of fancy technical speak whose purpose appears to mislead and confound. What does adding data redundancy and high risk data have to do w/ macros? What does using the cache for macros matter if the entire macro file already exists in memory?

The specifications of the locally stored macro file have already been figured out. The game executes one macro line per frame, thus macro execution speed depends on frame rate of the game. Not on how much memory it uses. And all this babble on storage this and memory that, makes makes Mr. Minagawa look incompetent or intentionally obfuscating the details of the situation to make it sound like much more work than it is, perhaps to hide the real reason (lack of funding, lack of time, lack of interest among the other developers, etc).

Why not say...
"We are looking into increasing the number of macros you may use. It might take some time but we have hope to find a way. Thank you for your patience."
This is a such better way to talk to us.

Lol, people complain when they don't give enough info and also complain if they give us too much info.

Before you create additional macro slots you need to improve the macro system as a whole.

Macros not able to queue.
Macros failing to execute properly during certain conditions;

Macro Line 1: <mo>
Macro Line 2: <t>
Macro Line 3: <me>

If <mo> target is too far away it will ignore Macro Line 1 and execute Macro Line 2 and the same thing will happen with Macro Line 2, if the target is too far away, it will execute Macro Line 3. Best would be for us to create conditions within the macro so that it does what we want.

Macro Line 1: <mo> "if no target cancel macro"
Macro Line 2: <t> "if no target cancel macro"
Macro Line 3: <me>

Then there is the fact that the Macro System will just fail by itself if you press the Macro too fast.

https://youtu.be/mGQgtAyYjTc

Quote:

---

Originally Posted by KariArisu

Any word on making macros more viable for combat? We really need a way for macros for simple abilities to be queue-able. If you macro all of your combo actions you suffer a DPS loss from latency, because you can't queue abilities.

---

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.

Like what Laraul(above) is saying, can we get a plain english translation? :P
I cant even begin to understand programming stuff so it would be nice if someone could summarise whats being said and what it means for macros.

As a healer I use dps macros that do this:

Quote:

---

/ac "Aero" <t>
/ac "Aero" <tt>
/ac "Aero" <ft>

---

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?

Quote:

---

Originally Posted by Shori

Like what Laraul(above) is saying, can we get a plain english translation? :P
I cant even begin to understand programming stuff so it would be nice if someone could summarise whats being said and what it means for macros.

---

They're working on it. Please be patient.

Quote:

---

Originally Posted by FJerome

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

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.

Quote:

---

Originally Posted by Shem

explanation

---

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

Quote:

---

Originally Posted by Asheilin

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.

Quote:

---

Originally Posted by dvoraen

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.

Quote:

---

Originally Posted by Sida

→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.

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.

Quote:

---

Originally Posted by 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.

---

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!

Quote:

---

Originally Posted by EinherjarLucian

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.