BUG and WoC

[ruff_hi]

As you know (or should know) BUG is all about unaltered game play. That is, unaltered in that no spoilers allowed, no additional units, no additional civs, no additional buildings, wonders, etc, etc, etc. Our aim is to provide you, the playing (not the 'l') public with a game that is just like the core BtS just looks nicer, pulls info out easier, etc. Further, we also aimed at making all of the mod-components that we added, optional so that you can disable them of you don't want them.

Another mod "World of Civilization" has a not dis-similar aim except the are more than ok with including mods that really do change the core game play.

Well, NikNaks93 sent me the following PM ...

Hey guys,
Has anyone ever asked you about joining the World of Civilization project? We offer many features which may be of use to you, probably the most interesting for you is the new "Modular Python". One thing you probably won't like is the DLL, but we're trying to incorporate as many SDK mods as we can so that we don't alienate anyone.
So what do you guys say? The offer's there.

NikNaks

We've had some internal discussion about this and really wanted to get your feedback (our target audience) on this. If we do merge (IF!!), then the biggest difference would be that BUG would adopt a custom built DLL that would open the door for some additional flexibility. The basic BUG approach of 'unaltered' would remain, but you would just have to trust us to a larger degree than currently about the 'unaltered' nature of BUG.

Ideally, BUG should be able to run without the the DLL ... I would expect that we could include some code around any new features we add ...

Spoiler :

try:
   bDLL = DLL.isThere()  #<-- always returns true
except:
   bDLL = False

if bDLL:
   funky new commands

... to handle if the user didn't want to copy in the DLL.

Thoughts / feedback / comments / other?

 

[alerum68]

Ruff, I don't know if I said anything about this in the mailing list, but I am very strongly against this. I have no problem with WoC taking the BUG Mod, and working around that, but I do not think adding a .DLL that cannot be viewed without extensive coding skills, should be including in BUG. So if WoC wants to have BUG included with their projects, I am fine with that, but not with adding WoC changes to BUG.

 

[·Imhotep·]

BUG should stay as it is. Just my opinion.

Imhotep

 

[Amra]

I have no problem with WoC taking the BUG Mod, and working around that, but I do not think adding a .DLL that cannot be viewed without extensive coding skills, should be including in BUG. So if WoC wants to have BUG included with their projects, I am fine with that, but not with adding WoC changes to BUG.

What he said.

 

[ripple01]

Cheers,
ripple01

 

[ruff_hi]

Ruff, I don't know if I said anything about this in the mailing list, but I am very strongly against this. I have no problem with WoC taking the BUG Mod, and working around that, but I do not think adding a .DLL that cannot be viewed without extensive coding skills, should be including in BUG. So if WoC wants to have BUG included with their projects, I am fine with that, but not with adding WoC changes to BUG.

I totally agree with the BUG with no DLL point. What I am trying to sound out is if it BUG should do the python work for WoC while WoC does the DLL stuff (if and only if BUG runs when you remove the DLL). I think this could work if we could ensure that BUG runs fine if the DLL is missing (using the code snippet from above).

If someone from WoC can create a totally clean DLL with a function as outlined above, then I could test to see if our python would run if the DLL was missing and if it was there.

That way, any block of code that requires the funky DLL would have an ...

if bDLL:
  non unaltered game python code

... or similar wrapped around it. That would at least show that it is technically possible to do this.

 

[alerum68]

The way BUG is set up now, WoC should be able to take it as is, and do what they want with it, with their own .DLL. I think a few of our longest users gave their thoughts on it as well. I could see helping them with taking BUG and doing the changes they need and making it their WoC "core", or something like Fall From Heaven did, but I don't think it's a good idea to take their .DLL in our code.

 

[CellKu]

The way BUG is set up now, WoC should be able to take it as is, and do what they want with it, with their own .DLL. I think a few of our longest users gave their thoughts on it as well. I could see helping them with taking BUG and doing the changes they need and making it their WoC "core", or something like Fall From Heaven did, but I don't think it's a good idea to take their .DLL in our code.

I completely agree with that.
I like BUG very much and have used it for quite a while now (thanks especially for the recent Sit-Rep addition to the MA - really great!). I would feel uncomfortable if there was an additional DLL for BUG (for example I wouldn't be sure whether a SG game could be played without problems by another player who doesn't have BUG). If, however, you want to do some work for WoC which is completely independent of the original BUG, I would have nothing against that. But I doubt that this was what you intended to ask with your question.

P.S.: Since that came just to my mind: Does the new version of BUG creates a problem with logging for non-BUG users if one SG player uses BUG?

 

[NikNaks]

Hey guys, thought I'd add my two cents:

I could see helping them with taking BUG and doing the changes they need and making it their WoC "core"... snip

If you'd actually be willing to do that, that's absolutely fine with us, and we'd very much appreciate it.
Of course, using Ruff's idea, you could omit the DLL, but keep both versions the same, as the code we put in will be completely ignored.

 

[alerum68]

