Caveman 2 Cosmos (ideas/discussions thread)

Some art files are duplicated on purpose though because it is the same model but linked with different textures and/or different animation files.
Some instances are just two different files with the same name too, where a rename should have been done but weren't.

Just mentioning it.
One needs to look at every duplication pairs on a case by case basis, to figure out if they are really duplicates or if they just appear to be duplicates.
Art that is unused (never referenced by XML or NIF or kf files) can be removed.
Identical art in two locations where two xml entries reference their own version can be optimized by making both reference the same and delete the now un-referenced duplicate.
etc.
I used program to find duplicates, and while there are 25 files with same name and file patch but different FPK, there are tons of files with same name and size scattered in art.

So I guess you can't really merge FPKs without checking files first.
 
Last edited:
If you have a file, say aha.dds, and you have it in the right file location, art/totally/tubular. But you also have the same file at a different file location, you'll get a duplicate but you need to keep it unless you go through and find the xml entries that call for that file in the locations they are both packed in.

If you have that file, aha.dds, and you have it in the file folder art/totally/tubular, then you pack it, then you put another file named the same in the same folder and try to pack it, it's already in the template file folder so on windows it will tell you that you are trying to place a duplicate file in the same location and won't let it happen unless you rename it, at which point, it's not really a duplicate file.

So although you may have duplicates, you have them in different file folder places in the structure. I'm not going to bother to try to audit to find all that but knock yourself out if you want AFTER the release. When you find such carbon copy duplicates, you MUST find ALL xml references to their location and change to the one location you allow to remain.
 
This file is here: Caveman2Cosmos\Assets\Python\BUG\Tabs\BugCreditsOptionsTab.py, so @Thunderbrd can find it and update it.
Last time it was updated in 2014 by you.
I have been looking for it all day! :blush::lol: No wonder I could not find it. Never thought to look in the Python files. That is all "greek" to me anyway.

Does anyone have a list of contributors since 2014? Especially from 2014 and 2015? Let alone 2016 thru 2019?
 
I have been looking for it all day! :blush::lol: No wonder I could not find it. Never thought to look in the Python files. That is all "greek" to me anyway.

Does anyone have a list of contributors since 2014? Especially from 2014 and 2015? Let alone 2016 thru 2019?
I know we can add our latest programmer contributors, @Anq , even a thanks to a few not yet 'on the team' officially, @sorcdk, Jayman (not sure of handle here), maybe look through the SVN thread for mentions. I think Whisperr may be overlooked on that list at the moment. Um... you? Harrier was helping us there for a bit as well and I'm not sure he ever made it. @Snofru for his maps. Some folks like Noriad2 should get a mention if they haven't already.

I'd super appreciate it if you're putting that update together for us!
 
I know we can add our latest programmer contributors, @Anq , even a thanks to a few not yet 'on the team' officially, @sorcdk, Jayman (not sure of handle here), maybe look through the SVN thread for mentions. I think Whisperr may be overlooked on that list at the moment. Um... you? Harrier was helping us there for a bit as well and I'm not sure he ever made it. @Snofru for his maps. Some folks like Noriad2 should get a mention if they haven't already.

I'd super appreciate it if you're putting that update together for us!
In SVN log, I can find that following people contributed since 2014:
AIAndy, alberts2, Anq, aztur, calvitix, Dancing Hoskuld, dsma_bell, faustmouse, Harrier123, hx2762, hydromancerx, JosEPh_II, KaTiON_PT, magillicutty, makotech222, mrazure, pepper2000, praetyre, raledon, raxo2222, sargonthegreat2, strategyonly, Thunderbrd, toffer90, Yudishtira

Some people did few commits since then. Also some of them seems to have different sourceforge and civfanatics nick.

By the way I don't think, that he knows how to edit python files :p
 
Last edited:
With all that art files beeing moved and the fpk's beeing repackaged the frezze should continue for at least 1-2 weeks.

One reason is that Civ4 likes crash alot if there are missing buttons or other problems with the art files.

The other is that we somehow managed to messup every release in the last years because of stupid mistakes lets not do this
again.
 
With all that art files beeing moved and the fpk's beeing repackaged the frezze should continue for at least 1-2 weeks.

