# Topic: Improving Production Sites

 toptopple Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums Posted at: 2016-07-31, 19:26 What would be a failed cycle then? Certainly not the ones which are not skipped. You need to have some negative event in this calculation scheme. Did you have proposal for this? Top Quote DragonAtma Joined: 2014-09-14, 01:54 Posts: 254 Tribe Member Posted at: 2016-07-31, 21:29 I can see up to three types of failed cycles: (1) The building wants to change materials X and Y into item Z, but doesn't have enough X and/or Y. (2) The flag in front of the building already has eight objects sitting there; therefore, there's no room to place another item there. (3) Everything the building produces is skipped because the warehouses have enough of every item produced there. Types 2 and 3 may be debatable; type 1 isn't. Top Quote Tibor Joined: 2009-03-23, 23:24 Posts: 1233 One Elder of Players Location: Slovakia Posted at: 2016-07-31, 21:44 toptopple wrote: @Tibor I. Calculation So are you saying that when productivity of a site (or the average of all sites of this type) surmounts the calculated value (which is a percentage) a new house is built? I hope the given formula is falsely put [code] treshold = 80 - 15 * count_of_outputs [/code] If I put in the count for e.g. empire->weaponsmithy (which is 5) I receive 80 - 15 * 5 = 5. You would receive countless houses until this value is not met. II. Impact on AI As for my observations, which so far confirm theory, statistics values for production sites won't change through the new scripts but they may become crudely FALSE because they don't represent the real productivity of the site any more. (Not sure if they did before!) They are false in the sense that they are TOO LOW (never to high)! But as your thresholds appear to be considerably low, it could well be there is no noticable change to the quality of AI playing. You are right, I had to look into code, the formula is: 10 + 70 / outputs.size() ... I had to look into code... For me the proper measure of performance would be 'time utilization' - what time in last 10 minutes the building were producing something. 35% would mean the building was productive for 3,5 minutes. 90% would mean that building is able to produce any type of product without peculiar skipping/waiting for unwanted/unsupplied products... But now AI has to use dubious statistics to figurou out when another building is needed. Top Quote toptopple Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums Posted at: 2016-08-01, 10:54 TiborFor me the proper measure of performance would be 'time utilization' - what time in last 10 minutes the building were producing something. 35% would mean the building was productive for 3,5 minutes. That could be a basis, yes. We need to asses the entire thing, however. Let's call the basic site working processor the "work-processor", this is programmatically defined outside of the scripts. The work-processor calls the "production-cycle", which cycles through a series of individual "product-runs". The latter two are defined in scripts. a) the work-processor consists of two time segments, the "site-idle" phase (which is just doing nothing) and the "site-at-work" phase. The site-idle time is currently around 15 sec but may be set differently for each type of production site. (Not sure if this is script, but it should.) For the new statistics there must be a small third phase, the "delay-phase". The delay-phase may be 1-3 sec and is the negative element in the calculation, for the case that no production occurs. b) the site-at-work phase is running the production-cycle and currently a mixture of actual production times and "penalty" (futile) wait times. In order for the new statistics to work properly it must reflect the work times only. In that my proposed modifications to the scripts are essential to operation. They must be even enhanced to eliminate all "penalty" times from them. c) the basic idea is to relate, within an interval, the time spent on site-at-work to the sum {absolute time spent minus site-idle time}. d) implementing a pure time interval based calculation of statistic values of sites might be consumptive, multi-threaded and look awkward. A more economic solution might be to set up a cycle counter and perform the calculation based on number of site-at-work cycles. The absolute time spend can be measured and doesn't need to be a fix value. The calculation can then be performed by the work-processor. e) if "penalty" times are wished for in the production-cycle, this should be possible by introducing a return value for non-productive time of the cycle. Then an extra command would have to be defined for the script. But before this happens, I guess we will be happy with the "pure" solution. Cheers! Edited: 2016-08-01, 11:05 Top Quote toptopple Joined: 2013-10-30, 08:11 Posts: 156 At home in WL-forums Posted at: 2016-08-01, 20:21 I must correct my suggestion! The "delay-phase" mentioned under a) shall not be unconditional, also the value is too low. So after reconsidering my plan goes: i) a "delay-time" sum-up value shall be kept in the work-processor and for each production-cycle that takes less than 1 sec time (= doing nothing), a fix value (e.g. 30 sec) shall be added to the delay-time value. (fictional time) ii) a "work-time" value shall be kept in the work-processor and for each production-cycle that takes more than 1 sec time (= doing something) the real spent time for this cycle shall be added to the work-time value. iii) "idle-time" is the sum which adds a fix value for the idle phase of each performed production-cycle. iv) the statistics calculation formula for the site then would look like "work_time * 100 / (time_spent + delay_time - idle_time)". Add a (min=0, max=100) check to it and ready. Any mistakes here or any better ideas than that? Top Quote Tibor Joined: 2009-03-23, 23:24 Posts: 1233 One Elder of Players Location: Slovakia Posted at: 2016-08-01, 20:36 The problem is how to store all that data. Currently we have simple FIFO bin of 20 bools. This is where you/we need to start.... Top Quote king_of_nowhere Joined: 2014-09-15, 18:35 Posts: 1312 One Elder of Players Posted at: 2016-08-02, 14:46 what i was referring to when i said statistics are inaccurate is that the program only count cycles worked or skipped. so for example an imperial milll has 5 seconds idle time and 15 seconds work time, if it skips a cycle and then work a cycle it says productivity 50% even if, in fact, it worked 20 seconds out of 25 and so should be at 80%. Tibor wrote: For me the proper measure of performance would be 'time utilization' - what time in last 10 minutes the building were producing something. 35% would mean the building was productive for 3,5 minutes. 90% would mean that building is able to produce any type of product without peculiar skipping/waiting for unwanted/unsupplied products... But now AI has to use dubious statistics to figurou out when another building is needed. exactly what i meant. But we're going offtopic here. Top Quote WorldSavior Joined: 2016-10-15, 04:10 Posts: 1143 One Elder of Players Location: GER Posted at: 2018-01-19, 18:25 I‘d suggest to make some buildings even more clever. For example, the Big Inn should waste less time. Right now in trunk, there are break times of 23 or 5 seconds in its programs, but I suggest to replace those times by a very short time – for example 0.1 seconds – in order to avoid unnecessary breaks and that only one type of ware is produced if the supply is low (in trunk, this is the case in the atlantean armor smithy where this time is 0 seconds). I wonder if the computer has to do a lot of calculations if the time is zero or very small? So if 0.1 seconds is too small, one could think about increasing it a little bit. In trunk, one program of the big inn looks like this: (sorry for bad syntax use) produce_ration = { `````` -- TRANSLATORS: Completed/Skipped/Did not start preparing a ration because ... descname = _"preparing a ration", actions = { -- time total: 33 "return=skipped unless economy needs ration", "sleep=23000", "consume=barbarians_bread,fish,meat", "play_sound=sound/barbarians/taverns tavern 100", "sleep=10000", "produce=ration" } }, `````` The change could look like this: (only concerning "sleep times") produce_ration = { `````` -- TRANSLATORS: Completed/Skipped/Did not start preparing a ration because ... descname = _"preparing a ration", actions = { -- time total: 33 "return=skipped unless economy needs ration", "sleep=100", "consume=barbarians_bread,fish,meat", "play_sound=sound/barbarians/taverns tavern 100", "sleep=32900", "produce=ration" } }, `````` Both other programs of the Big Inn should have the same changes. Other buildings which could be changed like that could be inns and smelting works. What do you think about that? “It's a threat to our planet to believe that someone else will save it.” - Robert Swan Top Quote WorldSavior Joined: 2016-10-15, 04:10 Posts: 1143 One Elder of Players Location: GER Posted at: 2018-01-25, 16:28 toptopple wrote: New branch [url=https://code.launchpad.net/~7010622-q/widelands/topple-production-logic-2/+merge/301477]topple-production-logic-2[/url]. This deals with the weapon and armour smithies of all races to eliminate ANY penalty time for unselectable products. This may, under circumstance, speed up production of simple weapons considerably. But the circumstances are almost irrelevant. The buildings are only faster if the input of a ware is too small AND if you do such a bad managing that the economy needs the products which contain that ware. That's not how it works. At the other hand, if you give for example a weapon smithy everything which it needs, or if it skips weapons which are not needed, there is no change. So there are no reasons for making the buildings slower. Do you know what, you trolled me with that: Some weeks ago a played a match in trunk and I wondered - what on earth is going on here, why are my dungeons only running at 50%? “It's a threat to our planet to believe that someone else will save it.” - Robert Swan Top Quote GunChleoc Joined: 2013-10-07, 15:56 Posts: 2891 One Elder of Players Location: RenderedRect Posted at: 2018-01-30, 12:09 How about getting rid of the first sleep entirely? Busy indexing nil values Top Quote