Getting Civ 4 Units into Civ 5 - Full Conversion

[GeoStelar]

Hate to digress but I have a quick question.

I'm having some trouble with viewing units on Nexus. I've got to the point where I'm able to load the game. So I'm able to have to the option to view the units, but when i actually click "Unit Viewer", a popup emerges saying "Unknown argument type in message SetWindow", then I receive "Unknown argument type in message ND" like five times.

I followed all the directions for setting up SDK for windows 8.1 as shown in this thread.

And I'm also using the Nexus Viewer from the old SDK.

I'm a bit stumped, so any help will be much appreciated!

 

[Ekmek]

honestly, I never view it in the sdk. I get the same problems. I just suck it down and go in game.

 

[Wodhann]

I have the same problem with the sdk viewer. Which is annoying. I don't think anyone around here knows why that happens.

Ah, your trying to export a multi-mesh CIV4 unit. That's why we went to BR2 method.

Wolfdog or wodhann may know better. But I think what you can do now is go back to blender and export as a BR2. Then have in nexusbuddy go to advanced and overwrite all meshes with your new BR2.

FBX distorts multiple meshes but BR2 doesn't. That *should* fix it. The overwrite BR2 method is seen in other tutorials like deliverator's wonder one.

Yeah if you're just replacing the meshes you export as br2 and overwrite the original .gr2, and if you're using custom animation you export as both fbx and br2 then overwrite the fbx meshes with the br2 ones. I haven't tried custom animation yet though.

 

[Nutty]

And I'm also using the Nexus Viewer from the old SDK.

You'll get those messages when Nexus is confused because of a version mismatch. You need to launch the old Nexus directly from Nexus.exe, not from the SDK launcher [and the Registry entry needs to be pointed to the correct Viewer.exe].

 

[Prairial]

I've rewritten the meshes by .br2, and it seems reset the materials associated to the meshes like this:

and the model likes this:

but after I set the meshes' materials, it still dosen't work well, no matter which material is associated to the head or some parts else.

 

[Wolfdog]

I've rewritten the meshes by .br2, and it seems reset the materials associated to the meshes like this:

and the model likes this:

but after I set the meshes' materials, it still dosen't work well, no matter which material is associated to the head or some parts else.

I notice some of your meshes have only 1 vertex group associated with it. I have had problems with this in the past where it does not apply a skin. As soon as it has 2 or more vertex groups in the mesh it worked. I would try merging the meshes that use the same .dds.

 

[Deliverator]

I notice some of your meshes have only 1 vertex group associated with it. I have had problems with this in the past where it does not apply a skin. As soon as it has 2 or more vertex groups in the mesh it worked. I would try merging the meshes that use the same .dds.

As well as trying that, bear in mind that the Z axis is Up in Blender, whereas the Granny .gr2 format has the Y axis as up. This means that depending what you are doing, you may need to rotate your objects in Blender on their backs so that the Y axis is up. The reason I don't do that in this tutorial is because I have a fix that rotates each animations at the skeleton root, so the original model can remain with the Z axis Up.

 

[Prairial]

I notice some of your meshes have only 1 vertex group associated with it. I have had problems with this in the past where it does not apply a skin. As soon as it has 2 or more vertex groups in the mesh it worked. I would try merging the meshes that use the same .dds.

Thanke you! By joining all the meshes shared the same .dds file it really works, and the animation can imported in the same way.

 

[Civitar]

I'm having a weird issue when I try to convert civ4 units as per this tutorial. When I import a NIF without animations I get no issues, but after exporting the updated NIF nothing appears in NifSkope and when I import the NIF with an animation nothing happens. I've updated my NIFScripts to 2.5.9 but the same thing keeps happening. The most frustrating thing is that I've done this successfully before, it's how I did the Kraken. But now...
Also, the updated NIF looks fine in Granny Viewer without animations after FBX and BR2 exports.

 

[Nomad or What]