One reason is that Civ4 likes crash alot if there are missing buttons or other problems with the art files.

The other is that we somehow managed to messup every release in the last years because of stupid mistakes lets not do this
again.
Buttons, units, buildings and other stuff is rendering correctly.
 
But PPIO is not core so should not be part of any testing. In fact any testing using it should be considered void as far as a release is concerned because of this.
It doesn't matter, that it isn't part of core.

Toffer could have add it to core long time ago, if he wanted.
 
Testing to verify if everything works before a release only makes sense without any modmods being used.

Only testing inside the pedia isn't working either because missing buttons lead to crashes ingame but in the pedia a pink texture is displayed instead and most times the pedia does not crash in these cases.
 
Only testing inside the pedia isn't working either because missing buttons lead to crashes ingame but in the pedia a pink texture is displayed instead and most times the pedia does not crash in these cases.
Yes indeed. This is because it is the exe that is trying to display things not the Python for example if the button is not exactly 64x64 pixels the game will crash when the exe tries to modify it to fit in the little circle on the city bar. That is just one example.
 
Yes indeed. This is because it is the exe that is trying to display things not the Python for example if the button is not exactly 64x64 pixels the game will crash when the exe tries to modify it to fit in the little circle on the city bar. That is just one example.
Indeed, there are many ways to ask the exe to display a texture, some ways are more finicky about the texture specifications than others.
The Pedia use one way to display a button while the city screen build list use another, both ask the exe to display it, though differently so.

Even if there's no pink buttons to be found in the pedia there may still be a button with wrong alpha information or of a resolution size that the exe really don't like in some cases.
 
Revisiting my idea on the other day. Here is the preferred version without explicitly using pointers. (post)

Code:
std::vector<int> m_Y;
const std::vector<int>& CvXInfo::getYArray() const
{
    return m_Y;
}
// to loop
X = GC.getXInfo(eInfo);
const std::vector<int>& vec = X.getYArray();
for (std::vector<int>::const_iterator it = vec.begin(); it != vec.end(); it++)
{ [...]
}

As soon as v39 is released, I can start to improve the data structure of reference info objects. Another idea of mine is to use an int-sized (4 byte) struct instead of pair<int,int> to store key-value pairs, where both the key and the value are 2-byte integers. This will be suitable for modifier k-v pairs as long as the xml-defined value is within the range of -32768 ~ 32767. Even the largest info category, aka BuildingInfos, is using only 10%(6080) of the capacity given by a 2-byte integer (65536). So the upper 16 bits of a enum is always zero, which is wasteful.

