hmmm... Well the first annoyance is that the AI is using a slaver to defend a city... It shouldn't be doing that it is set not to... the ssecond annoyance is that it still crashes even after the slaver is removed...
hmmmm....
ok so I found some more slavers being used in defence and got rid of them as well and that seems to have fixed it... But why the AI is using them for city defence I don't know... hmmm I wonder if I could add a -100% city defense to them if that would stop the AI
aaaah I may have found the culprit! I somehow left a 25% city defence bonus on it! I have changed it to -100% now. see what that does.
For anyone who wants to see if it helps the issue, add it to k-fallout/assets/xml/units and overwrite the other one
HOPEFULLY this should stop the computer using them defensively, which I think it where the issue lies, because I don't think they work as a defence unit because they are invisible... chip...chip...
Assert Failed
File: CvInfos.cpp
Line: 4821
Expression: iRouteType > -1
Message: Index out of bounds
Assert Failed
File: CvUnit.cpp
Line: 16053
Expression: iOurStrength > 0
Message: Combat strength is expected to be greater than zero
Assert Failed
File: CvUnitAI.cpp
Line: 15623
Expression: iParatrooperCount > 0
Message:
Assert Failed
File: CvCity.cpp
Line: 1257
Expression: GET_PLAYER(getOwnerINLINE()).getFreeCityCommerce((CommerceTypes)iI) >= 0
Message:
Assert Failed
File: CvUnitAI.cpp
Line: 12891
Expression: false
Message:
AI_ejectBestDefender failed
to choose a candidate for
AI_guardCity.
// < JRouteNative Mod Start >
bool CvUnitInfo::getRouteNative(int iRouteType) const
{
FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
FAssertMsg(iRouteType > -1, "Index out of bounds");
return m_pbRouteNative ? m_pbRouteNative[iRouteType] : false;
}
bool CvUnitInfo::getRouteImpassable(int iRouteType) const
{
FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
FAssertMsg(iRouteType > -1, "Index out of bounds");
return m_pbRouteImpassable ? m_pbRouteImpassable[iRouteType] : false;
}
bool CvUnitInfo::getRouteIgnore(int iRouteType) const
{
FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
[COLOR="Red"] FAssertMsg(iRouteType > -1, "Index out of bounds");[/COLOR]
return m_pbRouteIgnore ? m_pbRouteIgnore[iRouteType] : false;
}
int CvUnitInfo::getRouteSubstitute(int iRouteType) const
{
FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
FAssertMsg(iRouteType > -1, "Index out of bounds");
return m_piRouteSubstitute ? m_piRouteSubstitute[iRouteType] : -1;
}
// < JRouteNative Mod End >
iUnitDamage = std::max(1, ((GC.getDefineINT("RANGE_COMBAT_DAMAGE")) * (iOurStrength) / (iTheirStrength)));
iUnitDamage = (iTheirStrength > 0 ? std::max(1, ((GC.getDefineINT("RANGE_COMBAT_DAMAGE")) * (iOurStrength) / (iTheirStrength))) : 0);
Ah ok this makes sense, I think. I think what is happening is that opportunity fire uses ranged strength damage and slavers among others have no ranged strength hence the zero issue, so it wil need some kind of if zero skip function. I don't know how to right that though, maybe I can ask in the SDK forum. Well figured though.
iOurStrength = airCurrCombatStr(pDefender);
FAssertMsg(iOurStrength > 0, "Combat strength is expected to be greater than zero");
iTheirStrength = pDefender->maxCombatStr(pPlot, this);
iTheirStrength = pDefender->maxCombatStr(pPlot, this);
if ( !iTheirStrength ) return;