Test low-poly toys in BMS4..
-
the only side-by-side 3d pit available is Qawa’s A-6 pit work.
it was in FF and probably lost.btw the co-pilot model better be placed in main 3d pit model, not in cockpitwing model.
my tweak is just for fun, you need serious modellers to do the work. -
But still, could you explain a bit how you draw him in your wingview.LOD ?
I know the “delete node” command, that I learned to use when I tried to do my 1st wingview.LOD , on that Transall .
But how to add them and place them ? Same , I know how to erase a fuel nozzle on a model, but what if I want to create one ?
-EDIT- :
the co-pilot model better be placed in main 3d pit model, not in cockpitwing model.
Why ?
-
The Su-25, in version 4-35 render, has strange rays of light from the cockpit area.
-
But still, could you explain a bit how you draw him in your wingview.LOD ?
I know the “delete node” command, that I learned to use when I tried to do my 1st wingview.LOD , on that Transall .
But how to add them and place them ? Same , I know how to erase a fuel nozzle on a model, but what if I want to create one ?
-EDIT- :
Why ?
deleting nodes is easier than adding nodes. better learn 3d modelling first or more LE operation, then you can import new parts to existing models.
co-pilot is too close to simmer’s eye position, better be placed in main 3d cockpit model which is rendered lastly.
-
better learn 3d modelling first or more LE operation, then you can import new parts to existing models.
Hi ccc ,
Yeah , I was arriving to this conclusion before I fell asleep . Learning a bit 3D modeling should be the next step for me …
co-pilot is too close to simmer’s eye position, better be placed in main 3d cockpit model which is rendered lastly.
I see your point .
Thx for the reply !
-
The Su-25, in version 4-35 render, has strange rays of light from the cockpit area.
bug fixed - 4.35 gfx engine doesn’t like a pType in HUD node.
-
Thoughts to share with Theater DB modders.
< 3ddb builder part - model and skin >
-
All new models/Parent folders should be numbered higher than the last of BMS core DB. The new textures used by new models should be numbered higher than the last one in BMS DB. say, Parent number starts from 4000 or 5000. Texture number starts from 9000 or higher.
-
in this way you can create dev folders called “Parent” and “Texture”, place ALL new stuff in the two folders. Once a new BMS out, you can dump your new stuff in, run 3ddb builder, DONE 3d job.
< XML file part - link-up data >
-
this part is more tricky, it’s related to ALL XML files like CT, VCD, UCD, SSD, etc. ALL new stuff touching these files must be edited to make them functional. the key is still setting higher numbers for records.
-
you have to set up first working records in all XML files, by manual editing or import previous exported XML parts. the key is, change the record numbers to higher ones.
i.e. < CT number = 550 >, change to < CT number =900 >.
-
in this way ALL new stuff data will be grouped at higher number section and ALL linked up. you can store grouped data in dev XML folders. Once a new BMS out, attach them to new BMS XML files.
-
of course the job is not done, but much less workload. items may have specific numbers need to be re-ordered. and aircraft type items need file edits in Art and campaign folders.
PS: ALL Specific numbers, like other numbers, can use higher ones when you do first round of DB edit. Say, adding a new fighter record, set its VCD specific number 150, its UCD flight/squadron records specific number all 150, then you won’t bother to fix specific number duplication bug anymore.
Ideally, if you do the work right for once, ALL new theater-specific items/records will have a SAFE space between BMS core DB, linked up properly, and can be easily transferred to new BMS DB (unless it changes some parameters).
-
-
Nice idea if Dev Team approves . . . will check up on this on the Dev site and get back.
-
Thoughts to share with Theater DB modders.
< 3ddb builder part - model and skin >
-
All new models/Parent folders should be numbered higher than the last of BMS core DB. The new textures used by new models should be numbered higher than the last one in BMS DB. say, Parent number starts from 4000 or 5000. Texture number starts from 9000 or higher.
-
in this way you can create dev folders called “Parent” and “Texture”, place ALL new stuff in the two folders. Once a new BMS out, you can dump your new stuff in, run 3ddb builder, DONE 3d job.
< XML file part - link-up data >
-
this part is more tricky, it’s related to ALL XML files like CT, VCD, UCD, SSD, etc. ALL new stuff touching these files must be edited to make them functional. the key is still setting higher numbers for records.
-
you have to set up first working records in all XML files, by manual editing or import previous exported XML parts. the key is, change the record numbers to higher ones.
i.e. < CT number = 550 >, change to < CT number =900 >.
-
in this way ALL new stuff data will be grouped at higher number section and ALL linked up. you can store grouped data in dev XML folders. Once a new BMS out, attach them to new BMS XML files.
-
of course the job is not done, but much less workload. items may have specific numbers need to be re-ordered. and aircraft type items need file edits in Art and campaign folders.
PS: ALL Specific numbers, like other numbers, can use higher ones when you do first round of DB edit. Say, adding a new fighter record, set its VCD specific number 150, its UCD flight/squadron records specific number all 150, then you won’t bother to fix specific number duplication bug anymore.
Ideally, if you do the work right for once, ALL new theater-specific items/records will have a SAFE space between BMS core DB, linked up properly, and can be easily transferred to new BMS DB (unless it changes some parameters).
I was thinking about doing it in ITO (more to CT 6000 but you took it even further)
Still need to learn that stuff -
-
Thoughts to share with Theater DB modders.
< 3ddb builder part - model and skin >
-
All new models/Parent folders should be numbered higher than the last of BMS core DB. The new textures used by new models should be numbered higher than the last one in BMS DB. say, Parent number starts from 4000 or 5000. Texture number starts from 9000 or higher.
-
in this way you can create dev folders called “Parent” and “Texture”, place ALL new stuff in the two folders. Once a new BMS out, you can dump your new stuff in, run 3ddb builder, DONE 3d job.
< XML file part - link-up data >
-
this part is more tricky, it’s related to ALL XML files like CT, VCD, UCD, SSD, etc. ALL new stuff touching these files must be edited to make them functional. the key is still setting higher numbers for records.
-
you have to set up first working records in all XML files, by manual editing or import previous exported XML parts. the key is, change the record numbers to higher ones.
i.e. < CT number = 550 >, change to < CT number =900 >.
-
in this way ALL new stuff data will be grouped at higher number section and ALL linked up. you can store grouped data in dev XML folders. Once a new BMS out, attach them to new BMS XML files.
-
of course the job is not done, but much less workload. items may have specific numbers need to be re-ordered. and aircraft type items need file edits in Art and campaign folders.
PS: ALL Specific numbers, like other numbers, can use higher ones when you do first round of DB edit. Say, adding a new fighter record, set its VCD specific number 150, its UCD flight/squadron records specific number all 150, then you won’t bother to fix specific number duplication bug anymore.
Ideally, if you do the work right for once, ALL new theater-specific items/records will have a SAFE space between BMS core DB, linked up properly, and can be easily transferred to new BMS DB (unless it changes some parameters).
This (more or less) has been proposed some times ago (one or two years IIRC while working on DB cleaning) … nobody jumped on the idea to organize it in a more formal way among 3rd party participants.
On my side it is now too late to change anything to the current DB.I can however gives you a range is Texture ID that can be (if you like gents) be reserved for some 3rd theaters.
Up to you to organize yourselves (among 3rd party like Balkans, ITO, … etc …) by coordinating your strategy on a dedicated thread (you could even coordinate with a moderator or admin for a dedicated sub room in the forum) … to define allocations slot for each theaters … etc … -
-
Textures ID:
Firmly Reserved for stock DB:
Everything below 4400 (too much fragmented to be practical for use)
4900 to 5199
7900 to 8099
9998 RESERVED RTT
9999 RESERVED RTTSo to start with … I may propose you
Free slots: From 4400 to 4899
From 5200 to 7899
From 8100 to 9997
…
Theater builders should ask for some slots depending on their estimated needs (for instance 50 or 100 slots) … the 3rd party DB leader will be in charge to allocate those slots to each of them according to what is available.
Up to you to define a who is that leader who will define and manage the available slots and who will keep me advised about those slots allocations so I can keep the main texture allocation Excel sheet up to date to avoid any conflicts.Please open a dedicated thread for initial coordination.
-
CT allocation:
Not easy.
But lest say that we can imagine that stock DB will probably not go above 8000 (about twice what it is now).
I don’t know if code has a CT limitation. You will have to ask coders about it.But you may perform some test by increasing the DB beyond 10000 and see what happens. If is works, you know that you have at least from 8000 to 10000 available.
-
Parent allocation
We are at 4000, same as above, we can consider that 8000 is a reasonable maximum for the stock DB (maybe it will never go up to that amount, but no guaranty either that it will never go beyond).
So you may consider the same as above. Anything above 8000 is “yours”. However, here also, we need coders to know if/what is the maximum parent allocation authorized by the code (it is probably not unlimited).
I am not sure that our BMS coders knows the answer. I think that anyone having the SP4 code and some C++ knowledge can read the original code and try to find the answer. -
DJ Thanks for free Texture ID list.
I think theater DB modders can choose their favorite free Texture IDs independently, unless they want share common models/skins.
[Edit] i don’t think theater DB modders need TEX/CT/Parent number coordination - all new stuff are add-ons of core BMS and have independent DB.
Honestly my primary concern is to handle all XML data and some key files in Art, Sim and Campaign folders… leave a safe space between core BMS stuff and grouped, theater-specific stuff. ALL 3d and data stuff are readily linked up and handled at higher-number section. If it works, theater-specific stuff can be transferred to any new BMS with minimal workload.
I’ll test my idea and report back.
[Edit ] I see you are giving more numbers!
-
Alright, good news, i confirm my trick works.
-
transferring a lot of models and skins to new BMS is easy. done in minutes.
-
transferring a lot of XML and related data to new BMS is easy. it takes tens minutes.
The key is you’ve to do it right for once, and save new XML data properly for next BMS.
aircraft type items need more attention.
- new ac ACD files should have a higher number, leave space for BMS new ac. just change their numbers in ACD file.
- for sim\acdata\ actypes.lst file, i add placehoder fm.dat from 182-190, update total count. and add some copies of fm.dat named 182.dat - 190.dat.
192
.
.
f4m
aj37
q5ii
182
183
184
185
186
187
188
189
190
at36
k8in this way, i go back to ACD edit page, can re-direct new ac ACD to use new fm.dat.
then the new ACD data can link to fm properly - and independent of core BMS change.PS - current BMS fm count at 181. if next BMS fm count at 189 for example, you can cut the txt part from 190 to the end of your fm.dat, attach to the end of new bms actypes.lst, update total count, all ACD-fm links remains unchanged and working. you may increase the dummy fm.dat to 250 or more, to create a safer distance.
-
-
to make all new ac working, follwoing files should be edited, with higher numbers. all attach to the end of content.
\art\dgft\userids.id (all new data attach to the end of content)
DF_AC_AT36 22000
\art\main\textids.id (all new data attach to the end of content)
TXT_AT36 700
\art\main\unit.irc (all new data attach to the end of content)
[ADDTEXT] TXT_AT36 “A/T-36 Halcon”
\campaign\save\te-planes.lst ( for better order in selection list, you have to change order manually)
// AT-36
1 2 60 3 22000 700 10092\campaign\save\validac.dat (all new data attach to the end of content)
2 6 3 3 60 255 255 255
for ground and naval vehicle/units, trick is the same, use higher numbers. write down their specific numbers, and fill in teunit lst. you may prepare the new unit data in a txt in advance, then paste to new teunit.lst in next BMS. all done in seconds.
-
two old toys in latest Kurile mod.
-
Just on Tactical Engagement, right?
A pure Cold War campign is very much needed…
-
Just on Tactical Engagement, right?
yes.
A pure Cold War campign is very much needed…
well,
for f102, you need cold war korea, europe, vnam, aegean area mod.
for f106, you need cold war korea, alaska, iceland mod.of course both can be deployed to Kurile, fight along with F-4 and early F-15A.
-
For theater DB modders:
BMS 4.35 falcon4. *** XML files. - 19
ACD - ac fm and sensor - 186 (Last number)
CT - main record - 3800
DDP - 201
FCD - 1193
FED - 18998
ICD - IR sensor - 61
OCD - object - 639
PDX - 30452
PHD - 742
RCD - radar - 123
RKT - rocket - 27
RWD - RWR sensor - 62
SSD - squadron store - 97
SWD - SimWeapon - 360
UCD - unit - 581
VCD - vehicle - 422
VSD - visual field - 16
WCD - weapon - 697
WLD - hardpoint - 557