Dev Tracker - Discussion

We coulda had a Sephiroth battle, instead we got april fools post.

My drk was robbed of having an actual buster sword in XI.

Don't you dare play with my emotions like that.

Even if it were the same person doing both updates, it's a matter of level of effort.

Think about it this way:
How long would it take YOU to write the April Fools jokes on the version update?
How long would it take YOU to introduce an ilvl 119 version of besieged that you'd be satisfied with?

Are those both the same number of hours? If so, I'm astounded by your programming ability and/or lack of writing skills.

To think up creative ways to say *** you, it'd take a while at least.

To add +50 str and +1million hp to pre-created mobs, idk, 15 seconds? Seems generous, if I'm being honest. I can type +50 and control C control V pretttttttttty fast. Take the zone table and add statbloat to the entire thing with two clicks and enter.

And if your reply is "but testing!" Clearly. ***. Not. lol. Ain't none of that happening.

Nynjadamus gonna go ahead and predict they're gonna break em again

y'all clearly have never worked in public relations, and under-estimate the amount of attention that can go into one word. I'm not equating the two, but I won't minimize the scrutiny taken by anything with a company's name on it to avoid potential litigation,etc.

How about instead of "my job is harder than yours DUH" mentality, we all respect that good execution in any field takes true hard work and time, and also the money to pay good people to do those tasks. SE has decided the money spent on who makes their public statements is money worth spending, but keeping a functional staff for the development and maintenance of a once-flagship product isn't.

It's like going into a restaurant and you're starving and haven't eaten for days, but the kitchen only has bread and water. So you buy some bread and waster for $20, then the waitress comes out and looks at you and says, "I'm going to give you a steak meal and lots of beer, and it's on the house cause you're so cute!"

and you're thinking damn, this gonna be good I love steak and beer! and then she says "haha, just kidding!" and slaps the bread and water on the table.

and you're like, damn that was a good one. I love jokes.

Except it's April Fool's day and the waitress told you months ago in no uncertain terms that she was never going to give you steak and beer. Yet still, somehow, you're surprised that this happened to you, even though literally every year on April 1st she has made jokes for the last 20 years.

Can you imagine.

Thats not a prediction, thats a spoiler.

Honestly It's not that hard. I've done my share of game mods. Different engines too.

Copy/Edit Existing Maps
Copy/Edit Existing Classes
Copy/Edit Existing Stats/Abilities on Copied Classes
Edit Max Level of Besieged Enemies.

If I had the SDK, Oh man the crap I could do. Sure there is a learning curve like anything.

>>Get mad about april fools post and lack of content
>>Continues to pay the monthly fee to play FFXI

You forgot the most important parts...

Copy exemplar loss
Copy extreme lag and disconnects
Copy zone/character limit
Create new bugs that disrupt other content

It would really depend on how old their tools are. Unity / Unreal mods are one thing, but having to screw with code in C or some archaic packed binary data format, that's a whole other world of pain. And seeing that FFXI was coded by a bunch of PS2 console developers with 90's era tools, I shudder to think how bad their dev tools look like.

Nah, I'm pretty sure you just copy/paste 50 in a file somewhere man, it's really simple. SE engineers just haven't figured out how to copy/paste yet.

More like:

Copy/Edit Existing Maps
> Game breaks because zone ID's are stored as an 8 bit value in hundreds of functions.
> Update all those functions one by one
> Opening Region map crashes the client, and the server goes down anytime an S region changes hands in Campaign because those systems can't handle the new function output
> Fix the region map, disable Campaign for now
> Homepoint travel to new zones increases player gil instead of deducting it properly
> Fix homepoint gil
> Rmap is broken again
...

The learning curve is going to a descent into horror as you discover twenty years of technical debt and arbitrary system designs that all need to be refactored before you can actually begin to make the small changes you want.

It's not an exaggeration to say that it would be easier to re-create 99% of the game in a modern engine from scratch than it would be to bring the old code up to par.

Especially if you already had all the data in some sort of exportable format like CSV. Unity has a ton of tools that makes importing that kind of data really easy. Then write every function in the game into a script that references those tables and that's like 90% of the engine done. Hard part is hoping there is some way to export/import all those graphics assets and have them make sense.

And then you get to talking about how they could improve the textures while making them smaller so that we wouldn't have to super sample and load times would instantly be lessened.

Updated servers at whatever locations they have for FFXIV already because they are virtual now. We can have faster service if we're willing to transfer servers to location appropriate servers, if not it's the same as it ever was, bearably bad and outdated.

And then you get sad because this ain't going to happen.

Load times now don't have anything to do with textures, it's the damn server side bandwidth / packet limitation that makes it take forever to load into a zone. Packetflow has helped in this reguard.

Can't be any worse than the UT99 SDK :P Or maybe it is. Who knows how everything really looks.

Biggest issue seems to be old *** software on new Operating Systems. I kinda went through hell with that myself.

The real nightmare with FFXI might be recompiling stuff and breaking spaghetti code that randomly impacts a ton of things.

Kinda having UCC Make PTSD all of a sudden. I've never actually looked at FFXI.

I would love to though.

