No worries guys; I am not offended. I am
asking for criticism: constructive if possible but critical as well.
@johny - When I completed 3.0 of BUG, I considered releasing the BUG Core as a separate no-feature mod designed solely for what you're talking about. However, due to how BTS is coded it would still have replaced CvEventManager, CvAppInterface, CvScreensInterface, etc. There is just no way around that.
If I had followed the modders' method of modifying CvEventManager directly, the majority of code in the following modules off the top of my head would all be entangled in a single giant Python module:
- ReminderEventManager
- autologEventManager
- FavoriteCivicDetector
- Civ4lerts
- MoreCiv4lerts
- EventSigns
- CvCustomizableDomesticAdvisor
- CvTechAdvisor
- CvStrategyOverlay
- BugOptions
- BugOptionsScreen
- TradeUtil
- DiplomacyUtil
And a lot of those modules use the same events, meaning their functions would have to be merged together.
Total freakin' nightmare! There'd be no way to remove a single feature or copy one into your own BUGless mod. And it would be a
for me to maintain. Sure, if you wanted to merge in an old modcomp, it may have been slightly easier, but the cost would be too high.
Instead, everything having to do with Event Signs is in EventSigns.py and EventSigns.xml--save that one line in init.xml to load EventSigns.xml. Most features in BUG are self-contained in such a manner.
And then there's CvMainInterface. No matter how you slice it, there's no getting around the way that screen is built. Even if I rewrote it from scratch (I've been tempted), it would still be several interdependent modules. It may make reading the code easier, but it wouldn't be any less spaghetti-like.
As for CvAppInterface, I
must initialize BUG during the GameLoad or PreSave stage, but doing it from the events didn't work for PreSave. Thus I had no choice but to modify CvAppInterface. BUG simply would not work without it. For that you'll have to chat up Firaxis.
The main problem is that to make BUG really useful and easy for me to work on, I had to fix the design flaws in BTS. But the only way to do that is to
replace the original BTS files. Well, you can't do that and expect modcomps written to use the old method to work without modification. So my choice was crappy functionality and difficult to program, or non-trivial to merge.
Here is where having complete examples really could have helped. I was hoping the features in BUG would have been enough, but it's really hard to know what in BUG you can read in isolation as an example. The docs on our wiki are a good start, but working examples on the wiki are still needed. Believe me, though, it is
far easier to add a feature to BUG than to BTS. The only reason you find it easier without BUG is because you already know how to do it with BTS.
For events, as an example, I looked in the community and saw a lot of modcomps using CvCustomEventManager. So I took that as a base case, making BUG work seemlessly with mods written to use CvCEM. I can't help the mods that modify CvEventManager directly. Even Firaxis didn't intend for people to do that. That's the whole reason for the CvXXXInterface modules--to allow the modder to either subclass or replace the original XXX without having to modify it. But Firaxis had even less documentation than I did back when I started.
So to bring this back around, I don't think even having what you are asking for would really solve the problem you have. You want to be able to merge modcomps written to use the original Firaxis code without having to modify them beyond merging modules. Well, that's just not gonna happen with BUG. It can't. I've added too many features (not interface features, Python design features) that make it easier to write modcomps for BUG to have it support modcomps written for BTS without modification.
In many cases the modifications are trivial, e.g. if they were written to use CvCEM. In other cases it is very difficult, e.g. if they are CvMainInterface-based mods.
Now, if you have some specific ideas on how I could make it at least a little easier to do that, I'm all ears. This is where I need detailed specifics.
@xienwolf - I didn't spend much time looking at the XML parsing, but my memory is that it
depends on the ordering a lot of times. Sometimes it jumps to a child by name, but other times it read field after field expecting that they be present. Or is my memory totally off?
The whole XML parsing engine from BTS required a lot of manual work that you just wouldn't have if it had used a DOM parser and some generic code, but this is tough to do in C++ whereas in Python it is fairly trivial. I think WoC did the best it could given what it had to start from. The same can be said of BUG I think.
Good luck with whatever's keeping you busy.
