An Update on Additional Macro Slots

[Zhexos]

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.

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.

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

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. =/

[FJerome]

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.

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

[Mykll]

*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>

[Laraul]

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.

[Gilthas]

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

[Darkoon]

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

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