Topic: Frisian Balancing

hessenfarmer wrote:

WorldSavior wrote:

Okay, branch online. You convicend me to repair the frisian mines, too

Thanks a lot just saw the branch this morning and had a look to the diffs.

You're welcome

Currently I don't understand everything in detail but I will dig through the code. For easing this in the future it would be helpful to split the commits / branches in smaller units. (e.g. changes to fix mines, changes to undo unnecessary changes, general corrections of production cycles).

Ok

However from my perspective we should at least inform the community in the other related threads about the changes as well.

I've already send some changelog-lines to GunChleoc

I saw that you discovered wrong orders of production programs in the frisians buildings which led to long cycles if not properly supplied.

Yes, for example the toolsmithy. But also the honey bread bakery which I overlooked. Good Catch, you fixed it

this is an essential fix to frisan balance and behaviour and so should get into b20 to have frisians as good as they currently could be. The mine fixes would be fine as well. Only the fixes to the smithies were not finally discussed in the forum also I would support your opinion about the unnecessary uplift of the production cycle.

Thanks

Las t thing is the removal of the penalty sleep time for not supllying the building properly. First I don't know whether this could end in performance isssues. Furthermore I would be in favor of a small penalty for not supplying production sites properly.

This penalty still exists for many buildings (for example weapon smithies which only produce cheap weapons if the supply is low, or trainingssites which kick soldiers out if the supply is too bad).

But some kind of those penalties are not so meaningful in my opinion, for example i've always set the gold economy settings to zero if I wanted to have fast smelting works even when there was no gold ore. So this kind of penalty was just annoying...

But essentially we need to evaluate if this could lead to performance problems.
Overall many thanks for your work and analysis.

You're welcome

Unfortunately I discovered some mistakes which I made there (deep frisians mines except for coal mine), but I sended already the corrections.

okay saw that as well good to see it will be fixed.

Thanks for fixing that, so GunChleoc doesn't have to upload the files which I've send her

As long as your time allows now I still would be happy to have replays of your attempts to manage a dedicated map with different tribes over maybe 2 to 3 hours.

I'm wondering - shouldn't we implement further improvements for the frisians before we test? For example, experience of workers could be reduced (the same thing has been done with barbarians), and weapon smithies could need a speed up, because I removed the "speed down" of all other weapon smithies again (because there was no real reason for it) - and not only because of this reason, but also because they are slow and Frisians need a lot of weapons. And I discovered that berries don't grow that well, is it possible that farmers plant wrong berries sometimes? Furthermore there are some maps where trees grow well but berries grow very bad (for example on "hard ground" terrain).

Agreed that we will need to adjust the weapon production to the other tribe's values. I already made some calculations in training.xlsx. I will update this with your new values (thanks for the work ;-)) and see where we are.

You're welcome

I am not sure as far as I understood Nordfriese made a berry bush for every terrain. and the same pickiness as for trees should apply. Maybe the bushes are less picky to ensure for some variety in the optics.

the main reason for asking of some testplay was to have a benchmark and discover more possible possibilities to improve the balance without changing the "character" of the tribe. for this last reason I would consider changes in experience as last ressort cause the longer experience needed is some part of this character as I understand it. (Nordfriese could correct me if I am wrong)

You're welcome. Well, I don't think that it would have been nothing without my help...

As you were the person discussing with me the most frequent I would have little chance to reflect things proper. so thanks again.

By the way, you changed some Marble Mine probabilities from 20% to 15%. I don't think that this is correct, it would be only correct if the mine could skip the granite program if marble is needed (and vice versa) - which is not the case.

@Nordfriese: Do you still think that the branch needs fixing after hessenfarmer corrected my mistakes?

Wanted to save the world, then I got widetracked

Top

Quote

hessenfarmer wrote:

Changes to the marble Mine were done to be consistent with the crystal Mine.

But the crystal mine doesn't run all programs when any of the resources is needed, while the marble mine does that...

As the marble mine produces normally 3 marble 15% should give a 5% Chance.

... so the marble mine normally produces 2 marble, because it changes all the time between 3 and 1. And 15% give a 3.75% chance ;-) Or am I mistaken?

During my tests with 4 AI no performance issues were discovered. So we can skip the penalties, although some 5 seconds Penalty would have been some reward for proper gameplay.

That proper gameplay is still needed for trainingssites and their suppliers

At the other hand, the old penalties of (for example) inn and smelting works just force the player to do some annoying micromanagement: Reducing the economy settings (for example for snacks or gold) to zero, because then the program will be skipped, so there is no penalty.