Deliverator, I have been trying to convert units from Civ IV to Civ V since 2012, was met with failure and walked away for months only to return and fail again. That is no longer the case! Thank you and all of the other "fanatics" for your dedication to get this right; there are a lot of modders that truly appreciate it and I am one of them.

I just converted your Civ IV scorpion unit successfully (discussion thread here)! And rigging meshes to existing bones and animations is now a snap thanks to NexusBuddy and Blender tools!

I hope that in some small way I can contribute, so I would like to share some of the lessons learned while trying to convert the animations for the scorpion unit:

1) The objects imported from the original .nif file were so small in scale that they did not appear in Nexus or in-game after the conversion, even though seemingly appearing fine in Granny. I didn't realize this until I saw a teeny pink blip in Nexus while moving the cursor around in frustration. I should have realized it earlier because there was no grid while displaying the unit in the Granny Viewer. I had to scale the unit 200x larger than its original size. Unfortunately, after doing so the animations no longer worked and creating a new clean.nif file after re-scaling caused the imported animations to be deformed. So, I had to use the original clean.nif file, import each animation, scale it 200x and then export to .fbx. This was a bit tedious, but successful.

EDIT: I was having problems with the second issue (below) because I was not saving the animation files using the "Save Animation" button. This is what was causing the corruption because the animation was saved as a full (anim + mesh) file for each animation. Consequently it seems to appear fine in game but creates a pink image in Nexus and a static extra image in the Granny Viewer. Lesson learned!

Spoiler :

2) I noticed that many of my animations were corrupt; sometimes they would be correct, many times not. In the tutorial you had mentioned to export the primary file to both .fbx and .nb2, open the .fbx in NexusBuddy and then overwrite the mesh(es) with the .nb2 file. What was not explicitly mentioned was that the animation files also have a tendency to corrupt. To correct this I performed the same procedure for each animation file: I opened the animation .fbx file and the overwrote the meshes with the original .nb2 file. That worked like a charm and they came out perfectly every time.

Some of the above may have been mentioned before and perhaps I missed it. Nevertheless, a little redundancy doesn't hurt if it saves someone else from hours of frustration.

Now, off to make some more units! Happy modding all!

 

[Nomad or What]

I am trying to import Deliverator's Sandworm by doing a full conversion but I am encountering a very weird issue: the unit appears in-between two hex tiles in a random location on the map. It does this for all units generated, both mine and barbarian units - so they are literally stacked on top of the other. The icons move around and display nothing at all, but in the location where the unit is generated it displays whatever action you are performing. It will not, however, disappear after it dies:

Can anyone explain why this is happening?

Here is what I have done to troubleshoot so far:
1) Double-checked syntax in my .fxsxml and .xml files
2) Ensured that all files are VFS=true and that the two .xml files perform UpdateDatabase when OnModActivated
3) All animations and unit appear and perform perfectly in Granny
4) Everything looks fine in Nexus
5) Re-converted the unit a second time in the event the .gr2 file was corrupt - same result
6) Re-scaled the unit 10x in Blender to increase the size to be equivalent to a Civ V unit .blend template (most Civ IV units import into Blender at a much smaller scale than Civ V counterparts)
7) Cleared my Civ V cache and the Steam appdata cache

Nothing works. I have attached the Modfiles and the source files if anyone is interested in having a look at it.

So for now, I am back to

I need to go find something easier to convert for a while. Hopefully it will play nice....

EDIT:
One of the .kf files didn't contain an animation and I had accidentally saved it as a full mesh instead. This is what likely caused the above issue where all units were "stuck" in one location. However, now I have a completely different problem - and a problem that seems to be recurring often from many Civ IV conversion units. The image produces numerous stray mesh vectors in-game although it appears beautifully in Nexus and Granny:

Hopefully the cause of this can be identified and this unit will be ready to go!
:END EDIT

 

[Civitar]

