CivEffects

[orlanth]

I don't see a problem here

LOL I was just making a joke re the new concept of "Required Pecks" that showed up in your earlier post. It would be perfect for any mods with an Avian race or with YIELD_BIRDSEED.

<RequiredTechsOR>TECH_SARCASM</RequiredTechsOR>
<RequiredPecks>PECK_YIELD_BIRDSEED</RequiredPecks>

Seriously though the idea re requirements for CivEffects rather than techs/perks is good, and the idea to have the potential for whether things go in separate techtree screen (like trade perks currently are in MC) be configurable in XML is also a good one. Alternately, like the Founding Father screen currently has, there could be several "tabs" in the techtree advisor. For mods with a lot of techs that are in separate categories which don't interact much, this would let players easily flip between categories by clicking the tabs.

About the Arrow Color idea, IMO it would be the most useful to have the arrow color consistently show whether this is an AND (white) , OR (grey) , NOT (black) requirement (and whether the requirement has been met or not, in which case the arrow could turn green, or red if a NOT requirement had been met). If possible, the arrows from "OR" requirements could all join at a certain place (such as the bottom left of the techbox) while AND requirements join at another place (such as top left). As a player it would help more to visually see the nature of the AND/OR requirement (plus I imagine XML modders such as myself would be too lazy to color individual arrows between each tech )

 

[Nightinggale]

Alternately, like the Founding Father screen currently has, there could be several "tabs" in the techtree advisor. For mods with a lot of techs that are in separate categories which don't interact much, this would let players easily flip between categories by clicking the tabs.

That's the idea. It allows a single python file and a single button on the main interface and inside it is possible for XML modders to add as many buttons (or tabs) as required.

About the Arrow Color idea, IMO it would be the most useful to have the arrow color consistently show whether this is an AND (white) , OR (grey) , NOT (black) requirement (and whether the requirement has been met or not, in which case the arrow could turn green, or red if a NOT requirement had been met). If possible, the arrows from "OR" requirements could all join at a certain place (such as the bottom left of the techbox) while AND requirements join at another place (such as top left). As a player it would help more to visually see the nature of the AND/OR requirement (plus I imagine XML modders such as myself would be too lazy to color individual arrows between each tech )

That's a really good point. Modders are lazy, which is why the DLL is more and more self configuring

I like the idea of a meaning to the color, rather than a nice layout. I'm not sure I agree with the colors though, but if we define tech screens in XML, complete with different text and background, then why shouldn't be add the colors in XML as well? If a modder wants a gray background, then gray arrows would be silly. If decided by XML, then we will not need to recode anything if it turns out that some colors works horrible together.

As for the types. I kind of like AND, OR and NOT.

• AND: the player has to have all of them
• OR: the player has to have a certain amount of them set in XML (there is an int for this)
• NOT: the player has to have none of those

The check for canResearch has to check each of those individually. If you miss an AND, then you can't research even if you have too many OR.

We need 3 colors for AND and OR:

• requirement present
• requirement needs to be researched
• requirement can never be researched due to NOT conditions

I'm not sure about the amount of colors for a NOT condition.

NOT is to replace the blocked category. Also we should exploit the fact that we have an int for owning techs instead of just a bool. We could set it to -1 if the NOT condition is triggered. This mean canResearch can start by checking if the researched state is == 0, making this part of the code faster. If techs/perks generates a list of what else depends on them, then once one is blocked, it can call everything depending in it to see if they can ever be researched. If we block A and B has A as AND requirement, then B is blocked as well.

 

[Kailric]

I've been reading along even though I haven't made any replies. It all sounds good to me. But it also sounds like a bunch of work, too, but would make a grand tech screen

 

[Nightinggale]

I've been reading along even though I haven't made any replies.

I thought you had jumped ship and was about to hunt you and chain you down to your modder chair. Well since you are here, it's a job well done

It all sounds good to me. But it also sounds like a bunch of work, too, but would make a grand tech screen

Maybe or maybe not. I looked at the code. It's messy, but if it made in steps, then it should work.

1. replace civic with tech
2. fix requirements to use the lists
3. fix arrows
4. figure out a way to make it work on both techs and perks
5. add a row of buttons, which each sets a state to the page (like domestic advisor sets a state with each button)
6. Add to the drawing code that the tech/perk should only be drawn if its state == current screen state.

Interestingly enough step 4 is likely the only one to be potentially work heavy and/or tricky. The multiple screens should be piece of cake once the rest is working.

