If disabling the advisers does ge rid of them then it is that that is causing the problems. I am not getting the pop up when I build those units. let me just check that I have updated with the latest of that file and that I am using the latest of the rest.
Ok but it needs to stop trying to call for a null feat definition into the code. It wouldn't be able to get away with that in any mod - I've at least made it possible for us to get through it without crashing but it will cause delay until resolved.
popupInfo.setText(CyTranslator().getText(lUnitCombat[iCombat][1], (pUnit.getNameKey(), pCity.getNameKey(),)))popupInfo.setText(pUnit.getName() + " " + pCity.getName())
Takes less than 10 sec to add in such a code, just that it wasn't crashing anything in BTS
void EventTriggeredData::read(FDataStreamBase* pStream)
{
CvTaggedSaveFormatWrapper& wrapper = CvTaggedSaveFormatWrapper::getSaveFormatWrapper();
wrapper.AttachToStream(pStream);
WRAPPER_READ_OBJECT_START(wrapper);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iId);
[COLOR="Red"][B]WRAPPER_READ(wrapper, "EventTriggeredData",(int*)&m_eTrigger);[/B][/COLOR]
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iTurn);
WRAPPER_READ(wrapper, "EventTriggeredData",(int*)&m_ePlayer);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iCityId);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iPlotX);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iPlotY);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iUnitId);
WRAPPER_READ(wrapper, "EventTriggeredData",(int*)&m_eOtherPlayer);
WRAPPER_READ(wrapper, "EventTriggeredData",&m_iOtherPlayerCityId);
// Expiration was not stored in older saves (which didn;t store expired events for replay)
// so default to false if absent
m_bExpired = false;
WRAPPER_READ(wrapper, "EventTriggeredData",&m_bExpired);
WRAPPER_READ_CLASS_ENUM(wrapper, "EventTriggeredData",REMAPPED_CLASS_TYPE_RELIGIONS,(int*)&m_eReligion);
WRAPPER_READ_CLASS_ENUM(wrapper, "EventTriggeredData",REMAPPED_CLASS_TYPE_CORPORATIONS,(int*)&m_eCorporation);
WRAPPER_READ_CLASS_ENUM(wrapper, "EventTriggeredData",REMAPPED_CLASS_TYPE_BUILDINGS,(int*)&m_eBuilding);
WRAPPER_READ_STRING(wrapper, "EventTriggeredData",m_szText);
WRAPPER_READ_STRING(wrapper, "EventTriggeredData",m_szGlobalText);
WRAPPER_READ_OBJECT_END(wrapper);
}
void EventTriggeredData::write(FDataStreamBase* pStream)
{
CvTaggedSaveFormatWrapper& wrapper = CvTaggedSaveFormatWrapper::getSaveFormatWrapper();
wrapper.AttachToStream(pStream);
WRAPPER_WRITE_OBJECT_START(wrapper);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iId);
[COLOR="Red"][B]WRAPPER_WRITE(wrapper, "EventTriggeredData", m_eTrigger);[/B][/COLOR]
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iTurn);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_ePlayer);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iCityId);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iPlotX);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iPlotY);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iUnitId);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_eOtherPlayer);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_iOtherPlayerCityId);
WRAPPER_WRITE(wrapper, "EventTriggeredData", m_bExpired);
WRAPPER_WRITE_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_RELIGIONS, m_eReligion);
WRAPPER_WRITE_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_CORPORATIONS, m_eCorporation);
WRAPPER_WRITE_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_BUILDINGS, m_eBuilding);
WRAPPER_WRITE_STRING(wrapper, "EventTriggeredData", m_szText);
WRAPPER_WRITE_STRING(wrapper, "EventTriggeredData", m_szGlobalText);
WRAPPER_WRITE_OBJECT_END(wrapper);
}WRAPPER_READ_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_EVENT_TRIGGERS,(int*)&m_eTrigger);WRAPPER_WRITE_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_EVENT_TRIGGERS, m_eTrigger);
Ah but it is the same - any unrecognized value will register as -1 in the dll and in this case that's what's being called by the python so it very likely IS the problem and all we need to do is keep the python from calling any value of -1 (the indexed value of -1 anyhow.)
getUnitCombatType() would return the single value of the unit's primary combat class. If it returns one unrecognized by the python it may well return a -1. Anyhow, none of this should be an issue... Just keeping the call from being able to send a -1 should be enough to fix the whole concern.
My understanding is that what DH is saying went beyond this. That, of course, makes sense what you just said. But I believe he's trying to say that he can't set any AndDependency for the unit CLASS object without it causing a problem. This would mean that if he tried to put a Dependency on both the class and the info objects that was the same and based on a common element (which is the way this really SHOULD be established to do this in the safest manner) that no matter what the load process order, he's going to have a problem. So the REAL issue is, what's making it problematic for him to define an And Dependency for the unit Class at all?
If you're designating the class object as that which the infos object is dependent on, yes, that will quite naturally happen for that reason.
If the info isn't also being dependent on the same object, yes, if the class dissapears out from under the info object it'll cause problems for the info object. That makes sense.
You mean making the AndDependency defined as the class object for the info object and the info object for the class object? Of course that would be a problem!
Might just be a matter of the terminology but I feel it's important to clarify: NO, my fix did NOT CAUSE the popup to happen, it ALLOWED the null reference to pass and thus allowed the popup to take place despite the call returning a false result back to python. I presume that the popup was blank because the return was false and the python had never been prepped for that possibility (aka the popup was already called and the list was being generated for the options the popup would give and one or all of the items on that list included that NO_FEAT call itself so when it returns false, the pop's already manifesting but there's no list to accompany it so it ends up blank.)
We can't hedge against all presumptions firaxis made when developing the code. They appear to have been very clear within their team communications what would be necessary to prepare for (as in what COULD be negative and what could NOT - we've violated many of those presumptions they originally made for example) and coded according to those gamerule assumptions. Those lurk all over the place and in most cases they actually do have a little efficiency factor and built-in error checking factors that we wouldn't want to disable unless it proves that we need to - usually found by a mod doing something that was not planned for like this.
You seem to have discovered what was at the heart of the problem there so good job with that (to both you and platy!) Thanks!I would have done Platyping's change slightly differently so as to use less memory. Instead of making an array with all the unit combat classes in I would have only put in those that we want feats on... this difference would be negligible in most mods but not in C2C
