Dynaverse.net
Taldrenites => Dynaverse II Experiences => Topic started by: Dizzy on October 03, 2005, 01:51:52 am
-
nt
-
Looks like the server is coming up... mb rebooting itself? But it counts down to 0 and says there was an unknown error while attmepting to connect. After it times out, it crashes again. Happeded to me 2x.
Going to bed after I try to get my mic to work again. My kid stuck it in gravy, hehe.
-
Of course ! One of those rare days nowadays that I can play for hours and hours and hours, and it's not there.
Conspiracy !! ;)
-
Join the club ;)
-
Join the club ;)
Looks like I joined also. Do we get a membership card?? LOL
Wraith 413
-
I'm working on it... <bonk sh*ts brick> :(
-
I dont know if you can look at the db in terms of what happened per turn... but there were 14 or so peeps on at stardate .210 and it burped us all off. It immediately came back up way too quick for a reboot I told DH and then a minute later we saw the clock change from .210 to .211. So if it did crash and autoboot, then shouldnt it either back up to the last saved turn, .209, or wait 11.8 mins to hit .211?
Anyway... thats the 1st time I know of a burp and it did it one more time later than night. If it helps... there ya go.
-
OK, fixed the db, hex 18,25 was bugged, the cartel ownership was 2323 when it should have been 23.
The two characters I suspect were involved are KBF_Khemaraa_BM and Sloppy Wiper as they had active mission profiles in the db (only two). If you guys had a bugged mission in 18,25 I'd like to know, if not I'd like to know who experienced a bugged mission there and did they have a software firewall up? And what was the mission? And what ships were involved?
In the process of looking for the error, I found some odd values for medals in the db of like 129 and 64 for a few characters as well, I changed these back to 1 - sorry if you lost any medals, but these values just did not look right.
I also did a db clean in the process.
Server is back up, but the processSentinel will not work at the moment, something is stuck in memopry, I'll have to get Frey to hard reboot the machine.
Dizzy, the turn increments every shutdown-restart regardless of where the clock is. If it burped on this bugged hex a few times before it hung, that would explain what you saw.
-
In the process of looking for the error, I found some odd values for medals in the db of like 129 and 64 for a few characters as well, I changed these back to 1 - sorry if you lost any medals, but these values just did not look right.
I know that every problem that arises is usually worth a look to find a fix, but do we need to on this issue? Is this a function of the script that can cause these db errors... I dont like db errors, and I think medals suck anyway cuz they dont tell you what they are. I cant even remember the last server I clicked on the medals button. What medals?
-
OK, fixed the db, hex 18,25 was bugged, the cartel ownership was 2323 when it should have been 23.
I have seen this before on SQL, this could be our recurring problem with SQL that we do not see on the flatfile, as it is suspicious of an error in query translation...
-
In the process of looking for the error, I found some odd values for medals in the db of like 129 and 64 for a few characters as well, I changed these back to 1 - sorry if you lost any medals, but these values just did not look right.
I know that every problem that arises is usually worth a look to find a fix, but do we need to on this issue? Is this a function of the script that can cause these db errors... I dont like db errors, and I think medals suck anyway cuz they dont tell you what they are. I cant even remember the last server I clicked on the medals button. What medals?
Sorry but I cannot go back now, I did not backup the db before fixing it, only after it was fixed did I dump it to a file. I did not note which characters had these medals values so I cannot restore them. (It was only 2 or 3 characters). I was in a bit of a panic looking for the error...
I was watching where the server crashed on startup and looked in the related tables for errors. First the servcharacterrelay, so I checked the character table and removed the prepared missions, then it got past that and crashed on the newsrelay publishing, so I cleared the news rtable... I then recalled it does an economic report every two turns in the news which needs to look at the maphex table, so I looked there and found the error. Only by process of elimination did I discover the error in the maphex table. In future I will check the maphex table for this type of error first.
-
OK, fixed the db, hex 18,25 was bugged, the cartel ownership was 2323 when it should have been 23.
The two characters I suspect were involved are KBF_Khemaraa_BM and Sloppy Wiper as they had active mission profiles in the db (only two). If you guys had a bugged mission in 18,25 I'd like to know, if not I'd like to know who experienced a bugged mission there and did they have a software firewall up? And what was the mission? And what ships were involved?
In the process of looking for the error, I found some odd values for medals in the db of like 129 and 64 for a few characters as well, I changed these back to 1 - sorry if you lost any medals, but these values just did not look right.
I also did a db clean in the process.
Server is back up, but the processSentinel will not work at the moment, something is stuck in memopry, I'll have to get Frey to hard reboot the machine.
Dizzy, the turn increments every shutdown-restart regardless of where the clock is. If it burped on this bugged hex a few times before it hung, that would explain what you saw.
The values for character medals are bitwise enumerated values,
eg. kMedalOne might have the value 1 >> 4 which is a 1 bit, bitwise shifted 4 places. In decimal this is the same as multiplying a number by two. So, the medals values should look like one of, 2, 4, 6, 16, 32, 64, 128 etc etc.
I'm interested to know how the bugged hex occurred. Bugged hexes have occurred before in the flat file, but a hex bugged by an ernoneous ownership value has only ever hapenned as a result of a database edit (in flat file, and yes, it was Fluf's fault, lol, this hapenned on LB3).
For this to happen on SQL could indicate a programming bug, which is just the kind of info we need.
-
Ah, thanks for the info on the medals values Tracey, I would not have beed suprised by a value of 128 , but 129 just did not look right, unless its 129-1(original value). Anyhoo, I'll leve em be now that I know they were not the problem.
I'm interested to know how the bugged hex occurred. Bugged hexes have occurred before in the flat file, but a hex bugged by an ernoneous ownership value has only ever hapenned as a result of a database edit (in flat file, and yes, it was Fluf's fault, lol, this hapenned on LB3).
For this to happen on SQL could indicate a programming bug, which is just the kind of info we need.
Me too, very much so. This would not have been the result of a db edit unless someone hacked into the db (God forbid). But this does look like a bug and not a hack, it could only be a hack by someone very knowledgeable about how to crash the kit.
Like I said above I have seen this exact error before and it is suspicious of an error in query contstruction as the neutral cartel hex ownership value of 23 was simply repeated as 2323. But is is also possible that this is a symptomatic error of a problem with a particular mission or ship...
-
In the process of looking for the error, I found some odd values for medals in the db of like 129 and 64 for a few characters as well, I changed these back to 1 - sorry if you lost any medals, but these values just did not look right.
I know that every problem that arises is usually worth a look to find a fix, but do we need to on this issue? Is this a function of the script that can cause these db errors... I dont like db errors, and I think medals suck anyway cuz they dont tell you what they are. I cant even remember the last server I clicked on the medals button. What medals?
Ranks, medals and special mission medals are all stored together. This was not an error.
-
Here is the enumerated list of medals from the OP API
enum eMedals
{
kNoMedals = ( 0 << 0 ),
kMedalRankOne = ( 1 << 0 ),
kMedalRankTwo = ( 1 << 1 ),
kMedalRankThree = ( 1 << 2 ),
kMedalRankFour = ( 1 << 3 ),
kMedalRankFive = ( 1 << 4 ),
kMedalMissionOne = ( 1 << 5 ),
kMedalMissionTwo = ( 1 << 6 ),
kMedalMissionThree = ( 1 << 7 ),
kMedalMissionFour = ( 1 << 8 ),
kMedalSpecialOne = ( 1 << 9 ),
kMedalSpecialTwo = ( 1 << 10 ),
kMedalSpecialThree = ( 1 << 11 ),
kMedalSpecialFour = ( 1 << 12 )
};
As you can see, ranks, missions and special mission medals are all stored in the same place.
Combinations of the above are of course possible, so that if a character has a medal with a bit flag of a value of 128, a rank with a bit value of 1 (which is ceratinly possible as can be seen from above), then in the database, the decinal that is stored there will be 129 (128 + 1).
The value 1 << 3, for example is the value 1 bit wise shifted 3 places to the left.
So, in binary we have 0001, which is then bitwise shifted 3 places to become 0100. In decimal, these vaues are 1 and 8 respectively.
Now suppose we have a character that has a rank of captain, and has earned a medal for mission one. The value stored then will look like 0001 0010. The first 1 denotes the mission medal, and the second 1 denotes the character's ramk. These are called bit flags. The decimal value would be 18.
-
Coolness, that makes sense. Handy to know. :thumbsup:
...except... the rank appears to be stored separately as well in the SQL db, which might explain my confusion:
--
-- Table structure for table `servcharacter`
--
CREATE TABLE servcharacter (
ID int(11) NOT NULL default '0',
LOCKED datetime default NULL,
LOCKID int(11) default NULL,
WONLogon varchar(255) NOT NULL default '',
LastLoggedOn int(11) NOT NULL default '0',
MissionsPlayedVectorSize int(11) NOT NULL default '0',
MissionsPlayedVector blob NOT NULL,
IPAddress varchar(15) NOT NULL default '',
NextMissionTitle varchar(255) NOT NULL default '',
NextMissionScore int(11) NOT NULL default '0',
HomeWorldLocationX int(11) NOT NULL default '0',
HomeWorldLocationY int(11) NOT NULL default '0',
LastMustPlayLocationX int(11) NOT NULL default '0',
LastMustPlayLocationY int(11) NOT NULL default '0',
PreparedMissionsID int(11) NOT NULL default '0',
OpenShipBidsSize int(11) NOT NULL default '0',
OpenShipBids blob NOT NULL,
CharacterName varchar(255) NOT NULL default '',
ShipCacheVectorSize int(11) NOT NULL default '0',
ShipCacheVector blob NOT NULL,
CharacterRace int(11) NOT NULL default '0',
CharacterRank int(11) NOT NULL default '0',
CharacterPoliticalControl int(11) NOT NULL default '0',
Flags int(11) NOT NULL default '0',
CharacterLastBattleResult double NOT NULL default '0',
CharacterLocationX int(11) NOT NULL default '0',
CharacterLocationY int(11) NOT NULL default '0',
CharacterRating int(11) NOT NULL default '0',
Medals int(11) NOT NULL default '0',
CharacterCurrentPrestige int(11) NOT NULL default '0',
CharacterLifetimePrestige int(11) NOT NULL default '0',
CharacterBattlesPlayed int(11) NOT NULL default '0',
MissionSlotIdx int(11) NOT NULL default '0',
MoveCompletes int(11) NOT NULL default '0',
MoveDestinationX int(11) NOT NULL default '0',
MoveDestinationY int(11) NOT NULL default '0',
PRIMARY KEY (ID),
KEY CharNameIndex (CharacterName),
KEY WONLogonIndex (WONLogon)
) TYPE=MyISAM;
-
the problem hex was a nebula?
-
Coolness, that makes sense. Handy to know. :thumbsup:
...except... the rank appears to be stored separately as well in the SQL db, which might explain my confusion:
Indeed!! Bonk... you have made a very important discovery here. The API treats these as the same variable, but they are being stored seperately by SQL. Now, this in itself may not be a bad thing. Consider if we rewrote all the blobs, say the blob for ship damage and seperated out everything into a table with fields for each item. So long as we dont create two fields that are the same, or are supposed to have the same value in two tables that are not in themselves foreign keys or primary keys thereby introducing update anomalies into the database, then all is well. I have long suspected, however, that this is not the case, and that update anomalies are responsible for corruption in the database. Unfortunately, the only way to fix that, if that is the case, is to redesign the tables themselves, since its a design flaw.
-
the problem hex was a nebula?
It was 18,25, not sure what the terrain is...
edit: just checked the webmap, yes, it is a nebula.
edit#2: Just checked the mvm file, Nebula 3 to be exact.
The terrain may not be related to the bug however.
-
think its down again.might just be my connection but i got on earlier today.
-
the problem hex was a nebula?
It was 18,25, not sure what the terrain is...
edit: just checked the webmap, yes, it is a nebula.
edit#2: Just checked the mvm file, Nebula 3 to be exact.
The terrain may not be related to the bug however.
17,25 was where i tried to draft DH and at the very moment I tried to nab him, a coalition player got him instead. But my mission counted all the way down and then returned to the mission selection screen and wouldnt let me see the map, the buttons were shaded so I had to log off and back on to see the map. News didnt report and forefeits tho.
Probably was frey in that nebula tho... ISC ships like em.
-
think its down again.might just be my connection but i got on earlier today.
I asked Frey to reboot the box, it may be that, give it a few minutes and see if he posts to that effect.
-
:thumbsup: you rock
-
Coolness, that makes sense. Handy to know. :thumbsup:
...except... the rank appears to be stored separately as well in the SQL db, which might explain my confusion:
Indeed!! Bonk... you have made a very important discovery here. The API treats these as the same variable, but they are being stored seperately by SQL. Now, this in itself may not be a bad thing. Consider if we rewrote all the blobs, say the blob for ship damage and seperated out everything into a table with fields for each item. So long as we dont create two fields that are the same, or are supposed to have the same value in two tables that are not in themselves foreign keys or primary keys thereby introducing update anomalies into the database, then all is well. I have long suspected, however, that this is not the case, and that update anomalies are responsible for corruption in the database. Unfortunately, the only way to fix that, if that is the case, is to redesign the tables themselves, since its a design flaw.
Ah, but the MedalRank may actually be a separate variable fromthe CharacterRank, we'll need to look over the kit code to determine that. But something is rank for sure... ;)
-
Both HEIMDALL and THOR have been rebooted.
Directory services are coming up now after reboot..
-
TY.
-
TY
-
All services should be back up.
Just waiting on Bonk to logon and do the voodoo that he doo dooo
-
Aha, Ok, lemme check the server... did you shut down SGO5 before the reboot, or just treboot eh box?
-
OK the server is back up, but I cannot get the processsetinel to work any longer, thats really weird. It must be storing bad data in the registry somewhere... I'll keep diggin for it to see if I can get it working again, the next time the server goes down.
-
So much for working on the kills pages today... sigh... maybe tomorrow?
-
Let me look @ the process sentinal issue...
Yea, I see what you are saying.... it launches but won't auto-launch the server..
I have never seen that before.
-
Let me look @ the process sentinal issue...
It launched fine for me.....do you want me to relaunch the serverkit from the PS ?
What do you mean it launched fine for you, were we running two copies of the kit? Ack!
The server just went down when I was in mission, were you running another copy of the kit?
I'm gonna look at the db for corruption...
-
No, I meant the Process Sentinal launced fine.
No we were not running two instances of the kit.
I just tried to relaunch the Server within the Process Sentinal.
SOrry
-
When did you try the process senitnel? Just now? On what login? Might that explain why the server jsut went down?
(yes, the PS launces, but does not start the kit - its bugged somehiow)
Thor is now refusing remote connecitons from me... exceeded connections or something...
(don't feel bad we'll get this sorted eventually today...)
-
The db does not appear corrupt...
-
I'm backing off, hands in the air.....
:P
-
ROFL...
I just got intoa remote session it appears the kit is still running/hung?
Lemme try loggin in.
-
Kit is running OK now... just logged in for a mission.
I'll look into why the processSentiel is not working anymore, I imagine it has the kit recorded as runnng in the registry somewhere so does not launch it... something like that...
-
Down again...
-
Yep. STill down.. Just a note
Just before it went down I was at the web yard. Then of course a typical OP problem on XP machines happened and I couldn't shell back to the game without getting glitched graphics, requiring a ctl-alt-del on OP and restart. Sever down when I returned..
Of course its all related.
Khemaraa sends
-
I'm on it... gonna clean out the mission AI, as there was a few odd shutdowns today...
-
ok.. web map says 4 people on server yet I've hit refresh about 10 times and still can't see server on list
-
We aren't on it. It is remebmering who was when it dropped...
-
ok.. web map says 4 people on server yet I've hit refresh about 10 times and still can't see server on list
That's because it crashed/lost connection... the db will still show players on till it is restarted.
I think it crashed because of connectivity at the host network.
A moment ago Dynaverse.net was failed to be found but I could still see google. Also my remote session connection was broken, Then Thor would not reply to a remote session at all, now it will again...
The server is back up.
The process sentinel is still buggered (even after renaming the folder the kit is running from and creating a new processsentinel profile.)
-
We aren't on it. It is remebmering who was when it dropped...
+1 to Dax for figuring that out. :thumbsup:
-
With the process sentinel not working, mb I should get access afewr you guys are done with all the heavy petting so I can make sure it stays up at night? Either me or Chuut, he prolly wont want the job, but damn, the dudes up ALL night long...
-
With the process sentinel not working, mb I should get access afewr you guys are done with all the heavy petting so I can make sure it stays up at night? Either me or Chuut, he prolly wont want the job, but damn, the dudes up ALL night long...
I have already sent you the required information check your PMs... I'll send it again...
-
I gots it!
But dunna know what to do with it?
-
Many apologies, guys, we had some network issues with our backbone providers today.
Adaptive BGP seemed to brunt the majority of this by re-routing if possible, but there were some issues.
This should not happen again.
Regards,
-
LOL! Where's your sig? ahahahahahaha
-
Down again :puke:
-
Restarted.... this does not look good... :(
-
I gots it!
But dunna know what to do with it?
I'll send instructions.
-
Died again Bonk.
-
Its back up... No need for instructions, I figured it out. We need to get it to be able to autoboot again... Too bad thats broke atm...
-
Died again Bonk.
Dizzy shut it down and restrted it after I had started it, that was not another crash. We just have a little communications lag here...
-
...We need to get it to be able to autoboot again... Too bad thats broke atm...
Ya weirdest thing I ever saw... I have searched the registry up and down, I cannot fins where the processsentinel hides its data (if there at all) Frey rebooted the box, I renamed the folder the kit is in... I recreated its profile, I copied in a new sentinel exe... I'm just about out of ideas.
-
...We need to get it to be able to autoboot again... Too bad thats broke atm...
Ya weirdest thing I ever saw... I have searched the registry up and down, I cannot fins where the processsentinel hides its data (if there at all) Frey rebooted the box, I renamed the folder the kit is in... I recreated its profile, I copied in a new sentinel exe... I'm just about out of ideas.
Would you like me to take a look at it?
-
Hmmmm.. that would involve taking it down again...
it is not a simple mistake... at least I do not think so.
It just refuses to start the kit the way I always set it up.
It started this when the kit hung this morning on the maphex error.
I'll send you the info to take a look. But give everyone fair warning
when you are going to take the server down.
-
Hmmmm.. that would involve taking it down again...
it is not a simple mistake... at least I do not think so.
It just refuses to start the kit the way I always set it up.
It started this when the kit hung this morning on the maphex error.
I'll send you the info to take a look. But give everyone fair warning
when you are going to take the server down.
Will do, although I hadnt intended to take the server down, just to offer advice :-)
-
Oh, OK, let me know if you find anything that explains why the processsentinel.exe no longer works.
-
servers down 8(
-
Yep Down again...10:19 PST
-
dwn still...
-
server just dropped....
-
Back up, see this post: http://www.dynaverse.net/forum/index.php/topic,163360915.0.html