[Religion and Revolution]: Mod Development

Status
Not open for further replies.
But will it be possible to remove the positive bonus from health with xml configuring and only retain a malus with negative health?
I just went though the XML changes and I didn't spot any additions in the log, which could be used for setting upper/lower cap. I may have missed it, but my guess is that it is hardcoded somewhere in the DLL code (which I didn't read). Maybe Ray will add it to XML next weekend now that there is a request for it.

EDIT: by log I mean the diff between each commit, not the actual revision log.
 
Thanks for the info, I sure hope it will be added if it is not too much hassle. While I know my way around the xmls and the occasional python script the dll is way beyond me i fear. :blush:

I believe the health feature has some serious potential and could be expanded in interesting ways.

How about having health not only be affected by population count but also by certain buildings?
e.g. factories could also lower health which would a) give a drawback to their amazing ability to create things out of nothing and b) encourage city specialization and decentralization since no large city can support too many factories and the people to run them (something similar exists in the special case of the great tool factory with its -1 food already). Other (new) buildings like a bathhouse or a sewage system could add a flat amount of health or reduce the negative health generated by a percentage.

edit:

To clarify, the reason I think positive health should not give any kind of bonus but only act as a buffer before negative health kicks in is twofold:

- balance reason:
First I must say I cant see from the posted screenshots of health affects all productivity or only food, but the following argument is valid either way. There are already enough or even too many ways to boost (food-)production, there is no need for another one. Also if (food-)production was meant to be well balanced before the health system came in, the now added potential 25% additional boost automatically unbalances it (unless rebalancing the entire (food-)production to go along with the health system is planned which I assume is not).

- realism reason:
There is no such thing as positive health, just absense of sickness. Doctors do not make you healtier if you are not sick, they just make you less sick if you are (unless you think of these doctors of some sort of fitness trainers/lifecoaches which is completely out of place obviously). So also for this reason positve health makes no sense and should have no noticeable effect except for it taking longer for sickness effects to kick in.
 
Ok, some comments to the last posts.

1. City Health will affect (positively or negative) Productivity considering all Yields.
It will also affect growth, but that is the second aspect.

2. I will change DLL and XML to have upper positive limited and lower negative limit of city health configurable separatly.
-> This will allow to deactivate either one (and its effects)

3. Since Health is a normal Yield, it is already possible to give Buildings all the effects, they can have with other Yields already.
-> e.g. there will be a Building "Village Well" which will give +10% Health
-> There also already is a Founding Father affecting Health (so such things are possible as well)
-> There are a lot of other things possible, which I am currently not sure yet. I will see ...

4. When I am talking about "Positive City Health" than that is a relative aspects.
Doctors can simply keep citizens healthier than in average compared to cities without doctors.
In those days people were suffering from a lot of small issues like injuries and small diseases.
Doctors could help to cure those issues a lot faster. So I do see a "positive City Health".
-> I will configure both aspects for RaR. (People can do whatever they want in their private versions.)

Now I am tired from an exhausting week and will go to sleep. :sleep:
 
@team and partners:

There is a new revision available in SVN.

I implemented a few improvments to Health feature.
Mainly about Mouse-Over-Texts and Customizability of the feature.

I am still working a bit on the feature to further improve it.

Edit:

"Village Well" is now also implemented and uploaded to SVN.
Thanks again to Schmiddie for the great graphics. :goodjob:
 

Attachments

  • Civ4ScreenShot0000.JPG
    Civ4ScreenShot0000.JPG
    188 KB · Views: 121
Oh, I had almost forgotten to tell.

Specialists "Master Cannonsmith" and "Master Weaponsmith" have been united to one single Specialist "Master Weaponsmith" (for both professions).

Simply because:

1. In all other buildings with 2 professions there is also always only 1 Specialist.
2. It was annoying to have those Specialists separated and thus being less flexible considering their usage.
 
Oh, I had almost forgotten to tell.

Specialists "Master Cannonsmith" and "Master Weaponsmith" have been united to one single Specialist "Master Weaponsmith" (for both professions).

Simply because:

1. In all other buildings with 2 professions there is also always only 1 Specialist.
2. It was annoying to have those Specialists separated and thus being less flexible considering their usage.
Harbor? Sailcloth maker and rope maker? :confused:
 
Harbor? Sailcloth maker and rope maker? :confused:

You are right. :)
Then let's say "almost all other building with 2 professions have only 1 Specialist".
(Drying Cocoa and Coffee, Weaving Cloth and Wool Cloth, Slaughtering Sheep and Cattle, Producing Coats and Luxury Coats ...)

I'll think about "Sailcloth Maker" and "Rope Maker". :think:
(At the moment we might just leave those separated.)
 
I also agree, it's adequate leaving those two professions separated. :thumbsup:

Well, there is some logic in the attempt of "merging" both weapon professions into one single profession. For shure, an experienced gunsmith might be far more familiar with production of cannons than any farmer or fisher. Same thing for gunsmith and blacksmith.

