If he is getting attacked it seems yes, but if he joins in a battle and is not getting hit, tower production is not high.

Welp, no luck.  No matter which directories I mount in RetailDataPath.lua, no matter the order in which I mount them, the game ignores all files in those directories, including within hook subdirectories.  I can't find any other files that reference mount paths other than GameDataPath.lua, also in \bin, which seems to do absolutely nothing and is never called.

So, unless I'm missing something, the only way to do this is to make a copy of dgdata.zip with the modified files contained therein, and switch between the two with a batch file.  Not exactly convenient.

I already have that part worked out; the problem with using dgdata.zip is distribution.  dgdata.zip contains all of the lua for the entire game, and is 20mb.

I can just distribute a batch file and a mods.lua, but then installation is a pain in the ass, and either people won't figure it out or won't even bother to try because it's unnecessarily difficult.

Why do you think everyone does it?  Because it looks easier, and maybe it is at first.  Of course, then your 'work' won't work with everyone else's, and you just limited the audience of your mod to the few people that will choose it over others.

There's zero excuse for that in the moho engine though.  It lets you combine any number of mods smoothly and efficiently, and all you need to do is to learn some simple shorthand for editing blueprints.  I see people coming into the FA community all the time with this 'mod pack' mentality, and it's retarded, because then you end up with this stagnant set of a bunch of mods that are all individually being updated and improved and that work just fine together, but that the mod pack author doesn't have the time to keep up with and continually re-integrate.

Even when two mods don't play nice, the engine amazes once again by allowing a much smaller and simpler third mod to step in and integrate them from the outside, also with a minimum of destructive overrides (none in many cases).  This allows the mods to be individually maintained and improved while still working together just fine with the arbitrating mod.  There's simply no excuse to use destructive methods for anything but Baby's First Mod(tm) - take the hour or two to learn how to do it right, and I promise it will pay off-- especially if you're going to be spending dozens or hundreds of hours on a big mod project.

If you're making major code alterations, you need to learn how the game's lua works inside and out anyway, and this just gives you some basic experience with that.  When I started modding FA, I didn't know the first thing about lua, but I quickly memorized how to do some quick and easy hooking methods by looking at other people's mods.  Then after using them for a week or two, I understood why and what I was doing with these rote methods, and within a few months that segued into learning lua well enough to accomplish just about anything in which I have the time or energy to invest.

And I see you're already talking about merging other people's perfectly viable standalone UI mods into yours.  Again, why?  Who does this help?  Everyone already uses these UI mods, and they're great individually.  There's nothing to improve by mashing them together.  Nevermind that you would need the permission of all their authors to do this.

Actually, the absolute most common question in the FA mod forums is "is this mod compatible with that mod" even when they're huge, balance-changing mods that add tons of units.  By a factor of 50, over all other questions by 'average mod users'.  So yes, everyone definitely cares about which mods can work together, because these games are unique in making that possible.

None of the teams producing the big TC-type mods for FA intended for their mods to work together, but they eventually ended up that way by popular demand.  One guy did a solo rework of the massive mod he and a team made over 3 years for the express purpose of working with other mods, when it hadn't before due to destructive changes.

Basically, 'your vision' for the game isn't what most people want, no matter who you are or what it is.  The best way to build a mod that's popular, well-received, and worth maintaining is to do some of the things you want, but to appeal to the widest possible audience - which in Demigod or FA, is as simple as keeping different kinds of changes (balance, added features, AI tweaks, etc) in separate mods.

Either way, integrating UI mods into a sim mod is silly and pointless.  UI mods are great precisely because they can be used online, in any game, independent of any other sim mods.  If a sim mod tries to integrate those UI mods, and then the user tries to enable standalone versions, whoops, you've got problems.

This is a silly derail, but I'd just like to add that certainly not everyone sees it your way, especially mod users in GPG's game communities, who are quite used to being able to combine mods at will, and will actively avoid mods that break compatibility with or cause problems for the myriad other mods that they're using.  Demigod is a bit different because they provided limited to no ability to add new units or items (also because nobody plays it, loool), but the same UI / sim exclusion expectations apply, and should.