Custom Feature Art

You've probably thought of this already, but I'm curious: Does the Tech column in the ArtDefine_Landmarks do anything? Could you grant the user hidden technologies to reveal different layers of blight? If not, could you somehow fake a feature with a resource?

Nutty said:

You've probably thought of this already, but I'm curious: Does the Tech column in the ArtDefine_Landmarks do anything? Could you grant the user hidden technologies to reveal different layers of blight? If not, could you somehow fake a feature with a resource?

Click to expand...

I just ran a quick test and the Tech column doesn't seem to do anything. As far as I can see the art define DB tables are only ever used by the graphics DLL, not the gameplay DLL, so I'm not sure what that could do without some gameplay code to do the actual revealing/yield updating. It's null on all existing ArtDefine_Landmarks entries.

Faking a feature with a resource seems like the most flexible idea given the way features are limited mid-game. The only issue there is that there can only ever be one resource type on a single hex, so the 'feature' would overwrite resources as it spread. That may not necessarily be a problem, it's just a bit unexpected from a gameplay perspective. I'll take a look at this now.

Well, SetResourceType updates graphics just fine. The only issue there is that resources are referenced differently in the UI, as you can see from the tooltip in the screenshot I've attached.

And I've just had an idea. The resource worked just fine with the existing art define tag I'd set up for the feature. What if I add an extra column to the features table that references a corresponding resource to each new feature? Then I could create a new DLL function that forces a graphics (only) update with the corresponding resource type and the graphics engine would update with that, but the actual change will still have been a feature, so all of the UI will update correctly.

Nutty said:

but I'm curious: Does the Tech column in the ArtDefine_Landmarks do anything?

Click to expand...

It does do something, but not in the same way that the Era column does.

If you have two sets of art (old and new) and set the Era column appropriately, as you change into the new era, all the old improvements will visibly upgrade.

If you set a Tech on the new art (and use Era=Any for both of them), you will get the old art before you have that tech and the new art after, but as you acquire the tech all old improvements will not visibly upgrade (although they will on save/load)

I've used it in both my Airfield/Airbase improvement mods

Unfortunately it appears to be yet another "good idea, not fully implemented as it wasn't needed for the core game / scenarios"

Funny that you managed to decompile/recompile NexusBuddy the same week I had a breakthrough on exporting (most) Civ 5 GR2s with both skeletons and meshes.

I don't know if you'd be able to decompile the source for this program. At the moment, it won't export the skeletons for leaderheads although it does report the number of bones in the output. Anyway, join in with the thread above if you can help.

S3rgeus said:

If it's all right with the right people, I'll publish NexusBuddy's source code on the forum here so someone else might pick up developing it further? I'll look into it if I need it for anything else, but I feel I don't know enough about the 3D modelling side of this program to make any very complex additions.

Click to expand...

You should definitely do this. I'm sure Lemmy and CaptainBinky would be fine with it. I'd be interested to have a look at the source.

Deliverator said:

Funny that you managed to decompile/recompile NexusBuddy the same week I had a breakthrough on exporting (most) Civ 5 GR2s with both skeletons and meshes.

I don't know if you'd be able to decompile the source for this program. At the moment, it won't export the skeletons for leaderheads although it does report the number of bones in the output. Anyway, join in with the thread above if you can help.

Click to expand...

I've been following that thread actually, it looks like you're making great progress with getting new types of content into the game! I'll take a look at that program when I get a chance too. Do you know if it was originally written in C#? I'm using a C# decompiler and as far as I know, decompiling C++ (or similar language) programs from binaries doesn't have nearly as effective tools available.

Deliverator said:

You should definitely do this. I'm sure Lemmy and CaptainBinky would be fine with it. I'd be interested to have a look at the source.

Click to expand...

I've attached the source code for NexusBuddy to this post.

S3rgeus said:

Do you know if it was originally written in C#? I'm using a C# decompiler and as far as I know, decompiling C++ (or similar language) programs from binaries doesn't have nearly as effective tools available.

Click to expand...

No idea. It's a mystery utility of unknown origin. It could well be C++.

I've attached the source code for NexusBuddy to this post.

Click to expand...

Awesome, thanks! It's nice to at least have the possibility of changing how it works.

whoward69 said:

It does do something, but not in the same way that the Era column does.

If you have two sets of art (old and new) and set the Era column appropriately, as you change into the new era, all the old improvements will visibly upgrade.

