[Fun] What Is The Most WTF Thing In FFXI?

Can someone explain this to me plz?

When an Indomitable Faaz and a Jeering Pixie love each other very very much...

When Pixies and Faaz love each other really much, they make fat little ugly flying pig babies.

The lore in this game is actually pretty good if you care about that. I just came back from a 10+year break, and it's nice to see TVR actually wrapped stuff up and answered questions to some loose ends that they left basically since the base game.

FFXI had a terrible story system back in the day, due to the nature of how the cut-scenes happened you were usually in a group and had to rush past the dialogue.

I liked the story and characters on a surface level but I barely knew what the overall narrative was in any of them.

I quit in 2012 or so and came back about 2-3 years later, and I came back with a totally different mindset and got really fixated on the lore and stories.



lube, lots of it.

But… why aren’t the porxies living with their parents?

The economy of Reisenjima is good enough they could afford to move across the stream.

Ain't no way that Faaz is paying Child Support.

The teleport to Kirin's room is my biggest "WTF!".


For anyone who may be unaware, the teleport to Kirin's room could also seemingly randomly, teleport you to the middle of nowhere. Twentysomething people standing around waiting for the one poor *** who had to circle sky a dozen times just to get into the room.

Parradamo Tor is runner-up, mostly for the same reason. Go around >.>

old dynamis, a quadav whm using silena to remove its own silence

Trust me it's not at all a thing today AFAIK, but even the tools I had way back would allow me to be invis (or under the map if I felt like it) auto detect warp to and claim and nm, sure I'd use Dia or a dart or something less obvious than insta claim provoke. End result was still the same in college we had every Cassie spawn for over a month, was very competitive at king artho (1speed 1 velocity). And this was just me and a friend in college 2 boxing mnk/pld and drk/WHM (maybe rdm) it was silly af.

Oh god no, you reminded of things I learned to forget. Cause it was always me that everyone was waiting on.

Wasn't it time based or something.

Welcome to the magical world of HACKING (TM).

The way FFXI works, it's possible to tell the server "hey, tell me about this target here and send me regular updates about it". The server, weirdly enough, always honors that request. If the target is dead then the info will include a flag that say "the target is dead" and its position will be the X,Y,Z of where it last died. But since you're getting regular updates about it, the moment it comes alive you will receive a packet that says "hey the mob is alive" and that contains its current X,Y,Z coordinates.

Goes without saying, the vanilla client cannot do this natively: this is only possible through hacking, but it's not very hard hacking. And it uses the widescan mechanism (and the packets relative to it).

Somebody figured this out already 20 years ago, and it's been the same since. It's just useless to do it nowadays due to how most stuff of relevance is forced pops, and due to how warping around is now recognized and punished.

Square had no idea this game would last longer than 5 years so I doubt they really cared much about taking notes back in the day, for future coders who would take over. Which is why so little at a fundamental level has ever changed.

They said this a few times, if they wanted to do serious fundamental updates they would have to spend a long time reverse engineering all this code first.

I find it sad that people taking advantage of stuff didn't lead to them fixing those things, and instead just lead to them not doing that kind of content anymore. Not just in XI but XIV and many other games.

Ah, I wasn't aware this was a thing.

Does the vanilla client use this legitimately somehow, for tracking via widescan maybe? I'm curious why this bit of functionality would exist in the first place.

WotG isn't the original timeline, but it is our timeline and our past.

If I remember correctly, Cait peered into alternate timelines (of which ours was one of) to find one to supplant the original. Once she picked ours, she sent us back from the present of our "fake" timeline to change the past and make our timeline the "real" one. The whole thing is a bootstrap paradox. The timeline she used to change the original timeline was created by the very changes she made.

I don't remember any specific examples, but there are several instances where you can interact with characters in the present who remember you from the past, saying stuff like "you remind me of someone I used to know." Excenmille is one of them, I believe.

Edit:
I also always kind of assumed that Cait had picked several alternate timelines to experiment with and not just ours: one alternate timeline for each copy of Cait you see in the cutscenes (minus one probably, the Cait from the original real timeline), and that ours was just the one that proved most fruitful and the one the Caits agreed to ultimately go with. They probably had multiple timelines they were running throughout the entirety of WotG and just slowly culled them down with Atomos until the one they wanted (ours) remained. I don't have any huge reason for thinking this, it just always made sense to me as to why there were so many copies of Cait.

