Bug or Feature

We could search in SVN logs.
There ya go. I just want to make sure we have defined a way to do this right before it gets done. If you wanna do it, I won't stop you BUT, I really think we should hold off on committing it. Stability is ALL I really care about until after release at the moment.
 
There ya go. I just want to make sure we have defined a way to do this right before it gets done. If you wanna do it, I won't stop you BUT, I really think we should hold off on committing it. Stability is ALL I really care about until after release at the moment.
Spoiler :

Dwm 2019-07-16 19-01-09-36.png


Here is list of files, that had same name and location, I let Windows to rename them on conflict.
 
  • Like
Reactions: Anq
Great, I'll look into each one in case you need help identifying the right one.

I've used bold green text to mark the correct fpk file in each case.

ancient_24.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\features\ancient forest\ancient_24.dds
They are identical, same alpha, no mipmap on either, same compression.
babirusa_adult_f.dds in Units1.fpk and Units2.fpk
\art\units\animals\babirusa\babirusa_adult_f.dds
To me the one in Units2.fpk looks way better on the 3d model than the other one does.
Looked in SVN log, the one in Units2.fpk is supposed to be an improvement over the one in Units1.fpk.
see rev 7994 by aztur.​

camel.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\resources\camel\camel.dds
They are identical, no alpha or mipmap on either, same compression.​

camel.nif in Terrain.fpk and Terrain1.fpk
\art\terrain\resources\camel\camel.nif
The one in Terrain.fpk is animated, and was added as an improvement by DH in rev. 10120.​

camel1.dds in Terrain1.fpk is unused by the game and can be deleted.

crater.nif in Terrain.fpk and Terrain1.fpk
\art\terrain\features\crater\crater.nif
The one in Terrain.fpk is the latest version, I made it so I should know.​

diplomat.nif in C2C1.fpk and Units2.fpk
\art\units\early_diplomat\diplomat.nif
Really hard to say for sure... Both seems to reference their textures wrong...
I'll attach a version that should be correct.
glypto.dds in Units1.fpk and Units2.fpk
\art\units\animals\glypto\glypto.dds
Very similar, only difference is that they are compressed differently.
The one in Units1.fpk is supposed to have fixed an issue with the other one.
see rev. 8328 by aztur​

wolfmaned__adult.dds in Units1.fpk and Units2.fpk
\art\units\animals\manedwolf\wolfmaned__adult.dds
The one in Units2.fpk is obviously a fix to the one in Units1.fpk
SVN log tells the same story.
see rev 7994 by aztur.​

mountmine.kfm in Terrain.kfm and Terrain1.kfm
\art\terrain\improvements\mountmine\mountmine.kfm
The one in Terrain.kfm is a fix to an animation bug present in the other one
I made it so I should know.​

plantation_industrial.nif in C2C1.fpk and Structures.fpk
\art\structures\improvements\plantation\plantation_anglo\plantation_industrial.nif
The one in C2C1.fpk is a fix to the chimneysmoke error that has bothered SO so very long
I've made this fix two times already because it got packed wrong last time we had a release.
Let's not make me fix this particular problem a third time please. ^^​

possum_adult_f.dds in Units1.fpk and Units2.fpk
\art\units\animals\possum\possum_adult_f.dds
The one in Units2.fpk is a fix to the one in Units1.fpk
see rev 7994 by aztur.​

hippopotamuspygmy_adult_f.dds in Units1.fpk and Units2.fpk
\art\units\animals\pygmyhippo\hippopotamuspygmy_adult_f.dds
Very similar, only difference is that they are compressed differently.
The one in Units1.fpk is supposed to have fixed an issue with the other one.
see rev. 8327 by aztur​

allrivers.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\routes\rivers\allrivers.dds
The one in Terrain.fpk is an improvement to the other one.
I made it so I should know.​

allriversnormal.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\routes\rivers\allriversnormal.dds
The one in Terrain.fpk is made specifically for the new allrivers.dds.
I made it so I should know.​

canyons.tga in Terrain.fpk and Terrain1.fpk
\art\terrain\routes\rivers\canyons.tga
The one in Terrain.fpk is an improvement to the other one.
I made it so I should know.​

This entire folder (\art\textures) is unused by the game and should be removed from C2C1.fpk
It's an unused duplication of the \art\terrain\textures folder.​

