Latest Posts

Topic: Bugs

hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 672
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-24, 13:03

stonerl wrote:

@hessenfarmer

Regarding the performance on slow machines. I don't think it is necessary to add this 100ms delay. Did you see any significant change in CPU utilization?

As far as I understand the code, it is not the second time a program gets skipped, that it has to wait for 10s. Every time a program gets skipped it is moved to the skipped stack. And if one tool gets produced it immediately gets removed from the skipped stack.

Also, it is the main work program that gets skipped and not the subprogram.

Here is my understanding of the code. if a program returns a skipped state, it will be added to the table of skipped programs (sorted by its program name, toghether with the time of skipping it). If it later returns a completed state it gets erased from this table. this can be only subprograms as the main program does not report skipped as due to your very appreciated work it reports no stats.
At every program start the code iterates over the skipped programs assigns an earliest start time (reported skip time +10 seconds) and checks whether this is already passed. If yes the program gets started if not then not.
So basically neither of us was right in my view. but the effect of the 10 seconds could only occur in the atlantean or Frisian tool production. cause her the fail is as fast as skipping so if undersupplied and one programm skipped we will very quickly fail all programs skip the one program faill very quickly again and wait 10 seconds minus the small think times (at least 10 ms each as this is the normal waiting time if not skipped) for the failing programs. and then the whole thing gets repeated. in the empire and barbarian smithies a fail lasts about 20 seconds or so and therefore the mechanism will not be triggered. Its just to prevent productionsites with only one work program from skipping endlessly.


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 208
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-05-24, 15:47

Yes you're absolutely right. I had to look in the code again.

Regarding the fail time; doesn't that affect all programs that don't have a sleep time before the war consumption? Shouldn't we consider putting a 1-second sleep before all first consumption occurrences?

Regarding the barbarians and empire; shall we unify their programs to the other tribes' behaviour?


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 672
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-24, 17:16

stonerl wrote:

Yes you're absolutely right. I had to look in the code again.

Regarding the fail time; doesn't that affect all programs that don't have a sleep time before the war consumption? Shouldn't we consider putting a 1-second sleep before all first consumption occurrences?

That was already WorldSaviors suggestion. I think it maybe worth a try with a second or half a second. This would mitigate the effect of preference of the next program after the skipped one a bit. see my discussion with WorldSavior on the last page

Regarding the barbarians and empire; shall we unify their programs to the other tribes' behaviour?

That was the starting point for my discussion. I already registered a bug for that. But WorldSavior had a valid argument why this hasn't been done yet. So I am currently still undecided. World Savior had no objections else than this might have an impact on performance if we unify all of the working programs in this direction. I wanted to analyse candidates first and then discuss this further for the performance the 1 sec sleep would probably cope for that.


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 208
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-05-24, 17:34

Sorry, that I didn't catch up with your discussion. I'd favour a hard coded delay for failed programs, instead of going through every lua-program and add x seconds though. Maybe we can utilize:

ProductionSite::program_start

We could add a new constant iterator called FailedPrograms and delay the restart time for every failed attempt. The question is how many seconds. Would we want to use 10s as we do for skipped programs or less?

We could then move all sleep commands behind the consumption and wouldn't have to bother with this in the lua files.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 672
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-24, 18:04

stonerl wrote:

Sorry, that I didn't catch up with your discussion. I'd favour a hard coded delay for failed programs, instead of going through every lua-program and add x seconds though. Maybe we can utilize:

ProductionSite::program_start

We could add a new constant iterator called FailedPrograms and delay the restart time for every failed attempt. The question is how many seconds. Would we want to use 10s as we do for skipped programs or less?

We could then move all sleep commands behind the consumption and wouldn't have to bother with this in the lua files.

Using the same mechanism as for skipped programs might work. the mechanism is only working if all programs fail or skip. We just need to evaluate if there might be any cornercases.


Top Quote
WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 1213
Ranking
One Elder of Players
Location: GER
Posted at: 2019-05-24, 18:22

stonerl wrote:

Sorry, that I didn't catch up with your discussion. I'd favour a hard coded delay for failed programs, instead of going through every lua-program and add x seconds though. Maybe we can utilize:

ProductionSite::program_start

We could add a new constant iterator called FailedPrograms and delay the restart time for every failed attempt. The question is how many seconds. Would we want to use 10s as we do for skipped programs or less?

Why not using 0.5s for both cases?


“It's a threat to our planet to believe that someone else will save it.” - Robert Swan

Top Quote
WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 1213
Ranking
One Elder of Players
Location: GER
Posted at: 2019-05-24, 19:45

hessenfarmer wrote:

WorldSavior wrote:

It is logical that it does what you described although this is not desired. I believe we lower economy settings would help here as well.

Because programs get skipped? Probably that doesn't work when there are many unmanned buildings, because they increase the economy options.

