September 2021 Version Update

Yup, same reason there aren't slips for gear that has variable augments.

If they ever do implement a job-specific wardrobe like Buukki suggested, they could use the same system behind the scenes, which would be both efficient and pretty awesome. Could theoretically even store JSE necks and other single-path augment items at max rank, but it wouldn't work for JSE capes at all.

shut it all down guys.

this guy just solved the internet.

lets never discuss or critique again, holy *** that was deep.

wow man thank you

The reason they don't let you save stones and use them all up at once, is because of congestion. It's not instanced, it has a cap of people that can do it at one time and it's not very high of a cap. If they made the changes some are asking for, it would be like trying to enter Omen during extra drop campaigns. You're only thinking about it from the PoV of just doing it, without considering it will take you an hour to get in each time between each run.

They're incapable of seeing anything past the immediate I want to do it the way I want because I want to.

Augmented gear isn't a fair comparison so I didn't mention it. The number of configurations you can store AF or relic is much more manageable. Even if a unique normal storage slip were created every time you stored or retrieved armor/weapons, the master moogle slip would function like actual storage rather than consuming the item and flagging the master slip with it's data.

The problem with this argument is that gaol is using the same entry system, likely on the same server, same zone, etc. It's almost certainly sharing every resource, and there's no limit to how much you can save up segments and spam gaol.

Huh, when I used it, it made me look like the chief, not a regular apkallu.

There isn't enough space. Each item can hold, what... just under 256 bits? The porter moogle slips track over three thousand things. Even reforged JSE alone is 1,100 items.

They could theoretically add a new kind of character data storage to track JSE information without using inventory and automatically load those items into a unique wardrobe whenever you changed jobs. That's basically what Buukki was suggesting, and it would kick ***.

With how it is now, people who farm segments every day, usually also do boss every day, so it helps with congestion for Gaol too. I can totally see tons of people and horrible lines in weekend if you could store 3+1 KI.

If the best argument against giving more moglophones is that SE's servers can't handle more than the current small fraction of the playerbase using theirs on Bahamut/Asura, I think that's a serious problem that needs to be addressed by SE. These megaservers constantly have problems of this sort, while the other 14 are perfectly fine.

People who can only meet up a couple times a week are still paying for the game, but they shouldn't be able to schedule their content around their life because SE can't get their instances functioning effectively enough to handle the minimal amount of players..? If it actually caused such an increase in people doing the content, that should absolutely be considered a win by SE.

Just lockdown Asura and Bahamut like SE used to for the largest servers.

Lockdown Odin too, we don't want everyone's trash coming here.

JP are fine, working as intended.
Seriously I would prefer European server over any content for a year.

The only part of the idea I don't like is carrying gear I might not use just because it's part of a set. I only discount the idea because I don't see them allocating resources they don't have to get it done. Even then, if they had the resources I'd rather see an overhaul than a band-aid.

My idea isn't the ideal. It's the closest I could get to ideal within the confines of what we already have and how much(or little) time and resources they would be likely to divert to make the adjustment. Worst case scenario, we get nothing. Best case, we get a band-aid that's mildly to moderately inconvenient.

A master moogle slip isn't a valid idea. The slips use bitflags to indicate what they're holding, there isn't room for a slip to contain data on 20-odd other slips, so it'd have to be tied to the npc anyway. Pretty sure what they're actually doing is additional storage you can only access in a certain place(garden?). The limiting factor isn't character data, it costs nothing to store all your stuff. It's not NPC model either, they surely have an interface to store player data that can be used to model a NPC to behave in any way they want.

Limiting factor with a design based around a NPC is actually implementing all the menus to properly interact with the NPC. Limiting factor with additional wardrobes is load time when zoning. Assuming they won't fix load time when zoning, limiting the bags to garden or similar will make it less of an issue(garden already has obscenely long load times anyway), and they don't need a new interface if they work like the containers we already have.

Job specific wardrobes would probably be best implemented as a wardrobe that populates differently for each job. Rather than automatically tracking JSE, you could put whatever you want in it while on a job and it would remain there(but hidden) until you return to that job. This would not be unreasonable to code.
Server side would need to have an event that swaps the cached container for your active container whenever you change jobs, it could probably be treated like an active container by every other system. The downside is that if you were to put items that aren't job specific in there, it would be a ***** to find them again because you'd actually have to return to that job to search through it.

Could you imagine? 1-22 job changes to find the right job-specific Garden Locker which has the piece you were looking for? Yuck. No thanks.

I hope SE implements a solution that reflects better on them than the exectution of updates (messing up NPC names, forgetting to change ambuscade mob names, etc etc).

I don't really want any sort of Wardrobe expansion. It just adds even more time to zoning and having your inventory loading fully. When you're doing events on a tighter timer, that adds up and it's annoying.

I'd like to see a Mog House / Garden only storage container. It only loads when you interact with it. Think of a Resident Evil chest. You throw all of the stuff you won't be using frequently into it. Upgrade items, lesser used crafting mats, oddball sentimental stuff, your Mandau, etc.

IDC about your item search not working.

You can throw Rare items to yourself through delivery box, so worrying about holding multiple Rare is another dumb excuse.