The point I am making, is that it is not one or the other. Everyone getting angry over time spent doing community engagement because it somehow equates to less dev time just doesn't make sense. Does anyone believe that if SE had not done the April Fools update, that the savings would of allowed for enough dev time to implement something new or even fix a bug?

Again, as I said before, it is fine to be angry that SE will not devote more dev time to FFXI but do not pretend that scrubbing a ~10 minute post would magically give FFXI more dev time.

It wouldn't fix it, but it would be less insulting.

(though, the insult is the kink you're in it for so...)

Just *** up, is just *** up. Unless you *** up while prioritizing something less important at the same time, then you *** up^2.

Now I'm imagining an alternate universe where they didn't make April Fool's jokes and the forum was ablaze with comments about how not only will they not give us new content, they're too lazy/cheap to even pay someone to write jokes.

Can't *** win with these people.

The stupidity of the fake holiday would not be missed

They should have used those precious 10 minutes of dev time adding items to the moogle slips. We would have something useful from this update and they would have an excuse for *** it up again.

So is this just like the last time where it's fine on the JP client and only broken on the NA?

Bless PorterPacker regardless.

You won't be recompiling anything, this isn't a C# or .NET or even MS Visual C with a nice project file. At best it's some ancient gcc chain with a bunch of custom libraries in there, more likely it's some whacky C + ASM language. These were PS2 console developers, lots of libraries and functions were hand coded in ASM, compiled to object code and imported into C. I've had to do this before when modifying OpenSSL to use Via's Padlock encryption engine (main dev group refused to support it at that time), was not pretty. After Intel released AES-NI they begrudgingly accepted the Padlock patchs into the repo.

PS2 Homebrew

https://glampert.com/2015/02-27/ps2-homebrew-setting-up-the-environment/#:~:text=This%20post%20will%20be%20a,writing%20C%20and%20assembly%20code.

Actually, you're probably right. What I'm thinking of is the lag between entering dynamis jeuno specifically and when the first couple mobs show up. Or if you pop a statue quickly and the mobs just blink into existence around you. Both are probably server side bandwidth limitations and nothing else.

Custom lighting and effects issues are generally resolved with dgvoodoo, but we could have longer draw distances unless they intentionally want the 'fog of war' as a feature.

Either way, I'm not playing this on anything cutting edge. There aren't any real benefits to having a better rig other than you can run your 6 characters at once, which I just don't do. Maybe they intentionally don't try to optimize certain things so that it's more cumbersome for multi-boxers. Now I'm down a conspiracy theory rabbit hole and need to stop. And the idea of a graphical rework is pure fiction for this game anyways.

Thanks I'll have to check that out.

I know it's a general belief here that their code quality is poor, but I sincerely doubt it is as bad as people think it is rather the issues faced by them are due to a series of other factors.

In addition to what Saevel said above, there are a lot of issues when you deal with code of this age. For starters, anything written 20+ years ago is going to require a lot of workarounds and weird things that aren't done today, you can go look at old open source projects from back in those days and see it. If you spend any time reverse engineering video games from the mid-late 90s, there is a lot of weird ***going on, which is mostly artifacts of hardware limitations, lack of certain APIs/compiler features, or poor practices that we've learned about since. The original System Shock was developed with a "sock semaphore", their version control was a sock that got passed around and the person who had the sock on their desk was the only person that could make edits. SE has said they never had version control, so it's likely they had something similar in place. Practices like this lasted well into the 2000s and devs then didn't have the things many enjoy today, but that also extends to compiler extensions, hardware capabilities, documentation, and knowledge of best practices. A lot has changed in 20 years.

Cross platform code is always a handful, as well, and interweaving multi-arch code poses all sorts of challenges even in modern projects, but combining it with a console like the PS2 coupled with their apparent need to be bound to Sony's devkits (and presumably their code for handling things like file formats) makes it even more complicated. The folks at SE may not even have an understanding of how these formats work, it's possible/likely that Sony handed them a static library that gets built into the client for handling assets and they have no knowledge of it at all or even the source itself (this is less likely admittedly). Some of their compilation and development processes are likely hamstrung to specific tools solely for this reason even though PS2 support is long gone, they built the rest of the client around it and replacing it is a really difficult endeavor. They can't replace the PS2 dev tools because they depend on them to make edits, but they can't update their build tooling either because whatever they are using to handle the PS2 formats is likely bound to a certain set of tools.

All this is further compounded that games are just complicated, you have input handling, file/archive/texture/etc parsing/handling, network handling, animation/cutscene handling, rendering, config handling, and so on. It's a lot especially when you start gluing it all together. Even during simpler engine eras like the Build engine and Infinity engine, you see a lot of really complicated code and they had less to deal with than this game does. It's a complex weave and it's not spaghetti code by definition as much as it is a lot of code that depends on a lot of different modules/functionality that means one change can impact a lot of others, this is true of any software project above a certain size.

I guess point being, it's easy to point fingers at SE and blame them for the problems their code has, but the reality is that all of us in their position 20 years ago would've likely produced the same or worse. There are a lot of things we have access to now that simply weren't available then. It's also really not trivial to assume that they can fix a lot of the issues we think they can or that building it all is as easy as it is some modern platform.