Idea for theater integration: DB compare tool
-
Isn’t there like a 3DDB builder tool coming along with the BMS updates? I think I remember seeing such a file when applying some of the 4.32 updates. It might have been just a temporary file, deleted after usage to update the 3D db as I can’t find it back now.
Even if I manage to find this file back I’m not sure if posting this here in public will go along with the BMS License Agreement. Maybe one of the devs could advise at what’s possible here?
-
only viable scenario to a tool such as this is DB syncing.
you have U1 DB then U2 comes out. a tool such as this will show you the Delta. Which is useful for theater creators, to quicken up updates as you can adjust the things that had chaned.However it will never work between Major updates as lots of thigs move around (CTs,WCDs etc.). heck some minor updates might not work 100%
So this Request made by Echo a long, long time ago is awesome for theater creators, but it id defiantly not the holy grail.
-
Holy grail or not in a few days u have a compatible theater.
Sent from TapaTalk
-
Holy grail or not in a few days u have a compatible theater.
Sent from TapaTalk
it’s not because a DB compare tool…
-
Two things:
-
The units / vehicles of ITO theater are already included in the stock Korean DB. This alone makes migration easier than other theaters.
-
IMHO, the best approach would be -in future major updates- to split the sole koreanobj.lod file into two files. One that includes features and objectives and another that includes vehicles, units and weapons. This way we could save lots of time, since theater specific features and objectives could be migrated by a simple copy & paste of the first koreanobj.lod.
-
-
Two things:
-
The units / vehicles of ITO theater are already included in the stock Korean DB. This alone makes migration easier than other theaters.
-
IMHO, the best approach would be -in future major updates- to split the sole koreanobj.lod file into two files. One that includes features and objectives and another that includes vehicles, units and weapons. This way we could save lots of time, since theater specific features and objectives could be migrated by a simple copy & paste of the first koreanobj.lod.
That could work.
-
-
Actually not. Same work just 2 different files - databases to maintain.
The thing might be either:
1. THE TOOL
2. use the directories approach. If the theater has it’s own units and features and bla bla load them from their specific files.
So double files. Vanila BMS files. and theater files.
One more field for which is which to know as a flag.
So BMS updates their vanila database… theater dev’s don’t care the theater will work just fine. their data are on their own database set. so every theater will be depended to BMS updates only if database structure is changed. -
“fall back DB” i.e if you don’t find something in Theater DB then go to the DB benieth will cannot work on binary files, as you cannot skip indexes.
a Non-binary DB or at least a Binary DB with non-binary overlay DB would make it possible. but again, you are not immuned to things that shift around inside the DB.for example, I BMS choose to re-order weapon IDs in the BMS DB, then all hard-point entries on theater DBs would be useless without a matching adjustment.
-
Well if exists on the theater database use theater database entry. If you are a programmer u know it’s doable. everything is doable the thing is how easy it is and how much structural changes are needed.
Something like that I’m sure will need structural changes. Oh dear… nightmare again… but final nightmare.
Same way as for textures. not that easy though.
So if in your db you have set your weapons in the order you want and only order is changed no prob.
If u set the relationship between the 2 correctly you can do whatever you like… the relationship will be just there. This is the key to solve your index problem. So you don’t mess with it. if u mess it’s considered a structural change and ok guys time for nightmare.
This on top will need the editor to be also coded for the changes… nor to mention a new version of LodEditor… and Monster terrain editor and so on and so forth so we all agree it’s not gonna happen cause if one of the chains link is broken or undoable it’s fubared. As I understand it code for LE doesn’t exist nor any other tool to do it’s work.Sure db is more tricky but…
THE TOOL is the holly grail.
anything else falls behind and making it more complicated and hard for coders.
So… where is the tool? :lol:
:lol: I found the name for it: T.T. aka THE TOOL. I might allow T.T.E. not “time to extinguish” but: THE TOOL Editor :rofl:
-
When are we going to join together all the theater in a world wide theater ? We should send out a drone to map the globe and we use it for F4
-
When are we going to join together all the theater in a world wide theater ? We should send out a drone to map the globe and we use it for F4
A map is not a theater…
-
……
Any in an case, you will have t redo all the stuff at each major code change od DB change … will be the case for future BMS version (not patch).
DB work “is not for public” ppl.
Bold done by me. Statement by a developer (DeeJay).
-
Bold done by me. Statement by a developer (DeeJay).
Yep. In 2012.
And now in 2016 (nearly 2017), it is easier or just the same painful and time consuming task than in 2012 ?
-
Sorry, did not get your point, Deejay: You are saying that the DEV team is also looking forward to a tool like that and will support (=share code) information so that the tool can be accordingly updated each time the code etc is changed?
-
Sorry, did not get your point, Deejay: You are saying that the DEV team is also looking forward to a tool like that and will support (=share code) information so that the tool can be accordingly updated each time the code etc is changed?
No. Sorry If I badly expressed myself.
What I am saying there is that anytime BMS release a new version (or even sometimes a patch) 3rd party DB are invalidated.
When I say “DB work is not for public” … I mean : not for non aware peoples and not for inexperienced people. BMS is working and evaluates a possible partial solution. But it will not be THE PERFECT magic solution and won’t help with deeply modified database with different CT index … etc … -
@A.S:
That is why i had the Allied Forces db open and the same time the BMS db on the other side - as comparision tool if you will.
Compared EVERY crucial values, RUN-cross-checked them ingame (datarate, stores, hardpoints, features, repairtimes, radars, flags, weapons, Roster-Slots …you name it …list goes on) …fixed EVERY unit + weapon we will use in next RF server (min/max speeds and alt, rolescore, vis sig (was completly missing), RCS, fuel rate, GW, MTOW …all the FLAGS… …list goes on) …again…cross check all ingame…adjust for most realism…bla bla bla… it is work…indeed.Same with the campaign (korea) …rebuilt every link properly in respect to mountains, streets…coast, riverbeds…priority, suppy and fuel values distributed logically, objects placed right, unit names and slots filled right…rosterfixes…etc etc)
The db needs to be seriously redone from beginning and one solid one needs to be released as basis for the future.
Too much stuff is tweaked to death, moddified to mutations or completly missing
Infact its pain in the arse, but with dedicated testing (fly it) and understanding…you can do real good “magic” for your campaign. in terms of more realistic warfare and environment.I (with Demers help too) could only do it for what is required on our next server, but there are other great theaters now (as in example Isreal) which also would benefit from proper database work and fixes (one i.e Mystic just did fixing the oversaturated airspace >> roster-slots) ….etc etc.
Now there is a blast from the past……guess I did that when I WASN’T an Admin on the FO team, or maybe it was Falcon Workshop…remember that???..ROTFLMAO!!!
BUT, going forward, Deej is kinda right…see there are two types of disciplines going at it at the same time.
The Coders and the Editors.
In a past job, I had to bring these two disciplines together in a daily meeting…not pretty…a lot of “finger pointing” and non-productive discussion.
Dude1:You changed the Data, you were suppose to abide by the Code
Dudette2:I sent these edits 3 weeks ago, where are my adaptive Code edits???And so on…sigh.
In the end I moved one of each to each others office space so that I had a Coder with an Editor and vice versa. Then the “Magic” started to happenAs far as BMS, to tight and to loose of an organization to ever maintain that kind of control.They provide the working .exe and DBase and expect the 3rd party to adhere to their standard.
We should, as they already know it works.As far as a comparison tool…we already have it.
It’s called F4 Browse.
With it you can open x instances and export the Data to a spreadsheet and compare your values there,adjust if needed and then import them to your DB.
Exactly what I do with GUAM every time the .exe\DB is updated……not hard to do…see???tired demer
-
As far as a comparison tool…we already have it.
It’s called F4 Browse.
With it you can open x instances and export the Data to a spreadsheet and compare your values there,adjust if needed and then import them to your DB.
Exactly what I do with GUAM every time the .exe\DB is updated……not hard to do…see???tired demer
For POH that’s not an option anymore, sadly.
Since the DB has grown so much with new features and stuff, at some point throughout the development stage F4browse simply wasn’t able to open and edit the DB anymore.
Our only option sticks with BMSEditor (which I personally prefer to F4browse once “mastered”), although I believe it doesn’t have the ability to import/export to Excel, and that makes things a little bit more difficult and time consuming with every new DB update.Ahhh well, back to work with the nice tools we still have
-
@Nuno:
For POH that’s not an option anymore, sadly.
Since the DB has grown so much with new features and stuff, at some point throughout the development stage F4browse simply wasn’t able to open and edit the DB anymore.
Our only option sticks with BMSEditor (which I personally prefer to F4browse once “mastered”), although I believe it doesn’t have the ability to import/export to Excel, and that makes things a little bit more difficult and time consuming with every new DB update.Ahhh well, back to work with the nice tools we still have
That truly is a problem, even in GUAM with 150K+ Polygon (Triangle) carrier model’s….though they look sweet they occupied a lot of space in the DB.
So once past a little over 2GB in the LOD file F4 Browse spits an error at you saying something like “Not 1.7”… HELL no its 2.9GB…LOL!!!BUT Baldeagle’s tool has a nice little utility called Compact the data base. It removes a lot of unused LOD’s and shrinks the DB a lot
Guam went from 2.9GB’s just recently to 1.2GB’s using this option……be careful with it because it has in the past (FF daze) removed some things I wanted to keep…sigh!Cheers,
tired demer -
Is Baldeagle still around and maybe working on it?
If not is there any consideration passing the code to bms team for future updates?
Or taking it to open source so that the community might update it? -
That truly is a problem, even in GUAM with 150K+ Polygon (Triangle) carrier model’s….though they look sweet they occupied a lot of space in the DB.
So once past a little over 2GB in the LOD file F4 Browse spits an error at you saying something like “Not 1.7”… HELL no its 2.9GB…LOL!!!BUT Baldeagle’s tool has a nice little utility called Compact the data base. It removes a lot of unused LOD’s and shrinks the DB a lot
Guam went from 2.9GB’s just recently to 1.2GB’s using this option……be careful with it because it has in the past (FF daze) removed some things I wanted to keep…sigh!Cheers,
tired demerThank you very much for your explanations and your time, Demer.