Topic: Server just went down... Okay, it's back up, thx! (Read 5904 times)

Dizzy · « **Reply #1 on:** October 03, 2005, 03:01:52 am »

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.

Capt Jeff · « **Reply #2 on:** October 03, 2005, 06:11:57 am »

Of course ! One of those rare days nowadays that I can play for hours and hours and hours, and it's not there.

Conspiracy !!

FPF-SCM_TraceyG_XC · « **Reply #3 on:** October 03, 2005, 06:22:29 am »

Join the club

Wraith 413 · « **Reply #4 on:** October 03, 2005, 07:08:17 am »

Quote from: FPF-TraceyG on October 03, 2005, 06:22:29 am

Join the club

Looks like I joined also. Do we get a membership card?? LOL

Wraith 413

Bonk · « **Reply #5 on:** October 03, 2005, 07:13:32 am »

I'm working on it... <bonk sh*ts brick>

Dizzy · « **Reply #6 on:** October 03, 2005, 07:22:50 am »

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.

Bonk · « **Reply #7 on:** October 03, 2005, 07:54:04 am »

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.

Dizzy · « **Reply #8 on:** October 03, 2005, 08:15:39 am »

Quote from: Bonk on October 03, 2005, 07:54:04 am

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?

Bonk · « **Reply #9 on:** October 03, 2005, 08:16:41 am »

Quote from: Bonk on October 03, 2005, 07:54:04 am

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

Bonk · « **Reply #10 on:** October 03, 2005, 08:18:42 am »

Quote from: Dizzy on October 03, 2005, 08:15:39 am

Quote from: Bonk on October 03, 2005, 07:54:04 am
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.

FPF-SCM_TraceyG_XC · « **Reply #11 on:** October 03, 2005, 08:26:34 am »

Quote from: Bonk on October 03, 2005, 07:54:04 am

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.

Bonk · « **Reply #12 on:** October 03, 2005, 08:37:37 am »

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.

Quote

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

FPF-SCM_TraceyG_XC · « **Reply #13 on:** October 03, 2005, 08:51:15 am »

Quote from: Dizzy on October 03, 2005, 08:15:39 am

Quote from: Bonk on October 03, 2005, 07:54:04 am
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.

FPF-SCM_TraceyG_XC · « **Reply #14 on:** October 03, 2005, 09:00:43 am »

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.

Bonk · « **Reply #15 on:** October 03, 2005, 09:22:20 am »

Coolness, that makes sense. Handy to know.

...except... the rank appears to be stored separately as well in the SQL db, which might explain my confusion:

Quote

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

Dizzy · « **Reply #16 on:** October 03, 2005, 09:44:40 am »

the problem hex was a nebula?

FPF-SCM_TraceyG_XC · « **Reply #17 on:** October 03, 2005, 10:16:53 am »

Quote from: Bonk on October 03, 2005, 09:22:20 am

Coolness, that makes sense. Handy to know.

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

Bonk · « **Reply #18 on:** October 03, 2005, 10:26:15 am »

Quote from: Dizzy on October 03, 2005, 09:44:40 am

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.

KBF-Kurok · « **Reply #19 on:** October 03, 2005, 10:32:18 am »

think its down again.might just be my connection but i got on earlier today.

News:

Topic: Server just went down... Okay, it's back up, thx! (Read 5904 times) var addthis_config = {"data_track_clickback":true};

Topic: Server just went down... Okay, it's back up, thx! (Read 5904 times)