Quick Modding Questions Thread

[Dancing Hoskuld]

Could someone explain how iFlankingStrength works in Unitinfos?

As far as I can see that is not a standard BtS tag. It could be from Revolutions, or Dale's mods, or Afforess' stuff for RoM. Checked does not look like it is Afforess's stuff.

 

[<Nexus>]

As far as I can see that is not a standard BtS tag. It could be from Revolutions, or Dale's mods, or Afforess' stuff for RoM. Checked does not look like it is Afforess's stuff.

I don't know it's origin but it is in C2C too. Sometimes it's 50, other times it's 100.

 

[Kjotleik]

From the CIV4UnitInfos.xml in BTS 3.19. This is the Horse Archer entry.

My guess is that it is the strength of the unit (in % compared to the iCombat tag) when doing flanking-damage to the particular unit mentioned in the FlankingStrikeUnitClass.

If not, the developers didn't name their tags using common sense...

 

[merijn_v1]

iFlankingStrength determines the amount of damage done to the flanked unit compared to the damage done to the attacked unit. It uses the following formula:
Flankdamage = (40 * iFlankingStrength) / 100

So if you attack a unit and do, let's say, 40 hitpoints damage, you will also do 40 hitpoints damage to the flanked units. If you have a flankingstrength of 50, you will only do 20 hitpoints damage to the flanked units.

 

[Leoreth]

How does the game load Python modules? For the longest time I assumed it would simply load all *.py files in the Python folder, but that does not seem to be true. Usually a module is imported by another module which ensures it being loaded, so there's not much of a difference.

However, recently I learned that the BugEventManager allows having functions subscribe to an event, which is much cleaner than having a central module delegate event calls into submodules. The only issue is, when all a module does is subscribe to and handle a bunch of DLL events, there's no need for another module to import it, so it doesn't get loaded.

Of course I could import it from any arbitrary other module, but that kind of defeats the purpose of doing decentralised event handling like that. So how does the game go about loading modules? Where does it start? I would at least like to keep my dependency tree short with those modules.

 

[Leoreth]

I guess it is CvEventInterface.py and everything flows from there through the imports of your given event manager module?

 

[lfgr]

I recently added a new python file in python/entrypoints that is only called from the DLL, and that one works fine. Maybe a module gets loaded when it is referenced by a call in the DLL (or exe).

Doesn't the BUG mechanism of registering event handlers via XML work for you?

 

[Leoreth]

From how I understand it, it doesn't. That's because what I'd like to do is this:

# Events.py
from BugEventManager import g_eventManager

def handler(event):
    def handler_decorator(func):
        g_eventManager.addEventHandler(event, func)
        return func

    return handler_decorator

# Handler.py
from Events import handler

@handler("BeginGameTurn")
def function_that_is_called_every_turn(*args):
    # code here

@handler("BeginGameTurn")
def another_function_that_is_called_every_turn(*args):
    # code here

# and so on

Basically the idea is that you shouldn't have to think too hard about registering functions and delegating their calls between modules, and it's simplified to adding a decorator with the event type to be handled.

But this makes every Handler.py module transitively import BugEventManager. So if I load it from BugEventManager, I get a circular dependency. For the same reason, BUG's event handler registry doesn't work for me either, since it is triggered from BugEventManager as well (via the PreGameStart event, iirc).

But you're right, EntryPoints is exactly where everything originates, containing all the Python files being called from the DLL.

 

[lfgr]

So if I load it from BugEventManager, I get a circular dependency.

You could import Handler.py at the end of BugEventManager.BugEventManager.__init__(). That way g_eventManager should be already created when Handler.py is loaded. But that's maybe not the most robust construction.

Basically the idea is that you shouldn't have to think too hard about registering functions and delegating their calls between modules, and it's simplified to adding a decorator with the event type to be handled.

Just to make sure I understand correctly, you want to avoid the following config file (untested), because you don't want to register every handler function in XML, and use decorators instead?

<?xml version="1.0" encoding="ISO-8859-1" ?>
<mod id="Handler" module="Handler" [...] >
   <event type="BeginGameTurn" function="function_that_is_called_every_turn"/>
   <event type="BeginGameTurn" function="another_function_that_is_called_every_turn"/>
</mod>

 

[Leoreth]

Yeah, I don't really like the declarative XML style that BUG seems to encourage.

 

[Dancing Hoskuld]

If you are using the BUG modular python stuff then don't you define it in BUG's config/init.xml? That is how I have set it up before. Of course I don't modify the dll at all. I just do python and xml mods.

This way BUG handles all the integration stuff.

 

[Leoreth]

I'm not really using it. When I merged BUG and RFC code many years back, I didn't really want to refactor the entire existing RFC codebase, which heavily relies on event triggered logic. Also, I don't think I really understood that's how it was supposed to work back then, and I just wanted to make BUG work. RFC had its own huge event handler module hat implemented all the handler and then fanned out function calls to all the other modules. I am currently making the effort of refactoring all of that so each module does decentralised event handling. However, now that I am actually making the effort of rewriting the code I don't think BUG's way is the right thing to do either. I don't want to have to add each function/method into an XML config file and create a dependency that way that is neither readily apparent nor easy to refactor when I make code changes later on (for example, I run mass search/replace on Assets/Python, where function names in config files would not be found). A decorator is placed right at the function signature and makes it a) obvious that this is an event handler function and b) automatically respects renaming/deleting.

 

[topsecret]

So I've added some units that can be attached like Great Generals, but when one earns a Great General, sometimes you get the other units instead. Does anyone know where to find the code for this so I can just hardcode it to prevent it from happening?

 

[<Nexus>]

Is it possible to when building a wonder than play not a specific wonder movie but one randomly from a certain list? Like units play random sounds when selected, given orders, etc.

 

[<Nexus>]

Anyone knows a good model that could work as a Suburb improvement (upgrade from Town).

I tried to copy-paste things from Town but the results are these:

Spoiler :

Ancient era

Modern era

As seen in the above pictures stays as a humble ancient cottage(?)

 

[Leoreth]

I can't help you because PlotLSystem is still a mystery to me, but are those screenshots from AND? Vanilla Civ and most mods handle modern cottage/city fluff buildings very awkwardly, where all buildings are suddenly skyscrapers even in the smallest cottage and as if all older buildings had suddenly disappeared. I always thought it would help realism and regional flavour to keep old building art around more even in later eras, and this seems to do that. I would love to be able to adapt some of that work.

 

[<Nexus>]

are those screenshots from AND

Yes, my modmod is based on AND2.

 

[<Nexus>]

It clearly works in C2C but I don't understand the trick

 

[<Nexus>]

Here's my CIV4PlotLSystem file, maybe I miss something obvious.

 

[Vokarya]

Here's my CIV4PlotLSystem file, maybe I miss something obvious.

I don't see anything wrong there, but is your <bUseLSystem> tag set to 1 in the CIV4ImprovementInfos.xml file? I think that's required to use the PlotLSystem.