Polls

Default Game Speed

Log in to vote!

Currently Online

Latest Posts

Topic: Bugs

WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 1317
Ranking
One Elder of Players
Location: GER
Posted at: 2019-05-20, 19:53

hessenfarmer wrote:

WorldSavior wrote:

hessenfarmer wrote:

WorldSavior wrote:

The Tada sound effects don't appear anymore, and the old sound effects are not desired because they are unpleasent, so they had been removed once - which was good.

could you please give some feed back whether the smith_00.ogg and toolsmith_00.ogg sounds in b20 (or current trunk) are the desired soundfiles made by Tada or not. I couldn't find any change to these files after the Tada branch went in. If (hopefully) so we just need to ensure they are played and the others are not. If not we need to recover the Tada files from wherever they are available (I don't know yet).

How to check out the sound files without installing trunk or downloading the whole tarball?

In launchpad you can download the files one by one.

I went here: https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/files/head:/data/sound/smiths/ - but downloading somehow didn't work.

should be manageable as I think they are only 5 to 6 files. But I assumed you would have an actual build ready.

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

hessenfarmer wrote:

While searching through the code I have discovered that we changed some buildings to fail early if not supplied properly and others do not: especially where the purpose of a building is the same in different tribes eg. toolproduction this should be unified I think. Currently only Frisian and atlantean toolsmithes fails early empire and barbarians do sleep before fail.
Bug report is here https://bugs.launchpad.net/widelands/+bug/1829761

I don't see how this could be a bug?

And I can't see why there should be such differences between the tribes, especially as we changed atlanteans and not the other 2 legacy tribes.

Because the tribes are different here. imp and bar only need wood and metal, but atl and fri have a third material in the tool smithy. I just fixed the bug that a toolsmithy wastes a lot of time if it should make fishing nets and there is a demand of other tools but no iron available, and maybe also other bugs.


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

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

WorldSavior wrote:

hessenfarmer wrote:

WorldSavior wrote:

I went here: https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/files/head:/data/sound/smiths/ - but downloading somehow didn't work.

seems as if LP is a bit buggy there can't use the download either. Thanks for trying.

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

Strange as both files smith_00 and toolsmith_00 have the same revision, which is referring to the TADA branch. So I am a bit lost here. Maybe GunChleoc can help us out.

I don't see how this could be a bug?

And I can't see why there should be such differences between the tribes, especially as we changed atlanteans and not the other 2 legacy tribes.

Because the tribes are different here. imp and bar only need wood and metal, but atl and fri have a third material in the tool smithy. I just fixed the bug that a toolsmithy wastes a lot of time if it should make fishing nets and there is a demand of other tools but no iron available, and maybe also other bugs.

Ok thanks for the explanation. I will rethink my position based on this information. So far it sounds as you might be right.
On the other hand do you think it would do any harm to unify the structure of these programs? Reason for asking is that a new contributor would most probably not know about this reason and might be confused.

Edited: 2019-05-20, 20:12

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

hessenfarmer wrote:

WorldSavior wrote:

hessenfarmer wrote:

I don't see how this could be a bug?

And I can't see why there should be such differences between the tribes, especially as we changed atlanteans and not the other 2 legacy tribes.

Because the tribes are different here. imp and bar only need wood and metal, but atl and fri have a third material in the tool smithy. I just fixed the bug that a toolsmithy wastes a lot of time if it should make fishing nets and there is a demand of other tools but no iron available, and maybe also other bugs.

Ok thanks for the explanation. I will rethink my position based on this information. So far it sounds as you might be right.
On the other hand do you think it would do any harm to unify the structure of these programs?

In general I think that the barbarian and imperial toolsmithies don't have to stay like they are now. But now I see that the sequence "return consume sleep" has a disadvantage: If there are no resources, the building checks rather often for them, doesn't it? I wouldn't be surprised if this could slow down the game on slow machines - at the other hand I don't know if this is realistic. So maybe it would be better to have a short timespan, maybe half a second, and the sequences could look like "return sleep0.5s consume sleep", if you know what I mean.


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

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

WorldSavior wrote:

