hehe nice post.

Yeah I definitely understand that any SE development people reading my post would go 'oh ****!', but I don't exactly think that warrants the people who don't (and who often think they understand a lot more about how computers work than they actually do - so don't understand when a geek is 'speaking binary' so to speak) to go on a mad ratedown campaign.

Although I've never attempted to reverse engineer the code itself (but explored the object files a lot), I have seen many thinly veiled comments in 'official GM interviews' that essentially the codebase is on shakier ground than NT4 was back in the days when you'd have to install Service Pack 4 like 3 different times (immediately in install, after installing app1, after installing app2, etc) to get stuff to work.

I'm sorry for their sake, but it's not my fault if they don't have an active QA team working on bugfixes, reengineering 'scotch tape' from early rushes to get a semi-working chunk of code out the door, etc. There just are too many memory leaks on even a Windows box - and that's just the client end... I'm sure the player-objects on the server (where all the real numbers are generated, etc) are even worse off unless they've spend a lot of time isolating the leak sources in that code. Overall the code seems to work but I don't see why they can't continue to fix old bugs - especially since this isn't a one-off game but a platform that needs to stay running for at least a few more years. Obviously any patch can break new things - but test scripts could identify any of those pre-release.

I totally agree with you about the super tiny amount of RAM on a PS2 and I agree it must be challenging, however I'd rather have them reduce the memory footprint of the sound subsystem or something similar instead of affecting the inventory capacity - which really shouldn't take up that much space anyways. I've done some console and thin client coding so I understand the annoyances of coding with memory restrictions, however it's sad to have all FFXI players restricted essentially by some old fixable code that (most of which at least) really only pertains to the PS2 version.

I'm not sure if you've looked under the hood at all, but each game item has a unique reference # which is basically just a simple hex string - doesn't even look like they're using a (32bit) long int to store it (it seems to be 16bit). Now if they only are using 16 bits for object ID that does put a lower cap on the total unique number of objects the game can represent (~64,000), but it also means each item in 'storage' or 'mog safe' only takes a tiny amount of data to represent in memory if they didn't also keep all the attributes in memory - stackable items would perhaps need a tiny bit more since you'd also need to keep track of quantity, but there's no need to keep the damage and attack speed for a weapon in your storage loaded in memory unless you're actually looking at your storage box.

They say they can't increase inventory capacity, when if it was actually implemented correctly would only take a TINY amount of the total amount of memory allocated. As you at least understand, any graphics texture file for a typical beastman mob takes up a LOT more memory than a few hundred element long pointer array, linked list or other similar low level struct... The only inventory objects that would need to have 'details' loaded for them are ones equipped, or at the moment you 'use' them if they're in inventory. That's putting the cap around 20 (16 equippable slots + whatever consumables you may be using).

I know it's a lot of work and they'd need to fix other bugs in the process, but I really think they need to find a way to minimize the amount of game object data in memory to increase the functionality of the PS2 version - the other platforms of course should have enough memory and so it's more than a little bit annoying that we're being held back simply because SE didn't plan ahead when they were writing the PS2 code.

The accountants and managers at SE need to remember you need to invest in yourself... and not just for the sake of this particular game, but for their future projects as well. But since they don't actually play the game...

Edited, Thu Apr 13 12:07:00 2006

No, all of the local data objects related to your items are stored in the many data files on the client. Although the 'values' (and the 'official' inventory list) are mostly stored/computed on the server end to avoid hax0rs cheating/minting their own gil, the client has all of the data related to what items look like, sounds, motions, spell graphics, mob graphics, etc. It's all on the local side - and much of it really only needs to be pulled off the HDD _as needed_.

Indeed those data files contain ALL of the objects that one could possibly equip, sell, bazaar, etc - even if it's from an expansion area that you don't yet have. The main data files directly related to an expansion area define the monsters, zones, music, NPCs etc in those areas. Any equippable/buyable/sellable/dropped item, however, is stored in the 'common' data definition area so all people can see all the items on the AH, regardless of what expansions they have installed. That's why anybody can see the weapon you have equipped, even if it's dropped from an NM in an expansion area that person who is checking you doesn't have.

Currently they seem to hold a lot in memory that just isn't required to be persistent (at least on a low memory platform like PS2). If the inventory hash in-memory was simply a list of object IDs (but not the full details of an object sitting in storage for instance), and perhaps a few major attributes about these objects, you could leave ALL of the graphics and activation code routines (as well as the detailed attributes, which is still small but much more space than a single object ID) sitting on the HDD until used AND have cleared up room for MANY more objects in your object hash (i.e.: your character could put more crap in mog house, storage, gobbiebag, etc.).

Everything I mentioned wouldn't increase bandwidth in the slightest, and indeed if they did an upgrade correctly, you wouldn't even get an 'update packet' from the server mentioning that somebody entered the same zone as you until you; opened a search window, got within a certain proximity of their character, were in a party/alliance with them (before they zoned), or you heard a /shout from them. Then once the server tells your client that you're 'so far' away from them again, your local client can recover the memory used to store that other player info, and has no need to track their position in-zone - unless of course you approach their location when the server would tell your client to add it back on to 'nearby objects' list.

As is the game passes FAR too much information to the client about who is in your current zone... and especially when we're talking about Jeuno there's simply no reason to pass along all that data to the client - other than it was much easier to code that way.

Yay SE... :<

Edited, Fri Apr 7 11:43:05 2006