A wiki page I found lists them as Cait Aon, Cait Dha, Cait Tri, Cait Ceithir (the traitor we fight in the missions, maybe the one from the original timeline?), Cait Coig, Cait Sia, Cait Seachd, Cait Ochd, Cait Naoi, and Cait Deich. That would suggest they sampled 9 alternate timelines and ultimately chose to preserve ours alone.

Aight, so, the way Wings of the Goddess portrays the timelines and such, at least in English, is that the branching from the prime timeline starts in the Shadowreign Era. Hence all of the [S] on the past zones.

The timeline branched because Altana did not like the result of The Crystal War, wherein the original/prime timeline, the Allied Forces of Altana (the children of Promathia) lost the war to The Shadowlord. This is Lady Lilith's timeline.

So she wept and her tears created the Cait Sith who were tasked with changing the outcome of the war, thus changing the timeline. There are multiple Cait Sith because each one of them is a tear of Altana. They later fuse to become more powerful.

We come from a timeline that branched due to these changes being successful. However, due to the nature of changing time, many other timelines were brought about, and so Atomos was employed to consume them. This is why the Cavernous Maws appear.

Basically, WoTG is taking place in a time where all timelines are linked by Atomos.

This prompts Lady Lilith to travel back to the Shadowreign era as well, to foil the Cait Sith's efforts, to maintain her own timeline's existence.

We go back in time merely for being curious about the Cavernous Maws, and it is implied by Cait Sith that we are Altana's chosen, so it is our destiny to push our timeline into being the "true" timeline.

As with all time travel shenanigans it's really murky, but it does put Lady Lilith in a very sympathetic light, as it all really boils down to, "Kill or be killed." Just with a lot of supernatural window dressing. Which is why Lilisette goes to Lady Lilith's timeline to try and preserve it as well.

It only gets more screwy when we bring in and talk about Voidwatch, Voidwalkers, and Abyssea as well, since these introduce not only alternate timelines, but alternate universes what with the Grey Cait Siths from Provenance.

IIRC this was the going understanding at the time, but it couldn't really be tested. When you step onto the pad there is a dialogue box that pops up and prompts you to select when to teleport. If memory serves, that dialogue box obscured the game time so you couldn't verify it anyway.

Thanks Tanaka.

He's Paul.

Simple. Bad (more like incomplete) programming. It sounds like the widescan function has no failsafe to prevent the client from using it in a way it wasn't intended. Widescan is only meant to work in a radius centered around your character, but it sounds like there is server side functionality that allows it to work from anywhere in the zone regardless of distance. The client is not configured to widescan for mobs outside the intended radius, so normally it won't ever ask the server for information on a mob all the way across the zone. But just because the client isn't configured to ask for information on something doesn't mean you can't hack it to ask for information it normally wouldn't.

If the widescan coding was implemented properly there would be a check server side to ensure the requested information the client was asking for is valid, and there should also have been a check to make sure the job doing the widescan was either ranger or beastmaster (since this was in the days before widescan was given to every job at a smaller radius). It sounds like they didn't do either. The server code should have had a failsafe that said "If the requested widescan target is outside the intended range or from the wrong job, deny the request". From the sounds of it, the programmers never had the foresight to anticipate that scenario so they never included that check. Hence the reason the client is able to get around it.

In defense of programmers somewhat... you sometimes need to program making certain assumptions... I suspect they didn't program all their functions with the assumption 3 party tools would make all sorts of requests and therefore would spend time programming those contingencies. Not to excuse any spaghetti code... but it is 100% impossible to anticipate everything.

For my own oddities I find it funny that many of the rewards would have been useful prior to obtaining them. MAAT hat comes to mind for one (though I suppose ToM makes it at least somewhat useful after you get it).

Some of this is indeed part of the tracking mechanism, but for the most part this doesn't seem to be intended behavior - it's just a bunch of functions that are designed with the idea of on normally only being available in certain situations, so when you invoke them "manually" they do what they're written to do because there is no check for distance.

EDIT: to clarify further, widescan does use some of this, but the underlying mechanism is much more fundamental to how the FFXI client receives info about entities that are displayed on screen.

To be fair this was made to be a ps2 game and they probably had no idea it would ever be ported to PC when they made it, this was also their first online game I believe so they had no idea people would goto the lengths they did to get an advantage. Everyone working on the game also thought it would be closed in a few years and not last 22+

