Page 1 of 1

Retrofitting SEDB32E to SEDB32F compliance

Posted: Tue 28 Sep 2010 7:13 am
by IV/JG7_4Shades
Hi everyone,

Yes, it is possible to take an existing SEDB32E campaign and convert it to SEDB32F structural compliance without re-initializing. To learn how, read on.

Why is the new version not compatible with the old?
Databases consist of (1) structure, and (2) content. Compared to SEDB32E, SEDB32F introduces both new structure (new tables, new fields) and new content (revised object data, revised roads etc). If the structure changes, then the MP and DCS need to be updated to understand the new structure. Conversely, if you want to use the new MP and DCS features in an existing campaign, you must ensure that your database has the structure expected by the new software versions.

What is the bare minimum required to retrofit SEDB32E?
In the following I assume that you want to use a sector map that already exists in the old SEOW version, and you have a campaign in your SEDB32E database already. You MUST make these changes for the new DCS and MP to function with your database. In the following text, database tables are in orange bold face, table fields are in plain orange, and SQL queries are in yellow.

0. Before starting, make a backup copy of your SEDB32E database!!!!


1. The following new tables must be created:
Campaign_Notices :: for storing notice events generated by DCS
Destruction_Targets :: for programming target/furniture objects used by DCS

Copy these tables from a SEDB32F database. Populate Destruction_Targets with SEDB32F data. Campaign_Notices can be left empty as the DCS manages its contents dynamically.

2. The following five tables need structure updates (additional fields):

*) Structure Update for Table Campaign_Settings :: stores all feature settings
The following new fields are required
Create_Supply_Points (type int or number)
Enemy_Proximity (type int or number)
Landing_Penalties (type int or number)
Lock_Production_Allied (type int or number)
Lock_Production_Axis (type int or number)
Lock_Dissolve (type int or number)
Forward_Supply (type int or number)
Once added, these fields MUST be populated with 0 (false) or 1 (true). The exception is Enemy_Proximity which is the minimum distance (in metres) to enemy units to enable supply point creation (default 500 m). Example SQL is
UPDATE Campaign_Settings SET Create_Supply_Points=0,Enemy_Proximity=500,Landing_Penalties=0,Lock_Production_Allied=0,Lock_Production_Axis=0,Lock_Dissolve=0,Forward_Supply=0;

*) Structure Update for Table ObjMissionData :: stores order of battle records
A single new field is required
Penalty (type int or number)
Once added, this field MUST be populated. Example SQL is
UPDATE ObjMissionData SET Penalty=0;

*) Structure Update for Table PilotMissionDisposition :: stores all pilot status records
A single new field is required
EventTime (type varchar or text, length 255)
No population required

*) Structure Update for Table Resupply_Points :: lists all resupply and withdraw points
The following new fields are required
Max_Fuel (type int or number)
No_Loadout (type int or number)
Allowed_Types (type varchar or text, length 255)
Once added, these fields MUST be populated. Example SQL is
UPDATE Resupply_Points SET Max_Fuel=100, No_Loadout=0, Allowed_Types='all';

*) Structure Update for Table Resupply_Replacements :: lists all reinforcements available
The following new field is required
Transit (type int or number)
Once added, this field MUST be populated. Example SQL is
UPDATE Resupply_Replacements SET Transit=0;


What else can I do to retrofit SEDB32E?
3. Content revisions (optional)
Some other tables have revised data content. You may decide to use data from these tables in your retrofit database. This takes the retrofit from Fiat Bambino to Maserati, but any content changes may alter your campaign balance so be careful.

*) The Highways, Highway_Intersections, Railway_Waypoints and Railway_Intersections tables have significant data revisions for many sectors. These tables can be swapped into SEDB32E and will work with old SEOW software versions. Railway_Stations has been updated for Lvov and Stalingrad.
*) The Object_Roles, Object_Costs and Object_Specifications tables include new object types and roles, including the drivable WAGEN and JEEP types, plus a completely revised set of transport weights and capacities for units based on actual kilogram weights.
*) AircraftLoadout contains revised loadout directives
*) Industrial_Installations has been revised, chiefly for Marianas and Singapore, plus the new sectors.



That's it! Post any questions on retrofitting to this thread please.

Cheers,
4Shades

Posted: Thu 30 Sep 2010 10:48 am
by 22GCT_Gross
It's seem I could switch the Bagration "e" databases to the "f" release.
Let you know about next buildings and analysis.
Thanks

Posted: Fri 01 Oct 2010 4:06 am
by PA-Dore
Salut Diego ;-)

I will try to update my own Bagration Campaign to F database, with help of Mike's topic.
I will report here the result.

Posted: Fri 01 Oct 2010 7:12 am
by PA-Dore
My Smolensk campaign is updated to SEDB32F, all seems correct.

Mike: I'm not sure I used the right method. To avoid create new tables, I did that:
- Created a new database: import SEDB32F_Smolensk_extinserts.sql ==> 83 tables with correct new tables and fields.
- Then empty all tables
- sql request and checked every item of your topic
- Imported my Smolensk old database.
I have now 96 tables. is it correct? Perhaps unuseful tables?

DCS 3.2.15 works well. (no error message)

Posted: Fri 01 Oct 2010 7:13 pm
by IV/JG7_4Shades
Hi Dore,

That is another method. The main thing in SEDB32F is that in the sector-specific databases some obsolete tables are removed to make the databases smaller and easier to handle. n your method, you would retain the obsolete tables from your old database.

Cheers,
4S

Posted: Mon 04 Oct 2010 10:20 am
by =gRiJ=Petr
Hi Shades,

Great update!
Question: When creating a HQ re-supply point, one of the conditions is the strength of the HQ being at least 80%. I can see the logic but Bagration rules did not take that into account and our willy foe is doing everything he can to beat up our HQ's and columns ;)

Here's the question, can this requirement be lowered? Or is it hard coded?

Thanks!
Cheers,
Petr

Posted: Mon 04 Oct 2010 10:33 am
by =gRiJ=Petr
Hey again,

When new units are entered through a forward re-supply point created through an HQ, they enter with 0 fuel by default. Again, I understand the logic, but how can this be changed, if at all?

If not changable, will having a supply source close by allow the unit to draw supplies during deployment, or must it wait till the end of the mission?

Thanks!

Cheers,
Glenn

Posted: Mon 04 Oct 2010 8:10 pm
by IV/JG7_4Shades
Hi Petr,
Question: When creating a HQ re-supply point, one of the conditions is the strength of the HQ being at least 80%. I can see the logic but Bagration rules did not take that into account and our willy foe is doing everything he can to beat up our HQ's and columns

Here's the question, can this requirement be lowered? Or is it hard coded?
It is hard coded in MP, but is easy to change. Find lines 5714-5719 of MP-Head.js and change "80%" to what you prefer, and "CO.Damage >= 0.8 && CO.Supply >= 0.5*CO.FuelCapacity" to what you prefer.
When new units are entered through a forward re-supply point created through an HQ, they enter with 0 fuel by default.

It's a bug - fixed in MP4public v4.715.

Cheers,
4Shades

Posted: Tue 05 Oct 2010 5:00 am
by =gRiJ=Petr
Hi Shades,

2x excellent and thanks!

Cheers,
Petr