[BMS Tool] F4 3D Database Builder - v4.8
-
So u have it all in one place in the folder,
Patent. Dat
Lod1
Lod2
Lod3
1.dds
2.dds
3.dds“Not” possible … or let say, not more practical since many textures IDs are shared by two (or more) 3D models.
-
well DJ I disagree.
no issue if the same id’s are shared.
u will have an issue if u have a texture repeated 20-30 times in 20 30 folders?
No.
Cause u have a different task, u develop. The resulting outcome will be in one folder so for the user will be one.
So the loss is just some mb or gb in your hdd, but u have the quick reference for the files.Now in develop if you have all dat lod dds files in one folder you will have the same issue to find easily the lods - parents that are shared like damaged and destroyed models.
now where are those declarations? not in the dat but in the core db…
so you must go back to the falcon editor and open one by one to find.My main goal is not edit add update a single record for a vehicle or a feature.
It’s the update procedure of theater DB from current status to the new vanila from BMS.
In those cases working and having all the data and manipulate them in table structure is the way to go of instead one record of each table at a time and have somewhere some notes with your changes.
It’s doable but way time consuming.
we have most of the data and only a few parts of the puzzle are missing.I never said you dev’s have other tools or it’s easier for u. but you could also benefit from this.
-
u will have an issue if u have a texture repeated 20-30 times in 20 30 folders?
No.Of course you will.
1 - pointless space used on hard-drive (duplicates)
2 - pain to manage texture updates and versions
3 - which one will be used by code id multiple same IDs are found
4 - nightmare for maintenance (any updates will require to track, found and update each folders
…A texture is not loaded by a given LOD id … you can’t have duplicates.
-
Now in develop if you have all dat lod dds files in one folder you will have the same issue to find easily the lods - parents that are shared like damaged and destroyed models.
now where are those declarations? not in the dat but in the core db…
so you must go back to the falcon editor and open one by one to find.To find what? …
If you want to find easily what Parent is used by a CT … just go into Class Table and sort them in numeric order:
…
Or I still do not understand you point (?)
-
can you take notes on FE? no.
Do you have the dds associated? no.
Can you spot the differences for mass update from your current theater db to be compatible with the new 4.34 U1 DB? no
Can you mass manipulate and apply changes to the new 4.34 U1 DB and have a compatible theater with 4.34 U1? no. -
Do you have the dds associated? no.
The only way to know which texture files are used by a LOD is the use of the Lodeditor tool
Can you spot the differences for mass update from your current theater db to be compatible with the new 4.34 U1 DB? no
Yes, we have a history of all change but it is internal to bms dev
Can you mass manipulate and apply changes to the new 4.34 U1 DB and have a compatible theater with 4.34 U1? no.
We are only responsable about the official bms theater : KTO
-
So *** heads up here *** before transition to 4.34 get the list and keep it from LE. My precious… :lol:
Ok you have your history so we-they (theater dev’s) must keep their history of all changes. This is what I’m talking here. A tool or a way to have that history of changes in one place for all and be more efficient and why not use it to easier produce theater updates when BMS updates the vanila DB.
Well you are responsible for vanila theater only but your actions affect other theaters. I’m not saying u shouldn’t but it’s a fact we can’t avoid and it’s good to advance but burns down theater dev’s loosing time for compatibility maintenance when on the same time they could spot and fix errors on their theaters (which we all know are many) or enrich their theaters campaigns etc…
You (BMS team) took a very very good step with the xml db schema, I’m just pushing it to make it more efficient and save time to all theater dev’s that live the pain of conversion each time an update comes… also that way transition from one theater dev to another will be a walk in the park instead of diving in to deep and re invent the wheel.
-
@Bad:
Yes, we have a history of all change but it is internal to bms dev
Hey BB as you know we even don’t have a full history of all change expect by comparing with WinMerge each .XML changes. Don’t let them think that we have any kind of usable change-log for 3rd party Devs.
-
Hey BB as you know we even don’t have a full history of all change expect by comparing with WinMerge each .XML changes. Don’t let them think that we have any kind of usable change-log for 3rd party Devs.
and I was about to ask but I waited maybe someone would offer it voluntarily before I ask… :lol:
-
Ok you have your history so we-they (theater dev’s) must keep their history of all changes. This is what I’m talking here. A tool or a way to have that history of changes in one place for all and be more efficient and why not use it to easier produce theater updates when BMS updates the vanila DB.
There is no such “modification tracking list” list on Dev side. Only Tortoise SVN saving old version of files and able to compare two revisions like with win-merge.
But it is nowhere written that CT XX has been change to use Parent XXXX with Texture XXXX … the only “document” listing it is the .XML Database itself. And it is already a VERY BIG step forward because tis wasn’t possible in passed day when DB was binary.
You (BMS team) took a very very good step with the xml db schema, I’m just pushing it to make it more efficient and save time to all theater dev’s that live the pain of conversion each time an update comes.
Got to find someone to code a tool able to batch compare, track and list two different DB, something like MC does with old mission conversion.
There might be a plan for such tool on Dev side … but IMO, do not except it to be released soon. -
Got to find someone to code a tool able to batch compare, track and list two different DB, something like MC does with old mission conversion.
There might be a plan for such tool on Dev side … but IMO, do not except it to be released soon.sure.
we just toss ideas on the table and ask for any takers…
Excel wise I can do some stuff just my excel vb is rusty and I don’t know if I could manipulate complicated and demanding tasks on the procedure.
Finding and keeping track of changes between 3 db’s not that easy but doable.
The “ouch” for me is the db hierarchy like this weapon belongs to this rack to this unit to this squadron and to be able and user friendly represent it in excel.
I have done hardcore things in excel (if you recall as I mentioned earlier) the first globally build to order pc configurator.
yea it was super hardcore back then macros and calculations and vb code where running like crazy…To update it I recall I had to wait about 5-10 minutes for the calculation to complete. :lol:
-
There is no such “modification tracking list” list on Dev side. Only Tortoise SVN saving old version of files and able to compare two revisions like with win-merge.
But it is nowhere written that CT XX has been change to use Parent XXXX with Texture XXXX … the only “document” listing it is the .XML Database itself. And it is already a VERY BIG step forward because tis wasn’t possible in passed day when DB was binary.
Exactly this
And svn repositories are purely restricted to bms [edit] DEV, we can’t do better
-
@Bad:
svn repositories are purely restricted to bms [edit] DEV, we can’t do better
… and would be pointless for them anyway since modifications continuous, would require to follow it on a are daily basis, or sort the changes among hundreds of entries and would require them to develop their theaters in the same time than the Dev branch which includes modifications not suitable/compatible with their current 4.34 EXE.
-
@Bad:
The only way to know which texture files are used by a LOD is the use of the Lodeditor tool
Hi!
WaveyDave has a very nice tool, called F4TextureSetEditor, which allows you to find, edit or change the texture sets and numbers for every LOD directly.
5 stars!
-
@Nuno:
Hi!
WaveyDave has a very nice tool, called F4TextureSetEditor, which allows you to find, edit or change the texture sets and numbers for every LOD directly.
5 stars!
and where this tool can be found?
-
I wasn’t aware this tool was public released
-
… and I didn’t knew that it can find a LOD reference with associated Parent using a given texture ID!
-
Ummmmmmmmmmm……been in this tool for decades. Guess for the “skinheads”…DUNNO
demer
-
Oooook… I’m having a slight feeling that I spoke more than I should have…
If so, I’m sorry then, no harm intended, just trying to help…
-
@Nuno:
Oooook… I’m having a slight feeling that I spoke more than I should have…
If so, I’m sorry then, no harm intended, just trying to help…
No problems M8…I was just pointing out that it was there…I think Daveys was in response to .dds…IIRC.
Took Fred a minute to catch up in 6.19 or 6.21…I don’t remember, doesn’t matter anyway as long as they work, right???
demer
P.S. KEEP HELPING wrong or right.at least it is posted