Topic: Frisian Balancing

hessenfarmer wrote:

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.

Good

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.

Okay... I don't even know how the statistics are calculated for your new code. Maybe there is a bug and a depleted atlantean coal mine has now an expected shown productivity of 35%, I can only guess...

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.

Both sounds fine. It would be great if that will fix the problem that many mines become too inefficient when approaching the depleted state.

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.

Also beyond mine. But see below...

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

Ok

hessenfarmer wrote:

Just a short additional question the design with call=mine_produce would allow for having animation cycles assigned to each mine command. Perhaps it would look nicer this way? Opinions?

That's another good idea, because it would also reduce the problem that the mine shows "has produced (one) coal" even though 7 pieces of coal are produced in a very short time

Wanted to save the world, then I got widetracked

Top

Quote

Nordfriese wrote:

Two quick remarks from my playing experience:

• The hunter produces a lot of fur. I have three hunters houses and my warehouses accumulated masses of fur in a short time. It´s too much of an advantage (and highly map-dependent), I´m in favour of removing the hunter´s fur production.

Could be adopted but this is against my experience. On which map did you play that supports 3 hunters over a considerable amount of time. Do you have a replay perhaps? if yes just upload to the frisian balancing bug please.

• Farms require too much space. If only a few of the fields nearby are obstructed with roads, productivity stays in the red numbers. This doesn´t fit with the "good on bad terrain" idea. I suggest increasing the farm´s working area by one.

could be adopted as well. I will add this to a new branch to test it. However they just need 7 fields for 100% productivity which already allows for having them placed at a street. I never had problems with that. It just adds more difficulty in proper planning of farm locations.

Just a short additional question the design with call=mine_produce would allow for having animation cycles assigned to each mine command. Perhaps it would look nicer this way? Opinions?

That's another good idea, because it would also reduce the problem that the mine shows "has produced (one) coal" even though 7 pieces of coal are produced in a very short time

+1

branch with fixed mines is online. please review. still digging into the stats issue. it seems that due to the call mechanism it only counts total failed cycles as failed. maybe only cycles where the last mine_produce fails will be counted as failed. dont know exactly yet.

Top

Quote

Nordfriese wrote:

I don´t have access to my gaming computer at the moment, so I can´t provide a replay. I played on 4cells-torus, which has lots of animals. I´m sure there are many other maps with much game...

No worries. I'll do a round of testplay on the map as well. Confirming an issue is alwways a good excuse to play instead of doing some work However if I can confirm this, we should discuss how we could fix the issue of early training of a seamstress on maps with not that much game.

• Farms require too much space. If only a few of the fields nearby are obstructed with roads, productivity stays in the red numbers. This doesn´t fit with the "good on bad terrain" idea. I suggest increasing the farm´s working area by one.

could be adopted as well. I will add this to a new branch to test it. However they just need 7 fields for 100% productivity which already allows for having them placed at a street. I never had problems with that. It just adds more difficulty in proper planning of farm locations.

The current radius contains 19 fields total, of which 4 are used by the building, one for the flag, and at least one for a road. If the farm gets two roads, they need up to four fields. That leaves only three to six fields that can be blocked without reducing productivity, which is a great disadvantage on maps with limited space (e.g. archipelago sea, where there often isn´t enough land near big plots). A greater radius would allow the farmer to reach more fields there.

As I said I will give it a try but you should be aware that this makes playing the frisians easier as you don't need to be that careful with planning your space.

branch with fixed mines is online. please review. still digging into the stats issue. it seems that due to the call mechanism it only counts total failed cycles as failed. maybe only cycles where the last mine_produce fails will be counted as failed. dont know exactly yet.

You need to add "return=skipped" at the end of the main program, else it will change statistics although it doesn´t do anything.

Thanks a lot I reaaly missed that one issue is fixed and branch is uploaded.

Top

Quote

Furthermore barley doesn't grow at water. If I'm not mistaken a barley field requires 6 land triangles around it, while other plants allow some water triangles around them. ( A plant is never on a triangle, but at the spot where six triangles meet)

Yes, that´s correct. The farmer uses only spaces where not just the field itself but all six nodes around are clear. Other planters like berry farmers can plant things at any place they can walk to. This is the same for all tribes, but frisians have a greater disadvantage here because the farm needs more space to be efficient. A radius increase of 1 provides 18 extra fields that might be suited for farming, which is a small advantage on maps with enough space and a compensation for this disadvantage in limited areas.

Top

Quote

I can confirm this. it is even the case with the 8777 executable.
the good news is it is only related to the atlantean crystalmine and the empire marblemine. all other mines are fine except the frisian deep goldmine where I had a missing bracket.
the bad news is I don't know yet the rrot cause. seems it has to do with the stacked calls in these mines. I will investigate and keep you informed.

Top

Quote