plainsdetail.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\plainsdetail.dds
This is the one that triggered this entire endeavour.
The one in Terrain.fpk is superior.​

spaceblend.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\spaceblend.dds
They are identical, same alpha, no mipmap on either, same compression.​

spacedetail.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\spacedetail.dds
The one in Terrain.fpk is the correct one, but it is unnecessary high res to be 100% pure black for all pixels...
I'll attach an optimized version for it.​

swampblend.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\swampblend.dds
They are identical, same alpha, no mipmap on either, same compression.​

swampdetail.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\swampdetail.dds
They are identical, same alpha, no mipmap on either, same compression.​

swampgrids.dds in C2C1.fpk and Terrain.fpk
\art\terrain\textures\swampgrids.dds
They are identical, same alpha, no mipmap on either, same compression.​

trees_1024.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\features\treeevergreen\trees_1024.dds
I reduced the resolution of these textures without any visible degradation in-game.
My SVN log says that I saved 5 MB by doing it to all these trees textures.​

trees_1024_2.dds
in Terrain.fpk and Terrain1.fpk
\art\terrain\features\treeevergreen\trees_1024_2.dds
Same.​
trees_1024.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\features\treeevergreen1\trees_1024.dds
Same.​
trees_1024.dds in Terrain.fpk and Terrain1.fpk
\art\terrain\features\treeleafy\trees_1024.dds
Same.​

tribalvillage.dds in C2C1.fpk and Structures.fpk
\art\structures\improvements\tribalvillage\tribalvillage.dds
TB changed the goody hut roof to make it easier to see.​

WombatCommon_Adult_F.dds in Units1.fpk and Units2.fpk
\art\units\animals\wombat\WombatCommon_Adult_F.dds
The one in Units2.fpk is a fix to the one in Units1.fpk according to SVN log.
see rev. 7994 by aztur.​

wombatteeth.dds in Units1.fpk and Units2.fpk
\art\units\animals\wombat\wombatteeth.dds
They are identical.​

I've used bold green text to mark the correct fpk file in each case.
I'll compile the rest of the list in this post so come back here and look when needed.
 

Attachments