if we lower the Economy setting to 1 for each tool (at least for the AI) only the necessary tools are tried to produce. More cycles are skipped probably. So more buildings can get manned instead of producing unnecessary tools. that was what I meant. I think I will try to implement this and test it.

Good idea

Fortunately already a short timespan (as described in my last post) of 0.1s reduced this problem.

Good to see that. But reduced does not mean it is gone right?

Yes (and I made a mistake, didn't test with 0.1s but 1s). But maybe one can blame the fact that a building wastes time when it skips a step because of economy options?

we could reduce that time but that míght lead to performance problems then (although this needs to be tested then). Furthermore this would not evade the problem that the cycle (tool) behind the skipped tool(cycle) would be preferred. So the solutions I can see might be changing the order of the tools cycles to prefer the most needed tools in the economy (which we then need to identify)

One of those tools might be the fire tong, because a metal shortage might often result in a lack of those tools. And the other one: Probably the pick?

hessenfarmer wrote:

WorldSavior wrote:

I don't have trunk ready, but b20. "toolsmith" is probably from Tada, but "smith" is wrong.

I just reminded myself of my old b19 installation and compared them with b20 sound files. I can't confirm they haven't changed in b20. smith_00.ogg is shorter and sounds like further away in comparison. Same for toolsmith_00.ogg Furthermore their metadata shows mod. by Toptopple. So I believe this bug is not valid. What could be the case is that the program chooses one of the other we could try by renaming them to something not known by widelands.

But we had some sounds which were not shrill, and they are gone.

As said only 2 smith sounds were exchanged by the Tada branch (together with less annoying sheep, stag and so on). They are still present and in fact they sound much less shrill than their predecessors in comparison. Only problem might be that the programm prefers the alternatives now and plays them less frequent then before. As I said try to rename the Smith_01 and smith_02 together with toolsmith_01 with a leading prefix ( a single _ should do the trick) and see what happens. If smith_00 sounds shrill for you it might be your hearing has adopted and now is more sensitive.

I don't think so. I can remember clearly a smith sound which is not shrill at all, it's impossible that just my hearing changed.

Shall I send you the predecessors for comparison?

If you want, yes


“It's a threat to our planet to believe that someone else will save it.” - Robert Swan

Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 208
Ranking
Widelands-Forum-Junkie
Location: Earth
Posted at: 2019-05-24, 20:55

WorldSavior wrote:

stonerl wrote:

Sorry, that I didn't catch up with your discussion. I'd favour a hard coded delay for failed programs, instead of going through every lua-program and add x seconds though. Maybe we can utilize:

ProductionSite::program_start

We could add a new constant iterator called FailedPrograms and delay the restart time for every failed attempt. The question is how many seconds. Would we want to use 10s as we do for skipped programs or less?

Why not using 0.5s for both cases?

I definitely would prefer having the same value for both cases. Hessenfarmer and I were testing some values when we implemented the no_stats return value. I think we figured out that a value between 500ms and 1000ms was a good compromise back then. But I think 10s is still a reasonable value.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 672
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-24, 21:11

WorldSavior wrote:

stonerl wrote:

Sorry, that I didn't catch up with your discussion. I'd favour a hard coded delay for failed programs, instead of going through every lua-program and add x seconds though. Maybe we can utilize:

ProductionSite::program_start

We could add a new constant iterator called FailedPrograms and delay the restart time for every failed attempt. The question is how many seconds. Would we want to use 10s as we do for skipped programs or less?

Why not using 0.5s for both cases?

Because that would not do anything at all. this value isn't a waiting time for each program like a sleep in a lua file. this value is added to the time when the program got skipped. It is then prevented for this period of gametime when skipped plus this delta value. So if we choose 0.5 seconds we will hardly notice cause the calling the other programs will probably take longer than these 0.5 seconds. I hope this is understandable.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 672
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-24, 21:19

WorldSavior wrote:

Fortunately already a short timespan (as described in my last post) of 0.1s reduced this problem.

Good to see that. But reduced does not mean it is gone right?

Yes (and I made a mistake, didn't test with 0.1s but 1s). But maybe one can blame the fact that a building wastes time when it skips a step because of economy options?

we could reduce that time but that míght lead to performance problems then (although this needs to be tested then). Furthermore this would not evade the problem that the cycle (tool) behind the skipped tool(cycle) would be preferred. So the solutions I can see might be changing the order of the tools cycles to prefer the most needed tools in the economy (which we then need to identify)

One of those tools might be the fire tong, because a metal shortage might often result in a lack of those tools. And the other one: Probably the pick?

and what would be the less needed / most skipped per tribe we need to identify them as well.

I don't think so. I can remember clearly a smith sound which is not shrill at all, it's impossible that just my hearing changed.

Sorry but I found only 1 tada sound branch and the ones added there are the ones still in trunk and b20.

Shall I send you the predecessors for comparison?

If you want, yes

Email will get out immediately.


Top Quote