1. The Navmap Background is a piece of art, located in \DATA\INTERFACE\NEURONET\NAVMAP\NEWNAVMAP

It's in a TXM file. Open with UTF Edit.

2. You can currently alter existing SURs by changing their dimensions, via a utility called FLModel Tool, by Anton. The latest Beta can be downloaded from here. Basically... pick a SUR out by previewing them with HardCMP (version 1.0.0.2 can be downloaded here as well)... find a SUR that matches the geometry of your ship and then resize it with FLModel Tool. It's a crude way to make a custom SUR, but it works.

3. You don't need to use multiple LODs (although this is theoretically feasible).

The implementation pipeline is this:

A. Make your model.
B. Create a UV texturemap or maps for it. Models for FL can accept planar, cubical, cylindrical and spherical mapping types.
C. Convert the texturemaps to DDS or TGA (if TGA, then the maps must be flipped vertically before final export).
D. Import the model and textures into Milkshape 3D. Rotate so that -Y is "up"- i.e., it must be upside down, facing backwards.
E. Use the export plugins (found here on TLR) to export the geometry and the textures into a CMP and MAT (or, you can just put the textures into the CMP, but I digress).
F. Resize your exported model to the appropriate FL dimensions using FLModel Tool, if it's too large or too small. FLModel Tool will tell you its XYZ dimensions with good accuracy.
G. Add Hardpoints using HardCMP 1.0.0.2.
H. Find an appropriate SUR, and then resize/distort it with FLModel Tool.
I. Script the ship.
J. Test everything very thoroughly.
K. Cuss a lot, because you messed one of the many steps up.
L. Start from scratch with a better clue and a better model, or fix the one you have started. Hopefully you've saved your work at each step of the process...
M. Successfully implement a new ship!

4. The documentation that came with FLMM does cover implementing names. If you want to see specifics, you should look at an existing mod and steal code from it. I would have to suggest Mephistopheles's Prometheus mod, because it's easy to see what's doing what. Scripting a ship's not very hard, once you understand the INI structure.

5. I do not know of any editors for Random Missions. You can alter their behavior somewhat- this is true. But within pretty rigid limitations, at this time.

Lastly... I'm going to say the same thing I say to everybody who's just getting started. My advice is: take things slowly, read everything that's available here (even though some of it is contradictory or refers to older methods that are less useful than what we're doing these days)... and try something very small and simple before making something huge. You will find that making new content for FL isn't very hard, when you know what you're doing- it's the rest of it that tends to be difficult.

do you mean names as in npc names? if so use GENERATESTRRES and place \n where you want the line break. For non-C programmers that is a newline code.

Waow... that is going to help me much! thx

but a couple of things...

I do need several lods for what I'm planning...
Its no ship mesh I am going to make... its a simple asteroid (although until they figure out that last unknown - I've been following the sur thread - I think I am going to use an existing asteroid)

I want to make a... "special" asteroid field to see if it works.

the mod I have in mind is nothing way too hard... with my current experience in freelancer ini scripting I think it can be pulled off at a resonable timescale.

Again... thx for the many precise... precize... cice... (whatever) answers.

I am going ot keep on asking a little...

as for the several lods howto?

and the navmap... what do I have to look for in the txm file? and if I want to replace something what do I then do?

Edited by - BmB23 on 4/6/2005 12:29:40 PM

prettymap.tga in the txm file. Use UTFedit to export and import a new one (make sure the tga file is not RLE encoded though as FL will crash badly )

As for the LODs... well, basically you're going to have to make each one, export the entire thing as a series of meshes with textures... break it up with MeshConv, and then use UTF Edit to build up an entirely new file structure for the resulting CMP.

I cannot overstate how difficult that is likely to be... but it is possible. The real question is not whether it's possible- it's whether it's a good idea. What are you wanting to do here, exactly? Nobody has bothered with multiple LODs for spacecraft, in large part because there isn't any need. The FL engine will be OK with 15K of asteroid polys on the screen at once.

More than that is probably pushing things, at least for middle-run systems, and 30K or so is likely to choke all but the highest-powered gaming rigs. So, as a practical exercise... even asteroids with 500-1000 polygons would probably be OK, since they don't get drawn until they're fairly close anyhow. Keep in mind that you will never see just one asteroid on the screen at once- you have to manage polycounts with that in mind. Using LODs won't help a great deal with that problem, either, to be perfectly frank, because you're very likely to be within the lowest LOD range of objects often, in that context- or else your lowest LODs will be at such ridiculously short ranges that you'll almost never see them, which kind've reduces your work to an empty exercise.

You can also use CMPExporter to update an existing cmp with a new LOD model. I've no idea how well this works in practice...

Well... I wanna make an asteroid field that can be seen from a large distance...
and upclose I need them to have fairly high poly with fairly high resolution textures...

while at a distance of 200k I need them to be 50-60 polys or so with a crap texture.

If my little experiment will succeed I can post something that will show you what I mean.

But until completely custom .sur's become a reality I think I'll stick with the ingame ones.

Edited by - BmB23 on 4/7/2005 5:42:27 AM