Last edited:
Yeah ,where in worldbuilder ?
I didn`t find it,sorry for my stupidness...

Edit: Nevermind ,i find it !! :-)
 
Last edited:
I collected all duplicated (same name and path but different FPKs) files and placed them in art folder/subfolders where they reside in FPK.
I renamed them - added names of FPKs where they reside.

As for deleting files I bet there is many files, that could be safely deleted.
 

Attachments

Last edited:
As for deleting files I bet there is many files, that could be safely deleted.
Probably but Sparth did a lot of deletions and a lot of them proved to not be as safe as hoped. There's a lot of calls that can't be easily seen in the XML as well (from within animation files).
 
Probably but Sparth did a lot of deletions and a lot of them proved to not be as safe as hoped. There's a lot of calls that can't be easily seen in the XML as well (from within animation files).
Ah so KMF files may need that KM/NIF/DDS file, that seems to be unreferenced by xml.
Can't be those files "decompiled", so they would show up, when you search for file being referenced anywhere?

It seems like this can be useful too.
 
@Thunderbrd so correct files should be put as loose files in art folder for now?

Those files exist in two fpks at once, so removing from one shouldn't have any effect on stability.
 
@Thunderbrd so correct files should be put as loose files in art folder for now?

Those files exist in two fpks at once, so removing from one shouldn't have any effect on stability.
Sigh... no... just repack the fpks and get it done if we're completely sure.
 
Ah so KMF files may need that KM/NIF/DDS file, that seems to be unreferenced by xml.
Can't be those files "decompiled", so they would show up, when you search for file being referenced anywhere?

It seems like this can be useful too.
I'm going to let someone else field this. I'm not terribly familiar with the animation stuff yet.
 
Ok, the list I started on above is now complete.

I suggest that we merge Terrain and Terrain1 into one fpk
And that we merge Unit1 and Unit2 into one FPK.​

They won't become too big because of it. They would still be smaller than units_sparth.fpk which is 276 MB
This should help avoid future packing problems like this a bit.
 
Ah so KMF files may need that KM/NIF/DDS file, that seems to be unreferenced by xml.
KFM files ties kf files to a specific nif file.
So KFM only reference one nif file and a collection of kf files.
These are usually all in the same folder in all cases for C2C, although I think the kfm file might support relative paths (Not sure).

Nif files however can reference multiple dds file and even use relative paths to reference dds files that is not in the same folder as the nif file.
We could trim the FPK's quite a lot by utilizing relative paths to textures that are shared among multiple nif models, sparth and I have done this a little in the past.
Currently a lot of textures have been duplicated to be in the same folder of all the nif models that needs it.

When you search for a specific dds file by name you will need to include binary files in your search to be able to see if it is referenced within a nif file (even find it if the nif file is within a fpk file) which cannot be read as a text file.

Some dds files are actually referenced only from python code, the same could be true for dll code although I haven't seen this personally.
There are even a few examples of the exe referencing dds files... So, yeah it's not always a simple matter to decide if a file is unused or not.
 
Last edited:
Ok, the list I started on above is now complete.

I suggest that we merge Terrain and Terrain1 into one fpk
And that we merge Unit1 and Unit2 into one FPK.​

They won't become too big because of it. They would still be smaller than units_sparth.fpk which is 276 MB
This should help avoid future packing problems like this a bit.
Merged those two FPKs into one.
I moved Terrain folder to Terrain from C2C1 FPK so terrain stuff is together.
Similarly I moved Structures folder to Structures from C2C1 FPK, so this stuff is together too.

Other than that I removed useless pictures and text files (TXT and JPG).
 
After should be sufficient in this case. I can follow the math with this. I'm not saying it's necessarily a bad effect for design but I want to see how it's happening and be sure that Glorious is in-fact the culprit.
I have not updated to this thing where "Glorious" is and I have seen the problem, just saying.
Doesn't that method require that we know which look is the one the designer was going for?
No. Or it shouldn't as the FPK are just a set of compressed file of the actual art folder.
 
I have not updated to this thing where "Glorious" is and I have seen the problem, just saying.
I'm not saying it's a problem - I think I'd like this to be the consequence of negative free specialists since these kinds of free specialists don't mean extra population so much as that population doing more, like working second jobs and having such enhanced efficiency and efficacy that they represent the work of more people, and thus the inverse should be the penalty of a citizen's worth of labor. I just want to ensure this is the reason it's happening because we've had negative free specialists being possible from education penalties for a while and I haven't seen this before. You saying you've experienced it does suggest it may have been happening all along and I just didn't realize it because it only ever really countered other sources of free specialists and I've not seen a truly negative total situation.

No. Or it shouldn't as the FPK are just a set of compressed file of the actual art folder.
Yeah but he's talking about getting rid of the same file in 2 different FPKs and therefore one won't further override the other once loaded - one of the two is the one intended, where they are different but same-named and file-pathed anyhow, and we need to determine which of the two is the one intended.
 
'm not saying it's a problem - I think I'd like this to be the consequence of negative free specialists since these kinds of free specialists don't mean extra population so much as that population doing more, like working second jobs and having such enhanced efficiency and efficacy that they represent the work of more people, and thus the inverse should be the penalty of a citizen's worth of labor. I just want to ensure this is the reason it's happening because we've had negative free specialists being possible from education penalties for a while and I haven't seen this before. You saying you've experienced it does suggest it may have been happening all along and I just didn't realize it because it only ever really countered other sources of free specialists and I've not seen a truly negative total situation.
Yep, it's because of the total -1 Free Specialists. I think this is an appropriate game reaction to that negative amount.
 
I'm committing now those changes to FPKs - sourceforge is slow with max upload speed of 90 kbytes/second.

In morning (I'm in Europe) there is less traffic in Sourceforge too.
 
Yep, it's because of the total -1 Free Specialists. I think this is an appropriate game reaction to that negative amount.
On side note only other thing using <iFreeSpecialist>-1 are your education pseudobuildings.
Those with this tag are unlocked at Sedentary/Medieval/Industrial and so on Lifestyle Tags.

Probably this was what @Dancing Hoskuld noticed - he let city slip into second level of negative education.
He could been playing with Complex Traits without Developing Traits or something like that - some traits may be present in leaders.
 
Last edited:
Back
Top Bottom