How to's on converting your 4.32Theaters to 4.33

[demer928]

Hi peep’s,

I am starting this thread as a place to SHARE knowledge of 3rd party theater conversion from 4.32 to 4.33.
Let’s please try to keep it informational and civil. If the Dev’s\Moderators find it useful please Sticky it so they have somewhere to find this info.

So to start, there is a new file in the 4.33 Objects DB that affects and will cause CTD’s in your theater if not included in your DB.
That is the new .pdx file……WOT the hell is that…LOL!!!..just a catalog file that I am guessing is being used by the code to keep track of the PHD\PT data. Dev’s correct me if I’m wrong, please.

But for those that have built custom AB’s in 4.32 you will find that, at best, your AB’s don’t work anymore, at worse the whole thing CTD’s.
Here is how we fixed it in Guam.

When I imported Guam 4.32 to BMS 4.33 (I did include the new .pdx in the DB) I noticed that the Spawn points on Saipan ABase had moved???
So I went and looked at the PHD\PT data…this is what I found:

Hmm….this is waaaay off from the Data??? See 4.32 Saipan

So fixed

All we need to do is Export the 4.32 Pts in Editor and Import them to 4.33……see???

Regards,
demer

[Guest]

@demer928:

So to start, there is a new file in the 4.33 Objects DB that affects and will cause CTD’s in your theater if not included in your DB.
That is the new .pdx file……WOT the hell is that…LOL!!!..just a catalog file that I am guessing is being used by the code to keep track of the PHD\PT data. Dev’s correct me if I’m wrong, please.k anymore, at worse the whole thing CTD’s.

It’s pd data with elevation support,

[BlackWolf]

This is very useful,
thanks Demer

[Arty]

@Switch:

It’s pd data with elevation support,

Ok elevation support??? feel free to enlighten us please…
Meaning what?
How?

[Sherlock]

This is the type of discussion I meant to happen when I started the other thread about the impact of 4.33 on Add-on Theaters. Nice work Demer… Thank you!

[Guest]

@Arty:

Ok elevation support??? feel free to enlighten us please…
Meaning what?
How?

