I dont say that official statistics is completely wrong. But rather it looks at
the thing from other angle...
Also you said it will rise up slowly, but will fall down much faster, correct?
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your
I am on my fast(er) machine now, but here there is no also error. But after the
output of
NOCOM loading sound effect: sound/hammering//hammering_02.ogg
the output stops for a while. On each load of the save game the stop-time is
different, one time the stop lasts longer, the other time it
hm, there is now a text conflict shown...
Text conflict in data/tribes/workers/frisians/soldier/init.lua
--
https://code.launchpad.net/~widelands-dev/widelands/list-directories-in-cpp/+merge/366614
Your team Widelands Developers is requested to review the proposed merge of
skips take 10 seconds if second time skipped this is hardcoded in
productionsite.cc
fails do not need any time (except some milliseconds) for e.g. atlantean
toolsmithy
If we use UI stats we will not go to 100% suddenly cause we take the last 20
task into account. so if we have currently
But we are still talking only about info for AI not players
If we cannot produce something due to missing inputs and suddenly we will have
those inputs, the productionsite will have to reduce production of the ware
that is being produced 90% of time now. Might not be bad, but we will be
do we need another building also is task based from my perspective not time
based.
if we fail every 3rd attempt we don't need another building as we can't provide
enough inputs for the current one. Fails are rather short now for a lot of
buildings, as we have updated the working programs of
The question to answer here is - do we need another building of the type. If
time utilization is 35 % - we dont need.
If 97% - we definitely need.
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is requested to
Correct. I think the question is what is the relevant Information. I believe
the information necessary for management is how good is a building satisfying
its intended task. For me in this case it is more relevant the relation between
success and failure rather than the relation active to not
But if failure (whatever) takes 5 seconds and success 90, then after 2 failures
and 1 success, UI statistics will be 35%, but the productionsite was actually
working 90% of time
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team
Just had a second look. Now we do count a skipped program as a fail which
hasn't be the case in the previous version.
>From what I can see in the old version the algorithm was:
if failed --> scale the old stats to 80% (resulting in asymptotically falling
values if fail everytime)
if skipped
Continuous integration builds have changed state:
Travis build 5022. State: errored. Details:
https://travis-ci.org/widelands/widelands/builds/534690803.
Appveyor build 4802. State: success. Details:
Review: Approve
Forget my last comment. I had the wrong conception of bo.outputs
So for me Code looks good will test this tonight.
--
https://code.launchpad.net/~widelands-dev/widelands/bug-1829471-worker-preciousness/+merge/367608
Your team Widelands Developers is subscribed to branch
I think the deduction of Recruitment of second carrier will not work this way
as Outputs of recruitment sites contains the worker so it isn't empty. see
inline comment as well
Diff comments:
>
> === modified file 'src/ai/defaultai.cc'
> --- src/ai/defaultai.cc 2019-05-17 11:45:39 +
> There is a difference between hard-coding values like "preciousness = 5" and
> automatically deducing building types that get a completely different
> treatment and algorithm by the AI anyway.
Agreed on the difference. But not deducing the types and having flags instead
gives us more
* State: Chroot problem
* Recipe: widelands-dev/widelands-daily
* Archive: ~widelands-dev/ubuntu/widelands-daily
* Distroseries: bionic
* Duration: 1 minute
* Build Log:
https://launchpad.net/~widelands-dev/+archive/ubuntu/widelands-daily/+recipebuild/2335812/+files/buildlog.txt.gz
*
* State: Chroot problem
* Recipe: widelands-dev/widelands-daily
* Archive: ~widelands-dev/ubuntu/widelands-daily
* Distroseries: disco
* Duration: 1 minute
* Build Log:
https://launchpad.net/~widelands-dev/+archive/ubuntu/widelands-daily/+recipebuild/2335814/+files/buildlog.txt.gz
* Upload
AI need % of building utilization. And I think showed % (in UI) is not reliable
enough...
By old approach it just presumed that successful program took 5x more than
unsuccessful program - this is example. With exact timing the number would be
more exact.
Also we have 'skipped' and 'failed'
I guess the question here is - what are you using this for? Do you need the
exact duration of a specific run of the production program, or do you need to
know how long it usually takes?
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team
The proposal to merge lp:~widelands-dev/widelands/bug-1818013-new-logo into
lp:widelands has been updated.
Status: Needs review => Merged
For more details, see:
https://code.launchpad.net/~widelands-dev/widelands/bug-1818013-new-logo/+merge/366502
--
Your team Widelands Developers is
@hessenfarmer - see my responses
Diff comments:
> === modified file 'src/logic/map_objects/tribes/productionsite.cc'
> --- src/logic/map_objects/tribes/productionsite.cc2019-05-18 11:58:43
> +
> +++ src/logic/map_objects/tribes/productionsite.cc2019-05-19 20:55:45
> +
> @@
What I need here is % of time utilization, something more accurate that what is
now calculated. I know that times are deducted from LUA files, but it seems
easier to add one variable here. Also some production programs can vary in
duration, correct?
--
see inline comments
Diff comments:
> === modified file 'src/logic/map_objects/tribes/productionsite.cc'
> --- src/logic/map_objects/tribes/productionsite.cc2019-05-18 11:58:43
> +
> +++ src/logic/map_objects/tribes/productionsite.cc2019-05-19 20:55:45
> +
> @@ -954,24 +955,28
As I wrote on the forums, I think that this should be calculated when parsing
the production programs. This way, we get more accurate statistics, and we can
use it in the encyclopedia.
This has been in my head for a while and I plan to start working on this once
the 2 prerequisite branches are
I have added some debug log output to this branch so that we can find out which
file is causing the problem for you. You should see something like this with
your savegame:
Second and third phase loading Map Objects ... NOCOM loading sound effect:
sound/animals//frog.ogg
NOCOM loading sound
> One thing I would like to have is a definition of normal AI limit to be able
> to have the limit values currently hardcoded in lua.
Agreed, I have added it to the bug. I don't want to do it in this branch
though, because then we will have to re-review the code in this branch for
every new
P.S. What we probably really should do here is to treat output workers in the
exact same way as output wares and get rid of the special treatment code for
recruiting sites, but that is out of scope for this branch.
--
@bunnybot merge
--
https://code.launchpad.net/~widelands-dev/widelands/bug-1818013-new-logo/+merge/366502
Your team Widelands Developers is requested to review the proposed merge of
lp:~widelands-dev/widelands/bug-1818013-new-logo into lp:widelands.
There is a difference between hard-coding values like "preciousness = 5" and
automatically deducing building types that get a completely different treatment
and algorithm by the AI anyway.
--
https://code.launchpad.net/~widelands-dev/widelands/bug-1829471-worker-preciousness/+merge/367608
Your
28 matches
Mail list logo