I intentionally skipped any mention of colors. That's because for now it will just use the colors used in the last release. Some multi color feature is a fancy GUI feature, which could be added once all the GUI stuff works again.

 

[orlanth]

I like the idea of a meaning to the color, rather than a nice layout. I'm not sure I agree with the colors though, but if we define tech screens in XML, complete with different text and background, then why shouldn't be add the colors in XML as well? If a modder wants a gray background, then gray arrows would be silly. If decided by XML, then we will not need to recode anything if it turns out that some colors works horrible together.

True good points. In case you haven't seen Civ4Col has a system for XML-configurable RGB color values that can be set up in XML/Interface/CIV4ColorVals.XML . Other files like Interface/CIV4PlayerColorInfos.xml can then pick colors by referring to ColorVals XML entries. Probably adding a few interface colorvals references in GlobalDefines.xml could be an easy way to allow specifying colors for arrows and other widgets if needed.

 

[Nightinggale]

In case you haven't seen Civ4Col has a system for XML-configurable RGB color values that can be set up in XML/Interface/CIV4ColorVals.XML .

The newest DLL commit adds a JIT array enum type to this file. Not because I plan on using arrays for it, but that enum is used to tell InfoArrays which XML file it should read the types from. In other words InfoArrays now knows how to handle colors. It also mean I added a section in the enum for file based JIT arrays, which aren't used in savegames. That could be useful to expand later.

Probably adding a few interface colorvals references in GlobalDefines.xml could be an easy way to allow specifying colors for arrows and other widgets if needed.

I have added XML files to set up locations in GameFont and language setup. I don't see why I shouldn't be able to add one for arrow colors. I was thinking of adding it to the XML, which defines tech tree screens as that allows different colors to compensate for different backgrounds. However that would make the colors inconsistent. Maybe it would make sense to read a file with default color settings and then use that one whenever the screen in question has left the color blank

We have a number of of options on how to set up colors in XML and how we will do it isn't the most important part right now. What is important is that we want colors and that they should be controlled by XML. Also that colors will be implemented last, meaning we have time to think about it.

 

[Nightinggale]

I have a great breakthrough regarding coding for the GUI. The problem is that the info classes stores data in InfoArrays. This mean python interface needs a bunch of access functions to gain access to each array. The C++ code doesn't have this problem as the access functions returns a const pointer to the array itself.

I figured out how the info classes work in vanilla and added a python class called InfoArray. This mean it should be possible for python to understand what it is supposed to do when it gets a pointer to an InfoArray. All what is needed now to get it working is to add the keyword to the python interface to tell python that it is an existing object, like vanilla does here:

.def("getBonusInfo", &CyGlobalContext::getBonusInfo, [B][COLOR="Red"]python::return_value_policy<python::reference_existing_object>(), [/COLOR][/B]"(BonusID) - CvInfo for BonusID")

This way I only have to add access functions once (already done) and then the python interface can be added without a lot of C++ code

Now that this problem appears to be solved, the it should work once CivEffect gets a python class. It will get interesting to test this considering I will also mix it with class inheritance, which vanilla only use a little bit.

Of all the features I have ever created for M:C, CivEffects has turned into the most complex as it affects so much all over both the DLL and python. It will still be worth it in the end though when everything works and we have the greatest DLL ever created

 