In case it helps anyone (I've seen some people have trouble with nexus unit viewer), you don't view units through there, but you use asset viewer to open the fxsxml and then click the green folder icon to get 3d view.

 

[Nomad or What]

Another import with unknown bone mapping issues, this time a centaur. What I have done thus far:

1. Prepped the .nif in Nifskope (Spells | Batch | Update All Tangent Spaces + Spells | Optimize | Remove Bogus Nodes)
2. Imported into Blender and assigned all objects to a single mesh (shield and sword had no vertex groups and used the same .dds file so this was a simple Ctrl+J operation)
3. "Cleaned" the file and exported to .nif, .fbx, and .br2 with no errors (steps 3-6 of this tutorial)
4. Imported .kf animations and exported to .fbx for each
5. NexusBuddy .fbx conversion to .gr2 (overwrite mesh with .br2 and save animation for the animations)
6. Viewed mesh with animations in Granny - looked perfect!
7. Wrote .fxsxml file for the unit
8. Opened in Nexus and got this:

9. Created the mod with ModBuddy to test it in-game which, predictably, looked like this:

10. Cried

Awww, poor baby! What do we do when we fall off the horse?

a. Sorry Maury, I'm not a gymnast.
b. Beat it until it's dead. Stupid horse!
c. It's not a horse it's a centaur. Try again!

Not being too bright I chose answer c. (b. was the correct answer, as explained below...)

So, to troubleshoot the issue I decided to look at the "offending" parts of our object. I noticed that the right forearm and left hand & forearm were the parts of the object that skewed back to the scene root.

What to do? HAHA!!! Cut off his arms! Voila, no mesh problems!

Well that was fun, but it doesn't really help much, does it? Actually, it does help a bit. I didn't delete the skeleton, only the mesh - so the bones are still in the object (though they have no assigned vertices so obviously nothing shows up). That helps me to determine whether the problem is with the bones or the mesh.

To troubleshoot this, I decided to try the following:
1. Import new mesh with different vertex group assignments (I used the Spearman.blend from one of Deliverator's Civ V templates)
2. Paste the mesh into our centaur mesh and join (Ctrl+J) it to the existing mesh
3. Delete the old vertex groups where the mesh had been deleted (e.g., BIP L Forearm)
4. Rename the corresponding new mesh vertex groups (e.g., Base HumanLForearm) to the old vertex groups (e.g., BIP L Forearm). Effectively, we have imported new mesh with new vertex groups and renamed them to match the appropriate bones.
5. Delete the unused new mesh and vertex groups (I only need the arms from our imported mesh)
6. Move the new mesh into place over the bones (well, kinda - no need to be perfect).
7. Export and create the test.gr2 then view in Nexus

This was my result:

Obviously, the mesh or vertex grouping is not causing the problem since it is new. The problem must originate with the bone properties somehow. I don't know if that will help some of the expert modders out there to better isolate the problem with some of the issues we are encountering or not. I hope so.

So, what did we learn?

a. HAHA! No centaur for you!
b. You should have chosen answer b. the last time, because now you are really beating a dead horse!
c. Doggone it, Nomad! Quit wasting my time - I want my freakin' centaur NOW!!!

The answer is: d. Here are the attached files - YOU figure it out!

 

[Ekmek]

Those stray ve4ices would usually mean they were not rigged in civ4 but since these are conversions of working civ4 units my bet is that you are seeing fbx export errors. The fbx export script is really buggy.

 

[Nomad or What]

Those stray ve4ices would usually mean they were not rigged in civ4 but since these are conversions of working civ4 units my bet is that you are seeing fbx export errors. The fbx export script is really buggy.

I truly hope that is the case. I have tried to export to .fbx and .br2 multiple times to the same file and creating .gr2's from them to see if it appears differently or the same. It appears to be consistent.

Wait, what is the definition of insanity again - doing the same thing over and over again and expecting different results?

Anyways, if it is consistently wrong with some units (but not all), then maybe the bug can be tracked down and fixed. I am optimistic.

 

[Shirotora Kenshin]

i had the same problem before....to solve this,i assigned faces to another bones...this was the solution in my case....but it have to be the right bones !

in my case it was only one face,this face was assigned to neck2 bone...

after i removed it from the neck2 bone and assigned it to collarbone Right instead,everything was working fine !!!!

( with face i mean polygon )

hope this will help you a bit to find a solution...

 

[Nomad or What]

i had the same problem before....to solve this,i assigned faces to another bones...this was the solution in my case....but it have to be the right bones !

in my case it was only one face,this face was assigned to neck2 bone...

after i removed it from the neck2 bone and assigned it to collarbone Right instead,everything was working fine !!!!

( with face i mean polygon )

hope this will help you a bit to find a solution...

Thanks lasttry! That is a great idea and one that might work if that particular bone isn't needed for a specific action. In the case of the Centaur, however, shifting the faces (more specifically vertices, faces, and edges) from 'BIP L Forearm' to 'BIP L Hand' and 'BIP L Upperarm' may affect his animation when attacking. However, since they are all dependent bones (Hand dependent on Forearm, Forearm dependent on Upperarm, etc.) then maybe it won't be noticeable. I will definitely give this a try.

It's not a solution per se, but it may be an acceptable workaround

 

[Deliverator]

Thanks lasttry! That is a great idea and one that might work if that particular bone isn't needed for a specific action. In the case of the Centaur, however, shifting the faces (more specifically vertices, faces, and edges) from 'BIP L Forearm' to 'BIP L Hand' and 'BIP L Upperarm' may affect his animation when attacking. However, since they are all dependent bones (Hand dependent on Forearm, Forearm dependent on Upperarm, etc.) then maybe it won't be noticeable. I will definitely give this a try.

It's not a solution per se, but it may be an acceptable workaround

I think the issues must be to do with some particular form of mesh to bone mapping that the engine does like - perhaps when a vertex group has only one or two vertices assigned to a bone or something like that. It's obviously not a general problem and usually if you assign the model to only two bones these issues don't occur. If we can narrow down the scenario that causes these then I'm sure we can come up with a general fix or workaround. It would be useful to look at the simplest model - in terms of number of bones/vertex groups that has this issue to have a better chance of tracking down the cause.

 

[Deliverator]

Wait, what is the definition of insanity again - doing the same thing over and over again and expecting different results?

By that definition the flaky FBX export is insane because it does give different results each time! The BR2 export will give the same result each time given the same input though. Neither of these facts help with this stray vector issue though - something else seems to be going on.

 

[Nomad or What]

I think the issues must be to do with some particular form of mesh to bone mapping that the engine does like - perhaps when a vertex group has only one or two vertices assigned to a bone or something like that. It's obviously not a general problem and usually if you assign the model to only two bones these issues don't occur. If we can narrow down the scenario that causes these then I'm sure we can come up with a general fix or workaround. It would be useful to look at the simplest model - in terms of number of bones/vertex groups that has this issue to have a better chance of tracking down the cause.

I attached the source .blend files for the centaur in my earlier post if you want to view them to test your hypothesis, but I am fairly confident that there were more than 2 vertices attached to the problematic bones in question. There was also overlap, where some vertices belonged to 2 groups - and the distortion seems to begin at exactly those vertices that were assigned to the particular problematic bone(s) and no further.

I tested lasttry's workaroud - with resounding success! It does indeed correct the distortion, but also as I had assumed it affects the animation once the vertices are removed from the problem bone and reassigned to their adjacent bones. For the centaur, there were 3: BIP L Hand, BIP L Forearm, and BIP R Forearm. I reassigned the vertices from BIP R Forearm to both BIP R Hand and BIP R Upperarm, which did not seem to impact the animation dramatically (likely because they are immediately adjacent). For the left arm, however, I had to move both the hand and forearm vertices to BIP L Upperarm, which creates a noticeable difference:

Strike animation BEFORE the vertex group shift

Strike animation AFTER the vertex group shift

Shifting vertices to non-adjacent vertex groups dramatically impacts the animation of the shield, as you would expect. So, at this point I have a lame centaur - which is better than no centaur and better yet a centaur without arms (But beware its vicious headbutt!) .

So kudos to lasttry for his workaround! It doesn't solve our problem but it can at least mitigate it.

Centaur in Nexus after workaround