Bug Reports: SEDCS v3.2.0, MP4 v4.520, SEDB32

Post by **IV/JG7_4Shades** » Sat 28 Feb 2009 7:34 am

Hi everyone,

Please post bug reports here. As always, provide your software versions if you are seeking assistance.

Cheers,
4Shades

Grifo_rott · Post by **Grifo_rott** » Tue 03 Mar 2009 10:57 pm

Hey 4shades,

We tried the new version and it runs great until after the first mission. It seems to have an issue with partially destroyed supply columns. Apparently it tries to insert the record in the db and then tries to insert it again which generates an error (duplicate key - table Combined Unit Losses). Due to this error it won't finish processing the log.

We tried it on two different maps, two different campaigns, stops at the same point, pretty much.

We are running mysql 5.0.51 - PHP 5.2.6

I got the database dump, mission and game logs. If you would like I can send them to you so you can try to debug. Please let me know.

Thank you!

Post by **IV/JG7_4Shades** » Wed 04 Mar 2009 2:56 am

Eek! Please send me the stuff, or give me a link to download!

Cheers,
4S

Post by **IV/JG7_4Shades** » Thu 05 Mar 2009 7:35 am

Thanks Rott, I got your email. Please check yours for an analyzed DB that you can continue with (I have already made the change discussed below).

It seems that the problem is located in an errant Index definition in the Combined_Unit_Losses table. The Index definition in the release version was:

Index Name = "Stat1"
Field Names = "Mission", "Unit_Group"
Index Type = Unique

This is incorrect. The definition ought to be:

Index Name = "Stat1"
Field Names = "Mission", "Unit_Group", "Member"
Index Type = Unique

Once I changed this for your "Op_Husky" DB, the DCS analyzed the mission perfectly and the Statistics work fine.

Unfortunately this error applies to all sector DBs, but it can be corrected very easily by the following text search and replace in the SEDB32 release .sql files:

Search for:
UNIQUE KEY `Stat1` (`Mission`,`Unit_Group`)

Replace with:
UNIQUE KEY `Stat1` (`Mission`,`Unit_Group`, `Member`)

This error does not affect MSAccess forms of SEDB32.

Many thanks for the prompt report!

Cheers,
4Shades

Post by **IV/JG7_4Shades** » Thu 05 Mar 2009 10:07 am

The download file for SEDB32 has been incremented to SEDB32 Patch A, to take into account the fix for the table index error above.

This is a critical patch, so it is recommended that all SEOW admins use the latest DB version, or apply the patch manually (which may be done mid-campaign).

Cheers,
4Shades

Grifo_rott · Post by **Grifo_rott** » Thu 05 Mar 2009 10:02 pm

Thank you mate!

We will try it out tomorrow

Cheers!

Grifo_rott · Post by **Grifo_rott** » Sat 07 Mar 2009 3:11 am

Ooops, we seem to bump into another couple of small issues that stops us from running a third mission (it won't process the 2nd mission log)

The first is on MissionData. It keeps claiming there is a duplicate key and I realized it was because the default unique key length (I believe) is only the first 16 characters. Here is the mission name, it's 29 chars long:
SE-Op-Husky-194404100700.mis (first was 0600).

I raised it to unique(50) and it went past it but stopped at Combined_Unit_Losses. It kept saying it had a duplicate for the key. So I dropped the indexes, created an autonumber index field and let it run again. Here is the result:

Code: Select all

INSERT INTO `Combined_Unit_Losses` (`Map`, `Mission`, `Unit_Group`, `Object_Type`, `Member`, `Nation`, `index`) VALUES
('Italy', 'SE-Op-Husky-194404100600.mis', 'Reichsbahn00', 'Germany_CargoTrain/AA', '2', 'g', 1),
('Italy', 'SE-Op-Husky-194404100600.mis', 'Reichsbahn00', 'Germany_CargoTrain/AA', '3', 'g', 2),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '7', 'r', 3),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '6', 'r', 4),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '5', 'r', 5),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '4', 'r', 6),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '3', 'r', 7),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '1', 'r', 8),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '9', 'r', 9),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '0', 'r', 10),
('Italy', 'SE-Op-Husky-194404100600.mis', '1_Infantry000', 'USACarsColumnB', '2', 'r', 11),
('Italy', 'SE-Op-Husky-194404100700.mis', '16_SS_PzGren001', 'GermanyCarsColumnB', 'X', 'g', 13),
('Italy', 'SE-Op-Husky-194404100700.mis', '16_SS_PzGren001', 'GermanyCarsColumnB', 'X', 'g', 14),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '1', 'r', 15),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '0', 'r', 16),
('Italy', 'SE-Op-Husky-194404100700.mis', '16_SS_PzGren001', 'GermanyCarsColumnB', 'X', 'g', 17),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '3', 'r', 18),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '5', 'r', 19),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '4', 'r', 20),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '7', 'r', 21),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '6', 'r', 22),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '9', 'r', 23),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '8', 'r', 24),
('Italy', 'SE-Op-Husky-194404100700.mis', '1_Infantry001', 'USACarsColumnB', '2', 'r', 25),
('Italy', 'SE-Op-Husky-194404100700.mis', '16_SS_PzGren000', 'GermanyCarsColumnC', 'X', 'g', 26);

