Results -9 to 0 of 32

Threaded View

  1. #10
    Player
    Packetdancer's Avatar
    Join Date
    Oct 2019
    Location
    Gridania
    Posts
    1,948
    Character
    Khit Amariyo
    World
    Leviathan
    Main Class
    Sage Lv 100
    Quote Originally Posted by Nothv13 View Post
    Basically this. Yet they never will because the game is on spaghetti code that for some reason can't such a system.
    If I give them the benefit of the doubt, it's probably because their storage backend isn't well-suited to it. The game has a truly phenomenal amount of gear, and if you were to just maintain a list of every piece of gear that had ever passed through your hands (or even just every bit of gear you'd ever equipped), it could get pretty large if it was just a table of "Player X has Gear Piece Y unlocked".

    IF the backend were designed for it from the start, they could've ensured the database in use had the capability for special fields of some form, like a sparse bitfield where bit X is 1 or 0, and X = a given gear piece's item ID. That would make it far easier to store 'player has seen this gear piece' without such a list having actual potential legitimate performance and storage implications. But if they're already entrenched with their data storage representation and have no good way to extend it with something like a sparse bitfield data type, maintaining a list like that really actually could be prohibitive.

    Which, to be fair, boils down to "spaghetti code" (or at least, "deeply entrenched legacy code"), albeit "spaghetti code" where it could genuinely be a valid reason.

    On a wild guess, the armoire probably works off a non-sparse bitfield, making it much easier to load, but also much more restrictive in what you can put into it (and still becoming problematic as you expand the number of items that can fit in there, particularly because since it's a subset of all gear in the game you probably require a lookup table to map item ID -> armoire slot ID).

    Quote Originally Posted by Jin- View Post
    Didn't they say that it's "following" us everywhere but it's just hidden when closed and every other player has to load everyone's wardrobe when they are in the zone?

    Or am I totally wrong? Either way it's this mysterious spaghetti code
    If I remember the explanation I've heard before correctly, it's that for glamour plates to work, your entire wardrobe has to be loaded (because the glamour plates are not separate data... arguably the first mistake, and presumably the one place it could feasibly be corrected). And for your wardrobe to be loaded, it needs to load up to 400 additional item records into memory; it's actual instances of items (or at least, some form of item instances) as opposed to just item IDs, because you can dye items before putting them into the wardrobe, it remembers if they're HQ or not, etc.

    And because the game (admittedly rightly) doesn't just implicitly trust the client, the server presumably needs to load those objects to be able to handle glamouring things. Loading your personal wardrobe on the client side isn't an issue, but loading the personal wardrobe of everyone in a zone could probably have performance implications when the zone needs to be responsive for combat purposes. (One need only look at Second Life regions where something has gone Terribly Wrong in terms of loaded resources server-side to see what the implications could be.)

    Which, one assumes, is why glamour plates only work in sanctuary zones.

    From what I understand, this is also why the glamour dressers only work in personally-instanced areas like inn rooms or the barracks, where you know no other players will be present; evidently editing that data structure while other players are present has Bad Implications or something for overall zone state.

    Honestly, justifications like that do seem technically possible, but also make me terrified to imagine what the actual implementation of the glamour system looks like on the server.

    Though, to be fair, I've seen scenarios just as bad in actual code I've had the misfortune to work on. Scenarios where a product has been out for years, and was built atop the bones of a previous product which itself was forked off of yet another even earlier thing, and so you have a codebase where some parts are older than some of the programmers working on it, full of "well, I'll do this for now and fix it later" solutions to meet deadlines where "later" never arrived and the original author has moved on long ago and now everyone is afraid to touch that code for fear of breaking whatever house of cards is built atop it... and in those cases, "spaghetti code" almost seems like a generous description.

    (It's actually a common enough scenario to have a term to describe it among engineers: "code rot".)

    And given that from what I understand, now-FFXIV is built atop some of the bones (and certainly the data structures) of FFXIV 1.0, which itself had supposedly repurposed chunks of FFXI on the server side...

    But regardless of how things got into this situation, it doesn't change the fact that it's frustrating as heck.
    (7)
    Last edited by Packetdancer; 02-27-2021 at 01:56 AM.