Interface Comparisons BuG(and common merges) Vs Platypedia

[stolenrays]

BULL changelog lists the explanations for many of them if you want to add the definitions to your first post.

 

[Lib.Spi't]

Yeah I went looking for the BULL changelog, but I could not find it, every link I clicked seemed to take me somewhere with hardly anything in it...

 

[stolenrays]

I'd download the full Mod. The changelog is in it. In addition, if you look in the text files of the changelog, it has a thorough explanation of all the options.

 

[Lemon Merchant]

That is the bit I am struggling with at the moment, figuring out how all these bits work, whether pure sdk or if they have python content or pure python, and how all these bits hook into and work with each other..

AFAIK, all of the BULL bits have a supporting Python and XML component. BUG itself is entirely Python/XML based with no DLL components.

 

[Lib.Spi't]

Yeah my problem right now is attempting to figure out how to switch off BUG and then try switching it back on again with only the bits I want...

The whole process is just exhausting though and I am frankly rubbish at it!

 

[stolenrays]

Yeah, BUG allows via the options screen to turn on/off the components you want. However, as a mod merger, I have always found it to be very difficult to merge with other mods. Especially if the interface codes overlap or I want to permanently remove a BUG component.

The BUG code is spread over so many different files, it makes merging one part difficult for me (Great Person bar has code in GPUtil.py, MainInterface.py, FontUtil.py, etc.)

What I'm doing with my IIW Mod is adding a graphic option for the BUG components I can successfully merge. The BUG options code is spread over several files, but a checkbox options needs only one string of code. My version may not be as grouped or complex right now, but I find it easier to merge/code.

 

[platyping]

Splitting codes into multiple files has the advantage of making it easier for yourself to find what you need, and if a bug occurs in say, unit page for pedia, you know you won't need to analyse the data in building screen.

Also, for screen interface codes with handling input effects, you can be sure clicking a button in unit screen will not trigger a code in building screen.

That is why the pedia is split across 10+ files and I did my WB in similar way, while you noticed the BTS WB is just one file and another for diplomacy.

However, sometimes it can be counterproductive if you have alot of components in a same section.
In my gigapack with 200+python wonders, it makes more sense to code everything in just the event manager file, rather than split across 200 files.
This way, I don't need to open 5 files just to know what is the end result when a unit is built.

 

[Lib.Spi't]

Hey stolen,

have you had any success with your efforts?

Mine have thus far ended in faliure.

I tried to aim a little lower and just go with platypedia for now, and although I can get it to work I end up with python errors in game because of BUGs sevo pedia stuff (I think) As far as I can they don't break anything i actually use, it is just annoying to start the game with a stack of errors...

I don't have the energy to properly remove sevo, finding all the parts that need to be removed...

 

[Monaldinio]

Wrong thread...