Hey everyone, firstly sorry for the bump. I don't come on this site much at all so I haven't kept up with the post here regarding our plugin. I was linked to the thread last night in regards to a question about implementing something similar in another game so I got a chance to read the replies.
(Edit: For those that don't know who I am, I am atom0s. I am the lead dev of Ashita. Forgot the forum has my old characters in-game name.)
Wanted to say thank you to the kind words a lot of you said towards me. It's appreciated. :)
I also wanted to give some of my input on the whole SE hiring and my personal experience/information with the game to reply to some of the things said here.
Does this also help with input lag (IE, you issue a command and it does go through, but it takes like 1-2+ seconds to initiate)?
Input lag in the sense of lag that is happening entirely client sided (prior to sending or receiving any packets to 'execute' an action) is generally the result of poor frame times (not to be confused with FPS). Frame time is the amount of time it takes between each frame to render the next. In FFXI's case of being, by default, locked at 30fps, this means that you have 33.333ms for each individual frame of that 30 to fully handle all background tasks (updating all entities positions, updating each entities event VM states, processing all input, processing the current packet queue, etc.) If you start to go over that amount of time per frame, you will see spikes in your frame time which will result in the feel of input lag. Even though you can have these spikes and feel the input lag you can still be locked at 30fps and think something else is wrong.
If you are on a laptop running Windows 10 or newer, it is recommended that you use a translation layer proxy that will up-port the game from Direct3D8 to 9/10/11/12. (Or to another API like OpenGL/Vulkan) You will see a massive improvement in performance, especially on Nvidia hardware, because Direct3D8 will not cause Nvidia Optimus to trigger and make use of your dedicated GPU hardware. And while it may seem odd, the better / newer your laptop is, the worse XI will run on it because of this.
Other things you can do to help this is:
Ashita/Windower/Stock XI Options: Lower your mipmapping setting, reduce your background resolution, ensure your background resolution is square (ie. 4096x4096), when possible run your menu resolution the same as your window resolution to remove additional scaling math, use the lower end graphics settings for things like fonts, textures, maps, etc.
In-Game Options: Disable in-game shadows, disable weather effects, lower your clipping plane.
If you do not use a controller, it is HIGHLY recommended you disable it in the gamepad config tool for XI as well. FFXI constantly polls for a controller every 2-3 seconds. This was fine back in the day when computers had very few devices connected to it and prior to every device connected now having like 8 sub-devices for each added feature (extra USB ports, RGB lighting, profiles, built-in memory, etc.) Due to this, you can see a ton of micro-stutters or straight-up pauses every few seconds due to the game looking for a controller.
In some cases with things like Corsair keyboards, your game may even fully freeze for up to 1-2 minutes causing you to DC cause of this bug. I can go into more detail as to what causes this if people are interested.
I'd expect the server is smart enough to discard any packets that are abnormal or don't pass basic parsing. I also think Thorny mentioned position packets earlier, my assumption being these are typically high frequency, small size packets that would not raise alarm (I'd also assume both server/client have some form of keepalive, but maybe position fills that role also)
This has been a fix-it-as-it-becomes-a-problem situation for FFXI. The game was coded with pretty poor security practices in place (for both the game and PlayOnline for that matter) so packet protections have literally been an as-needed type of fix. For example, back in the day, you could easily crash an entire zone by sending a malformed chat packet that had half an auto-translate tag without a proper opening/closing. The server has trusted the client a lot more than it should over the years, which is why there has been dozens of dupes found throughout the years with little effort. This is pretty common for MMOs though as security oftentimes lands up being a 'do it later' goal and that goal never gets done until it has to be from an exploit. For the most part, they have added extra layers of checks and protections to the packet system on the server side, but there are still holes in it.
Kinda feels like that skeleton crew of a skeleton crew just doesn't know how to do modern programming imo
we can do all this stuff with external tools fixing the problems from the outside in, but these guys are hardfocused on fixing what they can from the inside out (which is not a bad idea, but that requires NOT being on a skeleton crew of a skeleton crew)
XI isn't really modern programming tbh. It's coded in C/C++ from the 90's era of coding and still uses old tooling that was from the PS2/PC cross-over development era. (It's compiled with VC6 still.) SE has said in previous interviews/Q&A's that the teams are/were still using PS2 dev tooling to work on the game for the PC version. (But I'd expect by now they have made some additional tooling to make PC dev easier, at least for content development.)
However, I also don't feel its fair to expect the small team they have working on XI to push out fairly big changes to the core code at this point. It's not as easy as just editing a few lines of code and going live. Changes to the core/engine of a game takes a lot of time and costs to fully cover things to avoid any kind of massive outage to the game if things go wrong. At this point in XI's life, they just don't have that kind of team size and budget put into modifications to the actual core.
For reference, all the changes that have happened to the client over the last handful of years have been strictly things that are not 'breaking' in a manner that would yield the game unplayable. They are more of 'safe additions', basically copy-pasting existing working code to add new things. (ie. Master level system.) Or just adding more onto existing systems. (ie. Extending wardrobes further.) These kinds of changes aren't game-breaking if something goes wrong and can be easily patched in an emergency maintenance.
SE tends to avoid going the route that will require rollbacks. If they implement a big change to the core/engine and that change is wrong/bad, it could lead to a massive amount of bad data being generated in the database which leads to even more problems. Which they don't have the team/budget setup for this game anymore.
XI makes plenty of money to pay a team, they just choose not to do it at this time still.
Matsui-P should get an intensive full-time English course to at least B2 to maybe C1 as part of a professional company training and speak to some persons of the Windower/Ashita community, then push to Yoshi-P and the CEO's to hire them freelance for a while. Can't even imagine what some people could accomplish if they just had the real back end on their hands. UX would be fixed in no time. You guys doing so much work around this game, it's astonishing. Great job actually posting this. Much love to all the devs and data miners out there!
I don't personally agree with this. There are a couple of things that would be a problem and a conflict of interest.
Firstly, in regards to SE hiring us (Ashita/Windower devs), this could come at the cost of our projects. Having to sign NDA's and additional agreements to work on XI's source could leave us in a position where we can no longer work on Ashita or Windower, or any similar/related/connected projects. This would require either us to negotiate in some manner to allow the projects to continue and let us still work on them, or something.
Next, this could be seen as a negative thing for SE and affect their other games / future projects and past decisions on how they handled bans. If they hire us, it sets an example that they are ok, to some degree, with the modding community of a game they have been very anti-third-party tooling over in the past. It is very fair and easy to say that XI's development has been shaped by our tools, but it's not as easy for SE to openly say 'ok' or agree to them, vs. being silent on the matter.
As for the UX overhaul comment, I don't think you understand just how in-depth XI is designed around its UI and menu system. This isn't a simple get-hired and overhaul in a month type thing. Sure people can adjust some stuff to clean things up and redo some textures and some other changes, but fully overhauling would be a literal full-on project itself.
(I am not talking about hiding the current UI and adding custom things in place, as that has/is already being done, that isn't really the same thing as fully overhauling.) A good majority of the game's code is intertwined with the menu system.
Likely they wouldn't be able to accomplish much if anything. POL / FFXI is old and was designed and built using old technologies and techniques, they might not even be using x86-compatible hardware for the servers. The entire reason we can do stuff with FFXI now is that both Windower and Ashita teams have built a framework that enables them to go around the client. They aren't attempting to fix or modify ancient C code (I think that's what the windows client is written in), opting instead to figure out where it's various functions are kept in memory and just hook into them directly.
SE isn't full of "lazy terrible developers", those guys work their butts off to produce whatever they can. In all likely hood they don't even have anyone around who even knows whatever screwball language the server engine is written in, much less is familiar enough with the networking libraries to not cause catastrophic damage changing them. Pretty much everything they are doing nowadays is scripting / object editing or resource modification, things that can be done with specialized in-house tools and don't require editing engine code.
As I mentioned above in another response, XI is coded in C/C++ using VC6. While Ashita/Windower are both coded in C++ as well, we use newer compilers/tooling. Parts of the language have changed since the VC6 era, but nothing to an extent that any experienced C++ developer wouldn't be able to work with. The client and servers XI uses are all x86 code. I can't say for sure what additional technologies are being used on the server end of things though. (ie. if they use any kind of scripting or additional things for the game servers.)
On the POL side of things, that's already [mostly] all reversed and being worked on privately. POL itself runs on 4 servers (patch, auth, profile, web). I outlined a bit of information in regards to those here:
https://www.reddit.com/r/ffxi/comments/v4gjve/things_i_have_found_out_about_the_playonline/ib6g9yi/
There are literally thousands of people who specialize in doing this exact kind of thing. It's not that hard. Sure, maybe At0mos can't do it(for the record, I would be surprised if he couldn't) but there are definitely lots of people they could hire that could in probably months if not weeks go over the entire codebase and fully document it assuming it's not documented.
Not to say this as a brag or anything, but I have most of the client reversed and documented, in some manner, already without the source. It's not really needed to get an understanding of how the game operates and functions. I'm pretty familiar with XI's inner core workings along with POL's. While seeing the actual code will still require time to get familiar with, myself and some others that work on this game would have an easier time getting situated vs. someone completely new imo.
(Please understand I don't hold myself in any higher regard/standard than anyone else, there are plenty of capable people that work on XI.)
Is there a way to make a packet that somehow represents multiple packets so more information can be pushed through the same "hole"? Kinda like a zip file packet?
Just asking, I know nothing of this stuff.
XI already operates this way. Packets are sent in chunks which contain multiple packets 'stacked' together. The client buffers packets to send to the server and then pushes chunks (compressed + encrypted) within the current rate limit and up to a max packet buffer size. The client and server both have systems to prioritize certain data, along with 'overwriting' some data that is being duplicated within the same packet frame. (For example, the client queue packet command has additional arguments that tell it if a packet already exists if the new one should be ignored or overwrite the old one before its sent.)
So a question about this addon, can the developers just put systems in place on the server to ignore whatever this addon does and just block it?
If they wanted to, yes. But it would require modifications to the server and client to be able to ignore it properly/fully.
The plugin abuses something the client and server are already designed to do.
Quetzalcoatl.Xilkk said:
»next pie int he sky is to ask a rebuild of ffxi on ue5 :P
There are already people working on various client rework projects. Each one at varying stages of implementation. Along with reworks of other parts of the game (ie. fully emulating PlayOnline). Each of these projects are discussed elsewhere and not really posted about publicly outside of more specific communities.
UE/Unity implementation of the client has been a thing for a pretty long time with various people working on it a hobby project. In the last few years, a more collective push to work on something as a group has been formed but their progress is slow and just still a side project for most of those involved.
A C++ reimplementation is being worked on as well.
As for PlayOnline emulation, that is something I am working on in my spare/hobby time when I'm bored. I've shared some information about it on my Patreon as well as on a few Discord servers, but since it's a hobby project I opt to not full-on advertise it currently since I'm working on it alone. (This kind of project though opens up a bit more than just a fun thing or for private servers, but instead also can be implemented as a replacement to current POL client for retail, allowing for a handful of different things.)