Announcement: DLL enables far easier modularization

rheinig

Chieftain
Joined
Jul 24, 2008
Messages
11
Hi all,

First of all, the DLL I'm presenting here is not WoC or a part of it, it is an alternate approach I came up with not knowing about WoC, here for the WoC team's inspection and/or inspiration.

This text is an updated copy of an earlier post in the Plug & pray forum. Thanks to tucoow I now hope this stuff will be of more use here. Let me quote myself:

Yes, you don't know me, and yes, this is practically my first post, but trust me - this is the result of some expertise.

I have played around with modular XML for a while without publishing anything to the world. Recently, after letting the game rest for two years, I revisited it and soon had the inspiration that eluded my for years regarding Python Event managers. While working on my fully modular Python Event Manager, I found one kind of events could not be elegantly modularized using Python metaprogramming (Random Events callbacks), so I went into the DLL and changed that. Soon, I arrived at an extensively changed DLL, and I kindly ask all of you to evaluate my work.

What advantages can you expect? For the audience of this forum:
  • Module load order is now easily predictable though not controllable (no good idea on that, I think predictability is already a vast improvement, coupled with a lessened need, see below).
  • Delayed pass 2 (e.g. tech prerequisites - can now crossreference across all tech modules)
  • Incremental Modular XML system. A module can now modify existing entries instead of replacing them. Example - a Module defines a new UnitCombatType. It can now add itself to the existing promotions instead of overwriting the whole promotion tree, without modifying the promotion effects, thus allowing other modules to touch these without needing to know about your new UnitCombatType...

There's a host of other fixes and improvements in there, but it's designed to be 100% backwards compatible with BTS 3.1.7. Most changes need some form of activation in XML, so without definitions catering to it, the DLL should behave identically (minus a few obvious bugs). Do refer to the readme included in the download for detailed information.

Please consider this an early beta - my horsing-around mod works well with this, but I haven't really had the time for proper every-code-path-touched testing. Feedback welcome.

So now for the download - should the forum attachment system not work you can load it here...

Missing installation instructions? It will have them once I declare it out of beta ;) - I'm out for feedback from people who know where a CvGameCoreDLL goes.

You may also want to look for more offerings by me - I plan to release the Fully Modular Python Manager and the example files soon - just have to work out a few kinks and spots where the modularization is not yet cleanly independent...

Have phun!

The current version differs from the one in that other forum. The most important differences are as follows:
  • Finally found the reason modularized random events broke
  • Source included
  • Base support xml files included

Note the source files now included are based on BTS317+Solver's inofficial 0.19 and include only those files I've changed. You'll need both to build this. Also note the vcproj included is modified in ways you may not want - I recommend starting with the BTS one, I've only included mine for comparison purposes.
 

Attachments

  • CvGameCoreDLL_RH_03.zip
    2 MB · Views: 116
Interesting, this is very similar to what we already have in WoC for quite a while. One of the things we still need to do, is find a way to modularize Python, so your "Fully Modular Python Manager" is most intriguing.
 
D*, earlier reply lost - pease tolerate crypticness.

what we already have
Just started looking into it. Seems like a reason to be pissed (at myself, though reinventing the wheel is loads of phun) - I thought WoC was just another 100M+ Mod and never checked into it. Maybe I should diff the stuff and process a list of suggestions out of it - a horsehockyload of tedious work...

find a why to modularize Python
...way... OK, I'll just bite back my pride and post the current version. Separate thread.

First impressions:
- why bloat the download with a _debug.dll? And, how the * did you get it to work? When *I* try to start a debug build, it always complains about Python initialization errors and proceeds to a nice crash, even when the release build runs fine even under the debugger...

- WoC seems to do what my 'Incremental' mode does -permanently-. I would have vetoed that design decision. My DLL does allow overriding an existing property with the default value. Take my modularization (see MPM post) of the BTS 'FfH Age of Ice' way animals work - I can take the bear, assign it a new UnitCombatType, and clear the bAnimal flag without touching any file outside my modular folder. Then I can give scouts and explorers the +100% against the 'animals' UnitCombatType and clear the normal +100 against animals so the pedia and tooltips look OK... All cleanly within a single folder. The current WoC way to do this sounds ugly and hard to document clearly.

- Where can I read most quickly what these MLF_ files that seem to point to mostly nonexisting directories are supposed to do? Are they really only there to allow suppressing specific folders? I thought being able to just move stuff out of the Modules tree is sufficient?

'later...
 
- WoC seems to do what my 'Incremental' mode does -permanently-. I would have vetoed that design decision. My DLL does allow overriding an existing property with the default value.
...
The current WoC way to do this sounds ugly and hard to document clearly.

not sure why they did either, imo a default value simply is a value too, so whatever value is set last, that is the one to use. If it is set multiple times, you need to make sure to set it to the correct value anyway (be that the default or any other).

- Where can I read most quickly what these MLF_ files that seem to point to mostly nonexisting directories are supposed to do? Are they really only there to allow suppressing specific folders? I thought being able to just move stuff out of the Modules tree is sufficient?

They determine what gets loaded (of course, just not having the dir will stop it from being loaded as well) and they determine the order the dirs are loaded in (just like multiple entries in one file are read from top to bottom, so are the dirs read in the order specified in the MLF). The order only matters if the definitions depend on each other.

As to the non-existant dirs, those will be provided in the as of now unreleased modules.
 
Top Bottom