Code:
struct InfoValuePair
{
    InfoValuePair(unsigned short info, short value = 0): i(info), v(value) { }
    unsigned short i;
    short v;
    const int info() const { return (int)i; }
    const int value() const { return (int)v; }
    inline bool operator==(const InfoValuePair& rhs) const { return info() == rhs.info(); } // for std::find
    inline bool operator!=(const InfoValuePair& rhs) const { return info() != rhs.info(); }
    inline bool operator< (const InfoValuePair& rhs) const { return info() <  rhs.info(); } // for std::sort
};
Spoiler more code :
Code:
std::vector<InfoValuePair> m_piPrereqNumOfBuildingClass;
int CvBuildingInfo::getPrereqNumOfBuildingClass(int i) const
{
    FAssertMsg(i < GC.getNumBuildingClassInfos(), "Index out of bounds");
    std::vector<InfoValuePair>::const_iterator pResult;
    if ( (pResult = std::find(m_piPrereqNumOfBuildingClass.begin(),m_piPrereqNumOfBuildingClass.end(),i))
            != m_piPrereqNumOfBuildingClass.end() )
    {
        return pResult->value();
    }
    return 0;
}
const std::vector<InfoValuePair>& CvBuildingInfo::getPrereqBuildingClassNumArray() const
{
    return m_piPrereqNumOfBuildingClass;
}
// with some modification to Albert's xml utility functions,
SetOptionalPairVector(m_piPrereqNumOfBuildingClass, L"PrereqBuildingClasses");
// this too.
CopyNonDefaultsFromVector<InfoValuePair>(m_piPrereqNumOfBuildingClass, pClassInfo->getPrereqBuildingClassNumArray());
Modification on @alberts2's functions
Code:
void SetOptionalPairVector(std::vector<InfoValuePair>& aInfos, const wchar_t* szRootTagName)
{
    CvString szTextVal;
    aInfos.clear();
    if (TryMoveToXmlFirstChild(szRootTagName))
    {
        int iNumSibs = GetXmlChildrenNumber();
        aInfos.reserve(iNumSibs);
        if (0 < iNumSibs)
        {
            if (TryMoveToXmlFirstChild())
            {
                for (int j = 0; j < iNumSibs; ++j)
                {
                    if (GetChildXmlVal(szTextVal))
                    {
                        int iType = GetInfoClass(szTextVal);
                        int iModifier;
                        GetNextXmlVal(&iModifier);
                        if (iType != -1 && iModifier != 0)
                        {
                            aInfos.push_back(InfoValuePair(iType, iModifier));
                        }

                        MoveToXmlParent();

                    }

                    if (!TryMoveToXmlNextSibling())
                    {
                        break;
                    }

                }

                MoveToXmlParent();
            }
        }

        MoveToXmlParent();
    }
}
Code:
template<class T>
static void CopyNonDefaultsFromVector(std::vector<T>& target, const std::vector<T>& source)
{
    target.reserve(target.size()+source.size());
    for (std::vector<T>::const_iterator it = source.begin(); it != source.end(); ++it)
    {
        if (*it != (T)-1 && find(target.begin(), target.end(), *it) == target.end())
        {
            target.push_back(*it);
        }
    }

    std::sort(target.begin(), target.end());
}
 
Last edited:
In SVN log, I can find that following people contributed since 2014:
AIAndy, alberts2, Anq, aztur, calvitix, Dancing Hoskuld, dsma_bell, faustmouse, Harrier123, hx2762, hydromancerx, JosEPh_II, KaTiON_PT, magillicutty, makotech222, mrazure, pepper2000, praetyre, raledon, raxo2222, sargonthegreat2, strategyonly, Thunderbrd, toffer90, Yudishtira

Some people did few commits since then. Also some of them seems to have different sourceforge and civfanatics nick.

By the way I don't think, that he knows how to edit python files :p

Correct.

Names already in list are: AIAndy, alberts2, calvitix, Dancing Hoskuld, faustmouse, hydromancerx, mrazure, strategyonly, Thunderbrd,
Yudishtira.

Not in list: Anq, aztur, dsma_bell, Harrier123, hx2762, JosEPh_II, KaTiON_PT, magillicutty, makotech222, pepper2000, praetyre, raledon, raxo2222, sargonthegreat2, toffer90,
 
Revisiting my idea on the other day. Here is the preferred version without explicitly using pointers. (post)

Code:
std::vector<int> m_Y;
const std::vector<int>& CvXInfo::getYArray() const
{
    return m_Y;
}
// to loop
X = CvInternalGlobalContext.getXInfo(eInfo);
const std::vector<int>& vec = X.getYArray();
for (std::vector<int>::const_iterator it = vec.begin(); it != vec.end(); it++)
{ [...]
}

As soon as v39 is released, I can start to improve the data structure of reference info objects. Another idea of mine is to use an int-sized (4 byte) struct instead of pair<int,int> to store key-value pairs, where both the key and the value are 2-byte integers. This will be suitable for modifier k-v pairs as long as the xml-defined value is within the range of -32768 ~ 32767. Even the largest info category, aka BuildingInfos, is using only 10%(6080) of the capacity given by a 2-byte integer (65536). So the upper 16 bits of a enum is always zero, which is wasteful.

