Working On zModular Python, Any Feature Requests?

Zebra 9

Emperor
Joined
May 17, 2006
Messages
1,554
Location
Middle of Cyberspace
I have no clue how much people have used my zModular Python, but thanks to a request for me to modularize a few MODs I have decided to make an update.

For those who don't know, what zModular does is make python mostly modular. Screens are not easily modularized, so I do not provide screen modularization. It's built on Dr. Elmer Giggle's Custom Event Manager but adds similar functionality for the I CvGameUtils. It also adds a dynamic file loader that searches for Managers and dynamically loads them. The drawbacks are:

  • there are specific things required in the Modules
  • module names can really mess up stuff if they have the same name as another python file
  • CvRandomEventInterface is not modularized
  • Modules can't interact
  • there is no way to disable a module without removing it
  • and there is no way to ensure your CvGameUtils code will be run
I'm sure there are other problems, but these are the ones I have found and can remember.

So I plan to fix these and was wondering if you guys had any ideas or suggestions. :D

P.S This will probably include some SDK changes so no idea is too far fetched and for that matter too simple.
 
The only other problem i remember, is, that the CvPath will crash, if it doesn't find a registry key, or can't get access to it.
-> remove that. There should be commands, to find out, where the file itself is located, without needing a registry key.
 
Yeah but it uses the registry key to find the My Games directory for the actively logged in Windows user. Is there an alternative method that has been found? I'd love to change it because the CvPath system is a bit hackish IMO. ;)

P.S. Why wouldn't you be able to access the necessary keys?
 
BUG already provides a lot of capabilities for modular python loading already. Have you seen the way it works in BUG? I don't use a lot of the capabilities, but it works great for event manager stuff.

Also, if you haven't discovered Dom Pedro's Mod Helper for Python Modders, you should definitely keep that in mind. It also provides a great way to modularize python by adding specific xml flags.
 
Wow, how long has BUG had that? Its got the basic idea down just isn't as far reaching. Thanks for pointing that out to me.
 
I found this project recently (after modularizing CvGameUtils sadly, though it was fun to do) and was impressed. Given my goals when designing BUG (first build a good mod, next provide tools to allow other modders to build atop BUG), I opted for the control of a centralized registry of modcomps (the XML configuration files) rather than drag-n-drop merging.

For one thing, I modified many of the original modcomps when first creating BUG, sometimes tying them together (e.g. Reminders can show up in the Autolog). Second, all the features in BUG make heavy use of the options system, so there's no real need to pull out a module once it's merged: just turn it off in the options screen.

The downside to the large set of core modules is that it's a little heavy to build a single small modcomp on top of it. I was tempted to extract all of the core modules, removing all of the BUG features and leaving just the initialization and configuration logic, but I didn't see much benefit to doing that. A lot of mods that build on BUG as a base want the features in BUG and use the core because there's no alternative. :mischief:

Given that the screens really can't be modularized and a majority of BUG's features are in the screens and main interface, there really seemed no point to modularity. Now that I've been spending more time helping modders work on game-altering mods, I see where modularity can pay off. BUG used a custom version of Dr. EJ's event manager from the start, but I added BugGameUtils pretty recently.

You might want to take a look at BugGameUtils. One thing I did differently from your version is that each callback registers its default value (if it has one). One callback can have several handlers which called one-by-one until one returns a non-default value. Each can also have multiple listeners--functions that get called with the value that is going to be passed back to the SDK. It's probably a bit overkill, but it was fun code to write. I liked that you checked the callback XML to make sure the registered callbacks were enabled (is that right?) and was thinking about actually enabling them automatically with gc.setDefineINT()--or maybe that's what your code does.

In any case, good luck on adding some new features to your modcomp.
 
You might want to take a look at BugGameUtils. One thing I did differently from your version is that each callback registers its default value (if it has one). One callback can have several handlers which called one-by-one until one returns a non-default value. Each can also have multiple listeners--functions that get called with the value that is going to be passed back to the SDK. It's probably a bit overkill, but it was fun code to write. I liked that you checked the callback XML to make sure the registered callbacks were enabled (is that right?) and was thinking about actually enabling them automatically with gc.setDefineINT()--or maybe that's what your code does.

In any case, good luck on adding some new features to your modcomp.
Wow, I just looked at Bug 4.0 (had to download it cuz I had 3.6) and wow. Cool stuff. I was wondering how BUG identifies modules because I can't seem to find a file search? I'm wondering because I would like to see how other people do it. :)

My GameUtils works similar to yours it just doesn't doesn't have listeners, at least the released one doesn't. When a callback is called it calls callbackHandler and passes the default. In the future I hope to go for a registered system rather than my precoded system.

Actually mine doesn't check the XML callback. It just toggles it on. My logic is that if a MOD COMP registers a handler they want that callback to get called.

