You've got it... we're going to probably run all the above without SQL scripts, (careful scheduling) but hopefully if we can prove a stable SQL server, SQL mission scripting will then be worthwhile. Note that terraforming and scorched earth require a server reboot even if it were done instantaneously from an SQL mission script... (see where I added a planet on the live map for The Forge, Hexx could supply on it etc, but it did not appear on the map until I rebooted the server... so some kit code modification would be required to make it fully instantaneous...) and as an aside drb and I were discussing removing the "forfeit" option from the mission selection screen altogether if possible without the client code as every forfeit puts such a hideous load on the the serverkit... or find a way to remove that load...
Also, regarding a non-web-browser-based approach, I have yet to check out the latest ACSIII client (http://www.r-pex.com/) which I had promised feedback on and possibly participation in for such purposes... from what I gather, they have made a good start, we could share technologies hopefully...
GDA-Kel figured out a way to register bonus DV for PvP kills without using specialized mission scripts when he ran his SQL dynas on EAW. If we used Oracle as the back-end database, we could use triggers to filter out the PvP wins and put in the bonus DV. Ideally, this func. should be done in a middle-ware win32 DLL, so that it is DB vendor neutral.
From an architectural point of view, a dynaverse server operates much like a web server. The physical layer is the database (dinosaur age flatfile or SQL), a virtually non-existent business rule layer (middle-ware objects stored procs., and com/atl objects),and the client layer (C++ win32 coded mission scripts).
It is always very inefficient to overload the client layer by using fat client mission scripts. But, with the dino flatfile DB, we had no choice but to shove most of the business rule functionality in the mission scripts. This results is a disjointed set of client objects that are not harmonized with each other. Only the shiplist.txt file has allowed some flexibility by regulating spares, and other ship releted func. No matter what mission scripts you use, the ship's spares are controlled by the shiplist.txt file. So, try and keep as much func. out of the mission scripts, where it's hard-coded, and instead put it in the back-end DB.
Missions are meant to write a story, not start embedding hard-coded business rules with each individual mission scripter making it up as they go. Only business rules that should be in scripts are of a macro-nature that set boundaries to define the SFC domain. For example, any realistic SFB universe game won't have DNs popping up everytime a BCH player runs a mission on the dyna. The maps should be of a standardized size unless it's a specialized mission. There should be an standardized level of difficulty in the mission no matter what ship the player flies, AI in late era don't always use slow drones, etc.
So, the sooner we get SQL, the better.