After the fix of the weapon production times the frisians performen quite well in the AI battle o Only thing I noticed so far is the stats of the mines are dropping very slowly when depleted.

Which stats? The "Productivity"?

Furthermore I noticed more than once the frisian depleted iron mine producing 3 ores

The deep one? That can happen. It was my plan to set some probabilites to 0%, but it is not possible, so I thought that 1% is the next one and I've chosen that instead. 1% doesn't have that much effect on the game, especially when it get's multiplied (for example to 0.01% or even 0.0001%), which is often the case.

Wanted to save the world, then I got widetracked

Top

Quote

The effect of this increasing failure rate leads to a problem in the current cycles. As already mined resources are thrown away. See my latest comment in the branch for details

Top

Quote

WorldSavior wrote:

Yes. The productivity stats were decreasing only slowly. But after a Look into the code for the mine program I am no longer sure if the mine really was depleted. It seems as if the mine programs start to fail randomly incteasing when ressources are starting to get depleted.

That happens to mines which go for 100% resources, yes

The Chance setting is not taken into acount until it is totally depleted though

So maybe you just discovered a bug? "Depleted mines can be more efficient than almost-depleted mines"? I wouldn't be surprised and think that the mines already behaved before my changes like this.

That is exactly the case. But perhaps it can be fixed easily. see below.

The effect of this increasing failure rate leads to a problem in the current cycles. As already mined resources are thrown away.

Is this different to the situation before the change?

yes it is as in older versions each mine command was followed by produce command so every ressource extracted was turned into a ware (or even more than one ware which was the reason for doing all the effort). However I might have found a solution for that.

See my latest comment in the branch for details

Ok... I guess that the mining code should be changed. For example in build19, Atlantean mines behave also strange. They need a lot of time before the are officially depleted and show very low percentages for a long time.

that is exactly a result of the bug. Mainly it is due to the fact that totally depleted fields in the work area (and all fields with the wrong ressource as well) will get a penalty. and atlantean mines have around 66 % more of this fields than the other tribes. So I would vote to skip the penalty for depleted fields and just keep the penalty for fields with low resources.

If we do this I would propose to change the mining programs to the following:

programs = {
work = {
-- TRANSLATORS: Completed/Skipped/Did not start mining coal because ...
descname = "mining coal",
actions = {
"sleep=40000",
"return=skipped unless economy needs coal",
"consume=smoked_fish,smoked_meat:2 atlanteans_bread:2",
"animate=working 60000",
"call=mine_produce",
"call=mine_produce",
"call=mine_produce",
"call=mine_produce",
"call=mine_produce",
"call=mine_produce",
"call=mine_produce",
}
},
mine_produce = {
-- TRANSLATORS: Completed/Skipped/Did not start mining coal because ...
descname = "mining and producing",
actions = {
"sleep=1000",
"mine=coal 4 100 5 2",
"produce=coal",
}
},
},

I already tested this code with the atalntean coal mine but it produces wrong statistics for a reason I don't know yet. the mine never drops below 10% even when producing nothing. Furthermore it shows only "produced coal" from my perspective the "produced x" string should be created at the end of the complete "work" program. Maybe this can be combined with the calculation of the statistics which is already done at the end of the program.
What do you think?

Top

Quote

WorldSavior wrote:

Good idea. What about removing the penalty for fields with the wrong resource as well, and also the penalty for non-mining-fields (if existing)?

All of them are exactly the same case as the condition for the penalty is amount=0. So the fix would apply to all of them.

I already tested this code with the atalntean coal mine but it produces wrong statistics for a reason I don't know yet. the mine never drops below 10% even when producing nothing.

How can a mine produce nothing at all?

Basically it was depleted and did not hit the 5% chance for quite a while. So I would have expected decreasing statistics down to zero. But it stopped around 10 %. Grammatically you are right that it is difficult to produce nothing. But it is easy to not produce anything.

The code looks very good if I'm not mistaken

So if there are no further objections I will change all mines in the same way as in my code example. I also could change the penalty value to zero.

Furthermore it shows only "produced coal" from my perspective the "produced x" string should be created at the end of the complete "work" program.

yes, that would be a nice-to-have

Unfortunately this is beyond my current knowledge of the code and my c skills.

Maybe this can be combined with the calculation of the statistics which is already done at the end of the program.

How do you mean that?

As far as I understand the code statistics are calculated when all actions of the "work" program are done (either completed, failed or skipped) my suggestion was to create the string for the hover text in this routine as well. However this might be difficult for multiple output production sites

Top

Quote