That means you can define the elevation of a PD point. It can be useful for helipad (CT# 468 / Parent# 193) in army base or lets imagine on a skyscraper with a Helipad on top. PD are ground level. In 4.32, helicopter would be “embedded” in the helipad, sitting on the ground and rotor proximately at platform level. Not really looking good graphically speaking, don’t you think? I can think as well of SAM launchers on structures, probably other things too.

However, I did not touch anything in the database related to that during 4.33 development, so I’m not sure about the how.

You can thank Biker for that one.

[Guest]

Actually, I’m not really sure it is already implemented or still in development. I will point Biker to this topic. He will certainly enlighten you more than me.

[Arty]

well the thing is with which tool and where you declare that elevation… It would be nice to have some weapons on the roof of some buildings… Nice. thanx

[uri_ba]

Just a point to think about.
You are all talking about “importing 4.32 theaters”. This is bad wording causing a lot of false assumptions.

4.32 & 4.33 are both falconBMS, but 4.33 does not have more in common with 4.32 as 4.32 had with OF or FF. And no one has ever thought of " importing" a theater.

We all used the term “rebuilding the theater”. And this term is still Valid. Theater should be rebuilt to work with 4.33.

Luckily for us, because of the fact that both were developed by the same folks, and in direct evolution we have tools to help us.

One of which is the Editor.

The ONLY correct thing is to use a clean 4.33 DB and import objects into it from the 4.32 editor.

However, the object then needs to be checked, as CT values might have changed, and you will find yourself with a missile rather then a building.

However, always make adjustments on the 4.33 base and not blindly copy values, as some things have changed under the hood sometimes considerably. So copying over ANY of the files from the SIM folder is a big no-no.

For considerable time during development of the Israeli theater we have used the Stock DB without editing it. A theater like this would be fully functional, even some of the objects are wrong, or that you don’t have the proper skins. But slowly replace, change or modify what you need.

However, the MOST important thing, use the tdf file to it’s full extent. In 4.33 a theater is self contained. Create a folder “Add-on Guam” for example and put all that is needed to be changed inside. If you plan to modify Sim folder copy it entirely. And point everything to the correct path.

I would recommend you have a look at the Israeli theater structure, as it is just that. You can utterly destroy stock BMS data, and ITO will stay as we intended to to be.

So even if you plan a Korea theater mod. Separate it. So stock KTO will always remain untouched as reference.

[demer928]

@Switch:

Actually, I’m not really sure it is already implemented or still in development. I will point Biker to this topic. He will certainly enlighten you more than me.

Think it is still in Dev. mode, but it does pork your custom PTs……eh’ Steph (Biker)…LOL!!!
Starting to remind me of RV daze…joke M8
You can see the concept in the new editor i.e. max height…etc.

demer

[biker]

Hi Dave,

@demer928:

Hi peep’s,

I am starting this thread as a place to SHARE knowledge of 3rd party theater conversion from 4.32 to 4.33.
Let’s please try to keep it informational and civil. If the Dev’s\Moderators find it useful please Sticky it so they have somewhere to find this info.

So to start, there is a new file in the 4.33 Objects DB that affects and will cause CTD’s in your theater if not included in your DB.
That is the new .pdx file……WOT the hell is that…LOL!!!..just a catalog file that I am guessing is being used by the code to keep track of the PHD\PT data. Dev’s correct me if I’m wrong, please.

But for those that have built custom AB’s in 4.32 you will find that, at best, your AB’s don’t work anymore, at worse the whole thing CTD’s.
Here is how we fixed it in Guam.

When I imported Guam 4.32 to BMS 4.33 (I did include the new .pdx in the DB) I noticed that the Spawn points on Saipan ABase had moved???
So I went and looked at the PHD\PT data…this is what I found:

Hmm….this is waaaay off from the Data??? See 4.32 Saipan

So fixed

All we need to do is Export the 4.32 Pts in Editor and Import them to 4.33……see???

Regards,
demer

pretty much all wrong.

The new *.PDX file holds the new extended PD data, just like Switch told you…

Extended PD data means:

• Z -> Lifting the point above terrain level (e.g. on a pedestal) -> Spawning ACs, Helis or vehicles at that Z level is not yet implemented
• Max Height -> Code does check if AC can fit into this parking point (e.g. if a HAS has limited height)
• Max Width -> Code does check if AC can fit into this parking point (wing-span)
• Max Length -> Gues what
• Root Idx -> We now do support taxiway branches (ATM only from branch into the main taxi trunk)
• Branch Idx -> Not yet supported

Little vid for the explanation of the taxiway branches:
Taxiway Branches – 02:16
— MrToastToastToast

The taxiway branches are pretty easy to add if you have the main taxiway (trunk) done already…

• Add a new TP and the end oft the PT list (you need to select the white space below last PT)
• Change PT type to TaxiPt
• You can see the PT still is linked to the previous PT in the list (white line)
• Now adjust the Root Idx to the PT, where the branch should join the main trunk (PT 70 in my screenshot)
• The next Taxi- and Parking Points can be done old style, they’re linked to the previous PT automatically

ATM this does work for AI only moving from the branches into the main trunk (takeoff procedure) for going back to the Parking Point after landing it’s not yet implemented, but I doubt, we really need this because AC usually aggregate fast after landing and reaching PT, so there shouldn’t be big shortage in free PTs.

Finally there is no need to copy this file into your theater (if you do so, all your modifications on PD will be lost).
If it does not exist, it will be generated if you use BMS Editor (start it, select your theater, restart, open any objective and then save to database).

In the MonoLogs you also can see if the standard or extended data is used…

Hope this helps.

BTW because of the missing *.PDX it never should crash, we then use old *.PD file with default values for the new variables!!!

Cheers
Biker

[demer928]

@biker:

Hi Dave,

pretty much all wrong.

The new *.PDX file holds the new extended PD data, just like Switch told you…

Extended PD data means:

• Z -> Lifting the point above terrain level (e.g. on a pedestal) -> Spawning ACs, Helis or vehicles at that Z level is not yet implemented
• Max Height -> Code does check if AC can fit into this parking point (e.g. if a HAS has limited height)
• Max Width -> Code does check if AC can fit into this parking point (wing-span)
• Max Length -> Gues what
• Root Idx -> We now do support taxiway branches (ATM only from branch into the main taxi trunk)
• Branch Idx -> Not yet supported

Little vid for the explanation of the taxiway branches:
Taxiway Branches – 02:16
— MrToastToastToast

Finally there is no need to copy this file into your theater (if you do so, all your modifications on PD will be lost).
If it does not exist, it will be generated if you use BMS Editor (start it, select your theater, restart, open any objective and then save to database).

In the MonoLogs you also can see if the standard or extended data is used…

Hope this helps.

BTW because of the missing *.PDX it never should crash, we then use old *.PD file with default values for the new variables!!!

Cheers
Biker

Hi Stephen,

I’d rather be “pretty much all wrong” than “almost” right……LOL!!!

Great dissimilation of needed info though.

On a moot point I did not open 433 Editor initially and did not know (how would we?) that the file would be auto-generated……my bad??? LOL!!!

Thanks again M8,
demer
P.S. 178 Crash Logs inbound buddy……LOL!!!

[demer928]

We have had a good discussion about the PD data and a very good example of what is new and what we can do now or somewhat… , thanks to Biker.
Going forward, I would like to example the changes in GUAM that made it fly with the old 432 data:

This is my stock 433 install DB

This is the Guam 433 DB

We can see by the Dates that I used some new, but kept some old.

I do NOT disagree that 3rd party devs should start with what is given them by the devs to maintain some stability.
Then again I see no reason to throw away what we have already done just because the latest and greatest hit the floor.

Cheers,
demer

[biker]

Pic of how it will look like after you’ve finished the taxiway branch (couldn’t find that pic yesterday):

And some more new stuff about PTs.

[demer928]

WARNING: RESTART BMS AFTER ANY THEATER CHANGE NOW!

Should have been doing it in the first place, but seems more critical now……Dunno why???
demer

[lazystone]

@demer928:

WARNING: RESTART BMS AFTER ANY THEATER CHANGE NOW!

Should have been doing it in the first place, but seems more critical now……Dunno why???
demer

Are you talking about any theater DB changes or about switching theaters?
… KTO -> Guam -> …

I wonder if we can get rid of the restart after switching, ever?

@biker
I also wonder why some .doc regarding the autogen wasn’t included in 4.33.

The only howto available is a tutorial which was posted in puplic,
short after old 4.32 release, but was IIRC removed soon again.
(because of disabled autogen in 4.32 ???)
http://www.mediafire.com/download/tldaaecwcqs8p47/INTERGRATING+EXISTING+THEATERS+INTO+BMS.docx

… just sayin’

Cheers,
LS

[biker]

@demer928:

WARNING: RESTART BMS AFTER ANY THEATER CHANGE NOW!

Should have been doing it in the first place, but seems more critical now……Dunno why???
demer

Why?
What are the effects if you don’t restart?

Cheers
Biker

[A.S]

It was a common procedure with 4.32 already… I forgot the effects, lol. Something went wrong if not done so. Maybe someone else remembers.

[Polak]

I also wonder why some .doc regarding the autogen wasn’t included in 4.33.

The new rules of how to place tree and grass autogen are briefly as follows:

• tree autogen texture located in folder “mistex” or “hiresmistex” contains 4x4 trees, where rows 1 and 2 are for decidious trees, rows 3 and 4 are for evergreen trees
• tree autogen code is now generating different types of tree /grass coverage depending on terrain type (either by designating circle/semicircle areas on each tile, or designating the entire set of tiles) :
  THICKFOREST: decidious trees (rows 1-2 of tree texture)
  THINFOREST: evergreen trees (rows 3-4 of tree texture)
  BRUSH: a mix of decidious and evergreens (all rows of the texture)

PLAINS: will override all of the coverages with no autogen (you can make a holes in autogen for entire tile coverage, if you choose to designate the whole set). Disclaimer: I do not know how this would affect the movement of the units on tile, or performance of the computation of speed of the movement.

-Grass
SWAMP: grass (texture grass)

I may add only that tree and grass textures should be made in consideration of terrain tiles so they are not contrasting unnaturally from the background. Each season has its own set of textures - summer, -spring, -fall, -winter, or else shader is being uses on one generic set and overall results may be not as good.

Hope this explains this process……

[A.S]

Polak, 4.32 understood only PLAIN and WATER Tile-Sets. I see now (in 4.33) THICKFOREST, THINFOREST, SWAMP and BRUSH has been added (for obvious reasons - trees and gras), but is that then ALL, or does BMS now also understand the rest of the Tile-Sets in terms of impact to the movement (speed and getting stuck of GUs after new THR building) of Ground-Units? You know?