Coding

Btw if solar has not internal hp

[destroy_hp_attachment] at_t = 0.100000 hardpoint = random fate = debris

Works fine too 🙂

The jumpholes are the only things we’ve added into the mod at this point. Eagle Utopia has had them for years but I don’t know what they did about the paths.

EU had added jumpholes to added clone systems. The JHs were placed well out of the ‘normal’ locations an unmodded player would be expected to fly for this reason.

Other than an unmodded player crashing when coming within 5k of one of these JHs while it was being used, they’ve had no ill effects. In fact, as long as no one was using the JHs, they could fly right up to them with no CTDs. The moment the hole was activated however, they would crash.

wondering if they’re related to a player running a mod with flhook installed. Such as the client mod for procyon.

Problem is that those only affect the debris created after the CollisionGroups are destroyed. These debris are always created at 0,0,0 on the root and tend to fly in odd patterns, which doesn’t look good at all when you have debris over 2k long.

The hard part is making the debris that spawn directly from the fuse look good.

Alright, thanks again to all who posted. Everything above is working very nicely so far.

@Xarian_Prime The Starport PM system seems to be buggered (keep saying it can’t connect to the server, but as you can see the forums work fine), so I sent an email.

Why docking ring, not station?

If you know German, a good tutorial will be this:
http://www.sturmspitze.de/mod_fl_tut_waffen.html

Cool, thanks.

I have some beam weapons i gave to my space creature faction in my mod. Similar to what Anubis made actually which was very nice btw but mine are green and yellow.

Regarding the lag they cause, easily solved for the npc’s at least, short rates of fire over short distances, none of this dying 10k away rubbish lol

OK, the inertia is one of the keys, it should be 10%-20% of the drag values or it will cause nodding or spinning.

The other values that I have not played with enough to draw conclusions, are the inertia values in the .sur file - I only learned of their existence from Dev’s sursplicer, in which he calls the 3 values on the 3rd line of the input ini file “inertia X, Y and Z”.

Now he may be wrong, but if he is right then changing these by large amounts should cause visible changes in the performance.

I have no time at the moment to do this investigaton, even though it should take only a couple of days in total to test several huge ship sizes and refine the formula.

Remember we will always have some limitation with this problem because FL had no large ships that could be flown, so the dynamics were not finalised to suit larger ships.

It may end up a case of living with it as it is now. But it may be conclusive too. Try the investgation of the sur inertias.

There is one more thing that affects the way masses rebound after colliding - constants.ini:-

[PhySysConsts]
MATERIAL_FRICTION = 0.100000
MATERIAL_ELASTICITY = 0.900000

I’ve done this for NU years ago, but thx for the info 😄

Im talking about vis_beam type effects. They crash FL when the light animation is longer than the lifetime of the bullet or when the bullet hits something before the light anim has done playing.

factionsets.ini is not used (I deleted it for JFLP). If you really aren’t going to use engine_good.ini, you could delete it and its line from freelancer.ini (I left it in since most mods use it, as Ozed indicates).

Heyup.

Well here’s the little info that I know…

Simply…
The name of the sur part is the same as the cmp group that it relates to, so for each part being checked for hits or collision, FL looks for the same name in the sur file. If it is even slightly different, then the sur part will not be matched to the cmp group and there will be no hit or collision detected on that part of the ship.

In more detail…
You will see in a standard .cmp file that the groups are listed in the \Cmpnd node as Root (the main ship group, the one at the top of the Groups list in Milkshape when you export a model) and then a series of one or more Part_shipname_shippart_lod1 formatted entries. Each of these nodes in turn contains the name of the corresponding cmp group that it is indexing - in this case shipname_shippart_lod1.

