Test low-poly toys in BMS4..
-
wait is there a download link for 4.35 or…
-
i take time to compare 4.34 and 4.35 fm.dat, just learn that there’re lots differences - tho my edited ac.dat files may work to some extent, they definitely miss some features. i’ll try update my fm.dat… very slowly.
-
Hi ,Master ccc1tw
Just 2 little questions for you, today :
1/ Did you ever think of making a “two-seater” version for the F111 F ?
2/ If not, how to do this ? The thing is that I would like to make a retrofitted version of the F111 F ( with a Tornado pit) , so I was wondering how to add what you have already done for the Su-24 M . I presume that you add smg in the F111-F.LOD , but where and how ? Currently , the F111 F is a single seater plane … I would like to correct this .-EDIT- : Subsidiary question : Is it possible to make a kind of “copy-paste” of what you have done on the “2 seater” Su-24 to directly add it in the F111 F.LOD ? I mean , copying the copilot+ a part of the “enlarged canopy” ? It would be great …
-
Are you sure you’re referring to the proper plane? The F-111 was ever only produced as a two-seat, side-by-side cockpit and the .lod does show two aircrew through the canopy…
-
the .lod does show two aircrew through the canopy…
Hi Parislord !
Yes ! But I was talking about the pilot POV , when YOU are looking inside the pit …
Look into ccc toybox , for the Su-24 , and you’ll understand what I would like to reproduce in this plane . He managed to draw a pilot on your right side and an enlarged canopy , that you can see when you are sitting in the plane . It’s a bit rough (ccc did it as a test , or for fun) , but I definitely loved it , and now I can’t fly without in the SU-24 ! In the F111 there isn’t such a thing , because :
1/ without retrofit , you are in a F-16 pit so obviously there’s no copilot on your side
2/after retrofit , it’s the same if I use a tornado pit . I could have a 2 seater side by side If I do it with the ccc1tw ckptwing lod for the SU-24 -EDIT- I just checked, and the copilot is indeed draw in the cockpitwing LODIn other words, if i want to see my copilot, for now the only way is to add a Su-24 ckpitwing lod to my F111 , + a tornado pit … I’ll end up with a Tornado pit , a copilot , but Su-24 wingview (from the pilots POV) . Maybe I should try this , but I would like to keep the cockpitwing.lod that I’m currently using for my F111(a MiG23’s wingview, it looks satisfying from the pilot POV) .
I’ll try with Su-24M wingview anyway , maybe it will look good … Your post gave me an idea …
Thx !!!
-
1st try … needs adjustements , but… it may work …! I only need some hints from ccc to push further … It could become a good retrofit , eventually …
-
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!