Dynaverse.net
Taldrenites => Dynaverse II Experiences => Topic started by: Braxton_RIP on October 01, 2005, 04:05:09 pm
-
We got 20
-
Coolness... :thumbsup: :) ...looking at starting ships and prodcution probabilities now... Too bad the players did not mention this stuff a week ago... bear with me... we're almost there...
-
we started forfeiting a few minutes ago. you now have a few hundred to study.
-
we started forfeiting a few minutes ago. you now have a few hundred to study.
Lol, and with 20 players it didnt crash? Thats cool... I wonder what the player limit could be pushed to now...
-
we started forfeiting a few minutes ago. you now have a few hundred to study.
No forfeits please!
-
That was onm the test server after they hit 20 peeps... hehe. So ya NO MORE FORFEITS@ Its against the rules.
Thanks for the testing guys and staying on top of it all, Bonk.
Whats the player limit look like to you. Bonk?
-
That was onm the test server after they hit 20 peeps... hehe. So ya NO MORE FORFEITS@ Its against the rules.
Thanks for the testing guys and staying on top of it all, Bonk.
Whats the player limit look like to you. Bonk?
No idea really, the forfeits made it such that I could not tell. They also appear to have been responsible for the runtime errors I was getting, as they have stopped appearing - as they persisted after I further adjusted the donation in the shiplist... I was unaware that people were forfeiting the whole time... interesting that this kit does not crash and burn like previous ones on forfeits though, just the runtime error and reduced but still present memory leaks but no crash till the runtime error was acknowledged, so we did learn something from it. The differeenmce in this SQL setup is a 4MB (or 2MB I forget which) packet limit on MySQL and the ODBC connector is connecting on a named pipe and is set to not impose any packet limit on queries and results.
-
That was onm the test server after they hit 20 peeps... hehe. So ya NO MORE FORFEITS@ Its against the rules.
Thanks for the testing guys and staying on top of it all, Bonk.
Whats the player limit look like to you. Bonk?
No idea really, the forfeits made it such that I could not tell. They also appear to have been responsible for the runtime errors I was getting, as they have stopped appearing - as they persisted after I further adjusted the donation in the shiplist... I was unaware that people were forfeiting the whole time... interesting that this kit does not crash and burn like previous ones on forfeits though, just the runtime error and reduced but still present memory leaks but no crash till the runtime error was acknowledged, so we did learn something from it. The differeenmce in this SQL setup is a 4MB (or 2MB I forget which) packet limit on MySQL and the ODBC connector is connecting on a named pipe and is set to not impose any packet limit on queries and results.
Did the current serverkit version crash on forfeits previously?
-
(Check yer mail)
Previous to what? Don't know if this current version produced a runtime error on forfeits on other setups. This is the first I have observed this build running on SQL with any significant number of live players. If we could do a stock test and reproduce the result, that would be handy. (it might be the shiplist/settings of course.)
BUT, consistently, all builds of the kit on SQL since EAW 2036 spike the processor hideously on forfeits, handles are not released, and threads do not die, it starts the memory leak process then the kit/server eventually die. Down with forfeits! :thumbsdown: It does not necessarily start the death throes with every forfeit, but depending on coincidence of events and CPU use, if the processor is spiked to 100% for longer than a few seconds the death throes usually start, but interestingly it is improved on this build, it still leaks memory but not as badly, and handles are released, it generates a runtime error and keeps running until the error is acknowledged. So something has changed for the better. Previous builds did not generate a runtime error, but just died or hung.
Of course we need to fix them, or make it so the kit does nothing, or something more apropriate when the button is pressed, if possible. A player forfeiting a mission they drew themselves should not be too complicated to rectify, but a player forfeiting a draft is the more complicated case... is it using the same code for both events? We need to examine this in detail.
-
Edited/added to above post.
-
Oh, you mean previous to adjusting the packet limit in the ODBC connector? Not sure... don't know when players started forfeiting.
Setting the ODBC connector to "Allow BIG Results" may have conicided with when players started forfeiting.
-
Checking my email :)
-
Cool, the pic I sent to your mail only shows one such runtime error, but I observed on a number of occasions dozens of them all cascaded... presumably corresponding to multiple forfeit events.
-
Oh, you mean previous to adjusting the packet limit in the ODBC connector? Not sure... don't know when players started forfeiting.
Setting the ODBC connector to "Allow BIG Results" may have conicided with when players started forfeiting.
I wonder if that has anything to do with a MySQL error I noticed that complained of queries being too big.
-
Oh, you mean previous to adjusting the packet limit in the ODBC connector? Not sure... don't know when players started forfeiting.
Setting the ODBC connector to "Allow BIG Results" may have conicided with when players started forfeiting.
I wonder if that has anything to do with a MySQL error I noticed that complained of queries being too big.
Might very well... when logging the SQL queries from the kit I saw some pretty absurdly large queries... like hundreds of WHERE clauses or joins in one query, I forget which... seemed completely unncessary, but the source flatfile code further back would have to be corrected to adjust this as it is doing the same thing, the flatfile is just more forgiving of it. (did you ever look at the GW4 SQL test logs? - I removed them from the file library but can upload them again when I get the chance...)
-
Never saw those test logs I'm afraid (or if I did, I've forgotten :( )
-
Hmmm, an AI on the server is currently showing as human... er kind of... its WONLogon is showinfg as ~AICharacter~ when it shoould be blank... I deleted it, it had no corresponding ships to delete either... weird... have seen this once before, not sure which mission is responsible...
I just noticed that in the servcharacter table that both WONLogon (the e-mail address) and the CharacterName are used as Keys in the servcharacter table. A really good reason not to allow logons with the same name, and a good reason not to use the "change the case of one letter of the e-mail bug" for multiple logins...
-
Never saw those test logs I'm afraid (or if I did, I've forgotten :( )
I'll try and dig them up and upload them again so you can take a look. Might be a while though.
-
Got your email.
This error at least can be replicated, so what we need to do is tun the serverkit from the VC++ debugger and find out which lines is causing the problem. If its related to forfeits as it appears, doing this will uncover that bug finally as well.
In regard to the table having multiple primary keys, we need to fo some backwards engineering and derive the E-R diagram for the database and determine if it really needs multiple keys (or if the table should be seperated).
-
I thought someone was running around with the name AI