In the sur file for the same ship, the corresponding sur part is also named shipname_shippart_lod1 but actually using the CRC (Cyclic Redundancy Check) character of shipname_shippart_lod1. If you use FLModel Tool to open the sur file and cmp file, some sur parts are recognised by FLModel tool so you will see the “English” name (because the author worked them out for us), but if it is not recognised then the name will appear as the hex CRC character of the name instead. This code can be easily found by putting the cmp group name (shipname_shippart_lod1) through CRC Tool or one of our other CRC/hash generator utilities, and you can then look for that hex code in the sur file in FLModel Tool.

Note that in the cmp files, the decoded signed CRC character is used, so it can be a negative decimal value! However in the sur files, the hex CRC character is used. Why should DA have set standards, eh?

Example:

The Borderworld Fighter (Dagger) has 7 cmp groups:-
Open the file DATA\SHIPS\BORDER_WORLD\BW_FIGHTER\bw_fighter.cmp in UTF editor then open the \Cmpnd node and you will see all the parts of the model are listed there:-

Root
Part_bw_baydoor02_lod1
Part_bw_baydoor01_lod1
Part_bw_eng01_lod1
Part_bw_port_wing01_lod1
Part_bw_star_wing01_lod1
Each of these nodes is an index into the .cmp file itself, it contains the real name of the cmp group, and the name of the corresponding node that contains the pointers to the model mesh for that group.

When you open one of the nodes, e.g. Part_bw_port_wing01_lod1 you will see a node named Object name. This node contains the name “bw_port_wing01_lod1”. This is the name of the cmp group.

When you open the ship’s sur file in FLModel Tool, and scroll down through it, you will find a mesh named TriangleID : 0xFE3AEE4E - “bw_port_wing01_lod1”.

Hey - Presto!! You can now see the connection that FL is looking for.

NOTE - when you make your own ship and give the groups names, remember that the cmp exporter will automatically place the “_lod1” suffix after each group name, except for the top group, which will be renamed “Root”. This “_lod1” suffix is needed in the .cmp file as you have seen, to match the name in the sur file. If you are going to make your own stitched sur using Sur-Splicer, then if you remember to add “_lod1” to each sur part name before you export them one by one, then you do not need to import the cons_fix data into your new .cmp after that, since this is all that the cons_fix import does.

Back to the cmp file for a little more info…

The node below “Object name” is “File name”, and that contains the name “bw_port_wing01_lod1020911030723.3db”.

This is the name of the node in this cmp file that contains the pointers to the model mesh for that part. You will find this node further down in the cmp file. The pointer to the model mesh is contained in that node in the \MultiLevel\Level0\VMeshPart\VMeshRef node. The second Integer value contained in the VMeshRef node in the case of the bw_fighter is 196713753 - this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod0-112.vms”.

At the top of the cmp file you will find a node named “VMeshLibrary”. Under this node you will find three nodes, named data.ships.border_world.bw_fighter.bw_fighter.lod0-112.vms, data.ships.border_world.bw_fighter.bw_fighter.lod1-112.vms, and data.ships.border_world.bw_fighter.bw_fighter.lod2-112.vms.

Each of these nodes contains a node named “VMeshData” - this is where the model mesh is stored.

The “lod0”,“lod1” and “lod2” in the names mean “Level of Detail” - 0, 1 and 2.

The “lod0” node contains the model mesh for Level0, which is the fully-detailed model that you see from your ship when you are close to the ship.

The “lod1” node contains a less-detailed model mesh of the same ship.

And the “lod2” node contains an even-less-detailed model mesh than the “lod1” node of the same ship.

This is because the model contains one fully-detailed model for close-up viewing, and two more less-detailed, lower “Level of Detail” meshes that are Switched to as the distance of the ship from your viewpoint increases when you are playing the game and looking at the ship.

The defaults for those distances are defined in the Switch node for that part, in this case 0, 100, 1000, 1000000. These values mean that the Level0 pointer set to the model meshes is used from distance 0 to 99 metres, the Level1 pointer set is used from 100 metres to 999 metres, the Level2 model is used from 1000 metres to 999999 metres, and the ship disappears from view completely at 1000000 metres.