CellKu - AFAWK it's gone. We haven't had anyone bring it up in a very long time. But that could be due to the fact that not many SGs are played with BUG Mod without permission because of that bug. I'd love to see some SGers testing it out for us again. (hint, hint)

NN - We still need input from EF, and he's gone for a few more days, but I don't really see him agreeing to add the dll. As for helping WoC intergrate BUG, I guess we'll need to know what your team is having problems with, or how you want to use BUG. Maybe you could have a few of your designers post here, and let us know what you were thinking.

 

[Cammagno]

Ruff, I don't know if I said anything about this in the mailing list, but I am very strongly against this. I have no problem with WoC taking the BUG Mod, and working around that, but I do not think adding a .DLL that cannot be viewed without extensive coding skills, should be including in BUG. So if WoC wants to have BUG included with their projects, I am fine with that, but not with adding WoC changes to BUG.

I agree 100%

 

[Balderstrom]

From what I see of WoC - is that it is modular. So if BUG joined WoC, bug could still remain as a distribution point, releasing without any of the modular add-ons that change gameplay.
BUG as a subset of WoC, all the current advantages of BUG + modular, would really be ultimate.

Too many modders still don't do modular code, and redistribute modified game assets instead.
Theres a number of mods out there that look really interesting but they deign to tweak or ream game mechanics along with their neat ideas. Which is a real turn off.

What should be considered as well, is most of us use a modified DLL already to incorporate Bhruic's fixes.
The ability to utilize modular python is nothing to sneeze at.

Modular really is the way to go. An incidental added advantage would be when CIV5 is released, a lot of the modular code wouldn't need 100% rewrites to be usable.

 

[EmperorFool]

Damn, I missed this thread. "Subscribe to forum" doesn't do what I thought -- it misses new threads.

In any case, I looked over the WoC forum and still don't see how it relates to BUG. BUG is all Python, and the little bits of XML that are there are simply to add text to the interface.

NikNaks93, could you please explain how you envision using the Python stuff from BUG in WoC? I recall your initial description saying "modular Python", and if that's correct, can you elaborate.

Modular as I see it doesn't easily apply to Python (or any) code as it does to XML. In XML, you are adding or replacing discrete entities:

• Add a new unit "Bob"
• Replace the "Maceman" unit with new graphics

With code, the changes are more like editing a book than adding/replacing discrete objects:

Frank ran across the street bolted into traffic and pushed knocked Mary out of the way of the oncoming truck , saving her life. The crowd howled in praise. He was a true hero.​

This is difficult to apply in a modular fashion given how the code is written, and it simply doesn't work if multiple mods edit the same Python file. Unfortunately, Firaxis didn't split up the modules enough. CvMainInterface.py includes the City Screen, so two seemingly unrelated mods -- Attitude Icons in Scores and Raw Commerce -- both modify the same file. A human can merge their changes together fairly easily, but the game cannot.

