Currently Online

Latest Posts

Topic: Bugs

WorldSavior
Avatar
Topic Opener
Joined: 2016-10-15, 04:10
Posts: 2091
OS: Linux
Version: Recent tournament version
Ranking
One Elder of Players
Location: Germany
Posted at: 2019-05-25, 21:06

stonerl wrote:

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.

Why reasonable, don't buildings waste then often 10s or even x times 10s for no real reason?

hessenfarmer wrote:

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.

So you think that it is more important that the building shows for 10s "was skipped" than that the building doesn't waste a lot of time for skipping? If I got everything right, many weapon smiths waste 40s when they should only produce one type of the ware, and with toolsmiths it's even worse, if they should produce only one type of tools (which might be often the case).

hessenfarmer wrote:

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.

Why, is there currently a tool which is produced less often than most others?

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.

Thanks. It still seems like one or more rather pleasent sound effects got lost somewhere, but this has not the highest priority.


Wanted to save the world, then I got widetracked

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

WorldSavior wrote:

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.

Why reasonable, don't buildings waste then often 10s or even x times 10s for no real reason?

No, as I tried to explain this is not a delay like a sleep which is executed every time. It is more a timer starting at the very moment the program got skipped (or fails if we implement this). This timer is like don't try this again until now + 10 seconds. So if at least one program can be fully executed this will last far longer than 10 seconds. So next time the check whether the 10 seconds have passed will be true and the program will be tried to be executed normally. This value comes only into place if the sequence of programs is run through faster then 10 seconds. In this case only the first skipped program will wait what is left of the 10 seconds timer, cause the timer of the other programs is running down meanwhile as well.

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.

So you think that it is more important that the building shows for 10s "was skipped" than that the building doesn't waste a lot of time for skipping? If I got everything right, many weapon smiths waste 40s when they should only produce one type of the ware, and with toolsmiths it's even worse, if they should produce only one type of tools (which might be often the case).

This is a misconception. see above where I tried to explain better how this works. 0.5 simply would not be noticeable, as a timer so short would always been run down if for the next try.

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.

Why, is there currently a tool which is produced less often than most others?

No. Starting point was that the tool behind a skipped tool is currently preferred as it gets better chances to have the material ready (talking about the atlantean design now). So I menat to have the most needed tools directly following the most skipped tools in the cycle, as these are the preferred positions. So identifying the most needed is one part. Knowing the less needed is the other part.

Thanks. It still seems like one or more rather pleasent sound effects got lost somewhere, but this has not the highest priority.

As said if they were there (somewhere) they never went into trunk. I can look into abandoned and neglected branches if there is something still open and never had a merged request. But in this case I wonder how they could have made their way to you.


Top Quote
JanO
Avatar
Joined: 2015-08-02, 11:56
Posts: 177
Ranking
At home in WL-forums
Posted at: 2019-05-26, 11:23

About this timer: To me it seems like this one is present to prevent buildings from trying to produce one (same) thing again and again when something else is desired. Is that correct? So the timer runs on the specific product, not on the building. If so, my suggestion would be to set the value of the timer to something like (production time of this building) times (number of possible products) plus or minus (some time, basically the value you are already discussing by now).


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-26, 12:53

Here's the commit by Tada that edited some sounds:

https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/8805

And edits by toptopple:

https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/8277


Busy indexing nil values

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

JanO wrote:

About this timer: To me it seems like this one is present to prevent buildings from trying to produce one (same) thing again and again when something else is desired. Is that correct? So the timer runs on the specific product, not on the building.

No, basically it is a guard for performance. It just prevents that a building that does not need to produce anything is skipping and trying all of its products very fast, which would produce a lot of computing cycles. So in this case and only in this case a 10 second gap is introduced.

If so, my suggestion would be to set the value of the timer to something like (production time of this building) times (number of possible products) plus or minus (some time, basically the value you are already discussing by now).

That would be far too long as it would mean indeed the building would waste a lot of time.


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

GunChleoc wrote:

Here's the commit by Tada that edited some sounds:

https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/8805

And edits by toptopple:

https://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/8277

One thing that seems weird is the sounds smith_00.ogg from 8805 still says in its metadata edited by toptopple. while smith_01 doesn't have this tag. But both were edited by toptopple according to 8277. Don't know whether 8277 was before or after b19 though.


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2019-05-26, 15:07

That was after Build 19. He might simply not have updated the tag.

Edited: 2019-05-26, 15:07

Busy indexing nil values

Top Quote
WorldSavior
Avatar
Topic Opener
Joined: 2016-10-15, 04:10
Posts: 2091
OS: Linux
Version: Recent tournament version
Ranking
One Elder of Players
Location: Germany
Posted at: 2019-05-26, 20:40

hessenfarmer wrote:

