Topic: Hexx I dont want to be a PITA, however...

[Hondo_8]

Hondo I have had my men strap your mini bar to the hull of my cruiser Muahahahaha!

FOUL! That act must be aginst some code or rule of war! 


1AFHondo

Noooooooooooooo

[FPF-Tobin Dax]

I'm so thankful we don't live in an SFC Democracy. I'm sure whatever Hexx does... it will be brilliant as usual. Either way, I'm fine, I just happen to deck out my servers with all the glitter and thought I'd pass the buck to Hexx on this one. Not that anyone has noticed... or cared... I just like to collect my own white stamps. I know you worship me. You dont need to say it.

And to you naysayers to the extra model folders that cite complications... It would be as transparent as some of the tactics you blokes use in battle against me. If put in the installer, you wont know it exists... Even granting the nod of even using tactis goes too far for some of you...

 

[Bonk]

And to you naysayers to the extra model folders that cite complications... It would be as transparent as some of the tactics you blokes use in battle against me. If put in the installer, you wont know it exists...

You misunderstand. It would make more work for whoever is creating the installer, making its creation more complicated, requiring more testing, thus delaying things further, that is all.

And yes, we're not worthy...   

[Dizzy]

dELAY THINGS FURTHER....  oops caps. 

Like waiting a few more days after already waiting 2+ months for a server will matter. 

Oh wait... I see.... he has YOU doing the installer. 

 

[Bonk]

Nope, not me. DH's msi installers work just fine.

[Bonk]

Plus,it's been more than 2 months... I just had look over the old installer files and map for the cancelled version from October '04. House Dizaroma... hehe, remember? We had the whole works customised... sounds, strings, cursors, racenames... based on Hooch's original work. Once was enough for me... thankfully it seems all those old hatchets have been buried. 

[Braxton_RIP]

I vote against the idea as it will complicate the installer and delay things further, if it is not implemented in the installer then players doing it manually will inevitably introduce errors and people will be forever crashing out of missions on model errors.

That, and I like the idea that it will be tough to tell friend from foe... it is a civil war. (or uncivil as the case may be... )

* Bonk contemplates implementing model crc checking in the serverkit for additional stability on the D2...

Doesn't altering the shiplist in any way throw a shiplist crc error anyway?

[Riskyllama]

I vote against the idea as it will complicate the installer and delay things further, if it is not implemented in the installer then players doing it manually will inevitably introduce errors and people will be forever crashing out of missions on model errors.

That, and I like the idea that it will be tough to tell friend from foe... it is a civil war. (or uncivil as the case may be... )

* Bonk contemplates implementing model crc checking in the serverkit for additional stability on the D2...

Doesn't altering the shiplist in any way throw a shiplist crc error anyway?

If i get this right, altering the shiplist would and usually does throw flags(assuming the server checks for the shiplist), but altering the resources that the shiplist points to presently does not(for instance Frey was using a battlestar galactica model renamed to match the ISC-CVA.mod). Although usually the issue isn't altered models(which i can understand, and think is cool) but people are usually missing or have misplaced fighter models or other such stuff, such as DH's cool looking skull squadron F-14(the models people are prolly gonna kill me for not correctly IDing the creator).

[Dizzy]

Doesn't altering the shiplist in any way throw a shiplist crc error anyway?

Not if done right. I you remember, My SG server was the 1st non-stock server to use an error free shiplist. That server crashed a whole lot less than the ones preceeding it, in fact I think server stability records were set. I'll have to look it up in the server awards thread... I dont know if KCW shiplist is error free.

[Bonk]

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...

[Capt Jeff]

Maybe a dumb question here...

The server kit does know that all races don't have all classes of ships in early-mid eras right?

DW,BCH,BB's for example.   So, it doesn't look to the shiplist to try and build one of these?

Bonk, can I be added to the Dyna-admins forum so I can make sure I'm on track with things for Storm Season III?   It's been 2 years since my last one, and I'm feeling a little rusty 

[Bonk]

Maybe a dumb question here...

The server kit does know that all races don't have all classes of ships in early-mid eras right?

DW,BCH,BB's for example.   So, it doesn't look to the shiplist to try and build one of these?

No, it does not know. But what matters is the presence of a ship that matches the starting ship conditions in all years the server will run.  The serverkit assumes that all shiplists are as complete as the stock shiplist.

Bonk, can I be added to the Dyna-admins forum so I can make sure I'm on track with things for Storm Season III?   It's been 2 years since my last one, and I'm feeling a little rusty 

Done.

[Bonk]

I will add to my comments above further:

It is not autonomous server AI that accumulates. The serverkit is cabable of destroying server AI and does. Depending on the gf settings and map it will reach a "steady state" after a number of cycles.

It is mission AI that accumulates clogging up the db. What causes this? Crashed missions, bugged missions, disconnects, ALT-F4s will all cause dead mission AI on the map to accumulate. As should be obvious by now it is often server gf settings and shiplist construction that will cause missions to crash. It is dead mission AI that necessitates db cleaning. The better the shiplist construction and gf configuration, the more stable the missions will be and the less dead mission AI will accumulate in the db. Dead mission AI should only accumualte due to disconnects. This is why I am adamant about software firewalls. (also, as close to stock mission matching settings as possible should be used)

Note also that a db cleaner should not remove the initially created map base AI (the number of whcih depends only on the map size), but it can remove the subsequently created server AI (as it will be recreated) in addition to the dead mission AI that db cleaners are necessary to remove.

edit: another note; even if allowAItotakehexes is set to zero the server will still resolve server AI battles, they will just not  have an effect on the map. So it is also best to minimise AI battles to be fought. With respect to all server AI gf configuration parameters it is best not to zero anything out, but minimise anything related to creation or activity and maximise anything related to their destruction. (bearing in mind the time periods used, and cpu power, especially if you intend to "run up the clock")