| OPT Creation Problems and Enhancements XWA applies a strong smoothing effect to the OPT files in it which is very useful in making quite simple models appear rounded but unfortunately the strength of this smoothing can cause some problems with extra shading between coplanar faces. This is very annoying as this happens most when you have been using Boolean operations to try to avoid problems with edge-wobble and venetian-blind, so by trying to avoid one problem that XWA creates (which the same model would not suffer from when rendered in a 3D modelling package) XWA managed to create a new one. One thing I would say is that 3DS MAX (at least) does not shade across vertices in separate meshes and so even if you apply a very strong smooth modifier to "preview" this problem you might not see all of it. If you use the collapse tool on a copy of your model to combine the meshes together and then se the weld tool to squidge coincident vertices together you will be able to see on this copy any extra shading this creates. You can then make sure that where meshes having coincident vertices causes extra shading that these meshes use different smooth groups. There are two possible solutions to the problem. The first solution is to give in and simplify the model so that you do not have as many coplanar faces and thus minimise the number of edges along which XWA could create the extra shading. This does mean that if you keep the details rather than removing them that the OPT will suffer from venetian-blind and edge-wobble. The second solution is to split meshes so faces that
you do not want the joins between smoothed/shaded across
are in different meshes. Select groups of faces in your
3D modelling package and try detaching them to see how
this affects the shading and eventually you hopefully
will have split the mesh so that the excess shading has
vanished. hangar entry/exit problem with mothership not in CRS slot For some reason XWA seems to have a problem judging the position of the players craft compared with whatever hangar OPT it is using if the players mothership is not installed in either of the two Calamari Cruiser slots. Although the game will pick up correctly on the fact that the player craft is by the hangar on whatever ship has been set as the mothership when the player enters the hangar they will find their end position being in parking in empty space and the various hangar camera positions also being incorrect. This does seem to be a peculiarity of what shipslot the mothership is installed in as if the same OPT which has been giving this problem in a non-CRS slot is installed instead into one of the CRS slots then the player will stop in the correct position. It is not a flaw with custom-OPTs or installing ships in slots which are not used by default as TG OPTs in TG slots behave in the same manner in both not working in their normal slot and working if installed into a CRS slot. 99.99km separation in Skirmishes When using custom OPTs the skirmish editor can get confused about how much clearance the various ships need to avoid collisions and decide to play it safe to the extent of separating them by what is displayed as 99.99km. This is a little annoying as although the skirmish editor is rather limited you do sometimes just want to have a quick fight and to involve custom OPTs. A partial solution seems to be juggling the order in which the Flight Groups are arranged in the skirmish editor and trying to sandwich custom ships between standard XWA ships. A more reliable solution would be to build up a little library of mission files created by the skirmish editor for TG opts and to edit these to change ship types to use the custom OPTs, save as temp.tie, and then make temp.tie read-only so the skirmish editor cannot overwrite it. Remember though that the player craft in the skirmish you use to launch this seems to need to be the same as the player craft in the mission file or a new skirmish is created (though temp.tie is not overwritten). Problems with Dual-Warhead launchers This was something that I discovered when I created the T-42 and only applies to if the craft is being used in a mission where the player launches from a hangar and the player tries to change his warhead loadout. XWA seems to change the wrong set of warheads and then to forget that the craft has dual-launchers. This is not a problem with custom OPTs as even the Skipray and the Missile Boat do not work properly in this respect. The Skipray works as badly as a craft with dual
launchers installed in a custom slot. The dual-warhead craft work fine in skirmishes and it is easy enough to just not give the option to change the warheads in a custom mission so this is not a huge problem. Turrets on a custom OPT firing backwards Credit for finding a solution to this problem goes to Marcos Edson. If XWA is determined to turn the turret 180 degrees away from the craft that is being firing at and then have the hardpoint on the muzzle of the turret guns fire backwards at approximately 45 degrees elevation then this is almost certainly down to the way the meshes axises are set up. From looking at the TG Gun Platform Marcos has said that it seems that the important thing is that the green axis should point in the same direction as the barrels of the turret guns. So if this is not true then all you need to do (I think) is edit the X/Y/Z translation boxes in OPTech so that the green axis points in the right direction. Excessive Engine Wash The strength of the engine wash is calculated according to the length of the mesh which has been defined as a engine. For this reason if you have an engine mesh which is a long pod or nacelle as well as the actual engine nozzle then your ship can have a disproportionately strong engine wash. This is something that was mentioned to me with V.2 of the MC-75 as people found it annoying to lose so much shield strength to the engine wash rather than the more acceptable reason of being shot. This is something to bear in mind when choosing what meshes to split from what and which meshes to combine. Meshes wobbling about Some shipslots have meshes in the OPT set to rotate or otherwise be animated, for example the dome of an R2 unit rotating back and forth, and so any OPT installed in that slot will have the mesh at the same position in the list of meshes being animated in this way. The only way as far as I know to get around this is to have the mesh at that position be either one for which this behaviour would be appropriate or to make the mesh one which is hidden and so cannot be seen to be wobbling. Strange multi-coloured textures in XWA This is generally down to the texture being set to have too great a colour depth. As your 3D modelling package can almost certainly display a texture with more than 256 colours and so can OPTech the texture will look normal in these packages. However when the OPT is created and viewed in XWA this same texture will appear multi-coloured with lots of dots of different colours (which can sometimes make quite an attractive pattern). The solution is simply to reduce the colour depth of the texture down to 256 colours and save as OPT again in OPTech to make an OPT using this modified texture. XWA crashes when the OPT is shot This often happens when one or more meshes within the OPT are too high in facecount and the recommended solution is to split the meshes. The first time this happened for me was with the Modified Action Transport when I added the low-detail versions to the OPT. From that I found that in a test reducing the facecount of the midsection mesh to 930 (from 967) allowed me to add the low-detail version (for the actual OPT I split the lower portion off as a separate hangar mesh). This also occurred with the Dominator Interdictor where I not only had a problem with XWA crashing after the low-detail versions were added when meshes were shot but also found that some meshes were causing this even before they had a low-detail version added. So it can be adding the low-detail version that tips the balance or it can be encountered before this is done. Multiple copies of a Texture (or Textures) in the Transparency / Self-Illumination list in OPTech I have found that when exporting as a 3DS and converting to OPZ I can have textures listed more than once in the OPTech Transparency / Self-Illumination and have found that the cause (or at least one cause) is where I have set up different parts of a mesh with different submaterials but have then decided to use the same multi-part texture on all these parts. Since this same texture is being referenced by different materials it seems to be listed the multiple times. This is not a major problem as only one copy of the texture is saved to the OPT file (checked by converting the OPT back into a 3DS) but it is simple to solve, all you have to do is select all the faces using the submaterials that are sharing the same texture and apply the same single submaterial to them all. The faces will all turn the same colour but since the definition of what part of the texture to use is in the mesh rather than the material editor settings this will make no difference to how they look textured. You can then edit the list of submaterials in the material to only have the ones used. Briefing Icons If you are using a custom ship then unless your new ship looks enough like one of the defaults for that briefing icon to be used then you will need to modify the briefing icon files to include this ship. This is thankfully not a very complicated process. The first thing I would recommend is to back up the six files containing the icons (all bar stars.cbm) which are in ...\xwa\frontres\mapicons. Next you can either use AceDXF to convert the custom OPT to a DXF to be imported into your 3D modelling package, use OPT3DS to convert the custom OPT to a 3D Studio file to be imported into your 3D modelling package, or if it is your own model simply load it in. The model will need to be a nice plain shade of grey so if you have a textured model (from the latter two options) then assign a plain grey material to it. Now render the model in this shade of grey making sure to have a black background and that all of the model is showing up with the lighting you have set up, nothing should be lost in shadow but at the same time the render should not be too washed out either. Rendering a 50*37 picture will match the size of most of the TG ship-icons but if you have a large starship you may wish to follow TGs example and make the icon larger as well. If you are doing more than one custom ship then repeat the process until all your little pictures are complete. Do any brightness/contrast adjustment or applying of filters required to make the picture(s) look nice and then load licon.bmp which contains the grey versions of the ship icons. Copy the picture(s) into this, keeping them nicely in line with the other ships. There is room for nine or ten (getting a bit close to the DS-II icon) on the same row as the Zero-Gs and possibly another fourteen if you start a new row so there is plenty of room. Next you might as well take the simple option and rather than pasting your picture(s) into the other files you can simply change the colour balance on licon.bmp and tint the grey to red, green, purple, blue, and yellow. You will need to be careful not to lose any details in over-brightening the picture by changing the colour balance through increasing one colour value too much instead of decreasing the other two. Save these bitmap files with the appropriate names into ...\xwa\frontres\mapicons so that when XWA starts it will convert these *.bmps into *.cbms (remember to delete the old cbms). The final thing to do is to run MapIcon (included with DATech) to alter shiplist.txt the simple way. Click both the Open LICON and Open SHIPLIST buttons and scroll down in both windows so you can see your new icons and the entry for the ship in the text file. Select the ship-entry and then the bounding box button without the 4-headed arrow. Draw a bounding box around your ship-icon (you may want to use the zoom Palpatrick has kindly included) and once you are satisfied then click the apply button and the icon-coordinates will be written to your shiplist.txt file. Skirmish Picture/Hull Icon/Map Icon I find these easiest to do using DATech as it has the Preview window to provide numerical values and it is what I am used to. Both the Hull Icon and the Map Icon can be made in a similar way to the Briefing Icon as they should also be plain grey but the Skirmish editor picture is considerably larger and should be of a textured model, either an in-game shot or a render of a 3DS. Remember that the skirmish-mode pictures are square shaped so try to get a nice angle that is roughly isometric and so will fill the available space (and fit with TGs pictures). For the hull icon you will need a 32*32*256(greyscale) bitmap, for the map icon a 16*16*256(greyscale) bitmap, while the skirmish-mode picture is 180*180*256 with pixel 0,0 being set to the background colour. All craft can have a skirmish-mode picture and a map-icon but only a limited number of slots can have a hull icon assigned so any fighter you want to be flyable with its own hull icon should be installed in one of those. To install your picture/icon fire up DATech and click the Preview button on the tool bar to find your ship and the numeric value for it. Next either open an existing custom DAT file or create one. Click the Import BMP button and select the bitmap to import, DATech will check the size and colour depth and the picture will appear. Change the value for the picture to the correct one for your ship (you can go back and change this later by selecting the "slot" and pressing F2) and then click the Add button The picture should be appended to the end of the DAT file for use by XWA. If you have created a new DAT file you will need to click the save button on the resdata.txt window so that the list of DAT files is updated. The preview box should show the pictures you wish (if it doesn't then double check the numeric values for transpositions or putting zeros in the wrong place (20100 rather than 20010 for instance)) and if the preview box does then so should XWA. Important: Remember that if you use MXvTED to install your ships characteristics then it appears that if MXvTED creates a species number over 232 (by appending information to the end of the file) that you will not get a numeric value for the skirmish picture displayed and so will be unable to do this. Section Links: DATech |