[Lib.Spi't]

EVER CREATED!!!!!!

 

[Nightinggale]

EVER CREATED!!!!!!

Ok, it might be subjective, but it is in my point of view. There are some good BTS ones, but they all lack the detailed civilian setup with professions and multiple yields. There are also some good colo mods, they lack the whole invention part. I want both to be in the game I play, which would make this DLL the best suited for my taste.

One thing I really like about our DLL is that I have added a whole lot of checks into the code. The compiler will complain about lots of stuff if a modder calls the wrong function or something similar, which is likely to cause a bug. This makes it fairly reliable and is likely to stay that way. The same goes for XML data. The DLL asserts if the XML modder is insane and adds values, which makes no sense instead of trying to hide that and provides a misbehaving game.

 

[Kailric]

Ok, it might be subjective, but it is in my point of view. There are some good BTS ones, but they all lack the detailed civilian setup with professions and multiple yields. There are also some good colo mods, they lack the whole invention part. I want both to be in the game I play, which would make this DLL the best suited for my taste.

One thing I really like about our DLL is that I have added a whole lot of checks into the code. The compiler will complain about lots of stuff if a modder calls the wrong function or something similar, which is likely to cause a bug. This makes it fairly reliable and is likely to stay that way. The same goes for XML data. The DLL asserts if the XML modder is insane and adds values, which makes no sense instead of trying to hide that and provides a misbehaving game.

As we say in ole Mexico, muchos buenos!!

 

[Lib.Spi't]

The DLL asserts if the XML modder is insane and adds values, which makes no sense instead of trying to hide that and provides a misbehaving game.

 

[Nightinggale]

I have run into a naming problem. I added CvTechInfo and when I refer to it, I call the variable eTech. The same goes for Perks and the others.

The parent class for perks and techs is called CvResearchCivEffectInfo and is intended for every class, which can appear in the tech tree (which might be even more in the future). Now it turns out that it makes sense to loop that class, but somehow iLoopResearchCivEffectInfo is a poor name.

Do any of you have an idea on a good short name, which provides a decent description for this class?

 

[Lib.Spi't]

I assume the iLoop and CivEffectInfo are all crucial to the understanding of the purpose?

I was going to suggest techtree or some variation of that, but that wouldn't make it any shorter...

could we abbreviate it some, like CivEI of CEffI or somthing along that kind of thinking?

 

[Nightinggale]

I was going to suggest techtree or some variation of that, but that wouldn't make it any shorter...

Shorter isn't the most important factor here. What is important is readable code as hard to read code is more likely to contain bugs, especially when somebody mods it half a year in the future and nobody remembers all the fine details anymore.

Research is kind of bad because it clashes with currentResearch.
TechTree is bad because the tech tree appears to be the main user for this class. This mean that one tech tree contains multiple tech trees. Also if we end up with multiple screens, those would likely be called CvTechTreeScreenInfo. That would clash too.

Oh man, this is ridiculously tricky. I figured out a way to make a "virtual" XML file containing techs and perks, making it easier to loop those. However even though the code is advanced and not seen before, figuring out a name appears to be the hardest part right now

It's unlikely that I will code on this for the next 48 hours. That will give us some time to think about this. Whatever name we come up with is likely something we will be stuck with forever. We should do this right or it will haunt us.

 

[Lib.Spi't]

What about just 'tree' as opposed to techtree.

If I am understanding what this name is planned for (but I probably am not!) this iloop is all about the data used in 'tree' screens? perktrees, techtrees, etc.

Or is the focus of this named code actually about those things that can be 'researched'(As in accumulate points to eventually earn something so FFs and such as well)

If so could we use a word like accumulated, pooled, earned, acquired, yielded, aquisitioned.

Something that represents the nature of made yields being pooled in a place that leads to an acquired 'thing' (FF, Perk, Tech, etc.)

 

[Nightinggale]

Tree

I don't think it hits the spot. I don't want to make another Just-in-time array mess where it is named correctly for the first thing I use it for and then I add all sorts of new features later and the name becomes poorly chosen.

The name here is for an info class, which mean by naming convention, it should be Cv_Info. That _ should be able to stand alone and indicate a loop variable.

The class should be a clear identifier for "CivEffects, which can be researched". It is a "code block", which adds tech tree X,Y coordinates and requirements. Nothing else. Since the requirements are used elsewhere (most noteworthy in canResearch()), then calling it tree is not that fitting. Also it might be expanded for anything else, which is needed by both techs and perks.

this is annoying to spend time on such a silly issue, which is unrelated to coding issues or gameplay.

 

[Lib.Spi't]

what about, path or pathed civeffectinfo. or chain/chained

representing the idea that they have a requirement that precedes it in it's path/chain...

as well as being visually represented in a path/chain in the tree screens.

or connected/connection, Required/requiring, link/linked, tied, string/strung/roped, thread/threaded, linial/line/lined....

 

[Nightinggale]

I will stick to CvResearchCivEffectInfo for the time being. I don't like it, but I don't like any of the proposed names either. It will likely be renamed at some point, but right now I'm more concerned with getting the code to work and don't want to stall on a naming issue.

Ideas are still welcome.

 

[Kailric]

So, is the current build on sourceforge playable? What exactly are the tasks that can be done for lay coders at this point?

 

[Nightinggale]

So, is the current build on sourceforge playable?

Sort of. I'm still working on the tech screen. It's almost working locally, but the almost has prevented me from committing it.

What exactly are the tasks that can be done for lay coders at this point?

Look though the XML files in CivEffects and see if they are set according to how you would expect it to be set.

Another task is to fill out the functions in CvGameTextMgr_CivEffect.cpp. I have added the structure to display the help text for the different CivEffect classes, but the actual text still needs to be added. The task here is to look at the function for each class and add text for each get function in the class header, preferably in the same order.