LODEditor Replacement
-
This is the goal. One model, one folder. You select the FOLDER and click import. Program will grab what is in the folder and either add it or replace existing. Models get imported to the DB, textures get copied to the appropriate folder. FM files, ckptart, everything required for one complete aircraft, all in one folder, all imported at the press of a button. Text IDS/IRC files automatically updated, actypes updated if required, (Optional) teunits and validac updated. Like I said, Download->Import->Fly. It should take seconds to import an aircraft, not hours.
I was thinking more of no install of the files into the db (no more 2Gb database limit) and use of models/skins/dat files straight from the folder… but that is probably a bridge too far at the moment…
-
LODEditor is a lot more than just a model editor. The tool has a lot of other functions for DB work. My first recommendation is simply rebuild LODEditor with all the current functions from 6.23 which is what most folks are using unless they some of the 7 series.
Perhaps one way to look at improvements would be clear up and avoid some of glitches that seem to occur when you use LODEditor . . . BMS Team has removed some issues by creating other tools that rebuild the DB and thus sidestep from LODEditor. However, I have found LODEditor to be very useful for some things and if operated in the proper way will usually produce good results - though not without a regular number of data corruptions. One of the biggest issues is when manipulating CTs and parents … say you are try to append a new parent - doing more than one parent at a time can result in a corruption - not sure why - just happens. When you update data on a parent it can corrupt as well. This can also occur when you replace a parent record assigned to CT … it is quite unpredictable. My solution has been to backup my work at the start of every session … then test at the end - if I get a corruption it is nearly always a result of the Falcon4.ct file being busted. So, any new LODEditor needs to be rock solid in the data manipulation piece.
Some really useful tools that go with DB work should include being able to identify orphaned parent records - ie parent records that for one reason or another are no longer used or associated with a CT or the CT0 in the case of cockpit stuff. Need a way to identify that stuff. Same goes for being able to identify unused textures and missing textures. That part is busted right now.
Another useful thing would be to have a way to check for parents being shared across CTs. This occurs way too frequently when you start having several people inputting data and losing track of which CT is using which parent. When a parent record is shared - one may not realize that changing a model in one parent changes it across all parents that are shared.
One issue I found with working with the LOD trees for nodes is that LOD is rather temperamental about being able to cut and paste stuff . . . when use different type of P-types or LP vs CP nodes you can get crashes if you don’t cut/paste in rather circuitous ways. I think ccc1tw has mastered all the tricks on this and would be a good resource to tap into.
Looking to the future I also thing a new LODEditor would benefit greatly from being able to tap into externalizing data and models with things like XML - so you could output the data into something that would then allow you to manipulate the data, see the data and possibly identify conflicts. In the past I used MATLAB to export the CT list and then built a custom spreadsheet to help organize data. Biker has done a super job with the BMSEditor for data - effectively replacing F4Browse with graphic interfaces that show you data and alllow you to view it in different ways. If new LODEditor could perhaps follow Biker’s lead in that area it would be a big improvement. Similarly, I reflect back to Rick Prior’s original LODEditor which was tied into MacBrowse . . . so in effect linking the models and their particulars and then ensuring conflict are not introduced. Again, BMSEditor does a nice job of linking up parts of and updating things. LODeditor needs to be able to analyze a model and ensure it properly identifies the switches, dofs, slots correctly and identifies when something is wrong or missing. One example is if a switch is orphaned - the entire model can cause a crash of LE. Another feature that would be nice is to combine the ability of viewing the model in a way that would allow for a better animation check as well as being able to manipulate LODs like you do in 3dsmax. For those ex RV guys, familiar with DXEdit - this was a neat model tool - it wasn’t a detailed model editing tool but rather was more like a finishing tool - it allowed one to easily autoshade the model flawlessly in seconds (a feature LODEditor has always stuggled with). It also allowed viewing the model in three lighting conditions bright lights, normal light, and night. This let you check the model for stuff like night strips and lighting, casting of light beams light landing lights, nav lights, afterburners. I have the source code for this tool and could send it to you to look at. While the tool was designed to work with DXM models in FreeFalcon - there might be something useful for you to look at. Another nice thing about DXEdit was the model tree structure was very easy to cut/paste and manipulate. It made a model novice like myself able to add pylongs, and move things around without a lot of training. So, from that perspective it was a more useful tool for those who have less time to learn a very complex and complete modeling software package like Autodesk 3dsmax.
There are lots of other things I could discuss with you but perhaps in the interest of giving others on this thread fair space to voice their interests - maybe just PM me.
-
This post is deleted! -
Deleting models not used…
Im pretty sure many r left as reference. To see properries and do things mostly for newbs or cause not all aspects of the thing where known, so leave them there just in case.
A good thing would be a tags or comments per record.
A function that doesnt actually exist in LE is delete records ct or parents.
Yeap reindexing might take a while but…
another alternative would be if the user doesnt want to reindex to replace such records with empty records with a blank model.
@Ranger822 u know this stuff so dont just wait for the others bomb away.
And bms guys should brainstorm on what they might need to pass on requests. Db restructuring is ouch on many cases. We know about multible hitboxes.And now that i mentioned hitboxes calculating those on 3ds max is a bit slow and transfering to LE not a fast procedure. Not on the pc now i’ll link u on the how to.
Also might be helpfull reference models for ptypes. Ive done some in the past. Will check them and pass it on in case they help.
sent from my mi5 using Tapatalk
-
Some really useful tools that go with DB work should include being able to identify orphaned parent records - ie parent records that for one reason or another are no longer used or associated with a CT or the CT0 in the case of cockpit stuff. Need a way to identify that stuff. Same goes for being able to identify unused textures and missing textures. That part is busted right now.
Yep! +1000 … because this DB needs some cleaning, so many unused (garbage) LODs could be removed and giving way for new models … especially considering the size limitation we still have for now.
Im pretty sure many r left as reference. To see properries and do things mostly for newbs or cause not all aspects of the thing where known, so leave them there just in case.
… good point, but we can also keep an old DB somewhere on a hard drive as reference in case of. No need to necessary keep everything in the core DB.
-
Yep! +1000 … because this DB needs some cleaning, so many unused (garbage) LODs could be removed and giving way for new models … especially considering the size limitation we still have for now.
… good point, but we can also keep an old DB somewhere on a hard drive as reference in case of. No need to necessary keep everything in the core DB.
This is a better point.
-
This post is deleted! -
Has anyone started to test to exeed the 2gb file size in LE?
If not IKAROS file is very close to it, so i’ll beef it up tonight to see how it goes.sent from my mi5 using Tapatalk
-
This post is deleted! -
We’ll see. Many such “myths” - ghosts exist in Falcon. So mythbusters mode ON. Check.
sent from my mi5 using Tapatalk
-
Has anyone started to test to exeed the 2gb file size in LE?
If not IKAROS file is very close to it, so i’ll beef it up tonight to see how it goes.sent from my mi5 using Tapatalk
Tried it to go past the 2Gb. Sim crashed every time.
-
Also calculating the shaders is an issue that should be looked at. Reaching the 70/80k my LE simply freezes… (with HDR limit set at 100k)
-
This post is deleted! -
We’ll see. Many such “myths” - ghosts exist in Falcon.
-
Tried it to go past the 2Gb. Sim crashed every time.
Raptor has also exceeded the 2GB limit several times and BMS crashed.
So it’s definitely been verified by multiple persons.
C9
-
I confirm also.
After 2gb LE works ok but Falcon when it’s about to load something 3d just crashes.For me it’s a Falcon exe thing and not a LOD Editor thing. LE seems to be doing ok.
Not an expert but Falcon crashes not LE.Edit: Strange thing though… compacting the damn thing from LE reduced the size bellow 2GB but still Falcon crashes.
Edit2: Just in case u wonder I tested the source first and it was working ok. Afterwards I started beefing… So she doesn’t like bacon… :lol:
-
This post is deleted! -
From my tests the db does not seem to be corrupted after compacting BEFORE the 2gb limit, you would only need afterwards to APPEND parent records and models in order to function properly and fill the empty gaps of the model records that were removed by the clean-up.
If you pass the 2gb limit there is no return / fix for the corruption (that without been 100% sure, it seems to be a hardcoded limit of the db, nothing to do with LE), you should use a working backup of the latest good working state in order to compact.
-
-
This post is deleted!