If you set a Tech on the new art (and use Era=Any for both of them), you will get the old art before you have that tech and the new art after, but as you acquire the tech all old improvements will not visibly upgrade (although they will on save/load)

I've used it in both my Airfield/Airbase improvement mods

Unfortunately it appears to be yet another "good idea, not fully implemented as it wasn't needed for the core game / scenarios"

Click to expand...

That makes a lot of sense, I did wonder why there was a tech column in the art define table! And I'm running into plenty of the problems that are of the type you've described, they're just slightly different from what was required in the base game, so getting them to work is nigh on impossible!

Related to my previous idea of 'faking' a resource when a new feature is added, I've had no luck with that one thus far. Resources are handled in an entirely different (and more sensible) way. Unfortunately their sensibility is exactly what prevents me from hijacking the "update resource graphics" logic and just throwing my own numbers at it. Most of my attempts thus far just crash the whole game when activated.

It's so frustrating because it's so close to working! If you just use a resource you can add and remove it all you like and there's no problem, but features are just evil.

Nice work on the NexusBuddy decompile! Which version was it?

the 05 version only handles fbx whereas 01 handles gr2s. I also use their grannymaterial hacker v2 (http://forums.civfanatics.com/downloads.php?do=file&id=20883). That was the only one that let me copy over materials to get a customer leaderhead in. But the material hacker can only use the top mesh AND for leaderskins it only lets you change the sref.dds and not the diff.dds

if you can decompile that one, maybe we can modify it to edit leaderskins and get a model in game. But a related question - the building material got your feature in and some features use leaderskin is it possible that UnitSkin and buildingskin are the only real shaders used?

I think they may have used a separate unit shader to make custom units easier. I recall firaxis saying that graphics like features, tile imps and others on map stuff have to be preloaded... so that may be how its being handled. :hm:

S3rgeus said:

Do you know if it was originally written in C#? I'm using a C# decompiler and as far as I know, decompiling C++ (or similar language) programs from binaries doesn't have nearly as effective tools available.

Click to expand...

From what I tracked down it got its code from that old, old altervista gr2decode which IIRC was C++

Ekmek said:

Nice work on the NexusBuddy decompile! Which version was it?

the 05 version only handles fbx whereas 01 handles gr2s. I also use their grannymaterial hacker v2 (http://forums.civfanatics.com/downloads.php?do=file&id=20883). That was the only one that let me copy over materials to get a customer leaderhead in. But the material hacker can only use the top mesh AND for leaderskins it only lets you change the sref.dds and not the diff.dds

if you can decompile that one, maybe we can modify it to edit leaderskins and get a model in game. But a related question - the building material got your feature in and some features use leaderskin is it possible that UnitSkin and buildingskin are the only real shaders used?

I think they may have used a separate unit shader to make custom units easier. I recall firaxis saying that graphics like features, tile imps and others on map stuff have to be preloaded... so that may be how its being handled. :hm:

Click to expand...

It was this version, the one referenced in Deliverator's unit reskinning tutorial. I also have a newer version downloaded, I can decompile that tomorrow if it's more useful/useful for different stuff from this version.

When I was looking around at the different feature gr2s, I noticed some of them use a shader called "SimpleShader". SimpleShader has several parameter sets related to Leaders which might be useful for you. (In the features those parameter sets were undefined, which caused crashes when trying to access them, but I imagine in the leader gr2s they would be properly defined.)

The structure of NexusBuddy, as I understand it, is there is a C# class corresponding to each shader type. (Eg. there's a class for LandmarkShader) They all inherit from the same base class and all they basically add is ways of accessing parameter sets with different names. I think it should be possible to create a class corresponding to "SimpleShader" if you can work out what the parameters are called. (That's where I got hung up before moving on when I found the building shader worked.)

You'll see in the code I uploaded actually, that I've made a small modification in Form1.cs, the AddMaterialToListbox function. I added a quick loop which dumped parameter info into a txt file for me to read. That should give you an idea of the information I was looking at, though I would recommend removing that code if you plan to use NexusBuddy normally.

And here's the source code for a more recent version of Nexus Buddy. I've lost track of which exact version it is, but this was the most recent one I could find. It's definitely more complex than the one I posted above. It's got Civ-like UI and there are classes for other meshes and materials (including leaders) which weren't in the above one (even if they don't seem to accessible through Nexus Buddy's UI). There's also no debugging code left in here from me.

I haven't made any functional changes, but I did have to make some changes to make the program compile. There was some old syntax style that doesn't seem to be supported in .NET 4 anymore (overriding Finalize for example). The same 'unsafe' function as I discussed in the previous version is in there, again I just commented it out (that doesn't compile for a variety of fun reasons), but it might be worth looking at that function because it seems like it should be important. Unlike in the older version of Nexus Buddy though, the unsafe function wasn't called anywhere.

In both versions I've uploaded, there are Visual Studio solutions included to work on the code, but they included references to the Firaxis DLLs in the Nexus install directory. The project is configured for my machines, so the filepaths probably won't work elsewhere. Visual Studio will complain about every imported type not existing, but if you look at the references list in the project explorer it should have highlighted the Firaxis dlls as it not being able to find them. Just add a reference to wherever they are on your machine and it should all start working again. (You only need to reference the dlls that are listed there as unfound, they're all in the ..\Nexus\x86\ directory.)

I was just revisiting this thread in the hope that something has changed. Some questions:

1. Is the failure-to-update difference really between the original 8 and the newer features, or is it between features that must blend with adjacent plots and those that don't? Many world wonders have to blend with adjacent plots, but not all I think.
2. Something I didn't understand: can the new "blight" feature be turned on and off if it is added as a replacement for one of the original 8 (e.g., fallout) and still has the original Type string and ID?
3. Could the blight graphic be added as an improvement? (Couldn't have another improvement there of course.)
4. In the case of using resource or improvement to modify a plot's appearance, how well can you mask the original plot? For example, could blight (as resource or improvement) totally blacken a whole plot so that it looks like an entirely different plot type? If so then you could achieve something like FFH's blighted areas in the course of the game. (Of course, the edges would be very sharp with no blending if you did this.)
5. Any new ideas/insight from folks working with Nexus Buddy 2?

Pazyryk said:

I was just revisiting this thread in the hope that something has changed. Some questions:

1. Is the failure-to-update difference really between the original 8 and the newer features, or is it between features that must blend with adjacent plots and those that don't? Many world wonders have to blend with adjacent plots, but not all I think.
2. Something I didn't understand: can the new "blight" feature be turned on and off if it is added as a replacement for one of the original 8 (e.g., fallout) and still has the original Type string and ID?
3. Could the blight graphic be added as an improvement? (Couldn't have another improvement there of course.)
4. In the case of using resource or improvement to modify a plot's appearance, how well can you mask the original plot? For example, could blight (as resource or improvement) totally blacken a whole plot so that it looks like an entirely different plot type? If so then you could achieve something like FFH's blighted areas in the course of the game. (Of course, the edges would be very sharp with no blending if you did this.)
5. Any new ideas/insight from folks working with Nexus Buddy 2?

Click to expand...

1. I'm fairly sure it's between the original 8 and any added after that. For example, atolls don't work mid-game (without reloading) and I don't think they affect other tiles.

2. This is the part that makes me think it's hard coded on the graphics DLL side. Changing the entry in the DB doesn't change the graphics used by setFeatureType. Even if you replace forest in the DB with a new entry, when the gDLL gets the number that normally corresponds to forest, it renders a forest. E.g. say 4 is forest (I don't remember if that's correct), and you replace the forest DB entry with Blight. This means that Blight now corresponds to the number 4 in the features enum, Blight has 4 as its DB ID. If you ue plot.setFeatureType(FEATURE_BLIGHT), the strategic view will update correctly and the tooltips will display the name and description for Blight. But the graphics DLL will draw a forest.

At least that's I think it worked, it's been a while since I did these tests.

3. Yes, you could add an improvement with new graphics and that would work fine. As you say, it would mean you can't build other improvements over it and it would be incorrectly identified in the tooltips and such.

4. From some earlier tests, it looks like you can make textures that stretch well beyond the edges of the plot that the actual 'source' is on. Try turning up the scale on some of the existing improvements/resources and see if they can only 'spread' so far beyond the edge of the hex.

5. I haven't had a chance to try out NexusBuddy 2 yet.

S3rgeus said:

4. From some earlier tests, it looks like you can make textures that stretch well beyond the edges of the plot that the actual 'source' is on. Try turning up the scale on some of the existing improvements/resources and see if they can only 'spread' so far beyond the edge of the hex.

Click to expand...

Seems like this could be used to "paint on" a new plot texture with a sort of poor-man's blending to the next plot. You would have 100% opacity over the plot, then fade out in some non-offensive pattern past the hex boundary. So you could make regions something like FFH's hell terrain. You just have to give up either a resource or an improvement on those plots.