@ Cold Void: I think the trouble with a 3db exporter might be that different 3db's have additional nodes for different things. For example, the Cockpit also has the camera information in it that other 3db's don't. But a base 3db exporter would be handy (one which merges the texture and mesh files and can have Hardpoints thrown in).
And thanks. I was rather chuffed with the way the bridge turned out.
@Argh: Ok, now've had some sleep (my sleeping patterns are all over the place at the moment), Some of the things that might be worth adding / correcting in the tutorial:
1. I know it is the same as orientating a ship, but it is worth emphasising again here that the model should be orientated the same way as the ship (I can't remember if the tutorial mentioned that or not). A handy tip to knowing if it is orientated correctly is by opening it up in HardCMP. If the cockpit is facing you and the correct way up in HardCMP upon load, it is correctly orientatated. It is also worth noting to model builders about removing facings that are away from the camera (this will both reduce the size of the final file by a little bit and bring the poly count down make a more efficient model inside the game).
2. The first node under which the VMeshData is stored should be renamed to the first group of your CMP with .lod0.vms tagged to the end. For example, if I called the first group isd_bridge, I would rename group1.lod0.vms (as it is in your sample cockpit) to isd_bridge.lod0.vms.
3. Under the the tree of Cmpnd/Root/File Name, you want to change the string (worth emphasising for the less experienced users out there that all variable changes in this process need to be done on string) to the name of your first group with .3db on the end. For example, isd_bridge.3db
4. Your sample cockpit has a load of extra texture references in the Material Library and Texture Library that will only serve to increase the file size and confuse which texture changes to the less experienced. If you want to keep it simple for people with the one texture thing, it might be an idea in your downloadable samples that people use as a base to remove the extra textures from the 3db or give people instructions on how to do it. Otherwise, their 3db is going to much larger than it need be.
5. .tga needs to be added to the name of the texture in the node under the Texture Library. It's pretty obvious to most people, but in the tutorial, it mentions only doing this to the Dt_name string variable.
6. The master node which leads to the VMeshRef needs to be renamed to your first group as well, with .3db placed on the end.
7. It is also worth noting that TGA textures can be used instead of DDS (some people prefer to use TGA's). However, to do so, MIPS needs to be renamed to MIP0.
8. A little extra piece on the tutorial on how to implement it into the mod would not go a miss either. I.e. Place the 3db file somewhere into the cockpits directory and then create (or just copy and paste one of the original) an ini for it (normally with the same name as the cmp with ini on the end instead, doesn't need to be the same name, but it is easier for reference). The code inside the ini will appear as:
[Cockpit
mesh = cockpits\swcockpits\isd_bridge.cmp <---- this needs to be set to look for your cmp file.
int_brightness = 5 <--- not sure how effective changing this number is in smaller cockpits, but it had little effect in internal brightness (which I gather it is reffering to) on my bridge model.
head_turn = 30, 10 <--- I gather this is probably about how much leeway the camera moves when you turn. I'd guess it is related to X and Y co-ordinates, bridge models and restricted view cockpits should probably have a lower values than more open smaller cockpits.
[CockpitCamera
[TurretCamera
tether = 0.000000, 12.970000, 41.888000
yaw_rotate_speed = 3.000000
pitch_rotate_speed = 2.000000
accel_speed = 1
(note the turret camera's speed and tether is controlled via this ini as well). Finally, to include the cockpit on one of the existing ships, this line needs to be found and changed in the shiparch.ini
cockpit = cockpits\civilian\civilian.ini
This needs to be changed for the individual ship that is using the cockpit to point to the location of your custom cockpit (for example, cockpits\swcockpits\isd_bridge.ini as in my bridge design).
I hope all off that is some help. Thanks for the tutorial though, it was much needed. In answer to your other questions:
1) In simple answer, yeah I'd like to know as well lol. You see, Wasabe programmed those but since 1.65's release, Wasabe has been around only sporadically (he also programmed a custom base scene .THN at Cloud City). Myself and Burnout have pretty much taken over the mod for development of 1.66 (Burnout is dealing with the ships and surs and myself is dealing with pretty much everything else). Over this next week I am going to try and crack them myself (as I want to build some custom rooms, including a senate hall for Coruscant) and I need to fix one of the intro THN's that seems to be a little messed up by the changes we made to 1.66 (that scene with the Jedi ship chasing the Slave 1 through an asteroid ice field, I think Burnout's renaming of the ships for easier reference has caused them to drop out of the scene). I will share anything I learn. Wasabe has popped in a few times to the forum and been able to answer any mod related questions Burnout has thrown his way, so I will PM him on our forums and see if he can drop into TLR and share his wisdom with the rest of the modding community as well.
2. The simple answer to the dfm's is that most of it is just texture changes, with only new models being built for props. But there are 9 levels of detail to each texture, but once you know the formula they use, it is easy to suss out. I will write up a tutorial for the Lancers Reactor either tonight or tomorrow. I am pretty sure this is all the original developers of Freeworlds did to create the Storm Troopers etc... as well as being how I made the Twi'lek that is pictured above. From what I have worked out, you are pretty much on the right track as to what the dfm's contain, though I think the actual animations are stored in another file (the fidgets for example) and all the dfm does is tell Freelancer where the animations are applied to the mesh. It would be cool to create custom meshes as well, but it would probably be a lot of work as well considering the about of mesh references in the dfm file.
EDIT: I've now added a tutorial to the tutorial section
here about making custom NPC's.
Edited by - Aldebaran28 on 3/28/2005 2:15:55 AM