I think skipped should be ignored in the UI, but the AI should be able to know
whether a program has been skipped a lot recently, because that means that a
new building is not needed.
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team
transient failure on travis
@bunnybot merge force
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is subscribed to branch
lp:~widelands-dev/widelands/ai_productionsites_statistics.
Have done some playtesting 4 AI players on full moon.
found no obvious anomalies.
@bunnybot merge
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is subscribed to branch
For AI this is the best I believe...
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is subscribed to branch
lp:~widelands-dev/widelands/ai_productionsites_statistics.
ok you are right especially for the AI cause the AI might want to build another
idle building then.
However we should perhaps have different rating for failed and skipped. If you
like we could deliver only half of the duration time to the update fuctionality
in case we skipped so it will fall
Low utilization can mean one of two shortage of inputs or that the output is
not needed. So by my opinion, skipped programs should be included in
statistics...
Because utilization close to 100 while the building being idle most of time can
confuse players in believing that new building is
OK, comments implemented.
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is subscribed to branch
lp:~widelands-dev/widelands/ai_productionsites_statistics.
___
Mailing
by the way I now see another option.
- this change plus exposing the new crude Statistics to the UI ;-)
--
https://code.launchpad.net/~widelands-dev/widelands/ai_productionsites_statistics/+merge/367613
Your team Widelands Developers is subscribed to branch
Review: Approve
Got the concept. I think we should have this after you perhaps might fix the
small nits from the below diff comments
Diff comments:
> === modified file 'src/logic/map_objects/tribes/productionsite.cc'
> --- src/logic/map_objects/tribes/productionsite.cc2019-05-18 11:58:43
Hm I made a excel now. reported a bug to upload it and linked it to this
branch. It seems your formula is delivering weird results. I don't know why or
if I made a mistake. I think I don't have understood this in total but at least
the old crude_statistics wasn't that far from UI but more
I completely understand current code. If it was "attempts in last x minutes" -
it would be fine for me. But 'last 20 attempts' - this I understand from coding
perspective - but dont like it.
'official statistics' to me is like actual_statistics^2. 100% and 0% are right,
but in between it is
UI stats are calcualted over the last 20 real attempts. Skipped does not count
as attempt. It is build like a shifting register with 20 positions containing
true or false. it is falling faster for most buildings due to the fail time is
shorter than working time. if fail time is really short it
I see the opinions differ too much. I see these options:
- no change
- this change
- no change, but expose official statistics to the AI's genetic algorithm and
retrain
- this change, but expose official statistics to the AI's genetic algorithm and
retrain
- remove this crude_statistics, and
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
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
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
@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
27 matches
Mail list logo
