Giving C2C the bird

[God-Emperor]

I got tired of the hawk, eagle, and Haast's eagle flying at or below treetops (and partly inside peaks) so I made a NIF for it that moves it up some. It looks like this was tried before, probably at least twice, but by applying translations to nodes that are evidently irrelevant to the game engine.

It is not translated up hugely (only about half the wingspan, +88.0 on the Z axis to the SceneRoot node in the NIF) so if you zoom in on the hawk, and possibly the eagle, it may be a smidge below treetop level still since when you zoom in the models are scaled less than the terrain/features. The unit scaling in the unit art info affects the hight adjustment the same as the model size so the hawk flies the lowest. But it is much better than it was. The only real issue is that the Haast's Eagle tends to fly somewhat too high in the civilopedia, since it shifts it up in there too.

Just replace the existing one (since they all use the same one) with this, in Art\Units\Hawk (if you add this folder and put it in there it will override the one in the FPK, which would be the DancingH_0.FPK file).

I also made some slightly modified skins for the hawk, eagle, and Haast's eagle so they do not all look exactly alike, although they are all still very close, if C2C wants them. They are not really based on any specific variety of bird, just made to look a little bit different from each other.

 

[Hydromancerx]

Glad someone got around to doing this. I was always unhappy that they all looked like bald eagles.

 

[God-Emperor]

I should have mentioned that I didn't include the textures in that zip, just the nif.

If you want the textures I can post them. Or maybe you could get someone to re-texture them who actually has the correct software to do a complete job of it - there are some odd things going on, like a brown blotch on one side of the face where some triangle is not using any part of the head texture since it has no matching color area.

This is why they currently look like.

 

[Hydromancerx]

Hmm. That looks kind of weird. I might have to take a look at the texture and see if I can make a better looking one.

Thanks for fixing the animation though.

I don't suppose you know how to fix the Golaiath Airship from the Dieselpunk mod. It seems to fly on the ground rather than the air.

 

[Dancing Hoskuld]

It works well in game. But it is in the units.fpk not mine. It may have been in an earlier version but we removed a number of duplicates. Putting it in a folder Assets/Art/Units/Hawk works and we will get it up on the SVN so it can be put in the correct FPK for next release.

 

[God-Emperor]

But it is in the units.fpk not mine.

Oops. I didn't check the current C2C FPKs. It, along with a bunch of other animals and miscellaneous other units, was in yours in v24 since that is where it is in R2R which is the set I actually extracted it from (since I have all of them unpacked already). But since you mentioned it, I just checked and it is also in the Units FPK in R2R so I've got a duplicate which can't be a good thing.

Guess I need to do some more preparation for a v1 release of R2R, for which I had planned to "sanitize" the FPK files to remove all redundancies and as much unused stuff as I could spend the time checking for. I removed some unused things for v0, but not quite everything for the stuff I cut from the XML even, let along checking for things that were never in use.

 

[Thunderbrd]

Awesome job GE! Mostly just in that this is finally being addressed as its long been a slight nuisance and a pain to try to resolve. So this is VERY helpful! Thank you!

 

[strategyonly]

Guess I need to do some more preparation for a v1 release of R2R, for which I had planned to "sanitize" the FPK files to remove all redundancies and as much unused stuff as I could spend the time checking for. I removed some unused things for v0, but not quite everything for the stuff I cut from the XML even, let along checking for things that were never in use.

Speaking of which, IF and thats a big IF, you can do a separate, listing for units ALSO in current C2C, while you are doing this, and let us know what are duplicates, and or redundancies, would DEFINITELY be appreciate, so we can get rid of the rif raf, thx.

 

[God-Emperor]

I don't suppose you know how to fix the Golaiath Airship from the Dieselpunk mod. It seems to fly on the ground rather than the air.

The issue with that, and the blimp, is that they were originally designed to be air domain units like the BtS Airship unit.

You can see it with the blimp since the barrage balloon uses the exact same model and it is an air unit. The blimp sits on the ground. The barrage balloon flies even if you place it on a plot it can't normally be on (i.e. not a city or fort) in worldbuilder.

For the Goliath it can be fixed in the same way, by moving the model up some in the NIF.

For the blimp it could be done the same way, but it would probably be good to separate the graphics from the barrage balloon so that the blimp can be shifted up without affecting the barrage balloon.

Note that neither the Goliath nor the blimp have any animations specified. I'd guess they were designed to use the animations of some other air unit (first guess would be the Airship), which (as far as I know) doesn't do you any good for land domain units.

 

[Hydromancerx]

@God-Emperor

Well if you can fix it then be my guest.

 

