XSI for mappers
The simple version all modders and mappers should understand:
XSI: the model format that bzone engine recognizes. Note only a few older versions of XSI will be supported properly
MSH: this is the optimized binary data that bzone.exe creates when it first encounters a XSI model. It only creates the msh if it cannot find an existing one. It will ALWAYs use a msh that currently exists, instead of creating a new one from the XSI.
binData folder: This is a temporary holding folder for meshes created from XSI's. It is always safe to delete all contents of this folder, in fact it is advised if you are making changes to XSIs. Meshes are not required to reside here for bzone.exe to find them. They may also exist in the addon tree. Remember, if a mesh is found anywhere, a new one will not be created.
How do I get my custom XSI into the game?
First you need a custom named XSI. It is very important in BZ2 modding to give everything you alter a unique name or the assets checker can prevent you using your creation in a multiplayer environment. (Texture names don't apply) Also it's not a good idea to exceed 11 characters in your prefixes of any BZ2 filenames, although there are cases where bzone.exe will tolerate them.
You decribe which XSI to use in the objects ODF file in these lines:
geometryName = "mymodel.xsi"
geometryScale = 1.5
This is where the scale of the model is described. You cannot scale a mesh once created. It is scaled at the time of creation from the XSI using the geometryScale value. If scale value is omitted, it defaults to 1.0. This is why changing the geometryScale will not work under most conditions, since normally the mshs have been precreated.
Now that we have our ODF and XSI we are ready. Go into the editor and place the object by typing the odf name into the object "config" box to select it, then place it on map. When describing objects in the editor, the ".odf" extension is not used, so mytank01.odf is entered as mytank01.
The instant you enter the ODF into editor the msh file gets created, you will probably even notice a slight delay as it's calculated. The msh gets placed in the data/binData folder. Now you have a completed mesh.
Exit the editor, remove the mesh from binData and place it into the folder containing your map assets in addon folder. Take the XSI and store it somewhere with other mod working files that aren't to be distributed. There is almost no reason at all to distribute XSI's with your map or mod. You should be distributing ONLY meshes. Wherever an XSI is called in the bzone files, it will use the msh instead with greater speed and memory efficiency.
Meshes are almost always smaller in file size and load far quicker than having a client generate one on his own machine. It keeps your mod work more proprietary, since editing meshes is extremely difficult beyond changing the textures in them.
Another reason to use meshes exclusively is that as you update your mod or map and share it with testers, you would have to constantly rely on the testers to delete the bindata folder. If they didnt, AV's and even more commonly GAMESTATING will result from using mismatched mshs. But if you include them as part of the map assets, they will automatically be updated with the rest of your map/mod beta versions.
regards SUB-0
XSI for mappers.txt
Moderators: GSH, VSMIT, Red Devil, Commando
Re: XSI for mappers.txt
1.3 is capable of detecting than an MSH file is old compared to an XSI, but it is still optimal to clear your binData before the 'final test'.
XSIs and now PICs and other source files are now often kept by the mod maker or released in 'modder data' packs in a way similar to how the 1.3 patch separates the source changed files from their much smaller game generated counterparts.
XSIs and now PICs and other source files are now often kept by the mod maker or released in 'modder data' packs in a way similar to how the 1.3 patch separates the source changed files from their much smaller game generated counterparts.
Re: XSI for mappers.txt
Forgetting the presence of a model in the binData folder is often the cause of many a frustration, and assumption that your modelling is broken. If you're making models, delete your binData folder's contents regularly.
Re: XSI for mappers.txt
When I make a new model for testing I have my OS set to open the model folder by default with 3dex that way I can regenerate a new XSI with 3dex and then delete the old MSH model from the bindata folder. Before I used to open it in 3dex and had to manually navigate to a new folder in the addon folder using 3dex. It was very tedious and time consuming. I mostly work with the X format to 3dex to XSI then to MM5 with the edit function enabled. The process is fairly quick and if any changes need to be made to the model then I just cycle back to the 3d modeling software and repeat the process over again. Boy do I wish that I could just use some sort of batch file to do it all. Anyways, it works real good when changing stuff like model parts or HP's for different weapons configurations or testing out alternate textures on the model. BTW, when we see a model in the map editor is that actually a MSH model we're looking at? Thanks.AHadley wrote:Forgetting the presence of a model in the binData folder is often the cause of many a frustration, and assumption that your modelling is broken. If you're making models, delete your binData folder's contents regularly.

Re: XSI for mappers.txt
Yes. The game munges .xsis before displaying them.Feenix wrote:BTW, when we see a model in the map editor is that actually a MSH model we're looking at? Thanks.
Re: XSI for mappers.txt
Do note that with 1.3, your BinData may be located within a Battlezone II folder in 'My Documents'.