I'm sorry, while I completely agree in principle, your entire list makes no sense...?Many of you have been asking which version we are going to use, and it's going to be 19xx this time around instead of the older 1299 or the more recent 18xx that we used in Vulcano.
Turns out 1299 actually has several disadvantages:
Not a big deal because of subservers/zone changes (which aren't fully supported in the unofficial files), but it's not true; back in KO Crusade I tested increasing the limit, which really didn't take more than half an hour. It worked well, though caused a crash I didn't have time to deal with, with other issues at the time, simply because I patched one too many things (I patched something unrelated by accident), and was too busy with other issues at the time to run through the list to see which one shouldn't have been there. Otherwise, it worked fine without too much hassle.-Ver. 1299 doesn't allow more than 1500 users.
This is very vague and generic, but I can't actually think of any 'unwanted disconnections' or 'various other login issues' that affect 1.298 OR newer clients (/ servers). The only issue that comes to mind is the client spamming the server at the server list, but that still exists even in 2.0xx.-Ver. 1299 servers are often chaotic on release due to the amount of people trying to log at the same time, which leads to unwanted disconnections and various other login issues that aren't present in 19xx servers.
It's a bit of a stab in the dark, but I'm going to have to assume you mean its reliance on its single-threaded separate-process Aujard setup in place of a multithreaded database request setup as your files are now using, but that's actually something you could have done with 1.298 if you cared to; the only thing needed changing was the main request handler. I haven't done this on the database-request side because it isn't a huge deal (so long as the procs are running fast, it's fast enough to leave alone), but I did make the requests themselves multithreaded, over TCP/IP rather than its dodgy shared memory setup.
Just bear in mind that official files still use shared memory in the exact same way, I changed this, because the setup made no sense to me. While the shared memory setup suffers performance wise, it does actually offer one benefit -- preserving data in case of a crash, which you can use to ensure everyone's saved. To combat this, I just save more frequently and implement a crash handler to attempting saving on crash.
That's not a limitation of 1.298 / stock files though, that's most certainly a limit of your login server / custom stuff. I've never had to do that once with 1.298.-Ver. 1299 requires a server restart everytime the login server goes down.
This isn't true either. If your argument is more you have access to implement more prevention, being you have access to the source code, then sure. But of course that applies to 1.298 as well.-Ver. 1299 has more lenience when it comes to creating / using cheats.
There's really only one improvement 1.9xx has over 1.298 in that specific department; (slightly) improved movement updates, making speed hacking so much easier to check for. Having said that, they also disabled the packets they used for their speedhack checks, so you win some, you lose some....
Oddly enough, the database layout has never been much of an issue. For the most part, anything important is accessed indirectly, so you can change it as you please. That said, none of the above even relate to the database, so...*None of the above can be fixed in the 1299 version due to how old the files are, and the way its database is structured.
There's a lot of reasons for using 1.9xx over 1.298, but not a single one of the listed reasons even make sense...
Bookmarks