So has anyone figured out how the client packets are sending instructions to the flatfile whenever a request is made? One thing I was playing with in NWN before I stopped being interested altogether was a nifty MySQL wrapper that enveloped the server executable, sniffing string arguments that contained SQL terminology, sending the statements to the DB and, if necessary, forcing the results of a query into a place in memory that NWN could address and use. This was a brilliant workaround for NWN's lack of persistent I/O, and way better than the halfassed solution they came up with later (this was the case for about all of their attempts to implement player-developed solutions that worked).
So if such a wrapper was capable of linking an instance of a DV2 server and a MySQL database, with another layer of scripting functionality built in (I don't know how well you can script server-level events in DV2), you can actually implement things like ridiculous OoB rules that are a pain to follow, special ship production limitations, hell even on-the-fly strategic goals that make DV2 seem more like, Idunno, a military campaign or something.
No this would not get rid of the flat file hell, but it would be a step on the way to it. The next step would obviously be cracking the server kit and implementing direct SQL layers and eliminating the flatfile, but you know all that. The wrapper would be a neat way for people to come up with horrible modifications nobody will enjoy while learning some SQL syntax in preparation for an evenual move to SQL.
Ex: You have a limit in ProductionCapacity determined by an equation based on the empire's overall economy, tracked over a time period. A shipyard turn comes up, and a DN is in queue. The potential shiplist is queried for approval, and the applet layer detects the presence of a DN. if((CurrentPCInUse >= ProductionCapacity) && (ShiplistEntry(X) == [one of a list of capitol ship classes]) { InterruptBuild(args); }.
Ex: You actually want to have a research and production model for an empire based on player choices and special mission objectives, instead of a dunderheaded list of ship choices with the year they come out so everyone knows what to expect every day. You have a humongous shiplist with production dates of 2100 for all classes, and turn off the shipyard, running your own shipyard applet instead. Every stardate (or whenever), each empire winds up with a number of allocatable research points based on expended economy, specialized missions to go get the super duper fake sciencey Star Trek artifact, possibly influenced by individual players spending prestige on "research direction." etc. Check to see if a new model has come out, based on the direction of reaearch, and exactly what that is. The problems of balancing a random technology build order are worth aq treatise in themselves, but it's a nice intermediary step between what we have now in gaming (predetermined technology trees) and a realistic research path.
The real benefit to an intermediary SQL wrapper step would be the ability enforce retarded rules that I really hate having to read and remember every time I play, and that so many players (in an open server, which is what we need to keep a community alive) just never bother to read. A system is better than a rule, since you can't argue about it; if you disengaged, the DB will time out your ability to take missions in that hex. This I think more than anything is what drives people away from a more structured DV2... the necessity of comprehending and following a bunch of rules designed to make things fair, as opposed to fighting more. Three Towns ran into this all the time, and where most servers would make a rule and force a DM to be a cop, we would just write a new system that took care of the behavioral issue for us. Ask anyone who played in the Heavy Gear TKZ campaign... it's no fun doing 2 hours of paperwork, debating drop conditions for another 2 hours, and setting up matches, only to have your entire team killed by me in 4 minutes.
So who all is carrying the SQL torch now, if anyone? Because the game is already pretty much dead as far as those outside this inner circle old timer's club are concerned, and I can't see anything but the implementation of a working, stable strategic operations layer bringing them back.
Topic: Client-server data stream interception and SQL wrappers (Read 2101 times)