Root is the base model that every other part is hung off of, or in a single part model, it is the whole thing. In Milkshape, these are defined as Groups when exporting the model. Root, when dealing with animations, is always stationary.

Yeah I was really looking forward to that Jumpgate And seeing how close it was to finished … even worse daaammmnnniiiiittt
But oh well, if this turns out as we hope, it’s worth it.

You can add in your own entries pretty easy, just do a google search on “graphics card vendor ID” and there are quite a few lists. Here’s the relevant search result on what looks like a decent site: Radeon HD card list

First off; when referencing coordinates, it is always based on Scene coordinates unless specified explicitly within the context.

As for needing more than 1 UTF version and Hex editor… that should no longer be the case. Here is why: one version could edit part names within Fix/Rev/Pris but not each part’s data. The other version could edit the data, but not the names. Neither version interpreted the Header information in anim scripts correctly, because it contains more than one type of data.

With the newest UTF Editor (last I downloaded a…while ago) those problems are all fixed and it can edit all names and data correctly, as well as offering a mini wizard to set up animation (when you edit Rev or Pris data, if I recall). I’m referring to the UTF Ed that can display your model in 3d.
I still don’t think you can introduce new animation scripts within UTF. Gotta drag n drop from other models, then Hex edit Rev/Pris data if you require more parts than it calls for in the original script. Perhaps in one of those threads it was covered, perhaps it was the Animation Showcase thread. Click on the post count by my name and dig through that, a lot of it pertains to either Mesh or Texture animation, and I’m certain that was covered.

As for why you are seeing 8 parts instead of 10; Fix and the two other types of parts are different sizes. Fix doesn’t need rotational information, so its data is shorter by that much.

One ale you might refer to as a starting point might be the nomad large engine (beam section). There is a beam passing through the center of the ship which sounds like what you are looking for. You’d likely need to speed up its rate, and as suggested add a negative scaling to shrink over time, or do it through an opacity / alpha fade.

Syncing the fx length with your ini range stats should look pretty decent.

Come to think of it, most engines have a beam used similarly, they just look like smoke with a fire color applied. They section is straight line, directional, scaled, and has specific length.

Using Valkyrie’s animation might mean your radar dishes are retracted inside the hull of the ship in your second picture. Those wing animations have a stop section, so they play once and then revert to the starting position. I know there are debugging tools out there with the ability to view your game in wireframe mode, just haven’t used / don’t know it personally. Anyhoo, that may be what is occurring. Or a spelling error, etc. Lots can happen and most of it’s hard to find ^.^
For your animation node, you might try the small station, tower section. It is constant rotate.

Oki, this is going to be an ugly picture
but it should hopefully get the essence of the idea across:

• What this shows is the Root as a single face.

• ani_Rot1 is its Child, and the first Rot-ating piece.

• ani_Pris1 that one’s child, and our first Pris (sliding) piece.

Just have your Base’s old Root mesh as ani_Pris1’s child. Then the children of that would be your propellers. Keep also in mind that you can have more Pris and Rot parts in the chain, following the same method.
*Or you could use these 3 pieces as a sort of prefab part to mount whatever solar mesh you wish on it. You would add a Hardpoint on the last triangle, then mount your other mesh via ini loadout. Check the Freeport bases for examples on the hardpoints they use, etc.

Just don’t forget to set up all those Parent -> Child relationships in the Rev and Pris data.
Hopefully the pic makes sense, if not… I can put a little more effort into it ;D
As a last note, you can also have a Fix part as a Child of a moving one, and then mount a moving part off that Fix part. Fix just means it has no movement of its own, but it can inherit movement from its parent. That’s part of why I drew the lighter blue lines to show the Child moves wherever and however the Parent does.

Oh yeah, and the Root is always stationary. It is never included in a Fix, Rev, or Pris anywhere because it is assumed stationary and the part / mesh upon which everything else will be hung. NPC’s always shoot the center of the Root (if I recall correctly). So that’s why I mentioned it, if you want a destructible base / solar / whatever. Otherwise attacking NPC’s will be shooting air and looking a bit schizophrenic.

A few relevant thread links at the bottom of post

Hum, I suppose quite a few people have wondered about the wandering station dilemma. In short, the way bases are done in FL, they must be set in one stationary spot, so the game knows where you will be able to dock and place NPC traffic. With that said, there are still options available to make it appear like it’s moving, via mesh animations. You would go about this by making your Root node the fixed point in space, then setting up entirely transparent faces to act as your movement chain.
So lets say it might look like:

• Root node as a single face

• aniFace_rot1 - a face which would rotate in whatever direction you prefer, on whatever axis you need. Personally, I would make it the length you want the second part to slide along and use it’s dimensions for the distance section of the next pris animation