[God-Emperor]

OK. So here are two adjusted NIF files. The height they fly at was selected somewhat arbitrarily - it is somewhere a bit under the length of the unit for each.

zeppelin_long_fins.nif is the Goliath
blimb.nif is the blimp (I have no idea why it is spelled that way)

I expect you can find where the originals are and swap these in, but I would recommend copying the existing blimp folder to a new barrage balloon folder and keeping the existing "blimb.nif" model for that otherwise it will probably be at an unusually high altitude as it flies over a city (and switch its art def to point to the new location, of course).

The Goliath suffers from the same problem the Haast's Eagle does in the 'pedia: it is flying too high to really show up properly in the art pane. In this case it does not appear at all in the model window unless you rotate the view (which only works when graphics are on high) so you might want to reduce the fInterfaceScale in its art def to make it show up there (0.75 might do it, but it still might be too high).

 

[Taxman66]

On the same note is this issue related to the floating peyote?

 

[Dancing Hoskuld]

blimb.nif is the blimp (I have no idea why it is spelled that way)

While I did not name it it is my type of dyslexia b, d, p and q often all look the same to me especially when I am tired.

 

[Hydromancerx]

Better than plimp.nif

 

[Koshling]

On the same note is this issue related to the floating peyote?

No - floating features are a viewport bug, that has not proved resolvable. If you ever see thi happening WITHOUT viewport enabled though please let us know.

 

[Thunderbrd]

No - floating features are a viewport bug, that has not proved resolvable. If you ever see thi happening WITHOUT viewport enabled though please let us know.

Actually, I was thinking... there MAY be something more to what was first discussed here in this thread that explains that effect. He said that only some ways to tweak the Z axis are effective and that there are other ways to attempt to tweak it that are subsequently ignored by the height map interaction with the object. Thus the relationship between the terrain height and the object's defined base is all that is considered and the object is sucked down to be affixed (at its lowest mesh point) to the top of the height map definition, and that effect overrides a floating Z setting.

What it sounds to me might be happening is that the objects like Peyote were made without any attempt to match that overriden Z setting to anything appropriate because, well, it was overriden so did not matter. BUT it sounds as if your viewports change may have 'broken' the height map override for features, allowing that previously defunct Z value to have meaning again.

So perhaps there IS a connection here... God Emperor: can you take a look at the graphics definitions on the Peyote and see if you can play with the Z value settings on that under a Viewports game sample and find a way to lower it back down to the ground? Or do you think my thoughts on this are probably way off track anyhow?

 

[Koshling]

Actually, I was thinking... there MAY be something more to what was first discussed here in this thread that explains that effect. He said that only some ways to tweak the Z axis are effective and that there are other ways to attempt to tweak it that are subsequently ignored by the height map interaction with the object. Thus the relationship between the terrain height and the object's defined base is all that is considered and the object is sucked down to be affixed (at its lowest mesh point) to the top of the height map definition, and that effect overrides a floating Z setting.

What it sounds to me might be happening is that the objects like Peyote were made without any attempt to match that overriden Z setting to anything appropriate because, well, it was overriden so did not matter. BUT it sounds as if your viewports change may have 'broken' the height map override for features, allowing that previously defunct Z value to have meaning again.

So perhaps there IS a connection here... God Emperor: can you take a look at the graphics definitions on the Peyote and see if you can play with the Z value settings on that under a Viewports game sample and find a way to lower it back down to the ground? Or do you think my thoughts on this are probably way off track anyhow?

It's not that Peyote (and other things) per se float with viewports. It's that when you SWITCH the viewport such that the terrain at viewport coordinates X,Y (which has the Peyote or whatever) is a different height to the terrain that previously appeared at that (X,Y) coordinate with the previous viewport, then the game engine seems to retain some memory of the height it thinks that X,Y has even though its been given a totally new terrain and marked as dirty (same as if you'd changed the terrain in Worldbuilder in essence so far as the game engine is concerned)

 

[Dancing Hoskuld]

Actually Peyote is not the best even without viewports where it often looks like it is on a neighbouring plot.

 

[Taxman66]

No - floating features are a viewport bug, that has not proved resolvable. If you ever see thi happening WITHOUT viewport enabled though please let us know.

I'll note that I see them float when I'm not using viewports. I generally don't turn view ports on until I get ships that can navigate open water and reveal significantly more of the map.

 

[JosEPh_II]

The hammers and Anvil for a mine on a hill now float above the worker. The worker was over the hammers before. This was SVN 5515 iirc. I've since updated to 5527 but have not had time today to see if the mine hammers have returned to their original height.

JosEPh