Final Fantasy XI (Online) Private Server files

Quote:

Originally Posted by DeannfromFFXI I need a bit of help here folks... How exactly do you update? Is the update where you have to run POL after breaking files and letting them update and fix your files for eight hours the only way? Or is there another simpler way of doing so?

Quote:

Originally Posted by borfax Unfortunately that really is the only way to do it. It takes a while, but you will have the most current data.

Quote:

Originally Posted by DeannfromFFXI Will I have to do this every time there is an update?

Quote:

Originally Posted by CherokeeMist Which files are the current most up to date? Is there a site/filehosting folder that has them updated regularly? Sifting through threads is tedious and not too specific. :(

Quote:

Originally Posted by AkkarinRX I'd be kind of wary about joining servers using the current builds, and want to share my concern with others... The way current SQL queries are structured (and not thoroughly checked for the variable bindings) leaves some vulnerabilities. I hate to introduce another dependency to the project, but in my experience switching all of the query format strings into using the Boost "format" type eliminates about 95% of the issues that allow any random player to do any damn thing they want to your databases. It's been a while since I posted so I thought I'd update folks on what I've been playing with... The change from 4 threads per player to an IO Completion Port model is good -- fantastic performance. I've simulated a sustained 10,000 connections to the account server portion at under 10% CPU (P4 2.66GHz server, clients sim'd from AMD Phenom II) with an additional 12% sustaining those 10,000 running around randomly in the lobby portion. ** A significant part of this CPU overhead is due to the instrumentation, querying performance counters & other things. Real CPU load is probably around 6-10% total. ** Still working on the game connection portion and making the compression/encryption more stable. Problem that was popping up was that the server would change keys *per connection* every time *someone* zoned... Frankly, I think there's no real need for that and it can be knocked back to a key-per-zone kind of implementation to avoid tons of recalculation. It's less of a burden to do a little more error checking to prevent rampant cheating. Also, with the change to the job queues and moving some stuff to non-IO worker threads, a lot has changed and (my) server became pretty unstable. I modified most classes to derive from a thread interface and manage it's own TimerQueue. This way, the kernel manages timed events (executive objets) like effect durations/expirations and spawns/despawns ... so it's actually a lightweight object that signals itself with a packet to the work queue rather than spawning a thread with lots of additional overhead (context & stack). In the end this turns out to be a huge change and it broke a lot of things, but what does run is lightning fast.... so I'm having to fix a lot as I go back through the packet handling (genLobbyPacket et al.). I don't know what the fuck SE was thinking with doing the compression and the encryption anyway... if the encryption was decent, probability of 0's and 1's would be equal - meaning that if it truly looked random then compression would save very very few bits. As it is, I'm still wondering why they did compression - it's just extra useless work for the server and client. I've been able to document most of the packet structures, so it's possible to handle them in native types (int, DWORD, etc.) rather than as casts from uchar* and offsets from the packet base address.

Quote:

Originally Posted by AkkarinRX At least five, but it seems their focus is more about making a few particular quests or abilities work rather than building on a scalable platform. Due to the way the threading is implemented, it requires a lot of extra work in resource locking (the semaphores). In areas where 2 or 3 locks need to be acquired - and there are many - the server risks deadlock as competing threads each hold resources locked that the others need. I know most people really only care about having a solo server or something they can use with a handful of friends. Any of the versions being worked on by various teams here can support this - and many of the contributions are interchangable. Consistent sharing is somewhat hard, but most of the time the major changes will be in CPacket.cpp or CChar.cpp. Availability varies by group - most open their servers up to others for testing, few make anything but stable releases available.

Quote:

Originally Posted by fdurv7 Anyone have a open server? Programing ur server IP change?

Quote:

Originally Posted by Roamin its the DATA folder from POL folder that you need to copy.