Code:
struct InfoValuePair
{
    InfoValuePair(unsigned short info, short value = 0): i(info), v(value) { }
    unsigned short i;
    short v;
    const int info() const { return (int)i; }
    const int value() const { return (int)v; }
    inline bool operator==(const InfoValuePair& rhs) const { return info() == rhs.info(); }
    inline bool operator!=(const InfoValuePair& rhs) const { return info() != rhs.info(); }
    inline bool operator< (const InfoValuePair& rhs) const { return info() < rhs.info(); } // for std::sort
};
Spoiler more code :
Code:
std::vector<InfoValuePair> m_piPrereqNumOfBuildingClass;
int CvBuildingInfo::getPrereqNumOfBuildingClass(int i) const
{
    FAssertMsg(i < GC.getNumBuildingClassInfos(), "Index out of bounds");
    std::vector<InfoValuePair>::const_iterator pResult;
    if ( (pResult = std::find(m_piPrereqNumOfBuildingClass.begin(),m_piPrereqNumOfBuildingClass.end(),i))
            != m_piPrereqNumOfBuildingClass.end() )
    {
        return pResult->value();
    }
    return 0;
}
const std::vector<InfoValuePair>& CvBuildingInfo::getPrereqBuildingClassNumArray() const
{
    return m_piPrereqNumOfBuildingClass;
}
// with some modification to Albert's xml utility functions,
SetOptionalPairVector<InfoValuePair>(m_piPrereqNumOfBuildingClass, L"PrereqBuildingClasses");
// this too.
CopyNonDefaultsFromVector<InfoValuePair>(m_piPrereqNumOfBuildingClass, pClassInfo->getPrereqBuildingClassNumArray());
Modification on @alberts2's functions
Code:
void SetOptionalPairVector(std::vector<InfoValuePair>* aInfos, const wchar_t* szRootTagName)
{
    CvString szTextVal;
    aInfos->clear();
    if (TryMoveToXmlFirstChild(szRootTagName))
    {
        int iNumSibs = GetXmlChildrenNumber();
        aInfos->reserve(iNumSibs);
        if (0 < iNumSibs)
        {
            if (TryMoveToXmlFirstChild())
            {
                for (int j = 0; j < iNumSibs; ++j)
                {
                    if (GetChildXmlVal(szTextVal))
                    {
                        int iType = GetInfoClass(szTextVal);
                        int iModifier;
                        GetNextXmlVal(&iModifier);
                        if (iType != -1 && iModifier != 0)
                        {
                            aInfos->push_back(InfoValuePair(iType, iModifier));
                        }

                        MoveToXmlParent();

                    }

                    if (!TryMoveToXmlNextSibling())
                    {
                        break;
                    }

                }

                MoveToXmlParent();
            }
        }

        MoveToXmlParent();
    }
}
Code:
template<class T>
static void CopyNonDefaultsFromVector(std::vector<T>& target, const std::vector<T>& source)
{
    target.reserve(target.size()+source.size());
    for (std::vector<T>::const_iterator it = source.begin(); it != source.end(); ++it)
    {
        if (*it != (T)-1 && find(target.begin(), target.end(), *it) == target.end())
        {
            target.push_back(*it);
        }
    }

    std::sort(target.begin(), target.end());
}

I'am working an a new dll which will be compiled using the VC2019 compiler. The Plan is to move stuff from CvGameCore into a C2C.dll. The new dll will use a abstract interface.

Please don't change the interface of CvInfo to use anything but POD datatypes. A std::vector isn't a POD type and it would make it impossible to move the CvInfo stuff into this new Dll.
 
I'am working an a new dll which will be compiled using the VC2019 compiler. The Plan is to move stuff from CvGameCore into a C2C.dll. The new dll will use a abstract interface.

Please don't change the interface of CvInfo to use anything but POD datatypes. A std::vector isn't a POD type and it would make it impossible to move the CvInfo stuff into this new Dll.
That is so unfortunate it seems...
How do you iterate through an array with POD? You need to keep separate functions, one for the size, one for the lookup... working with vector is more natural I think.
 
Correct.

Names already in list are: AIAndy, alberts2, calvitix, Dancing Hoskuld, faustmouse, hydromancerx, mrazure, strategyonly, Thunderbrd,
Yudishtira.

Not in list: Anq, aztur, dsma_bell, Harrier123, hx2762, JosEPh_II, KaTiON_PT, magillicutty, makotech222, pepper2000, praetyre, raledon, raxo2222, sargonthegreat2, toffer90,
thx Joe, also make sure u put a little verb next to their names also, meaning what they did with C2C, but not a big line, small please, thx. SO
 
Top Bottom