My goal has been to make a MOD COMP that allowed MODers to make MOD COMPs without having to touch files needed by every MOD COMP. It looks as though BUG does this but I think I'll finish this since it is lighter weight.

Thanks :)
 
All of the configuration is driven by init.xml which can load other XML files using the <load> element. Some modules in BUG depend on other modules, so it was necessary that I be able to control the order of initialization. At some point I'd like to make it so all the XML files in the Config folder are loaded automatically and be able to specify which other modules they depend on.

Other than init.xml, modders don't have to touch the same files in BUG either. BugConfig adds event handlers to BugEventHandler and callback handlers to BugGameUtils, etc.
 
P.S. Why wouldn't you be able to access the necessary keys?

1) Mac users
2) Other keys. Steam, CivComplete, etc. have other registry keys
3) No administrator rights.

2+3 just bring it to crash, no idea about 1.
 
Oh right, I forgot about CvPath. For BUG I rewrote it as BugPath to get around 1 and 2. If you need administrator rights to gain access to your My Games folder, you've got bigger problems. :p
 
Oh right, I forgot about CvPath. For BUG I rewrote it as BugPath to get around 1 and 2.

Already seen, good work, but will not prevent possible problems in the future.

If you need administrator rights to gain access to your My Games folder, you've got bigger problems. :p

Not the "My Games" folder, the programs and windows folder ;).
I had the problem, because i'm going online with an account without administrator rights, and tried to load a savegame, and strange effects occured. These effects also occured sometimes on other persons pcs (and they had administrator rights), so i had to remove zModular python, sorry Zebra :(.
 
Already seen, good work, but will not prevent possible problems in the future.

Well, I obviously won't claim that BugPath is safe for all possible problems in the future, but do you have anything specific in mind that might help both of us?
 
Reading your post, i hope, you didn't take my last post as an offense, that was not intended :(.

And no, sorry, i didn't think of anything specific, but i just can't believe, that there's no other way to get the username. Okay, did a quick google search, nothing on the first pages.

...but what comes to my mind...the civ4.ini in the BtS folder is just a link to the real .ini in the my games folder, and that depends on the user, who's logged in. Maybe there's a chance to get it.
 
Reading your post, i hope, you didn't take my last post as an offense, that was not intended :(.

No offense taken at all. Your wording simply intrigued me as it seemed you were hinting at a problem you were anticipating. I was just being cheeky with my opening. :mischief:

...but what comes to my mind...the civ4.ini in the BtS folder is just a link to the real .ini in the my games folder, and that depends on the user, who's logged in. Maybe there's a chance to get it.

This is a good observation, and I spent some time looking for a Python module that could extract the path from the .lnk file. Unfortunately, I didn't have any luck. :(
 
Ah, I see. I figured the third but hadn't thought about the other two. Would it be possible for me to use the BugPath in my MOD COMP?

What kinds of strange effects?
 
If you strip out all the BugUtil calls (logging), it may be usable. I made some changes for BUG 4.0 in where the INI files are looked for, and that might cause issues. But you might be able to extract just the stuff that looks in multiple places for the My Games folder more easily.
 
I just wanted to say thanks again. The one problem I have with BUG is either you have BUG take over python or you don't have it all. I would like to see a drag and drop in modules to automatically turn it on and allow BUG to still be configurable. It may or may or not be possible.

I am hoping there could a full fledged modular python side to match with the WoC modular xml in the modules folder. The point being that nothing would have to be done to merge BUG into mods other than drag it into the modules folder. It would be nice in the paths could for ini files could be to a ini inside of a self contained BUG folder. But again I don't know enough to know what can be done. Some things will probably have to stay in the python folder, but what turns them on and off is really the main issue and so simple to merge that someone does not need to use a python editor even.

Revolution's python I was hoping as well could be done into a subfolder that is inside of a Revolution folder that is dragged and dropped in modules. The Revolution game options not showing by default I thought and the xml definitions changed once loaded from modules.

I know this would help greatly with people trying to make completely self contained modules. Thanks again.
 
The main hurdles to having completely modular Python are pretty high. First, the interface just isn't going to be modular. Probably the best we could achieve would be to have the ability to add tabs to screens, but that would require rewriting those screens entirely. And I know of very few mods that consist of just adding/replacing a tab to a screen.

As for having .py files outside the Python folder, that is controlled by the Python interpreter. Civ4 initializes it with a set of system folders (like a system path for finding applications), all the folders under Python. It may be possible to add new folders to that set, but then you need to deal with name conflicts (if that's possible).

The only truly modular parts that I've seen so far are events and game-utils. I think random events could be made modular with some Python trickery, but I don't know how many mods there are that add new events. If this would be something very useful, I'd consider adding it to BUG.
 
Top Bottom