CMP Import/export dll

Has anyone else noticed that the CMPImporter imports rotated hardpoints in the wrong direction, i.e. rotated left instead of right (looking down at the hardpoint, on the Y axis), so that hardpoints turned to the right 90 degrees are imported turned to the left (-90 degrees), and vice-versa?

And the CMPExporter converts a hardpoint 90 degrees rotation to the right (on the Y axis, looking down) to -180, -180, -90 when read in HardCMP, and 90 degrees to the left becomes -180, -180, 90? They both end up correctly oriented, but…??

And often, hardpoints don’t show up in HardCMP until we re-enter the orientation values.

So what this means is that we have to fix the hardpoint orientations using HardCMP (or whatever you prefer) after every export.

??

Dunno for import, still just creating new.
But have question considering hardpoints, that now rly hard goes on my nerves.

Problem: Fully equiped Eagle (4x10 class & 2x9 class) when is sold/buyed (switched with) my new ship, the 9 class weapons are in class 10 slots! User must unmount them and mount class 10 and class 9 weapons on right slots.

Before when ship was fully hardpointed with HARD CMP and HpWeapon01, HpWeapon02, … was inserted in number order it was good.
Now when its created with MilkShape I have this behaviour. I also deleted HPs in HARD CMP and placed new like before and still doesn’t helps.

Hardpoints are part of same wings, same side, same spot, and called same name (port/starboard wings).

Check it out!

Shiparch.ini part is same considering
hp_type = hp_gun_special_10, HpWeapon01, …
.
.
entries.

How to fix this?

Very strange.

Check in shiparch.ini that class 10 is top, then class 9, then class 8 etc.

I can’t see how it can be MilkShape or the exporter, because only the shiparch.ini class entries can affect this I think?

Also check in weapon_equip.ini that the weapons really are class 10?

And check the ship package in goods.ini in case the same weapons are being sold with the ship as default, and mounted on the wrong hardpoints?

As u can see, this only happens when from Eagle u switch to 3MAJ ship!

1. case - WRONG Eagle to 3MAJ (their own .cmp files)
2. case - GOOD 3MAJ to Sabre (their own .cmp files)
3. case - GOOD Sabre to Eagle (Eagle used 3MAJ.cmp renamed to cv_vheavy_fighter.cmp)
4. case - GOOD Eagle to 3MAJ (3MAJ used Eagle.cmp renamed to 3MAJ-VHF.cmp)

3MAJ shiparch entry + 3MAJ.cmp not work!
3MAJ shiparch entry + Eagle.cmp works!
Eagle shiparch entry + 3MAJ.cmp works!

Shiparch.ini

Goods.ini is without weapons!

P.S. This worked before when ship was still a single part!

Here is 3MAJ multipart CMP

I couldn’t see anything obviously wrong using HardCMP and UTF Editor.

But - OK, you have given me a clue - when the ship was exported as a single group, every mesh (MilkShape group) of the ship is named “Root”.

So every hardpoint is then related to Root and is “easy” to find because in “laymans terms” it is just "root\HpWeapon01 etc. to the FL engine (maybe guys who know the detail can explain better?)

I have a feeling that it may be caused by the ship name starting with a number, “3MAJ” and this may be causing conflict in the FL engine…

No standard ship name starts with any number.

And no standard ship name or folder has a hyphen (-) in it, they have underscores (_).

These things are normally done for a reason, soif it is not because of the “3” then it is possible the hyphen is causing a break when it is used by the FL engine.

So, since you have struggled for a very long time, please rename the ship to something like the standard format, without spaces, hyphens or numbers, and export a new.cmp, .mat, .3db, and .sur, (and cockpit.ini if you named it 3MAJ-VHF.ini) and fix the path and file names in the shiparch.ini, (loadout.ini?), goods.ini, market_ships.ini files and any other file where it’s used, such as the faction_prop.ini, mshipprops.ini, npcships.ini?

If you have given your ship a name, like “HyperDragon” for example, then I use the same name for the folder, so it becomes something like DATA\SHIPS\MyShips\HyperDragon\HyperDragon.cmp

Notice that I don’t use underscores either, I join the name parts instead, to be “more sure”!

Sorry it’s not a conclusive answer.

Let us know how you get on?

That was a problem - you spot it! Tnx.
To answer a question - asked here - NO LIMITS !
So than, was no need to rename them (every gun has own group).

So the problem was the hyphen (-) in the name?

And starting with “3” is OK, then?

Nope! The name of the ship never changed.
Its the name of the groups that has number in it (I think).
Lead by rule of unique names I did like that from start.
Name is 3MAJ-VHF
Root part is 3MAJ_VHF

Still I dont think its a smart idea to name them like I did so avoid that.

When ship was made with 15 groups (version 2) it acted perfectly and sur was valid and tight (almost got screw heads in it). The name of parts was named with number and only problem that existed is that weapon class change at dealer and rotating parts where moved in CMP from their location.