Ok thanks for the explanation. I will rethink my position based on this information. So far it sounds as you might be right.
On the other hand do you think it would do any harm to unify the structure of these programs?

In general I think that the barbarian and imperial toolsmithies don't have to stay like they are now. But now I see that the sequence "return consume sleep" has a disadvantage: If there are no resources, the building checks rather often for them, doesn't it? I wouldn't be surprised if this could slow down the game on slow machines - at the other hand I don't know if this is realistic. So maybe it would be better to have a short timespan, maybe half a second, and the sequences could look like "return sleep0.5s consume sleep", if you know what I mean.

I know exatly what you mean. I have thought about this problem as well and came to a similar possible solution. So far I have not seen any impact on performance though. But maybe only due to the fact that a player (either human or AI) does not need that much toolsmithies. So I would consider implementing it for the atl and frisians to have a short sleep cycle in the beginning. 500 ms sounds good for the beginning.
I am not sure about your answer to my previous question about unifying the buildings sequences in this way. I understood you have no objections, if the potential performance problem is solved like we just discussed. Correct?

If so I would investigate all candidates and list them here before implementing the changes. Ok?


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

hessenfarmer wrote:

WorldSavior wrote:

Ok thanks for the explanation. I will rethink my position based on this information. So far it sounds as you might be right.
On the other hand do you think it would do any harm to unify the structure of these programs?

In general I think that the barbarian and imperial toolsmithies don't have to stay like they are now. But now I see that the sequence "return consume sleep" has a disadvantage: If there are no resources, the building checks rather often for them, doesn't it? I wouldn't be surprised if this could slow down the game on slow machines - at the other hand I don't know if this is realistic. So maybe it would be better to have a short timespan, maybe half a second, and the sequences could look like "return sleep0.5s consume sleep", if you know what I mean.

I know exatly what you mean. I have thought about this problem as well and came to a similar possible solution. So far I have not seen any impact on performance though.

I tested what a Frisian toolsmithy produces if iron supply is too low and if it skips production of baskets&fish-nets. Unfortunately mainly two kinds of tools, because it receives the Iron while the smithy skips producing basket or fishing net - and this skipping time is not 0 but apparently bigger than the time of "failing because cannot be consumed".

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

But maybe only due to the fact that a player (either human or AI) does not need that much toolsmithies. So I would consider implementing it for the atl and frisians to have a short sleep cycle in the beginning. 500 ms sounds good for the beginning.
I am not sure about your answer to my previous question about unifying the buildings sequences in this way. I understood you have no objections, if the potential performance problem is solved like we just discussed. Correct?

Yes

If so I would investigate all candidates and list them here before implementing the changes. Ok?

Okay


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

Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 852
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-05-22, 20:47

WorldSavior wrote:

I tested what a Frisian toolsmithy produces if iron supply is too low and if it skips production of baskets&fish-nets. Unfortunately mainly two kinds of tools, because it receives the Iron while the smithy skips producing basket or fishing net - and this skipping time is not 0 but apparently bigger than the time of "failing because cannot be consumed".

If a program gets skipped for the second time there is a hardcoded waiting time of 10 s. 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.

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?


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

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.


Top Quote
WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 1317
Ranking
One Elder of Players
Location: GER
Posted at: 2019-05-23, 01:46

hessenfarmer wrote:

WorldSavior wrote:

I tested what a Frisian toolsmithy produces if iron supply is too low and if it skips production of baskets&fish-nets. Unfortunately mainly two kinds of tools, because it receives the Iron while the smithy skips producing basket or fishing net - and this skipping time is not 0 but apparently bigger than the time of "failing because cannot be consumed".

If a program gets skipped for the second time there is a hardcoded waiting time of 10 s.

Second time in a row?

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.

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?

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.


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

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

WorldSavior wrote:

If a program gets skipped for the second time there is a hardcoded waiting time of 10 s.

Second time in a row?

Yes.

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.

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) or remove the order by randomizing the next cycle. Both options have their advantages and disadvantages.

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. Shall I send you the predecessors for comparison?


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 273
Ranking
Tribe Member
Location: Earth
Posted at: 2019-05-23, 14:21

@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.

Edited: 2019-05-23, 17:14

Top Quote