Now, we could certainly embark on an epic mod that rewrites all of the interface code in a way that would allow modular modding. It would make merging in any future Civ4 patches extremely painstaking. That's a huge effort, and I'd rather just continue down the BUG path of making each addition optional (yes, Ruff, I'm working on PLE ) unless Firaxis wants to hire me to do it.

 

[NikNaks]

Well, our version of modular Python isn't brilliant, in fact your way is probably better (i.e. writing the code into an INI). What we like to try and do is make all the decisions through XML, not through INIs and actual codeblocks, so is it plausible to recode the INI configuration to use the GlobalDefines XML?

Second of all, our coders are far too busy with SDK work to work with Python, especially not the interface, so we're looking to improve that side of the mod. We only have around 5 or 6 changes to the interface at the moment, and they aren't really aesthetic. I would try myself but I'm a codetard.

So, what would work for us is changing the INI configuration into XML (if possible), perhaps using our SDK if necessary, and just incorporating the mod into our core in general.

Is that what you were asking?

P.S. Subscribing to a forum means it is displayed on your My Account page, and when there are new posts/threads, this icon appears to the left:

so that you can click on the link and access the forum to look for the posts. The individual threads don't get subscribed at all, you have to do that manually.

 

[EmperorFool]

Is it plausible to recode the INI configuration to use the GlobalDefines XML?

Sure, that should be possible. The downside is that you cannot save changes to XML without considerable DLL work. We could split out "options" from "configuration" in that you'd configure whole code paths to be on/off outside the game (enable PLE, enable Logging, etc) using XML and change "options" using INI settings while the game is running.

But I wonder if that's reasonable. If it's all modular, you'd install PLE if you wanted it. You wouldn't then turn it off or you wouldn't have installed it in the first place. But then maybe I don't understand the central point to WoC. My view is that it's to make installing several disparate mods easier rather than making it easy to turn on and off those mods from game-to-game.

This is based on my typical use case, which is adding interface mods. I always want them running. I don't play a new game and think, "Hmm, perhaps I'll play without the Advanced Scoreboard today." The story would be different if I were using gameplay-changing mods. But then again, those would probably be installed as actual mods, so I wouldn't need to turn them on or off -- I'd load the full mod.

Could you give me an idea of what you'd like the user to be able to do given modular Python?

So, what would work for us is changing the INI configuration into XML (if possible), perhaps using our SDK if necessary, and just incorporating the mod into our core in general.

Obviously I support WoC integrating BUG into its core as other mods have done. The real question is do I have time to do this work for WoC, but I have a considerable BUG backlog as it is. What would be the gain to switching from INI to XML?

P.S. Subscribing to a forum means it is displayed on your My Account page. . . . The individual threads don't get subscribed at all, you have to do that manually.

Thanks for the clarification. They shouldn't call it subscribe then since it performs an entirely unrelated operation. I use the emails for new posts so I don't have to load the forum page all the time, but I guess that option is out.

 

[NikNaks]

Sure, that should be possible. The downside is that you cannot save changes to XML without considerable DLL work. We could split out "options" from "configuration" in that you'd configure whole code paths to be on/off outside the game (enable PLE, enable Logging, etc) using XML and change "options" using INI settings while the game is running.

But I wonder if that's reasonable. If it's all modular, you'd install PLE if you wanted it. You wouldn't then turn it off or you wouldn't have installed it in the first place.

Ideally, that's what we'd aim for, but with Python, it's evidently not feasible to do things like that. However, by default, all the WoC modules are disabled, so you'd really be "turning it on if you want it", not being forced to use it.

But then maybe I don't understand the central point to WoC. My view is that it's to make installing several disparate mods easier rather than making it easy to turn on and off those mods from game-to-game.

It's a little of both really. All mods should be able to be played together, and the end user can decide which combination to use from game to game. Also we have a cool little utility which means that if you try and load a save-game with a different combination than the saved game has, the code reloads the correct module set so that the game can continue.

This is based on my typical use case, which is adding interface mods. I always want them running. I don't play a new game and think, "Hmm, perhaps I'll play without the Advanced Scoreboard today." The story would be different if I were using gameplay-changing mods. But then again, those would probably be installed as actual mods, so I wouldn't need to turn them on or off -- I'd load the full mod.

Although I see no reason why you'd want to disable BUG, or any part of it, our goal is to make everything optional.

As for the "full mod" idea, if you don't want change X, but you do want changes Y and Z, you can pick and choose which ones to have enabled, instead of having to use everything that a modder decides.

Could you give me an idea of what you'd like the user to be able to do given modular Python?

In an ideal situation, you'd be able to have the disparate snippets of Python code stored in the Modules folder and have them enabled/disabled by moving the folder itself. Zebra 9's zModular Python doesn't support screens, so unfortunately that isn't an option. But the compromise we take with the SDK (disabling through XML) is probably the best bet.

Obviously I support WoC integrating BUG into its core as other mods have done. The real question is do I have time to do this work for WoC, but I have a considerable BUG backlog as it is. What would be the gain to switching from INI to XML?

Well, from your point of view there wouldn't really be one, I imagine. If you could point me in the right direction as to how I might do it (perhaps one example?) I could see if I can make it work. From our point of view, it means that BUG can work in the same way as our DLL-based mods, so that each can be enabled and disabled through the modules folder.

Seriously, one example might be enough to give me the initiative to get on and give it a go myself.

 

[Balderstrom]

The main issue I have atm, is PLE - which if you read thru the code. And read thru the actual readme. He is doing definitive hacks to get around limitations in creating a UnitStack. One of the hacks is the code actually MOVES units 'away' to 'some other tile' - creates the stack based on the current filter-et-al, then MOVES the unit back...

If there was some SDK work, broken things like being able to pass an argument to the C's createStack cmd from python's accesspoint would get rid of a lot of unnecessary code.

As well the PLE code recreates a number of things like getXP amongst others, that already exist.

3000 lines of code have been added to CvMain...and we wonder why 2.30 is less stable than 2.22...

 

[NikNaks]

Well, PLE is one of the things that would be better done in the SDK, which I'm sure we will, similar to what we did with the Unit Statistics mod.

 

[Balderstrom]

Honestly, I wish these larger game companies would just license DGD LPC.
You get to write atomic runtime C code that supports Objects, definitive debugging, mapped arrays, all code updateable in realtime, cleanly interfaces with C or C++ without writing a slew of wrapper functions, etc etc ;-)

 

[EmperorFool]

As well the PLE code recreates a number of things like getXP amongst others, that already exist.

The reason for functions like these is that the game engine isn't concerned with supplying information about the future; it's only concerned with the game state right now. I faced the same issue when working on my Whip Assist (as yet unfinished) mod that will tell you the optimal times to whip (max overflow ). I had to replicate the C++ calculations in Python so they would run into the future.

Note that you'd face the same issues had they used LPC. Unless they specifically wrote functions to predict future values, PLE would have had to write new LPC functions to do just that.

I would say they probably chose C++ and Python to leverage people's existing knowledge of those languages. It's also a lot more likely for someone to pick up Python than LPC (useful outside of gaming* and--from my 5 minute perusal of LPC--easier to learn with more available information).

* I know LPC can be used to write other types of software, but I doubt Google is going to start using LPC for Gmail any time soon.