But these default values are overridden by those defined in the LODranges = line in the [Ship] section for that ship in the DATA\SHIPS\shiparch.ini if they exist, and in this case in standard FL they are “LODranges = 0, 75, 125, 1000”.

To continue a little further…

Under the bw_port_wing01_lod1020911030723.3db node in the \MultiLevel\Level1\VMeshPart\VMeshRef node, the second Integer value is -423074755 - this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod1-112.vms”.

And under the bw_port_wing01_lod1020911030723.3db node in the \MultiLevel\Level2\VMeshPart\VMeshRef node, the second Integer value is -107778942 - and this is the decoded signed CRC of “data.ships.border_world.bw_fighter.bw_fighter.lod2-112.vms”.

In fact all of the part nodes contain the nodes \MultiLevel\Level0\VMeshPart\VMeshRef, \MultiLevel\Level1\VMeshPart\VMeshRef and \MultiLevel\Level2\VMeshPart\VMeshRef.

So this is where FL finds where the model mesh is kept for each Level of Detail.

In the case of break-off groups, those group meshes are replaced with the “damage cap” model meshes when they are blown off the ship. Those groups are defined in the shiparch.ini file under the section headings [CollisionGroup] just below the [Ship] section of the ship they refer to, together with their hit points and the name of the damage cap mesh that will be used. In the case of the bw_fighter, there are two wing damage caps (damaged wing stub model meshes) which are ew_dmg_portwing01_cap and ew_dmg_starwing01_cap. These are defined in shiparch.ini in [Simple] sections, as follows:-

**[Simple]
nickname = ew_dmg_portwing01_cap
DA_archetype = SHIPS\border_world\bw_elite\bw_dmg_port_wing01.3db
material_library = SHIPS\border_world\bw_ships.mat
mass = 5
LODranges = 0, 100, 1000

[Simple]
nickname = ew_dmg_starwing01_cap
DA_archetype = SHIPS\border_world\bw_elite\bw_dmg_star_wing01.3db
material_library = SHIPS\border_world\bw_ships.mat
mass = 5
LODranges = 0, 100, 1000**

So the Dagger (bw_fighter) is using the wing stub model meshes from the Stiletto (bw_elite) when its wings are damaged. In the Stiletto’s folder, SHIPS\BORDER_WORLD\BW_ELITE, you will find the two stub meshes bw_dmg_port_wing01.3db and bw_dmg_star_wing01.3db, and each one has its own .sur file with the same name.

Well, I can’t go on more as I don’t know enough about the other pointers in the “MultiLevel\Level0”, “MultiLevel\Level1” and “MultiLevel\Level2” nodes to explain which part of the relevant model mesh they point to for drawing each model group. But I have a feeling someone else has explained those in some detail somewhere?

Sorry for the long-winded story and for jumping around within the .cmp file and between sur file and cmp file, and if I have made any mistakes please let me know to correct this post for “post-erity”. 😄

8-)

Ouch!

I know what you went through! :-?

U can also try to attach your effect to a custom engine as flame or trail fx.

This would be a very nice feature to have, I have a ton of info cards that need repair and it would be nice simply to set the ids_info to 1 and it generate it’s own like the weps do.

As was pointed out in another thread, the size of the zone does influence the distance that the center of the zone can be from a base and still give a mission. For a zone size of 10000, the center of the vignette must be within 34000 m (34km) from a base to give a mission; any further, and it won’t even be considered (unless a tradelane is involved…). Doubling the size to 20000 makes the limit 44000m (the formula is simply (vignette zone size + 24000)). adoxa found an offset that can change the 24000, too, which I’ve done. So it does affect something.

MK

Wolfie wrote:
So did anything here help? Looks pretty good already.

oh my goodness… you mean the code looks good, and with my modesty I thought you react to the picture I post…
and so I start talk about the Starspheres…
oh, there is no way out…
you have to think, I am fishing for compliments…
no, please, oh, there is no way out…
:oops:

Small Town Lem

I think this tut is meaning.
understand encounters