Spaghetti code is a meme but with XI it's kind of true, they are afraid to touch anything cause the original coders did mcguyver ***. If they adjust the rubber band the house will burn down.

I don't think SE ever built this game with the concept it would fail in a few years, that's a terrible business model. I'm sure a lot of their business plan for the game was based around Everquest. It was pretty successful at launch, but was pretty bot filled after only a few years.

People have been cheating in video games ever since video games have been invented. We used to have magazines come to our house every month to learn how to cheat. We could even trade 2 weeks phone privileges to call a 900 number and have an adult tell us how to cheat for only $3.99/min.

Thanks, that makes sense.


I would defer to people who have actually REd the client, but I doubt the code is as bad as people are making it out to be, rather it's a product of its era. Development practices, standards, and processes have changed a lot since the late 90s when they started writing 11, there are things understood now that I don't think they would've expected then. Anything this large is going to have "there be dragons" in the code, but I'd be surprised if it's as messy or disorganized as the meme would indicate.

The idea of excessively trusting the client was common practice in that era (and still is depending on where you poke around), something that's better understood is a "bad idea" (to the extent it is avoidable) now. I've seen far more egregious examples from this era, including one application whose entire auth scheme involved the client requesting the plaintext password file, the server sending it, the client verifying the password, then sending a message to the server with its own auth data. I still see nonsense like this from time to time, but not nearly as much and most developers at this point understand you can't trust client data or state, something that would be far less understood then.

General availability and quality of software reverse engineering tools has improved a lot since the early 2000s as well. As a result, I think devs are more likely to know, at least at a high level, that their code isn't some binary black box that no one will figure out.

Exactly. If I were the developer designing the widescan function I probably wouldn't have thought to add that either. When you're designing code for something you create it to do what you want it to do. This is perfectly fine and won't cause problems (shouldn't cause anyway) if the function is for a standalone app. But when you have a client-server interaction, and especially within the realm of an online video game, you have to think outside the box and try to build contingencies with the assumption in mind that the user is going to try to break things, so you want as many fail safes in place as possible to prevent them from doing things they shouldn't be allowed to.

This however is a more modern mindset to design. Ranger and beastmaster existed at the game's launch, so we're talking about code that was written before the 2002 release in Japan. Back then thought processes and best industry practices were vastly different from what they are today. So I can't fault them for not thinking about this interaction ahead of time. BUT, the fact that that functionality still remains today as it did back then means either one of two things.

1 - The developers never realized that users were using third party tools to abuse the widescan function in the 7 or 8 years or so of the level 75 era. That was the hayday of claimbots targeting and claiming mobs before they even showed up on screen, resulting in mobs spawning purple.

2 - The developers DID realize the function was being abused but chose not to make any changes.

I'm going to assume the latter is the case, because they implemented the claim delay server side at some point in time during the 75 era as a workaround to the base issue. It's possible they figured that since ranger and beastmaster would still be able to use widescan anyway then the better fix would just be to implement the claim delay system so that claimbots wouldn't automatically have an advantage, but if that's the case.... they STILL should have added the check to the widescan function in addition to adding the claim delay system. Adding a new system to correct an existing vulnerability doesn't mean you shouldn't also close the vulnerability hole if it can be done. This is conjecture of course. We don't know what the devs did or did not know about what users were doing with third party tools at the time. But it does make you wonder doesn't it?

It's also possible changes were too difficult or required too much re-architecting to fix, even if they were aware.

Using this model, if they are 'subscribing' to the position of the mob when tracking happens, then all of those subscriptions would have to be purged when the mob dies (requiring a notification to the client) and there would have to be state checks against the status of the mob when the subscription is requested, as well as a range check (widescan distance was shorter in some conditions then IIRC). It's possible that the code handling mob state didn't have the hooks necessary for the widescan code to do this or do it without other side effects, or there was some other issue that untangling was too difficult.

9 times out of 10 when there is a bug that seems trivial to fix on the surface, digging into the code reveals it's a far more complicated architectural issue and I could abstractly see how fixing this would turn into a cascading series of changes that was easier to just mitigate than fix.

I'd give almost equal likelihood to them not being aware, though, same with some other tools that let you bypass certain state checks I would've thought existed and are still used now.