• aniFace_pris1 - this face will use a Pris node to translate / slide along one axis. It would be the Child node of aniFace_rot1.

• base_model here, as a Child to aniFace_pris1, with other rotating parts of the main model as Children of base_model and so on

Here are some problems you will run into:

• NPCs shoot at the center of the model - for us that is a part / face without a sur and effectively invisible in space

• Only the slowest movement will allow player docking, and I mean seriously slooooow, because player ships briefly stop, then slow down when locked into the docking sequence

• Your rotating station looks rather sweet in the video, but it would be a very short amount of time before every ship captain banded together to place bombs on your station’s engines. Practicality must reign here, nobody will attempt take their own life in their hands to land on a death trap ^.^

• If we ignore the point above, you must use a Jump type docking sphere in the ini code

• You must be certain, as with any multi part model, that your HPs are attached to the proper mesh part.

• Using multiple animation parts means that with a complex model -if you don’t use Max to export the CMP- you may run into the Milkshit CMP exporter’s 18 part limit. That means you’ll need to get funky with Sushi’s multi vmesh splicing method.

If you construct your Rot and Pris pieces / sections with some forethought, you can give the appearance of random movement. Varying the keyframe distance / angle values in the animation script will be your method.

As a side-note, you could in theory make the the whole Root / Rot / Pris contraption, with no SUR file at all, and use it like a pre-fab root for mounting other base parts on. Look through the ini’s for most Freeport types to get an idea how pre-fabs are glued together. Take a look in both their CMPs, and how their HPs are used and referred to in the ini’s. I’m working from memory here, but I think you could actually mount existing base models on this sort of invisible rotating and sliding doohickey.

PS: Constant animations are accomplished via AttachedFX, useable on both Bases and Ships.

These links are discussions had before this latest and greatest MaxCMP exporter. They deal with Milkshape, UTF editor, and a Hex editor.

• Whole process, for ships

• Sort of a short note on it here

• Overly long, but in-depth discussion

• Sushi’s mesh splice thread, again for quick ref

I know Sushi’s thread deals with >20k polygon models, but the method is relevant when trying to go all old-scool with this model if you need to do anything in Milkshape and must export from there.

Not that I’ve ever found. But it should be possible to simulate it using a flip-book style (same as the thread on animated signs, using frame anims, instead of slide). I’d user a tile count of 16 for that to approach looking fluid, but the texture would probably look best at 1024x1024 or above. Each frame should show the rotation progressing, and you can add in whatever blur effect you like
You could conceivably use both mesh and material together, having a single face centered on the propeller (with the mat anim on it) along with the regular rotating prop at a slower speed. It would look more authentic, and have thickness then.
Good luck.

Big bummer news here. Lots of fond memories on this server / mod. Was like a kid in a candy store on my first run through that neat multi-level minefield. The trek to Sol… Druid system at the end of the other minefield… First encounter with a Phantom >< Beautiful X2 ship imports, the dinky little 2k hull zingers that were such a blast to fly in a dog fight (Harrier & Zephyr). Lots of interesting additions to the game I won’t forget any time soon, plus my old buddies from GoM I actually met on Starworlds.

salute Thanks Tekagis for an outstanding run and pretty outstanding staff. And another for the departed.

The 1.8.4 version is referring to Milkshape’s version (and SDK used to compile the plugin). Which means it may not work with an older version of Milkshape. If, however, you are using MS 1.8.4 you might try renaming the old import/exporter dll with a “.bak” extension to see if the newer dll shows up then -ie: perhaps the two versions are conflicting and MS only loads the first one it encounters.

Should probably also post your .ini entries too, the problem may lie there.

I’d recommend checking your flspew (FL’s log file) and looking at the last entries leading up to the crash. There should also be a little tool here in downloads, just a simple VBscript which makes reading flspew a bit more use friendly. The script is editable in Notepad or whatever text editor you are fond of, so you can look within at the path it is using and find flspew to look at raw also. Either way, it’s good to know where that file is, especially for modders introducing new models, as it often shows what part in the model is causing problems, or what texture is missing, etc…

2. How do i also do transparency? i only know that PNG has transparency as part of it?

There are 4 ways to do transparency in FL:

• In the Texture - Opacity built right in, using (TGA) or (DXT Xbits +X alpha). For this just start with your background transparent.

• In the Material :
  [olist]

• Non transparent background TGA / DXT as your Dt node, along with a gray scale Opacity map in an Ot node (Type: DcDtOt)

• Non transparent background TGA / DXT as your Dt node, along with an Oc node adjusting the opacity for the entire texture -0.0 for full see-through, 1.0 for solid as a brick wall.

• Purely a DcOc with Glass in the name -check vanilla LF, HF, VHF models for examples.

