CMP Editor

**Here is the first test version of the CMP Editor…

[Click here to download the test version

Thanks to Friendly Fire for testing earlier versions.

I have only tested this on a few files. The program will create a ‘Temp’ and an ‘Output’ folder. When you load the UTF file the data within it will be saved to the Temp folder. When you save the UTF or save a script, it will go to the output folder.

It will not overwrite the file you are editing. At this time you wil have to copy it to the correct folder. I will change this later but we have to make sure the program is working right before I do this.

Warning, make a backup of the UTF file you are messing with if you intend on replacing it with the files this program generates. I do not know at this time if the loader and saver are stable. They appear to be on the few files I have tested but I have yet to test all of the files in FL with this program.

For editable leaves simply double-click them to edit them. I don’t have every type built in yet but the main types can be edited.

When you click on a texture, you can see it on the right side bar. Also, when you load or save raw textures or sounds, they will have the proper extensions on them (thanks FF for suggesting that).

Each leaf node that is supported is auto-detected. This means that when you click ‘Edit’ or double-click on the leaf, it will pop up the correct edit box for that leaf name. As in you double-click on a ‘Dc’ node, it will pop up the color picker.

VMeshData is the only leaf that currently supports script export. I haven’t written the importer yet but that will be coming soon. This feature supercedes the one in UTF Editor 1.4, it has everything listed in it and is built as a compilable script that my code can read.](http://www.galacticenigma.com/LS/CMP_Editor.zip)**

Description updated

**Do you have the latest version of DX installed?

Click here for the latest DX runtime installer

That DLL you mentioned is part of your DX install, this program requires an up-to-date DX install to work. The texture viewer uses DX to convert the texture to bitmap which the program can load.**

Ok, it time for suggestions on what you want to see in the program.

**It is intended to edit any UTF file. I will check and see what has changed that makes it crash.

This editor makes every string separate so that is the most likely cause of the size increase.

The data is stored as binary files in the ‘Temp’ folder, so until I get the editors working for every part, it should not change any data stored in the leaf nodes that you can’t edit.**

I did test it last night and you are correct, it causes a crash. Has anyone tested any other UTF files to see if they work? I’ve only tested it so far to see if the UTF editor and HardCMP loads them up.

**1 ) A very good idea, hadn’t considered multi-selection on the nodes

2 ) Saving them is the way I had intended on implementing the copy and paste, I never use the clipboard since I simulate it with an actual image of the data on the HD**

**DFM files can be loaded and saved using the next version I will be releasing. It turns out that the dfm file has a huge number of tree nodes so I increased the maximum nodes to 32k.

Also, I found a major bug in the save routine, none of the saved UTF from the current version should even work. It was a test version so that is to be expected.**

**The current version above is bugged badly. It can’t be used to edit any file properly. I will put up another test version this afternoon (or after midnight ur time Jong).

The next version should properly allow you to load and save the DFM files. I do have an add and remove node feature but it is incomplete. I’ve also added in the normal ASCII and HEX preview boxes like in the other UTF editors out there.

Another thing is I have been going through every UTF file and hunting down all of the missing nodes that I didn’t already have in it. I still haven’t added in the OpenFLAME stuff. Once I do that it will effectively double the number of nodes that can be edited.

I have found one thing though. The data size is the actual size of the data stored in the node. The allocated size is long aligned (as in every 4 bytes) and has a minimum size of 8 bytes. This is very important to FL and is not done in the version listed above.**

**@ Zaxx - yes, I have already tested it on DFM files and it loads and saves them properly.

@ Jong - I actually wrote this program so I could complete the CMP to SUR code. In that program I wrote so many UTF node decoders that making this program made perfect sense. Plus now I can see stuff that the UTF Editor 1.4 doesn’t even show.

@ Mini-me - yes, that is the whole point. The way I am implementing it is through a script file. If a user finds an unsupported leaf node, they simply add it to the script and then it should show up in the new node section.

@CoT - good idea, I could simply implement a incremental saver like the one in my Commodity Ticker program (unreleased sorry).**