Currently the Dynaverse server will only validate the shiplist.txt, ftrlist.txt, StarfleetOP.exe and *.scr mission script files, that is all, and only if the server admin places those files in the server "ValidatedClientFiles" folder. It does not validate models, and on second thought, the load and time required to do so may be prohibitive. (imagine checking the crc on all the models on OP+4... would make for a pretty long login time at the security check.)
Diz, that's a different kind of error. MagnumMan currently has me working on adding a description for that error to the serverkit code so that dyna admins will better understand what is going on when the server spits this out (partial quotes from development discussions):
Yup, that was it, when I removed all ships from the fed list but the F-BB the kit produced the following errors many times over:
Error!: i->GetShipCacheVector()->size() > 0 failed the validate in C:\Projects\T
aldren\Projects\SFC2_5\Meta\Servers\Character\AsyncCharacterProcedures\AsyncChar
acterProcedures_CreateAICharacter.cpp(238)
Error!: 0 failed the validate in D:\Projects\SFC_NEW_VC6\Projects\Taldren\Project
s\SFC2_5\Meta\Servers\Ship\MetaSpecLoader.cpp(860)
Error!: 0 failed the validate in C:\Projects\Taldren\Projects\SFC2_5\Meta\Server
s\Ship\ShipYard.cpp(97)
By the look of that the \Common\Exceptions\Validate.cpp code is doing exactly what it should. Server admins just need to know that they cannot chop shiplists like they do to control the shipyards.
The solution to this problem for the long term is to modify the shipyard and economy code so that the shipyard will do what server admins want without them having to resort to shiplist hatchet jobs.
Now that I think about it just about every time a gf setting is called for it has a valid default value specified beforehand.
As for the validate, what I would do is augment it to take one or two more arguments, and fix everywhere it is called. Then it can say "0 failed the validate for PlayerTurnRatio in file Settings.gf". That's MUCH more helpful.
OK, I'll try and trip a bad gf setting first but as I mentioned this error mosly comes up because enough ships are not present in the shiplist, I could add a message to that effect... The 0 is coming up becausee the necessary ships are not present.
Shiplist CRC check errors at player login are unrelated, and only indicate that the client has the wrong shiplist to login to the server.
edit: note this is more a of a problem when AI creation is not disabled. An AI character without a ship is a problem. THe solution may seem to be to disable AI creation, however this is known to destabilise the server in other ways. The AI that nobody wants is tied into the serverkit functioning at every level. It is not practical to attempt to remove it altogether at this point as that would effectively mean re-writing the whole serverkit whcih would be a mammoth undertaking. Just updating it to VC8 and squashing bugs with minor additions to functionality is all that we can manage at this point. Unfortunately, we do not have the resources that the original developer had at their disposal. (i.e. we're not getting paid to do this.) To give you an idea, the serverkit source consists of 2337 seperate files!
(not counting the 1819 included files from the Gamespy, Microsoft, MicroQuill and WON APIs)
edit #2: currently it is best to just minimise server AI creation (and maximise destruction) and use a shiplist and server gfs that allow for it. As the server will keep creating and destroying AI every turn throughout the server and they are subject to the same starting ship conditions as human characters so a valid starting ship must be availaible in all years the server will run. Note also that there are two kinds of AI: autonomous server AI characters and mission AI characters, it is the autonomous server AI characters that I am talking about here...
note to self: I just noticed that two of those errors quoted above indicate that some of the libraries still have not been rebuilt as they still refer to the paths used by Taldren, dammit, those should have been rebuilt with the recent project dependencies we've changed... I'll have to look into that...