I remember a different approach from another mod (but I don't remember what mod it was). The fact, that work of Blacksmith, Gunsmith and Cannonsmith is taking place in an similar "milieu" (melting iron all day) could be illustrated by giving a 50% bonus to these 3 specialists when doing one of the "familiar" professions.

So, Master Cannonsmith (and Master Blacksmith) would have a 50% Bonus for the production of weapons - and vice versa. Also, Master Cannonsmith and Master Weaponsmith would have 50% Bonus when producing tools.
Do you like the idea? :)
 
I remember a different approach from another mod (but I don't remember what mod it was). The fact, that work of Blacksmith, Gunsmith and Cannonsmith is taking place in an similar "milieu" (melting iron all day) could be illustrated by giving a 50% bonus to these 3 specialists when doing one of the "familiar" professions.
M:C does that, though not with guns. Instead it's weaponsmith/armorsmith etc.
 
Hi Willi,

Also, Master Cannonsmith and Master Weaponsmith would have 50% Bonus when producing tools.
Do you like the idea? :)

"Master Weaponsmith" and "Master Cannonsmith" have already been combined into 1 Specialist "Master Weaponsmith" (now for Guns and Cannons).
But I don't think I like to give "Master Weaponsmith" a bonus on producing Tools as well.

We did leave "Master Sailcloth Maker" and "Master Rope Maker" separated though.
 
Another new revision available in SVN.

I fixed a small issue in Pedia:
(actually a Vanilla issue)

Pedia for Improvments did not show information of Bonus Structs.
(Now of course it does. :) )

@Nightinggale:
Thanks for taking a look at it. :thumbsup:
But I now just simply quickly fixed it myself.
 

Attachments

  • Civ4ScreenShot0001.JPG
    Civ4ScreenShot0001.JPG
    285.6 KB · Views: 121
The current plan for upcoming Release 2.0:

1. Adding further (small) improvments if they are developed.
(e.g. graphical improvments from Schmiddie or performance improvments from Nightinggale)

2. Adding the maps (and French translations) from Marla_Singer, once they are finished.

3. Testing, testing, testing (Which might lead to bugfixes and other improvments of course.)

----------

That is pretty much it. :)
Once we have a good feeling about stability and gameplay we will publish Release 2.0.
(We will probably be testing internally for a couple of weeks.)

Otherwise I explicitly would not like to implement new features or any other big changes now.
We simply had enough changes for one release already in the last months.

When development of Release 2.1 will start, we will see again.
 
When looking at how 2-plot radius works, I wonder about how the plots are numbered. The order where plots are looped are:
24 | 17 | 16 | 15 | 23
18 | 7 | 8 | 9 | 14
19 | 6 | 1 | 2 | 13
20 | 5 | 4 | 3 | 12
25 | 21 | 10 | 11 | 22

The hardware is optimized to minimize memory I/O waiting time when the layout is
1 | 2 | 3 | 4 | 5
6 | 7 | 8 | 9 | 10
11 | 12 | 13 | 14 | 15
16 | 17 | 18 | 19 | 20
21 | 22 | 23 | 24 | 25
The reason is that once plot 2 or 3 is requested, the hardware will figure out that it is looping an array and read 4 and 5 into the input buffer BEFORE the code actually requests those data. This prediction can't be made when the order is random.

I'm not going to change this now (that would require a lot of AI testing). I just wonder if there is a reason why the code is different from the normally recommended way of coding something like this.
 
I'm not going to change this now (that would require a lot of AI testing). I just wonder if there is a reason why the code is different from the normally recommended way of coding something like this.

Yes, there is a reason.
The city radius is growing (in 3 steps) and it does make sense to go from inner to outer plots.
(The order of plots is not random at all.)
 
I finally committed the second part of my optimisation. The first part was committed on the 8th of Marts.

This optimisation caches the output for CvUnit::getYield() and CvPlot::hasYield() and returns the cache instead of recalculating every time it needs the result. The result is that the time spend waiting for the AI to take its turn is reduced by around 19,5%.

I did some calculations and now all the optimisations I wrote since RaR 1.5 have reduced the waiting time by 40% combined. Unsurprisingly it gets increasingly difficult to find anywhere in the code, which can be improved. In fact I suspect it is no longer possible to increase performance noteworthy without affecting game behaviour. In other words this is likely to be the last optimisation update for RaR.

(The order of plots is not random at all.)
I noticed that the order isn't random for humans, but it is from a hardware point of view. My point was if there is some reason to the order if we are going to loop though all of the plots anyway? Most (all?) of the time all plots are looped and unowned plots are skipped. We have AI priority to select plots closest to the city plot meaning priority shouldn't be an issue. I still can't see a good reason for the loop order.
 
This optimisation caches the output for CvUnit::getYield() and CvPlot::hasYield() and returns the cache instead of recalculating every time it needs the result. The result is that the time spend waiting for the AI to take its turn is reduced by around 19,5%.

@Nightinggale:

That generally does sound great. :thumbsup:

But did you also test Lifestock Breeding (of Horses, Cattle and Sheep) ? :think:
Because the Yield output from the plot depends on the amount of those Yields stored in the city and is thus highly dynamic.

I haven't yet taken a close look at this or done any testing yet myself.
(I just came home from a long week of work and am too tired now.)

I still can't see a good reason for the loop order.

Please leave the loop order of the city radius plots as it is. :)
 
Status
Not open for further replies.
Back
Top Bottom