WorldSavior wrote:

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.

Why reasonable, don't buildings waste then often 10s or even x times 10s for no real reason?

No, as I tried to explain this is not a delay like a sleep which is executed every time. It is more a timer starting at the very moment the program got skipped (or fails if we implement this). This timer is like don't try this again until now + 10 seconds. So if at least one program can be fully executed this will last far longer than 10 seconds. So next time the check whether the 10 seconds have passed will be true and the program will be tried to be executed normally. This value comes only into place if the sequence of programs is run through faster then 10 seconds. In this case only the first skipped program will wait what is left of the 10 seconds timer, cause the timer of the other programs is running down meanwhile as well.

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.

So you think that it is more important that the building shows for 10s "was skipped" than that the building doesn't waste a lot of time for skipping? If I got everything right, many weapon smiths waste 40s when they should only produce one type of the ware, and with toolsmiths it's even worse, if they should produce only one type of tools (which might be often the case).

This is a misconception. see above where I tried to explain better how this works. 0.5 simply would not be noticeable, as a timer so short would always been run down if for the next try.

Okay, fine, sorry for confusing

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.

Why, is there currently a tool which is produced less often than most others?

No. Starting point was that the tool behind a skipped tool is currently preferred as it gets better chances to have the material ready (talking about the atlantean design now). So I menat to have the most needed tools directly following the most skipped tools in the cycle, as these are the preferred positions. So identifying the most needed is one part. Knowing the less needed is the other part.

Less needed could be for example milking tongs, buckets and hammers (atl) and needles, axes and hunter-spears (fri).

Thanks. It still seems like one or more rather pleasent sound effects got lost somewhere, but this has not the highest priority.

As said if they were there (somewhere) they never went into trunk. I can look into abandoned and neglected branches if there is something still open and never had a merged request. But in this case I wonder how they could have made their way to you.

They couldn't, I heard the sounds in trunk. Or my hearing has adopted indeed, which would be rather creepy and mysterious.


Wanted to save the world, then I got widetracked

Top Quote
Tribal-Chief
Avatar
Joined: 2018-12-09, 17:16
Posts: 62
Ranking
Likes to be here
Posted at: 2019-05-28, 13:41

Just updated as I was getting problems with 'field' definitions when starting ant teritorial game. Now I et

ERROR: Unused key "color" in LuaTable. Please report as a bug.
ERROR: Unused key "image" in LuaTable. Please report as a bug.
ERROR: Unused key "primary" in LuaTable. Please report as a bug.
ERROR: Unused key "secondary" in LuaTable. Please report as a bug.
ERROR: Unused key "wui" in LuaTable. Please report as a bug.
ERROR: Unused key "dropdowns" in LuaTable. Please report as a bug.
ERROR: Unused key "editboxes" in LuaTable. Please report as a bug.
ERROR: Unused key "scrollbars" in LuaTable. Please report as a bug.
ERROR: Unused key "sliders" in LuaTable. Please report as a bug.
ERROR: Unused key "tabpanels" in LuaTable. Please report as a bug.
Style Manager: Reading style templates took 1ms

Caught exception (of type '16LuaTableKeyError') in outermost handler!
The exception said: [../src/scripting/lua_errors.cc:22] enabled is not a field in this table.

This should not happen. Please file a bug report on version bzr9129[trunk](Release).

Uing archlinux

Edited: 2019-05-28, 18:46

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

Tribal-Chief wrote:

Just updated as I was getting problems with 'field' definitions when starting ant teritorial game. Now I et

ERROR: Unused key "color" in LuaTable. Please report as a bug. ERROR: Unused key "image" in LuaTable. Please report as a bug. ERROR: Unused key "primary" in LuaTable. Please report as a bug. ERROR: Unused key "secondary" in LuaTable. Please report as a bug. ERROR: Unused key "wui" in LuaTable. Please report as a bug. ERROR: Unused key "dropdowns" in LuaTable. Please report as a bug. ERROR: Unused key "editboxes" in LuaTable. Please report as a bug. ERROR: Unused key "scrollbars" in LuaTable. Please report as a bug. ERROR: Unused key "sliders" in LuaTable. Please report as a bug. ERROR: Unused key "tabpanels" in LuaTable. Please report as a bug. Style Manager: Reading style templates took 1ms

Caught exception (of type '16LuaTableKeyError') in outermost handler! The exception said: [../src/scripting/lua_errors.cc:22] enabled is not a field in this table.

This should not happen. Please file a bug report on version bzr9129trunk.

Uing archlinux

I had the same thing with my latest windows build. I started a clean build though to be sure whether it is not a something due to my old buildfiles. Will report back if it still fails with a clean build.

EDIT: needed to copy the data folder, after that it was fine.

Edited: 2019-05-28, 20:31

Top Quote