For using an opacity map, or creating a Dc/Glass mat, you’ll need a copy of UTF editor -the more current, the better.
Where to look: in the .mat file named like your *shipname, or the material library section within your CMP / 3DB when you choose to include materials directly into the model when exporting.

*many vanilla models use a texture archive approach, referencing textures from one or more common .mat (or .txm for planets etc) files. This can be easy to spot if you have no texture library, and or material library node. Take Liberty ships for example, no mat files in each ship directory, no texture library or material library entries within the ship’s cmp, but in the \SHIPS\LIBERTY\ directory we have li_playerships.mat

Most common mat file entries:
Dc - diffuse color
Dt - diffuse texture
Oc - opacity color (grayscale 0 to 1)
Ot - opacity texture (grayscale texture applied to Dc and or Dt)
Et - emissive texture (glow map for lights and other purtiness)
It’s a good idea to become familiar with all these, just study various vanilla examples.

For DXT conversion you have a few choices; Exporter plugin for whatever image editing prog you use. Or proprietary DXT compressors from nVidia / ATI depending on your gfx card (usually command-line, but can be nice for batches). Check their websites for those specialized tools.

Last Note: When you install Freelancer, all ini files are encoded. To edit these (to say… change a material location for the ship) you must either decode them manually, one by one…
OR have already installed a modder’s copy of them (unofficial patch by Adoxa or EOA). Check the downloads section here, if that doesn’t lead you to it, search Adoxa and I believe he’ll have a link with his website which has tons of FL related tools.

Hammerhead is tops for me; always dug the odd, vertical style.
For pure art, the Osiris or Liberty Dreadnought; both rather byooteeful design and skinning.

Of course I never get tired of just staring at Nomads, purely for the nifty material effects.

Lancer Solurus has a nice long post documenting what each part of the ALE files do / take for a value. Do a google search on his name and “ALE File”, select the link from EOA serious zone.
if I remember, it’ll be in the Emitter section to adjust trail length /size/ frequency/direction.

this package has the ale editor and heaps of other useful stuff:
http://forge.discoveryfluk.com/forge/modding/flmt/

the XML Project also decodes ALEs into XML, and encodes back. it’s here in the downloads section.

If you post a couple renders using a Wire type texture, it’s easier for us to offer suggestions / opinions on where to shave down on faces. Flat areas of course are perfect candidates. Small details can be simulated in texture, rather than geometry, same with certain structures like fencing or masts and towers (like the Eiffel Tower could be done as a near solid box, or basic boxes for each leg and flat polygons for everything in between).
Another good practice; if you smooth, follow with an optimize.
Curved surfaces tend to get out of control quickly, so you’ve got to weigh the importance of said curved area. As you thought with the texture area in the exhaust being covered by effects in normal usage. It’s always nice to have a fully realized design, but performance must play a part in game design at all times. Especially with an engine which is perhaps not cutting edge, and geared towards computer specs in the same range. If all your models have dilly-bobs popping out at every opportunity, then when you have a small squadron of said models show up on your screen, mister computer soils itself. Plus think how things get exponentially worse on a Base design. Add all that together and you may get an unplayable experience, or entirely crash it.
As a player, I dig having a sweet ship design, but if an opponent is flying the same ship and it lags the hell outta me, I’d prefer a less sweet ship design that leaves debris more efficiently.

Most (including me) get a bit put off at the prospect of texturing the model after we’ve just finished making a sweet design. But planning the texture as you construct can really help cut down on face count big-time. It just doesn’t look as super-sweeeet until the materials are applied. But there’s so much fun to be had in the texturing; with glows, opacity, detail, and Bt.

Especially for a first run, that’s a nice polished model, with a nice texture too.

ehm, sorry for rambling on a bit

EDIT: tossed together a couple ideas for taking down the face count a bit. Every little bit helps and adds up:

Adoxa said what shipname.sur is for -collision detection. If you don’t have one for your ship model, nothing will be able to hit you- or whoever is flying the ship with that model.

For your second Q: I believe you’re referring to a damage cap. You don’t need one, unless you get into advanced building where parts of your ship are meant to be destroyed. Just about all the original ships in FL have them, but 90% of modders won’t bother with them.

So all you’ll need is shipname.cmp and shipname.sur for your model to work just fine.

Thank you oh fishy one, looks like this’ll be a great step forward in complex models. Just stumbled on the compiled versions in the downloads section today, pleasant surprise with x64 and 32 bit versions for max 2010 & 2011.

Lets hear it for Milkshape’s exit from the pipeline

Just a quick question… during export I get an ‘Error exporting LOD’ which says:

“The node under your component must specify the lod”

Sooo… my meshes are already grouped as Root, and each part is named
“blah blee_bloo_lod1”
“blah blar_blur_lod1”

amimissingsomething? which node might this refer to?

Might be a good idear to include a sample / template file for easy reference.