Hi Delnar,
I'm back to modding, yesterday I've spent about 3-4 good hours only to check all your changes on the surface... Wow! You really spent a good amount of hours doing this amazing work, my legacy changes could be about only 10-15% of the change volume.
I was already preparing an updated new version of Smart AI, my initial idea is to keep a simple DLL with AI upgrade while contributing the Community Patch with the most interesting enhancements not addresed there.
Seeing your approach is very similar to mine... Do you mind I use your project as code base for my new Smart AI version?
My personal approach in modding the AI: Keep the dll fully compatible. Don't add any new bug at all costs, Keep the performance similar of the unmodded game, focus on existing behaviours over adding new layers of complexity.
I hope you're agree, let me know if this must be further discussed or you are totally disagree. Your work and DLL would be fully recognized and recommended from mine, and I could send you pull requests with my new enhancements and fixes.
As always, I do not mind anyone using my code for their own mod, so long as everything is properly attributed. As Gazebo said in the post I'm quoting below though, a lot of AuI's changes have apparently made their way into the CPP's base DLL (the one that doesn't include any gameplay changes). Since CPP's DLL contains a lot more fixes and modular options than mine, it may be worth thinking about using their DLL as a base instead.
Don't sell yourself too short, BTW. Sure, the changes you made that I migrated over and built on top of are now just a small part of the overall package, but your code also often served as inspiration for seemingly unrelated fixes. For example, it was your (not well functioning) "avoid water tiles" changes to the Move to Safety functions that made me look into the DangerPlots class in the first place.
I'll be honest, I really don't see why we need three separate AI-improvement DLLs (4 if you count the work whoward has done in the VMC). The CP has incorporated almost all of the work both of you have done, and its performance is much, much faster than the vanilla DLL (especially in the late-game). I think it makes a lot of sense for us to join forces on a single DLL that all other mods in the community can use as their base (helps prevent mod fragmentation as well).
I mostly would agree with you, but I wish to keep AuI its own thing for now for two, closely intertwined reasons:
- AuI's code is what I'm familiar with inside and out. Even if the CPP's code has more features, I'm only superficially familiar with most of them because I simply haven't spent the time needed to really get to know them. Since I'm so limited on time as of late (since mid-October), I would rather just stick with my own WIP codebase for now whenever I get the free time to actually work on it instead of trying to familiarize myself with another WIP codebase.
- Even though you migrated AuI's changes into the CPP, I know that a lot of the stuff that is currently in the v10 experimental branch is very much a placeholder, even if it is functional. For example, my new DangerPlots combat simulation stuff is incredibly non-portable, as are its sibling functions in TacticalAI; I know that I will want to use CvCombatInfo stuff for the final implementations of these functions. I also know that my citizen management plot-swapper (the code that lets the citizen managers of multiple cities determine which city should be working a shared tile) could also be a lot better optimized (IIRC, it's also buggy as heck). Basically, even if the code sort of works and is committed (in the experimental branch), I don't necessarily want it in the DLL. You ported these functions over to the CPP and I assume built a lot of extra functionality on top of them, so I'm guessing that me scrapping these functions and replacing them with a different system would break a lot of CPP-specific code. I don't want to deal with that, not when my code already breaks as much as it currently does.
Also, unless you guys significantly changed the defines setups since I last looked at the CPP's code base, the preprocessor defines in the CPP that control the technical and AI improvements are organized so that one or two defines toggle a wide array of unrelated changes (eg. a "core tweaks" define, a "core balance tweaks" define, etc.). On the other hand, I like to have one define per individual change type (with a few exceptions for incredibly miniscule changes) both as a good form of documentation for myself and to act as a lazy man's complete changelog.
I also might violate the CPP core's dogma with some of the changes I've been working on as a side thing for NQMod and plan to move back into AuI's experimental branch, as those changes alter core Civ5 gameplay. The best example is my change that yields for the player's turn are cached at the very beginning of turn processing, so actions during turn processing that would alter yields no longer do so; e.g. growing a pop and having it work a tile with hammers no longer increases the city's hammer output that very turn, building a building will no longer increase the city's gold maintenance that very turn, a lux trade expiring for the player will not lower the player's calculated happiness that turn (this one was probably the hardest to implement, since the logic for deal expiration is not built to take individual players into account), etc.