To me, it feels like people aren't fully utilizing the tools they have at their disposal like Porter Moogles when they ask for JSE-based stuff. Yeah, there's a ton of slips now. Oh well.

The current slips would retain their data. The main slip isn't meant to function as the current slips, it's more of a meme to show you've unlocked access and because who doesn't need slips to store all their slips memes. It's essentially slip-specific, limited access inventory conveniently located near/on porter moogles.

That's my "they should've done this" inventory does not have to fully load every time you zone. You do not need to impulsively check your mog safe 2 every 5 minutes. I don't care if you can't find something while outside your mog house.

There should be inventory that only loads in the mog house (except that they've made it impossible because the rare items) which I really don't care about either. Who gives a ***if someone wants 2 or 12 or 1000 (Drings) of something rare. The rare tag doesn't need to exist. But they do.

A master slip could work, but only if it was used in a very specify way (multi-level pointers). It's single-bit fields could have the server tell the client, you do own slips 25, 27 and 29, for example. Slips 25 and 27 work as they do today, so we're good there. The overhead cost is simple, 1 Master Slip item whose Extra data contains single bits of the slips you do own (1) and don't own (0).

The server backend would store today's bitflags from 25 and 27 (which is the same net-total storage as the current Storage slip 25 and 27), but moved away from the item field to areas such as: a KI or the same byte storage as NPCs who store: Chapters, Skirmish and Fern/Pellucid/Taupe stones? Anyway, the point is: this is a net-equal storage to remove the existing slips this way.

Slip 29 doesn't exist yet, but let's say SE adds it, they CAN add Odyssey gear to it, but only RP-capped pieces. This is much like level 90 relic+2 armor with 20k XP augments as being store-able.

Does this make sense? Thorny is still right about the limited factors, such as NPC-menu interactions being limit factor in choosing slips, among others he's already mentioned.

The Rare tag is irrelevant because you couldn't pull a 2nd one onto your character at the same time. Just like with the delivery box.

If they inventory doesn't load, then the game can't tell you have one.

They already *** this up before when they added mog sacks. People got 2 COP rings because the game couldn't tell you had a ring in a new inventory.

But again, who cares even if it does break the spaghetti. Let em have 45 Ridills if they're dumb enough to do it.

Loving the shade lol

I've got one that takes up a slot of usable inventory, too.

Note that the reason this takes time to load is the inefficient way the server sends each item in a single packet one by one. They could overcome this by sending inventory as an array of items at once instead, but I'm not holding my breath they'll re-architecture this.

Getting a mog wardrobe should also give you one moghouse only accessible storage slot (maybe from 2nd floor or something to give them more use and help loading problems). A lot more would pay for it if that were the case, and it would also mean you have less desire to fill out each mog wardobe slot to capacity.

I think one of the problems they have is they have anti-dupe systems also, it's not just pure inventory loading.

The slips can't retain their data if you don't have them. Some kind of server side storage seperate from inventories would need to do it, at which point why bother with slips in the first place? Just abolish the system and have a npc with 27(?) submenus that stores any of the slip stuff after you pay an initial 1M.

Not really true. First off, the things windower calls packets aren't packets, but instructions. The server already mashes a ton of them together, packs them with encryption, and sends them in a single UDP packet. The instruction itself containing only one item isn't much of a problem either, the only waste is 4 bytes per item to give it a header, so using an array to avoid multiple headers would only increase speed by about 1/10. The real waste is that they send the full item every time, when the majority of items have nothing in the extra data fields.

If they did something to avoid sending extdata for items that don't use it, they could double the amount of items they could fit in the space they use (16+4 bytes per plain item instead of 40+4 for items with extdata, assuming they kept padding). After doing that, an array becomes more useful, because headers are a much more significant portion of the data. By doing both, they could fit 10 items per instruction for 160+8 bytes, which would be 2.6x more items in the same data space. This would be a significant boost, they could send all the non-extdata items as arrays then send the single items afterwards and likely end up finishing in half the time or less.

Doing that would require significant restructuring on the server end and is unlikely to happen. But, by just changing the prioritization on instructions, they could increase speed by a factor of 4. I did some numbers and explained a good bit more on this the last time we had this thread:
https://www.ffxiah.com/forum/topic/55065/july-2020-version-update/10/#3529435

The client doesn't tell you you have one, the server does. The server still has access to all the bags, so it would require some work but this is the most HELP I AM TRAPPED IN 2006 PLEASE SEND A TIME MACHINE complaint.

It's not a complaint, it's a fact. it already happened, they managed to *** it up.

Way back when, if you put your Rajas in your sack, the game couldn't find it and considered it dropped. Then you go obtain a second ring. I don't know if you could've had two Rajas or not though.

Yea, and that happened because of a mistake they made. They added the sack, but did not adjust their internal 'check for rare item' function to include the sack.

It doesn't matter if the player can see the container or not, it matters if SE codes their ***correctly. You can say they frequently fail to do so, but that's just giving them a cop-out for avoiding changes that we desperately need. If they're really scared they'll screw something up, they could check the same flag delivery box has and only allow you to store things that are self-dboxable. Problem solved.

The current staff can't find their *** with both hands. so.

It's not me giving them a pass, it's knowing they won't even try it because they're incompetent.