Theater conversion from 4.33 to 4.34
-
We standby Falcas.
All stated advice already proved useful.
Very different db is most likely my main issue. Functionality of MC is not.
I understand and see many useful changes since last iteration.
And look forward to new changes as well.
When I hit problems, it is usually on my end. -
We standby Falcas.
All stated advice already proved useful.
Very different db is most likely my main issue. Functionality of MC is not.
I understand and see many useful changes since last iteration.
And look forward to new changes as well.
When I hit problems, it is usually on my end.Coffee break is over… back to work
-
Guys,
Little help, please.
To add a new squadron in database, I’ve addcopied the vehicle, then the squadron and finally the unit. Database ok.
Now I can’t remember which .txt files I have to edit, besides validac.act and teplanes.lst for the new plane to be selectable in TE Editor. I’m sure there’s at least one or two more, but can’t remember which.
Can anyone shed some light here, please?
Cheers!
EDIT: Got it, “units.irc” and “textids.id” inside Art\Main folder
-
For the validAc and tePlanes.
Start MC and load a mission, te_new.tac for example.
Go to the Planes tab and the rest you will see how it works.Gr Falcas
-
Thanks, Falcas!
First squadron created in DB and available in dropdown list:
Only 3 zillion more to go!:D
-
As well as doing your station+ils… use MC
Gr Falcas
-
-
@Nuno:
Thanks, Falcas!
First squadron created in DB and available in dropdown list:
https://i.imgur.com/Mm08m1F.pngOnly 3 zillion more to go!:D
Great work mate.
Keep it up!About Stations+ILS and RadioMap, am already working on it…
Will be ready soon… -
Guys, another question.
In 4.33 I had exported all our custom objectives using BMS Editor, which made extremely easy to recover feature and PHD data, for instance, when updating the DB.
Since right now, in 4.34, the CT#s have changed, is there a practical way of recovering the previously exported objective´s data or one has to redo them by hand? (so far it’s what I’m doing, but it’s a tedious workload…)
So far, the only thing I’ve been able to recover is the PHD data from airbases (which could be improved also due to new taxiway branch capability), while trying to recover the feature data gives an obvious CTD in BMS Editor.
So, only way is populating the objectives from scratch?
Thanks!
-
Can someone shed some light to the ‘naming scheme’ for the new db update (upgrade) scheme with single xml file(s) – Terrdata/Objectives/RCD , /SSD , /UCD etc… dirs.
Like it is done in ‘Add-On Korea TvT’ , where theater/campaign use default (fallback) database but units/objectives are updated via xml’s , eg… ‘/Objects/WLD/115_F-18CD 37.xml’ or
‘/Objects/UCD/6_Battalion_Patriot MIM-104.xml’ …WOW, WHICH I THINK is pretty Cool feature , in the future no more countless GB’s of databases with copyofcopyofcopy of the same database over and over.
So is there a ‘respect’ to the names of xmls or it just looks inside the header idx ?
THANKS
@Nuno , maybe you can do this approach , check the TvT objectives folder , yes they are overrides… but unfortunately only to the DEFAULT (Korea/Terrdata) database.
-
The single XML files are to overwrite the database. As you can see with TVT, this is used to keep the same DB as KTO, but have small differences where needed.
If your theater has its own database, this is probably not something you are going to use much as you can do the changes as you like.
It can be very useful in many cases though.Gr Falcas
-
The single XML files are to overwrite the database. As you can see with TVT, this is used to keep the same DB as KTO, but have small differences where needed.
If your theater has its own database, this is probably not something you are going to use much as you can do the changes as you like.
It can be very useful in many cases though.Gr Falcas
ON CONTRAIRE … it is VERY VERY VERY useful for my theater , … since I’ve already converted my old DB to 4.34 format so I can read it with ‘4.34 Editor’ then export my units/whatever… and re-import to new eg.Balkans default db , as single xml overrides. There are not too ‘MANY’ changes… I think
Only problem is they are overrides to a default KTO db , not the ADD-ON DB , so I need to think… I would need to do 2 sets of overrides . 1.set between new Balkans DB and KTO DB , then … 2nd set between MY DB and KTO DB.
Only then, as I figured, that would work as intended…But… somehow I think it is more complicated lol , then , as You’ve said , making OWN db.
IF you could DEFINE another ADD-ON DB as default, eg in .TDF file , add another ‘switch’ >defaultObjectsDatabase …/add-on/terrdata/SomeObjectsDir<… then overrides would be EVEN great stuff… but let’s leave that for another update , just as an option to think on.
----But , what was question,… Are the XML naming scheme important/crucial , or can it be ‘whatever/random’ … well, i can test myself tho, but if someone knows?
Cheers
-
Yeah … as Cars said, it is also a matter of CT/Index links among the different DB parts/files that could be easily scrubbed by using unsuitable “editing” methods. And once those are messed up … good luck to restore the correct links. This is truly critical.
I take my hat off to you, guys!!!
BMS Editor is proving to be more and more reliable. Much more than in 4.33, now with the testing features and such.
Right now, it’s much safer than before to prevent/recover from any mistakes done on the DB.
Great work you’ve done here, thanks!!!
Cheers
-
Yes the naming is very important. Have the name wrong and it doesn’t work.
Reading your post here it clear you don’t fully understand how it works.
No, the single XMLs are not overriding the default KTO, but any database where they are located in.
In case you do not have a database at all, it will revert to KTO. But in case of KTO TVT, the default is KTO
It does not add anything new, only overrides values included in the DB.So you can use the single XML for your DB using the correct location and the correct naming.
Look at TVT how to do this.But as said before… its just easier to edit the DB directly.
K.I.S.S… Keep It Simple Stupidgr Falcas
ON CONTRAIRE … it is VERY VERY VERY useful for my theater , … since I’ve already converted my old DB to 4.34 format so I can read it with ‘4.34 Editor’ then export my units/whatever… and re-import to new eg.Balkans default db , as single xml overrides. There are not too ‘MANY’ changes… I think
Only problem is they are overrides to a default KTO db , not the ADD-ON DB , so I need to think… I would need to do 2 sets of overrides . 1.set between new Balkans DB and KTO DB , then … 2nd set between MY DB and KTO DB.
Only then, as I figured, that would work as intended…But… somehow I think it is more complicated lol , then , as You’ve said , making OWN db.
IF you could DEFINE another ADD-ON DB as default, eg in .TDF file , add another ‘switch’ >defaultObjectsDatabase …/add-on/terrdata/SomeObjectsDir<… then overrides would be EVEN great stuff… but let’s leave that for another update , just as an option to think on.
----But , what was question,… Are the XML naming scheme important/crucial , or can it be ‘whatever/random’ … well, i can test myself tho, but if someone knows?
Cheers
-
Yes the naming is very important. Have the name wrong and it doesn’t work.
Reading your post here it clear you don’t fully understand how it works.
No, the single XMLs are not overriding the default KTO, but any database where they are located in.
In case you do not have a database at all, it will revert to KTO. But in case of KTO TVT, the default is KTO
It does not add anything new, only overrides values included in the DB.So you can use the single XML for your DB using the correct location and the correct naming.
Look at TVT how to do this.But as said before… its just easier to edit the DB directly.
K.I.S.S… Keep It Simple Stupidgr Falcas
Well, can’t blame me tho … None of this wasn’t documented , and You are the first who spill the beans… , anyway I have good info now, rest is just try&fail.
Totally agree with K.I.S.S … :hug:
-
Some FM and AFM info before this large vid of moving f-35b to 4.34
For 2 (or more) engine jets, the Thrust Multiplier should be set from 2 to 1.
Looks like this rule goes to F35b as well, if I did not lower this, jet flew from rwy to space in 9 sec (exaggerated maybe)
And here is the fm and afm I used in this next video. they work pretty good , but may need refined
https://www.mediafire.com/file/d9tvx5iep85ocav/f35bfms.rar/fileYou should watch vid #2 first and then come back to one, this way you won’t have afm ctd problem I did.
vid1
vid2
-
When adding fm to actypes list, we are supposed to add to bottom of list right?
else some fm gets confused?
I know i added to the top before and things got messed up. -
For 2 (or more) engine jets, the Thrust Multiplier should be set from 2 to 1.
yes in 4.34 thrust mulitiplier all set to 1. all data for one single engine.
you can fine-tune that engine table thru multiplier vlaue.
the quantity of engine is set in nEngine flag.When adding fm to actypes list, we are supposed to add to bottom of list right?
else some fm gets confused?yes add to the bottom of list, then first number+1.
-
Hi Gents!
I’m now at the stage of adding new units to the 2DDB.
What I found is happening (at least to me) is the following, when creating new aircraft / helo entries:
#1- I addcopy a VEHICLE from the DB, similar to the one I’m creating (ok so far);
#2- I addcopy a corresponding SQUADRON to link to the newly added aircraft (ok so far);
#3- I addcopy a corresponding UNIT to link it to the newly added aircraft.At this point, it’s where the issue arises. In the DB, everything is ok, even when testing the DB.
The problem is, if I try to open Mission Commander, it gives an error in the FALCON4_UCD.XML file, which prevents me from correctly editing the saveX.cam or te_new.tac files.Again, in the DB through BMS Editor everything looks ok, still.
Now, I’ve tested and tested and the only solution found was this:
- After point #2 and before point #3, I have to exit BMS Editor;
- Reenter BMS Editor and do point #3;
- Exit BMS Editor again and reenter to complete the rest of the procedure (assign specific numbering, etc…).
Is this a know issue for the DEVS or is this happening on my side only?
Thanks, cheers!
-
Please can someone tell me, does have any limit with totaly noumber of Point Header points in 4.34 database?