Thanks.
Also, while I was at it I found that I forgot to add save/load code for Hills work rate modifiers.
Those will be in my next commit, sorry for that everyone.
General DLL programming questions
- Thread starter Thunderbrd
- Start date
Thanks.
Also, while I was at it I found that I forgot to add save/load code for Hills work rate modifiers.
Those will be in my next commit, sorry for that everyone.
Thunderbrd
C2C War Dog
Damn... you found that before I did huh? lol. Actually... please just leave it out as I've got it taken care of on this end. I simply ran out of my modding time this weekend to get things cleaned up and remerged into the new code since the last remerge onto a remerge onto a remerge enough to get it pushed to the svn. I really do wish you could be patient.
If I had been 'paitent' we still would be waiting on the release of V29 for your commit, and no modding work would have really been done in the past three weeks or so. My philosophy is that it is better to fix bugs faster rather than lumping them all together for one giant commit that is constantly delayed.
Thunderbrd
C2C War Dog
Dividing up this project so that I can simply commit ONLY the parts that have been fully debugged would take even longer. I agree to some extent but the meat of the project was already under way when the rest came into the picture. So its been a project interrupted by a project interrupted by a project and a LOT of time has been spent on remerging and remerging only to find I didn't have enough time left to finish the last merge before another need to merge presented itself. Working over the same area in the code is not too hard to avoid and 3 weeks is not a long time - what's that, 20 hrs of modding time maybe?
Note: I would not have delayed the release this far by any means... upon discovering the depth of the issues I decided to keep it out of the release for that very reason. I'm not complaining about that... just saying your section is complete and awaiting clearance and a full merge into a code base that stays constant long enough to do so without having to again remerge once I'm done.
Note: I would not have delayed the release this far by any means... upon discovering the depth of the issues I decided to keep it out of the release for that very reason. I'm not complaining about that... just saying your section is complete and awaiting clearance and a full merge into a code base that stays constant long enough to do so without having to again remerge once I'm done.
I suggest to have a look at the creation of SVN branches.
Speaking of branches I should probably delete the old Combat Worker branch, as I haven't used it at all and it is just taking up space.
There is no such thing as truely deleting an SVN branch. Any delete is undoable and the branches take up as much space now as they did before you deleted them.
Making a branch does not make a full copy either. It just stores the differences in the branch compared to what it is branched from. So that is a cheap operation (with next to 0 space usage right after branching).
Maybe I did it wrong then because for me it made a whole new copy of the trunk and never updated it. At any rate that is now gone from the SVN.
Thunderbrd
C2C War Dog
How are you suggesting the creation of a branch would've helped in this situation AIAndy?
Because that way you could have continuously merged your commits that are not specific to the buggy feature into trunk.
Thunderbrd
C2C War Dog
Ah... what's taken me some time is figuring out what was and was not buggy. I suppose if I had a branch I was committing to whenever I was finished coding for a day, that might work, but it takes a long time just to commit so that would be rather annoying.
Perhaps I'm missing some functionality of the feature you're talking about that would've been more helpful. I'm trying to get all this stuff I've done cleared so it can then undergo the process of merging with the CURRENT code as I don't dare update a project during the project to make sure that I don't somehow overwrite something I've done by accident.
Perhaps I'm missing some functionality of the feature you're talking about that would've been more helpful. I'm trying to get all this stuff I've done cleared so it can then undergo the process of merging with the CURRENT code as I don't dare update a project during the project to make sure that I don't somehow overwrite something I've done by accident.
I prefer updating all the time as that way I can resolve any conflicts when they happen and merging works better in small steps than in large ones.
One thing that would help not only development but also the sudden impacts your large changes have on gameplay is for you to make smaller and more bite-size changes as part of your larger projects. This would be easier for you as there would be less merging and less stressful for the rest of us who don't quite know how much stuff will change when you do a commit.
Thunderbrd
C2C War Dog
I understand that but when projects are large just to get a platform for them then they are interrupted by other projects which are interrupted by other projects it does tend to grow out of hand quickly. I suppose to improve on this I'm just going to have to accept the need to merge my own work into my own work more often and break all projects up into their own file sources.
Try (after this is done) just making one small part of your project and committing that before making your next component. I'll bet you'll be surprised how much easier that makes things.
Thunderbrd
C2C War Dog
Ok, I know of a bug and have a little insight as to what could be causing it. But going through the code that I suspect its located in somewhere, I'm totally lost as to where the bug may lurk exactly.
The problem: We're getting units sometimes coming up twice in the city popup build lists.
Observation: It appears this is (perhaps reliably) happening on units with multiple combat classes.
Difficulty with solution: I'm not seeing any direct relation between any use of hasCombatType and the generation of the build lists. I'm not understanding the enormous complexity of how the build lists are derived in the first place - getting quickly lost in that structure which looks to be one of the most involved anywhere in the dll.
Suspicion: I'm wondering if it has something to do with the build cost adjustment - perhaps rather than totaling the Combat Classes' modifiers on the unit type, its adding each to a differing instance of the unit thereby generating new instances of the unit in the build lists.
Can any of the better programmers than I look into this? This one is just overwhelmingly complicated and my analysis falls apart at the seams in trying to understand the generation of that list! I was not anticipating that great a complexity - particularly after having worked on the trait selection list and figuring it would not be all that dissimilar. I'm baffled here. Help would be appreciated!
EDIT: Note I just realized that hasCombatType is for the units in the game rather than the base unit type data... I'm still looking into things further of course
Yeah, so unfortunately, though I've found the CvCity and CvPlayer canTrain and related functions, I'm totally lost on what most of it is actually doing. So it has to be something in there and again, rather than tweak with something I don't understand, I'd like one of you to see what you can find in there that could be causing SubCombats to bring up new instances into the training lists. Thanks again!
The problem: We're getting units sometimes coming up twice in the city popup build lists.
Observation: It appears this is (perhaps reliably) happening on units with multiple combat classes.
Difficulty with solution: I'm not seeing any direct relation between any use of hasCombatType and the generation of the build lists. I'm not understanding the enormous complexity of how the build lists are derived in the first place - getting quickly lost in that structure which looks to be one of the most involved anywhere in the dll.
Suspicion: I'm wondering if it has something to do with the build cost adjustment - perhaps rather than totaling the Combat Classes' modifiers on the unit type, its adding each to a differing instance of the unit thereby generating new instances of the unit in the build lists.
Can any of the better programmers than I look into this? This one is just overwhelmingly complicated and my analysis falls apart at the seams in trying to understand the generation of that list! I was not anticipating that great a complexity - particularly after having worked on the trait selection list and figuring it would not be all that dissimilar. I'm baffled here. Help would be appreciated!
EDIT: Note I just realized that hasCombatType is for the units in the game rather than the base unit type data... I'm still looking into things further of course
Yeah, so unfortunately, though I've found the CvCity and CvPlayer canTrain and related functions, I'm totally lost on what most of it is actually doing. So it has to be something in there and again, rather than tweak with something I don't understand, I'd like one of you to see what you can find in there that could be causing SubCombats to bring up new instances into the training lists. Thanks again!
Thunderbrd
C2C War Dog
@AIAndy:
I'm attempting to add the replacement mechanism to more classes and I'm now getting this odd compiler error:
erm... sounds like I've pushed some limit I don't understand to its breaking point. Any insights on how to overcome this?
EDIT: If I reduce the number of classes I'm trying to include into the replacement mechanism down to just one more than we have now (3 at the moment) then I'm able to successfully compile a Final_Release version but I still get an error - of a differing nature this time, now very vague and instructing us to get technical help - when trying to compile a debug version.
I'm attempting to add the replacement mechanism to more classes and I'm now getting this odd compiler error:
Code:
1>C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\include\xtree(267) : fatal error C1076: compiler limit : internal heap limit reached; use /Zm to specify a higher limitEDIT: If I reduce the number of classes I'm trying to include into the replacement mechanism down to just one more than we have now (3 at the moment) then I'm able to successfully compile a Final_Release version but I still get an error - of a differing nature this time, now very vague and instructing us to get technical help - when trying to compile a debug version.
The Python exposing code seems to drive the compiler pretty close to its limit so any code that is visible to the same code can drive those limits over the edge. You can try setting the compiler switch that that message notes but in my experience that only gives some limited playground and results in other error messages afterwards.
The other solution is to try to keep the memory intensive definitions from being seen by the code that does the Python exposure.
Thunderbrd
C2C War Dog
Sounds like: Translation - we're screwed.
This is what is taking place when I try to add additional class objects to the replacement mechanism following the examples you gave on the tech class in Rev 4918. Even adding just one more causes trouble, though that one more might work.
In my next update, I'll have added to the source codes all the necessary steps, so far as I could see, to each of the classes I wanted to add to have this replacement capability. But the code will be commented out so you can see what's happening if you simply remove the comment lines on a class or two. Then you can see if there's anything you can do to get us past that...
I presume when you mean
you mean the entire python reporting of the class being given the opportunity to pick up a replacement itself? Obviously this would be completely impossible right? Nothing about this system has any independent python reporting...
And I cannot even begin to derive any meaning in what it was trying to tell me to do. What is '/Zm'? Is that some kind of program, file or function?
Screwed? No, definitely not.
No, the problem are the Cy_X_Interface.cpp compilation units that expose functionality to Python. As you might see those are already split up into several files as the compiler would be overwhelmed if all of those complex templates would be done in the same compilation unit.
Those compilation units see several other declarations via includes, some of them pointless (someone should really go through all the includes in the files that are in turn included by most files and remove all those that are not needed). Amongst them CvGlobals.h. Instantiating the replacement template more times in CvGlobals adds complexity and memory usage during compilation which in addition to the complex Python templates can cause the issues we see here.
One way to remove that issue is to move the CvInfoReplacement stuff from CvGlobals to somewhere else. Another globals singleton or just using a global directly.
It is a compiler switch.
Similar threads