Version 3
Close to limit!
80 parts!
With hitbox parts like v2 used
I got this behaviour.

To explain! All the Rev parts are possible to rotate and all parts are attached to each other like chain.

Names? Again I think its not smart to do like I did but once it worked, why would not work again.
The adoxa’s XML project is also confused and spits this code:

 <vmeshlibrary><_maj-vhf.lod0-112.vms name="3maj-vhf.lod0-112.vms" include="3MAJ-VHF_cmp\lod0-112.vms.xml"/></vmeshlibrary> 

```But does his job!
Also example for one of the animation that stretched my nerves was head part. In start it was neck-head-mouth conection (3MAJ_neck 3MAJ_head and 3MAJ_mouth).
This dont work! ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/wha.gif)
After renaming this to 3MAJ_head1 3MAJ_head2 and 3MAJ_head3 the animation worked perfectly. ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/huh.gif)

Same was with tail. It has 31 part and all was named by numbers exceeding from 1 but last part I named just 3MAJ_tail with no any number and made it part of last that it needs to be connected. FAIL! ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/dummer.gif) Putting a next number in name it got connected. ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/thumbsup.gif)
So that its for u to know - place numbers if u want to connect something to animate. ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/cool.gif)

The problem I facing now is sur that seems only Root recognize and just one part of it. Still investigating why? ![](http://i557.photobucket.com/albums/ss15/3MAJ/XsmileysX/sos.gif)
But as a problem of losing part that has animation - all parts stop to animate too - I will be satisfied to all parts be Root and have right collision damage.
But that is a story for different thread.

OK so I didn’t solve it, but it made you think to add numbers to your connected parts, and that works now, right?

Technically group names need the numbers, just its maybe not smart to start with them!
For some reason now SUR file fails to work.
Still investigating!

I seem to be having the same problem that StarTrader reported earlier with the plugins not showing up in ms3d v1.8.4. Anyone have any suggestions?

I’m afraid I still haven’t solved that on my desktop, Jimbo.

My laptop is still working with the plugins.

Things like this really make me angry with Windows!

Have you tried using 1.8.5 beta?

Version 2 is available here: http://www.chumba.ch/chumbalum-soft//files/ms3d185beta2.zip

jimbo32 wrote:
I seem to be having the same problem that StarTrader reported earlier with the plugins not showing up in ms3d v1.8.4. Anyone have any suggestions?

Nope, but I am still encountering that problem on my 1.8.4, even after removing my 2.7 and 0.2 import/export…

Fus

Sorry to grave dig, but was there a fix to the problems this had? i.e. missing letters from the nodes and such?

sumanuti wrote:
The adoxa’s XML project is also confused and spits this code:

 <vmeshlibrary><_maj-vhf.lod0-112.vms name="3maj-vhf.lod0-112.vms" include="3MAJ-VHF_cmp\lod0-112.vms.xml"/></vmeshlibrary> 

I thought that was too much data, so moved it into a separate file (check Include Files to actually generate them).

Re: plugins not showing up

Perhaps you are missing mfc100.dll and/or msvcr100.dll. They’re probably installed from other software, so search your drive(s) and copy them to MilkShape.

Uh, i downloaded two .dll from in here to overwrite my old ones because i was having problems exporting a turret correctly from milkshape to a CMP, i’d follow all the steps but it would only show the barrel of the turret not th base.

but with the new .dll i dont get the same box that comes up with the options back to front and the scale slide bar with the group number option at the bottom…

it brings up a small box within it showing a kind of heirarchy like the UTF editor would do. and its totally confusing, how do i know what does what in here? is there any tutorials on how to use it?

adoxa wrote:

sumanuti wrote:
The adoxa’s XML project is also confused and spits this code:

 <vmeshlibrary><_maj-vhf.lod0-112.vms name="3maj-vhf.lod0-112.vms" include="3MAJ-VHF_cmp\lod0-112.vms.xml"/></vmeshlibrary> 

I thought that was too much data, so moved it into a separate file (check Include Files to actually generate them).

Re: plugins not showing up

Perhaps you are missing mfc100.dll and/or msvcr100.dll. They’re probably installed from other software, so search your drive(s) and copy them to MilkShape.

Now I made confusion, sorry.
<_maj-vhf.lod0-112.vms name="…
  î Here the project doesn’t expect I might put a number, but that is irrelevant, cose import/export works correctly.

Now I made confusion, sorry.
<_maj-vhf.lod0-112.vms name="…
  î Here the project doesn’t expect I might put a number, but that is irrelevant, cose import/export works correctly.

Ah, I see! The XML spec prevents tags starting with digits, so invalid characters are converted to underscore and the name element is added to store the original value.

Anyone know the max vertices* the output can do via “makewire” feature?

limits
one of the solutions