What's that?
Also, I might be on a TV Quiz Show in a few weeks, so I need to study for that, so I might not get much modding done in the next few weeks. However, I managed to add a few new bonuses over the weekend.
CIVILIZATION IV:iNoc
- Thread starter Voyhkah
- Start date
What's that?
Also, I might be on a TV Quiz Show in a few weeks, so I need to study for that, so I might not get much modding done in the next few weeks. However, I managed to add a few new bonuses over the weekend.
I am getting what I now consider to be the weirdest error ever, but in a few days I will, in hindsight, realize was perfectly understandable and I just needed to look carefully at it. Problem is, that hasn't happened yet. Anyone got any ideas?
Spoiler :
God-Emperor
Deity
My first, and so far only, guess is that you are either using a value for something when it wants the address of the value, or you are using an uninitialized pointer (a pointer that has never been set to point to anything), or you have managed to pass the address of a function instead of the results of running the function.
The specific hex value abababff looks intrinsically suspicious. I don't know of anything the compiler uses this specific value for, and a quick Goggling turns up nothing, but it is close to abababab which is used for guard values to mark memory off the ends of an allocated range on the heap.
The specific hex value abababff looks intrinsically suspicious. I don't know of anything the compiler uses this specific value for, and a quick Goggling turns up nothing, but it is close to abababab which is used for guard values to mark memory off the ends of an allocated range on the heap.
I think I got it.
The dll expects a return value for lResult, but...
...
...
(in BugEventManager)
So... The dll method postEvent calls python onEvent which returns the result of a call of handleEvent which has no return.
This is a problem. What makes solving this difficult is that I have no idea how this stuff works and is supposed to work. I don't even know what any of these methods are supposed to do!
Code:
bool CvDllPythonEvents::postEvent(CyArgsList& eventData)
{
eventData.add(GC.getGameINLINE().isDebugMode());
eventData.add(false);
eventData.add(gDLL->altKey());
eventData.add(gDLL->ctrlKey());
eventData.add(gDLL->shiftKey());
eventData.add(gDLL->getChtLvl() > 0);
long lResult = -1;
bool bOK = gDLL->getPythonIFace()->callFunction(PYEventModule, "onEvent", eventData.makeFunctionArgs(), &lResult);
return (bOK && lResult==1);
}The dll expects a return value for lResult, but...
Code:
def onEvent(argsList):
"""Called when a game event happens - return 1 if the event was consumed."""
return getEventManager().handleEvent(argsList)
Code:
eventManager = BugEventManager.BugEventManager()
def getEventManager():
return eventManager(in BugEventManager)
Code:
def handleEvent(self, argsList):
"""Handles events by calling all installed handlers."""
self.bDbg, self.bMultiPlayer, self.bAlt, self.bCtrl, self.bShift, self.bAllowCheats = argsList[-6:]
self._dispatchEvent(argsList[0], argsList[1:-6])So... The dll method postEvent calls python onEvent which returns the result of a call of handleEvent which has no return.
This is a problem. What makes solving this difficult is that I have no idea how this stuff works and is supposed to work. I don't even know what any of these methods are supposed to do!
Back in ye olden days (like with the vanilla BtS DLL) you couldn't have more than thirty-some resources without breaking the Gamefonts. Sephi and others quickly raised that limit to 75, but until a year ago that was a limit to resources. AIAndy solved that issue then so you might want to ask him about what he did to fix it.
.
.
Thunderbrd
C2C War Dog
It'd be about finding the python function causing trouble and doing the same thing to it that you must do to dll functions all the time, add a check like if 'classobjectindex' != noclassobject THEN run the following, otherwise ignore this bit.
Right? I'm not a python master by any means, but it would seem to me that if you're having trouble of that nature, this would be the basic answer. Finding where the python info is being derived is what would be beyond my current skills.
Actually... come to think of it... you COULD run the python call and assign the value to an arbitrary established variable IN the dll coding and do the classinfo null check BEFORE it causes trouble by running it through that processing in the function you're having trouble with. Inside the function processing, you'd then refer to the variable itself rather than the full python call.
God-Emperor
Deity
Strangely, that is just the way the BUG code is. It appears to be wrong, technically, but it does not normally cause a problem like this.
The event handlers mostly do not actually return a value, but the handleEvent function that calls them in the regular event manager always returns whatever they return. The return for a function that returns nothing is in Python is presumably the special None value which is the equivalent to NULL in C++. Since most of the event handlers provide no return value, presumably not passing one back in the handelEvent is effectively identical in behavior for them (directly not returning anything should be the same as passing on the return value from a function that did not actually return anything). I would hope that the gDLL->getPythonIFace()->callFunction would handle that properly and set the lResult value to something useful.
Mods using BUG do generally work just fine, after all.
So I suspect the actual error may lie elsewhere. I would try examining what is being passed in the argument to the postEvent function. It may still be the case that one of the pieces of data added to that object is bad. So I would examine the eventData being used and also check farther up the call stack to see what it is adding to this object before it is getting here. Something off the end of an array (element -1, perhaps) or a pointer to a function instead of the results of that function, for example.
The event handlers mostly do not actually return a value, but the handleEvent function that calls them in the regular event manager always returns whatever they return. The return for a function that returns nothing is in Python is presumably the special None value which is the equivalent to NULL in C++. Since most of the event handlers provide no return value, presumably not passing one back in the handelEvent is effectively identical in behavior for them (directly not returning anything should be the same as passing on the return value from a function that did not actually return anything). I would hope that the gDLL->getPythonIFace()->callFunction would handle that properly and set the lResult value to something useful.
Mods using BUG do generally work just fine, after all.
So I suspect the actual error may lie elsewhere. I would try examining what is being passed in the argument to the postEvent function. It may still be the case that one of the pieces of data added to that object is bad. So I would examine the eventData being used and also check farther up the call stack to see what it is adding to this object before it is getting here. Something off the end of an array (element -1, perhaps) or a pointer to a function instead of the results of that function, for example.
Here's where the argsList is created:
I've confirmed that pUnit and pCity are fine.
On a different note, does anyone know what method is called when a unit moves into a plot (after any attack has taken place), and the method where a move is initiated (first thing)?
Code:
void CvDllPythonEvents::reportUnitBuilt(CvCity *pCity, CvUnit* pUnit)
{
if (preEvent())
{
CyArgsList eventData;
eventData.add("unitBuilt"); // add key to lookup python handler fxn
CyCity* pyc = new CyCity(pCity);
eventData.add(gDLL->getPythonIFace()->makePythonObject(pyc));
CyUnit* pyu = new CyUnit(pUnit);
eventData.add(gDLL->getPythonIFace()->makePythonObject(pyu));
postEvent(eventData);
delete pyc;
delete pyu;
}
}On a different note, does anyone know what method is called when a unit moves into a plot (after any attack has taken place), and the method where a move is initiated (first thing)?
I am currently working on Civics. iNoc makes each Civic category have 6 civics, and adds 3 new categories, Health, Military, and Education. I also got rid of State Property, as that civic has never worked for any civilization in history. I considered replacing it with Supply-Side Economics, but the track record for that is no better 
. I eventually ended up with the two new economic Civics being Keynesianism and Socialism.
Health Civics:
Village Care
Hippocratic Medicine
Scientific Medicine
Doctors
Bureaucratic Healthcare
Universal Care
Military Civics:
Militia
Standing Army
Constant War
Feudalism
Draft
Modern Warfare
Education Civics:
Tradition
Religious Study
Apprenticeship
Private Schools
Public Education
Free College
The new Government civic is Cashocracy (Might change this). The new Legal civic is Religious Law. The new Labor civic is Unionization. The new religious civic is Extremism, representing the reversion into materialistic religious fundamentalism seen in Afghanistan, Pakistan, Saudi Arabia, Iran, and the United States.
. I eventually ended up with the two new economic Civics being Keynesianism and Socialism.Health Civics:
Village Care
Hippocratic Medicine
Scientific Medicine
Doctors
Bureaucratic Healthcare
Universal Care
Military Civics:
Militia
Standing Army
Constant War
Feudalism
Draft
Modern Warfare
Education Civics:
Tradition
Religious Study
Apprenticeship
Private Schools
Public Education
Free College
The new Government civic is Cashocracy (Might change this). The new Legal civic is Religious Law. The new Labor civic is Unionization. The new religious civic is Extremism, representing the reversion into materialistic religious fundamentalism seen in Afghanistan, Pakistan, Saudi Arabia, Iran, and the United States.
PixelStrategist
Warlord
- Joined
- Jul 20, 2012
- Messages
- 176
For pure aesthetic reasons i'd change draft to conscription. Other than that the ideas are legit, but how will they affect the game?
Similar threads
