Ekmek
on steam: ekmek_e
sweet! looking forward to it. RevDCM is the only way I play now!
RevolutionDCM for BTS
- Thread starter glider1
- Start date
glider1
Deity
This is why I want to make sure it is not crashing out, so that we can enjoy RevolutionDCM fully
Post compilation testing is continuing. There has been a midgame CTD which I have been tracking down but unfortunately each cycle means another automated game to work through to confirm a fix.
If I can get this working, it looks good. Jdog has even improved the AI in some small ways.
Testing will continue for a couple of hours yet I'd say unfortunately.
Cheers.
glider1
Deity
Testing has not gone well with merging Revolution 1.5 into RevolutionDCM version 0.71. This is why I'm posting this trial version of 0.8 so that someone else can use some of their computer cycles to track down the problem. After going up a lot of garden paths, I believe the CTD is simply related to one or more DCM components.....but I'm not sure because the CTD does not happen all the time only sometimes. It is not repeatable. So I pass this trial onto you with all DCM options disabled. See how you go. If we can sort the stability out, I'll release a proper version.
Cheers.
Cheers.
Ekmek
on steam: ekmek_e
in .6 i have been getting periodic crashes it keeps giving me a memory allocation but upon loading the autosave it doesnt crash until a few turns later it seemed linked to the ever increasing number of civs. in some cases i think its on first contact with a new civ
well,
thanks glider for the answer,
i can say that dale and rev atleat in my compile, gives a random ctd after 500-1000 turns,
i use 1.42, it doesnt happen every game , but it there,
try to turn off all of the componants escept revolution, and run aiautoplay,
and see what happens.
goodlick buddy.
thanks glider for the answer,
i can say that dale and rev atleat in my compile, gives a random ctd after 500-1000 turns,
i use 1.42, it doesnt happen every game , but it there,
try to turn off all of the componants escept revolution, and run aiautoplay,
and see what happens.
goodlick buddy.
Tboy
Future world ruler
I notice that stack attack is now automatically turned off. Would turning it back on likely increase risk of CTDs?
glider1
Deity
Yep. Stack attack is one of the most unstable components. It is also incompatible with Influence driven war. If you are getting CTD's suspect Dales Combat Mod components and turn them off. You can carry on the game you are playing by exiting out of it, reconfiguring Dales Combat Mod and get straight back into your game again.
I'm working on a new release of RevolutionDCM with a high degree of confidence that the CTD's will be a thing of the past. There is a lot of testing to do.
Cheers.
Ekmek
on steam: ekmek_e
Thanks glider. your work surely earns you a sainthood 
glider1
Deity
If I could fix it I would declare myself a saint Kidding. Each lead means at least five complete standard game run throughs with each run through taking 1/2 to 1 hour. If I had five computers on a desk all running in parallel that would speed things up.
Cheers.
PS) The "trial" version 0.8 I posted yesterday is bugged. The random CTD does occur in that version independent of whether DCM components are running or not. I am now testing a build that seems to have fixed the CTD but time will tell.
Kidding. Each lead means at least five complete standard game run throughs with each run through taking 1/2 to 1 hour. If I had five computers on a desk all running in parallel that would speed things up.Cheers.
PS) The "trial" version 0.8 I posted yesterday is bugged. The random CTD does occur in that version independent of whether DCM components are running or not. I am now testing a build that seems to have fixed the CTD but time will tell.
Ekmek
on steam: ekmek_e
glider did you catch in the rev forum that Amra said some fixes were done in bhurics 1.2 but rev has been using 1.2?
glider1
Deity
Yeah thanks got that one. At the moment I'm onto a lead regarding the way that DCM and IDW access their configuration data. IDW appears wrong and not sure about DCM. Revolution is the bench mark for quality coding and uses a different technique. The CTD problems with IDW and DCM have gotton worse since Revolution 1.5 for some reason. This has triggered me into wanting to get the issue sorted out.
Cheers
Ekmek
on steam: ekmek_e
Good work man we're rooting for ya!
glider1
Deity
Well thanks to the encouragement of you lot out there, I'm happy and shocked to say that this release is a major stability improvement release. Most if not all CTD's have been removed. This has been done by removing all DCM and IDW references to GlobalDefinesAlt.xml and hardcoding all references in the short term. Basically CTD likelyhood increases with any mod that references XML in C++ using this code technique:
if (GC.getDefineINT("WHATEVER_ENABLED")) {whatever code}.
Why exactly is not clear. IDW 1.1 does not cache it's XML data while DCM 1.5 does yet both techniques still can fail, IDW non caching approach is more likely to fail than a caching approach but even a caching approach is unstable to some degree. It is perhaps that there is a limit to how much global data can be stored in the GC object structure, or that there is some sort of timing error when GC is used in a conditional statement. The recommendation is to study how vanilla BTS and Revolution 1.5 access XML data to better understand this resolved CTD issue. In any case, from my "novice" perspective over using global variables is not a good thing. I think modders may be working GC too hard because it's the easier approach.
I'm sorry for the inability to turn DCM and IDW components on and off via XML. You will notice that GlobalAltDefines.xml is gone. It will not return. In future releases I will study how Jdog5000 accesses external variables and emulate that. I believe the Revolutions mod is doing it correctly and that this code is the absolute state of the art standard for BTS modding. Jaw dropping stuff.
In the meantime, I even think that you will find that the DCM components are now running much more reliably. The nature of the CTD problem using GlobalAltDefines.xml is random and is system resource dependent. Thus it will appear that active defense might not be working, or that opportunity fire is not working, but it is not the logic itself. Dale has done an excellent job there. It is merely the technique of accessing xml that is the question mark.
At least battle effect duration has been halved. Sorry I did not take it out altogether but I like the concept! I really feel that Dale is onto a good thing with DCM. I was forced to take out stack attack because of incompatibility with IDW and I also had to disable one component of IDW because of a rare problem connected with capturing cities. See the readme for more details.
As for me, after running probably 100 full game test runs over the last four days, I'm gunna put my feet up and do some serious RevolutionDCM playing myself instead of endless test runs on two computers (Vista x64 and XP).
After a decent monarch game (which I will probably loose in a couple of days) I will begin working on emulating Jdog5000 Revolution excellence. Unfortunately unless DCM or IDW change the way they access external data, I will have to change it myself in RevolutionDCM which will mean that new version releases will be significantly longer between release intervals.
Cheers.
PS) The BTS and Revolutions code leaves me shaking my head at how a game like civ is possible at all. The rheems of logical constructs down at the coding level are breathtaking. Appreciate this great game.
if (GC.getDefineINT("WHATEVER_ENABLED")) {whatever code}.
Why exactly is not clear. IDW 1.1 does not cache it's XML data while DCM 1.5 does yet both techniques still can fail, IDW non caching approach is more likely to fail than a caching approach but even a caching approach is unstable to some degree. It is perhaps that there is a limit to how much global data can be stored in the GC object structure, or that there is some sort of timing error when GC is used in a conditional statement. The recommendation is to study how vanilla BTS and Revolution 1.5 access XML data to better understand this resolved CTD issue. In any case, from my "novice" perspective over using global variables is not a good thing. I think modders may be working GC too hard because it's the easier approach.
I'm sorry for the inability to turn DCM and IDW components on and off via XML. You will notice that GlobalAltDefines.xml is gone. It will not return. In future releases I will study how Jdog5000 accesses external variables and emulate that. I believe the Revolutions mod is doing it correctly and that this code is the absolute state of the art standard for BTS modding. Jaw dropping stuff.
In the meantime, I even think that you will find that the DCM components are now running much more reliably. The nature of the CTD problem using GlobalAltDefines.xml is random and is system resource dependent. Thus it will appear that active defense might not be working, or that opportunity fire is not working, but it is not the logic itself. Dale has done an excellent job there. It is merely the technique of accessing xml that is the question mark.
At least battle effect duration has been halved. Sorry I did not take it out altogether but I like the concept! I really feel that Dale is onto a good thing with DCM. I was forced to take out stack attack because of incompatibility with IDW and I also had to disable one component of IDW because of a rare problem connected with capturing cities. See the readme for more details.
As for me, after running probably 100 full game test runs over the last four days, I'm gunna put my feet up and do some serious RevolutionDCM playing myself instead of endless test runs on two computers (Vista x64 and XP).
After a decent monarch game (which I will probably loose in a couple of days) I will begin working on emulating Jdog5000 Revolution excellence. Unfortunately unless DCM or IDW change the way they access external data, I will have to change it myself in RevolutionDCM which will mean that new version releases will be significantly longer between release intervals.
Cheers.
PS) The BTS and Revolutions code leaves me shaking my head at how a game like civ is possible at all. The rheems of logical constructs down at the coding level are breathtaking. Appreciate this great game.
Ekmek
on steam: ekmek_e
Great news on the stability but I'm bummed on stack attack. Have you PM'd Dale about this incompatibility?
BobTheTerrible
Just Another Bob
I'm assuming the incompatibility is due to the fact that stack attack only counts as one battle for the purposes of Influence Driven War, so the culture transfer would only happen once, even if 20 units were taking place in the battle on either side.
glider1
Deity
Good thought. I think that stack attacks do not register with IDW at all. IDW thinks that there has been no attack that has taken place. It is quite possible that stack attack bypasses the normal attack mechanics and thus goes under the nose of IDW. I haven't looked at it closely. The other point is that there was no way that I could get to 95% confidence on stability by including the stack attack option in testing. It is the most unreliable component of them all.
Top priority is to get most of it working without the CTD's then we can fill in the details about getting individual components working. Stack attack will work eventually, because I don't think that the instability of it is a function of the graphics subsystem and thus beyond our reach, but is within the function of the SA code itself. It's only a hunch. SA is a good idea and is also fun.
The hard coding of all these options is only a temporary phase before this mod goes into full Revolution mod approach without sacrifising stability.
Cheers.
Kalimakhus
Emperor
- Joined
- May 8, 2007
- Messages
- 1,249
The following are some thoughts about the findings of Glider concerning the instability of DCM components and its probable causes:
Spoiler :
glider1
Deity
@Kalimakhus
Thanks for that information! You are the first to confirm that this release does "appear" to be more stable. You are keeping an eye out to the big picture, that there are system level processes going on that make the mod more or less stable. That is what makes it so difficult to track down CTD's. Are they because of the mod logic or are they system level? Sometimes they are, sometimes they are not.
If other people can confirm that this release is more stable, I can continue on with making it configurable without decreasing the stability. Suggestions by Kalimakhus and others on how to do this would be appreciated.
Cheers.
Thanks for that information! You are the first to confirm that this release does "appear" to be more stable. You are keeping an eye out to the big picture, that there are system level processes going on that make the mod more or less stable. That is what makes it so difficult to track down CTD's. Are they because of the mod logic or are they system level? Sometimes they are, sometimes they are not.
If other people can confirm that this release is more stable, I can continue on with making it configurable without decreasing the stability. Suggestions by Kalimakhus and others on how to do this would be appreciated.
Cheers.
BobTheTerrible
Just Another Bob
If other people can confirm that this release is more stable, I can continue on with making it configurable without decreasing the stability. Suggestions by Kalimakhus and others on how to do this would be appreciated.
Cheers.
I haven't had any problems with the mod so far, except that I can't trade gold for anything in diplomacy (If I put a tech on the table, my gold and the AIs gold just disappear. I can't even trade gold for world maps). This seems to be a bug with the base revolutions mod though since a few other people have posted about this in the rev forum.
glider1
Deity
@BobTheTerrible
I'll keep an eye on it while I'm in a game. I think the problem is that it's difficult to see how Rev could be affecting it unless it is something to do with Bhruic.
@Kalimakus
Good analysis on SA and how it seems to be potentially causing the instability. However on the other hand, there is potential for some hope with SA instability. That is that SA CTD's are very perculiar in terms of when they actually happen. If you pull up an old copy of RevDCM and turn SA on and test for crashes, I think you will notice what I have noticed, and that the crash actually only occurs like a noticeably 1/2 to a 1 sec after the stack attack is completed including animations. Is that an inconsistency within the system heap cleaning itself up after the attack or is it something in the logic or the like within the SA code? For example, I found that if you turned off active defense and kept SA on, SA no longer crashed post attack. So the other "issue" about stack attack is that I think it is interrelated with other components as well in terms of crashing. Testing SA is another whole story on it's own and I want to get into that too at some stage. Stack attacks are fun.
Cheers.
PS) out of interest does anyone know what the AI used to do with SA on? When it attacks does it stack attack or not? More questions.
I'll keep an eye on it while I'm in a game. I think the problem is that it's difficult to see how Rev could be affecting it unless it is something to do with Bhruic.
@Kalimakus
Good analysis on SA and how it seems to be potentially causing the instability. However on the other hand, there is potential for some hope with SA instability. That is that SA CTD's are very perculiar in terms of when they actually happen. If you pull up an old copy of RevDCM and turn SA on and test for crashes, I think you will notice what I have noticed, and that the crash actually only occurs like a noticeably 1/2 to a 1 sec after the stack attack is completed including animations. Is that an inconsistency within the system heap cleaning itself up after the attack or is it something in the logic or the like within the SA code? For example, I found that if you turned off active defense and kept SA on, SA no longer crashed post attack. So the other "issue" about stack attack is that I think it is interrelated with other components as well in terms of crashing. Testing SA is another whole story on it's own and I want to get into that too at some stage. Stack attacks are fun.
Cheers.
PS) out of interest does anyone know what the AI used to do with SA on? When it attacks does it stack attack or not? More questions.
Similar threads
