CivEffects

[Lib.Spi't]

The other reason I asked (and just remembered) is that currently FF points (In a Specific Category) only do FFs OR Perks.

Trade FF points go into Trade Perks and there is no Trade FFs.

The other ones all just go to FFs, No perks.

wait.. trade perks number resets to 0 each time, FFs too..

So having a do you buy a perk or do you buy an FF system would already be doable, we would just need to change it from the 'Pre-choose and Fill System' of the Perk/Tech system to a 'Do you want to Buy?' System like the FFs.

Otherwise, you will always be filling perks, and never be able to 'buy' FFs..

Does that make sense?

 

[Nightinggale]

I see 3 solutions.

1: excess player points goes to team

2: player points are copied to team, like gaining one military point will give the player and the team one point.
In this case excess player points will be wasted.

3: CivEffects will gain player points as gift.
This will allow perks (and other CivEffects) to provide X points of Y points to the player once researched. Being a list, it can provide 50 military points and 10 trade points or whatever we want it to deliver. Quite possibly this gift should be possible to provide on research and for first to research, just like free units.

Using an XML switch between 1 and 2 and always enable 3 with the default 0 value would push the design decision to XML rather than the DLL. We would still have to make the decision, but the different mods would no longer have to agree on which solution to use.

 

[Nightinggale]

The other reason I asked (and just remembered) is that currently FF points (In a Specific Category) only do FFs OR Perks.

Trade FF points go into Trade Perks and there is no Trade FFs.

The other ones all just go to FFs, No perks.

That is the current XML setup. The goal is to free the DLL of this limitation and allow perks to be researched with any type of FF points. This mean I'm not planning for the current XML layout, but rather for what the DLL should be able to handle. The DLL is intended to be versatile enough to set up the game in a reasonable fashion regardless of what crazy ideas the XML modders might come up with in the future. If coded correctly, people can do stuff in XML, which nobody thought about at the time of coding and no new code will be needed.

But you are right. The current setup will never end up in a case where a single point type can be used for both categories. This is part of the reason why the problem exist. The current DLL avoided the issue purely with XML setup and it will not respond like you think if you start to unlock using any type of FF point for perks (trade techs). It also shares the trade points in the team, which mean two players on the same team can join forces and research a trade tech, which is then given to just one of the players, not both. That issue is solved with one player on each team and add more (like vassals) can cause issues here.

 

[Lib.Spi't]

2: Would the points be wasted? Or simply be part of the flow..

In other words, with 1: your FFs only get the excess points. (lets say 3 out of 23) but 2: You get you get all 23 points.. no?

Or is it something like the 'send FP to FF pool trigger' is only called at the end of a tech discovery, and just reads the FP price of the tech and copies that to the FF pool, rather than looking at the rate of FF production.

3: Seems like a good possibility, and may remove the issue I was seeing and explained about counter productivity, in that producing a military tech that needs 20 War FP, but then gives 30 War FP on completion, would see that a Nation constantly thinking about War IS more likely to Produce a great War Thinker..

 

[Nightinggale]

In other words, with 1: your FFs only get the excess points. (lets say 3 out of 23) but 2: You get you get all 23 points.. no?

You had 20 at the start of the turn, which you accumulated over the past 7 turns, but will still not gain the perk because you lack points of some other type. Imagine keeping the points. That way you can gather 57 once you research the perk and then you have 37 left, which is an instant research of a perk, which cost 30. Also if you pick perks with no military costs time after time, you can collect say 200 points and then quickly get one after another.

To avoid this, at the end of the turn (or something), the stored points in players will be reduced to what the current research costs. That way you will not stockpile and will have to do proper research for each. In option #2, the excess can't be places in the FF pool and is simply lost. Remember whenever you gain a point, you gain one in both FF and perk pools and you keep the FF one even if the perk one is lost.

If we do not clear excess points, we can end up with this scenario:
A->B->C->D

Only D requires military points. This mean the player will stockpile the points while researching A, B and C. D can then be a near instant research. However at the same time the arrows states the requirements meaning D will technically be researched before the requirements are ready.

 

[Lib.Spi't]

Yes I think I see your point, I see what the difference is now.

In 1 the flow stops in the perk pool but not the FF pool.

In 2 the flow stops to both the perk pool and the FF pool, and the the perk pool is 'poured' into the FF Pool at the end of the tech research.

If that takes 50 turns (to finish the tech), that means the tap to the FF pool has been off the whole time and you lose 50 points. (not good)

Equally we don't want the perk tap to be left on the whole time as the FF tap, as that means you will be researching future requirements of future techs.

We want the perk pool to spill over into the FF pool, then at the end of the tech we want to put in a fresh(empty) perk pool.

 

[Nightinggale]

Yes I think I see your point, I see what the difference is now.

I'm not sure. I will try a different approach.

1:

new point
       |
       v
Perk research
       |
       v (excess only)
Founding Father

2:

                     new point
                          |
                          v
Founding Father  <-- duplicator --> perk
                                      |
                                      v (excess)
                                    lost

In solution 1 nothing is lost, but founding father point gathering is stalled. In solution 2 founding father and perk research runs in parallel, but then the perk part loses excess points.

 

[Lib.Spi't]

In solution 1 when you say stalled, you mean because only the perk gains points, then when the perk finishes gaining all the points it needs it goes to into FFs.

So if the tech cost 20 points the FF is stalled for 20 points?

Where as in 2 the points feed into both simultaneously, and on the perk side ONLY the excess is lost.

So example:
You produce 7 points per turn, your tech is at 28/30.

next turn, 7 new points, FF goes up by 7.

perk goes up by 2.

next turn, 7 new points, FF goes up by 7.

perk goes up by 0
(RP completes tech)

next turn, 7 new points, FF goes up by 7.

New Perk goes up by 7.

If that sounds right, then I think I prefer 2 over 1.

Where the FF gains constantly.

The perk gain is self contained for each perk and cannot store up Perk points for a new/next perk.

 

[Kailric]

Where are we at again on this? I'm at the point on my build to ask others for help in playtesting/debugging. If it will be a while before the Civeffects is ready to merge I may go ahead and post a test version of my latest build.

 

[Nightinggale]

It would likely be a good idea to post a test version regardless of state of CivEffects. After all if a bug is found, locating it could be easier if we haven't changed too much at once.

I have a goal where only the GUI stuff is missing. That is getting fairly close, but to be honest playtesting a version with a broken GUI would likely not be the best idea.

 

[Kailric]

It would likely be a good idea to post a test version regardless of state of CivEffects. After all if a bug is found, locating it could be easier if we haven't changed too much at once.

I have a goal where only the GUI stuff is missing. That is getting fairly close, but to be honest playtesting a version with a broken GUI would likely not be the best idea.

Yeah, that makes sense. I'll get a test version packaged up sometime soon for peeps to test out. I'll try to recruit mastrude as well, he is always lurking about in the shadows

 

[Nightinggale]

I'll get a test version packaged up sometime soon for peeps to test out.

Remember not to make it a real release on ModDB or anything like that. We can place it on SF if we need a disk server (we have unlimited space provided it is project relevant).

Also remember to make it an assert build. Ideally we will fix all conditions, which will make the game assert. It would be nice to fix assert issues regardless of their age.

 

[Kailric]

Right, I'll just put it some where people can download it and post a link on the forums.

 

[Lib.Spi't]

I better dig up and reinstall colonization!

 

[Nightinggale]

I have been thinking for a while on how I want tech/perk requirements and now I think I have come up with a solution I like, which also is fairly easy to code.

XML contains

1. RequiredTechs
2. RequiredTechsOR
3. RequiredPecks
4. RequiredPecksOR
5. iNumRequiredOR

1-4 are lists while 5 is an int.

This is put in the code, which is shared between perks and techs meaning techs can require perks and vice versa. Also it only has to be coded once.

The idea being that the required techs/perks really are required. If one of them is missing, the player can't research the tech/perk in question regardless of the other requirements.

The OR techs/perks will then be counted. CanResearch will fail if the combine owned number is below iNumRequiredOR.

I'm thinking something like adding a list for adding arrows as well, though I'm not completely sure. That's a graphical only and not important for game mechanics.

New idea
While writing this a new idea came to light. What if techs and perks are merged into a single CivEffect list

If we fully exploit that, then we can write code like this:

<RequiredCivEffects>
    <RequiredCivEffect>ERA_X</RequiredCivEffect>
</RequiredCivEffects>
<RequiredCivEffectsOR>
    <RequiredCivEffect>TRAIT_BRILLIANT</RequiredCivEffect>
    <RequiredCivEffect>TECH_A</RequiredCivEffect>
    <RequiredCivEffect>TECH_B</RequiredCivEffect>
</RequiredCivEffectsOR>
<iNumRequiredOR>1</iNumRequiredOR>

This will be a tech, which can be researched when the player reach era X and has either tech A or tech B. However if the player is lucky enough to have TRAIT_BRILLIANT, then it is enough to simply reach era X.

It would also be possible to place the trait requirement in requirements (not OR), in which case it is a tech, which can only be researched by brilliant people. To fully use this, we could make say 3 traits and then ensure that all leaders has precisely one of those, then we can make tech trees of equal size and usefulness for each type of leader, but they wouldn't gain access to precisely the same techs. This could be made into something interesting, particularly with tech/perk trading or spies.

The CivEffect approach would require more or less the same amount of coding to get working (possibly even less because the number of lists is halved). However I would need to make XML reading code to read strings and convert to CivEffect indexes. That would likely be a good idea to add anyway as it can be used elsewhere as well.

There has been talk about affecting research cost if more than enough OR requirements is available. We can add that later if we still want to do that. For now, I just want to figure out the XML layout and the general design strategy.

What do you say? Should we go for the CivEffect list idea? Do you have any other idea, which could make this even better?

 

[Lib.Spi't]

This certainly sounds very interesting, I like the idea of being able to have the techs/perks/traits be interchangable, if we could expand it (or maybe we don't have to I forget the definitions and what nots) so that certain 'states' like excommunicated and anarchy (I forget what they are defined as, the little 'moodles' on the left side of the screen) so you could potentially have special techs that require you to be in a certain 'state' like 'preparing for war' that give you techs that unlock special stuff.

So you could end up with some 'mini' techs that you can exploit when your kingdom is acting in a certain way.

Overall though it sounds interesting and flexible!

 

[Nightinggale]

if we could expand it (or maybe we don't have to I forget the definitions and what nots) so that certain 'states' like excommunicated and anarchy (I forget what they are defined as, the little 'moodles' on the left side of the screen) so you could potentially have special techs that require you to be in a certain 'state' like 'preparing for war' that give you techs that unlock special stuff.

Current CivEffects:

• Censures
• Civics
• Perks
• Techs

We also talked about adding eras and traits, possibly even some event stuff, like a random event, which adds a CivEffect for X turns. I even proposed one, which is civic like, except that it is an on/off for each and they have a positive and a negative feature. Say unit food cost -1 and growth cost +200 food (or whatever we figure out to be balanced). There are plenty of options for adding new CivEffects.

If we write code, which works with a CivEffect, it should work just fine if we add a new type of CivEffect in the future. Naturally this makes expansions relying on CivEffects even more attractive

However it doesn't really answer my question. My real question is if I should just start coding this or if the design should be modified first. It's a major part of the game as well as for how XML modders should work. We better agree on this because I'm not planning on redoing this over and over, particularly not if it mean rewriting XML files. The last is a pain right now, and a serious issue once multiple mods relies on the same DLL.

 

[orlanth]

I have been thinking for a while on how I want tech/perk requirements and now I think I have come up with a solution I like, which also is fairly easy to code.

XML contains

RequiredTechs
RequiredTechsOR
RequiredPecks
RequiredPecksOR
iNumRequiredOR

1-4 are lists while 5 is an int.

Nice, I especially like the Required Pecks. When it comes time to revise the GUI, can we add a pigeon-accessible interface like this one?

New idea
What do you say? Should we go for the CivEffect list idea? Do you have any other idea, which could make this even better?

Hmm, I suppose that way does sound even better, although the Avians race in 2071 will suffer from not having Pecks listed separately. (btw that is the race that Nightingale has been appointed Alien Emperor of, because of the fitting name ).

Would the four classes of CivEffect still have their own XML file, or be in one file with all the same tags? I imagine there could be a few tags unique to one class of CivEffect (Civics belonging to a Civicoptions category where you can have only one active, Techs to a Tech Category where you can have multiple active, etc). But it would make sense to be able to refer to any class of CivEffect as AND/OR requirement as you say. Potentially a tag for CivEffects NOT requirements could be useful in certain cases as well, in cases of Papal tech bans, etc etc.

One other question is how to handle cases where you once met the and/or requirements for a CivEffect, but no longer meet them. I would propose for simplicity to just have these requirements apply to which new CivEffects you're eligible to add (otherwise there are so many possible requirement situations that we could get bogged down constantly checking which may have changed, removing a CivEffect based on that, and then having the potential for an infinite loop since the requirements of others might change after losing that Civeffect.)

 

[Nightinggale]

although the Avians race in 2071 will suffer from not having Pecks listed separately.

I don't see a problem here. Perks and Techs are two different XML files. The only merge are the requirement lists and order doesn't matter meaning you can sort them like you want.

Would the four classes of CivEffect still have their own XML file, or be in one file with all the same tags?

Each CivEffect has a unique file and a unique schema. Most of the schema file is copy paste of basic stuff (type, description etc) and the taggroups. In addition to that, each can have unique tags, like research costs, tech category and all the other stuff, which applies to one type only.

Potentially a tag for CivEffects NOT requirements could be useful in certain cases as well, in cases of Papal tech bans, etc etc.

We do have that, sort of. There is a list called BlockedTechs/Civics/Perks. It's a list and if a player has at least one CivEffect, which blocks research, then it can't be researched regardless of other conditions. It is written in the CivEffect, which blocks, not in the one, which is blocked. This difference is important because it mean it is possible to block a civic from a trait. Well, it was an important difference until I came up with the idea to make a list of CivEffects rather than individual types. Now I'm not sure what is the best solution.

One other question is how to handle cases where you once met the and/or requirements for a CivEffect, but no longer meet them.

I have been thinking of that. I'm thinking of disallowing requirements, which aren't permanent. The tech requirements in vanilla BTS works well because once you meet the requirements for a tech, you will never fail the requirements again. Until now we have only used requirements, which are permanent like that, not something, which can be turned off again, like civics. Maybe we should continue this approach.

We have introduced the blocked lists. This is supposed to work based on only researching one tech at a time. This mean once you gain A, which blocks B, B will simply vanish from the list. However right now I started wondering. What if the player is researching B and discovered A in a ruin? The add CivEffect code will need to verify that current research is still valid.

 

[Nightinggale]

I ended up implementing requirements for CivEffects rather than techs/perks. The XML layout is like I wrote in post #175.

During the update, I noticed that all RequiredTechOr has vanished and that they are gone on git as well, though they should be present somewhere in the git history. The DLL can handle those (well RequiredCivEffectsOr) and they should be readded by somebody at some point.

I added RequiredCivEffectArrows and in this group the first tag is Color. The plan is to allow arrows of different colors or make the tech tree easier to read. While writing this function, I wondered about the ability to leave color blank, in which case the arrow will use some generic color. I propose using vanilla color 0, which is named COLOR_CLEAR. It is 100% transparent, which mean it makes no sense to use it for arrows anyway.

If the game has to add a generic color, the current code would pick black. However it would be nice to be able to globally set colors in XML. Tech Categories would be a nice place. Imagine a farming category and all techs of that category would be green and the arrows from those would also be green. Mining could be say silver while weapons could be red. It should be possible to set each individually, but overall just assigning one for each category would be the way to go. Maybe the tech categories should be moved to the research class, in which case they can be set for perks as well.

Another idea is to add an XML file for "tech trees". Each item on a tech tree then has the ID of the screen it should be on. The tech screen should then have a row of buttons. The domestic advisor can add and space out buttons on the fly and this code could be reused to make the screen adapt to whatever settings are written in XML. Perks and Techs should share code here meaning it will be possible to add screens for perks as well with no extra code writing. In fact my plan is to make the two so alike, that the code can place both in the same tech tree and connect them with arrows. It may or may not make sense for the game, but the decision to not mix them should be made in XML, not DLL/python.

But for now the next goal is to actually get the game to draw something useful again.