You will notice that the GermanyCarsColumnB for some reason has an X for the "Member" field, while the USA column (which I wiped out on 20mm alone

) shows correctly number from 0 to 9.

If we let it run further it goes completely bonkers saying it can't recognize squadron 16_SS_PzGren but I assume that error is probably caused by the modifications I made to force it to run.

If it will help I can get you SQL, log and mission again for you to run a debug. Let me know

Thank you!

Post by **IV/JG7_4Shades** » Sat 07 Mar 2009 8:13 pm

Don't worry about the "X" characters, they are mean to be there!

Also, I found the following MySQL 5.0.x bug report regarding key lengths:
http://bugs.mysql.com/bug.php?id=26909
Can you please tell me where you found the default length of 16? I can't find this setting. Also, what is your MysQL version?

Please send me the campaign data and I'll check it out.

Cheers,
4S

Post by **IV/JG7_4Shades** » Sun 08 Mar 2009 9:48 am

Hmm. I think this is basically the same problem as the first one. I suspect I need to change that MySQL Index from "Unique" to "Normal". Still checking this out though...

Cheers,
4Shades

Grifo_rott · Post by **Grifo_rott** » Sun 08 Mar 2009 12:51 pm

IV/JG7_4Shades wrote:Don't worry about the "X" characters, they are mean to be there!

But if they don't have a member number they should not be inserted more than once correct? DCS inserted it 3 times once I changed the key.

Can you please tell me where you found the default length of 16? I can't find this setting.

I tried to find the source but I cannot

I had to do an extensive research on full-text searches a couple of months ago and I am sure I read that somewhere during that research. I believe however that the default length is indeed shorter that the size of the entry (29 chars) which explains why, when I raised the size of the index to 50 it went through without an error.

Also, what is your MysQL version?

MySQL 5.0.51

I will get you the files asap. Thanks again mate!

Post by **IV/JG7_4Shades** » Tue 10 Mar 2009 3:51 am

Paddington has lodged a bug report. Basically in his Ardennes campaign the Admin user could load any map view in the MP, but no other user could. Fatal browser error 500.

He sent me his DB and when I loaded it on my system I got the same thing. It turns out that for his combination of Factory production and HistorySFX settings there was bad SQL being generated when the MP tried to work out the allowable factory production objects. Simple fix. Line 1119 of MP-SQL.php should read:

Code: Select all

	$FPM = ($FactoryProductionMode == 2) ? " AND Service_Date <= '".substr($strSequenceNumber,0,8)."' AND HistorySFX=0" : " AND HistorySFX=0";

A simple patch will be released shortly, containing this fix, a typo in the Augusta.php file and a minor Stats formatting fix.

Cheers,
4Shades

Post by **IV/JG7_4Shades** » Wed 11 Mar 2009 9:28 am

Bug detected in vehicle column destruction code - fix appearing shortly.

Cheers,
4Shades

Goanna · Post by **Goanna** » Sun 15 Mar 2009 8:51 am

Shades,
missing this line from default-green.php

Code: Select all

$SectorLinkData["GothicLine"] = SectorLink("GothicLine");

Cheers

Goanna

Ala13_Nachote · Post by **Ala13_Nachote** » Sat 28 Mar 2009 3:52 am

Spy units in a friend airbase dont appear in the list of Select Taskable Unit in Create New menu, then cant be selected for move by his own. If they are far of an airbase they can.

They can be selected to load if there are cargo planes in the airbase.

Ala13_Nachote · Post by **Ala13_Nachote** » Sun 29 Mar 2009 3:09 pm

Spy units in a friend airbase dont appear in the list of Select Taskable Unit in Create New menu, then cant be selected for move by his own. If they are far of an airbase they can.

They can be selected to load if there are cargo planes in the airbase.

sorry, not sure about this report, seems there was a problem uploading the log.

Official SEOW

An Open Source community for historical flight simulation.

Bug Reports: SEDCS v3.2.0, MP4 v4.520, SEDB32

Bug Reports: SEDCS v3.2.0, MP4 v4.520, SEDB32