Topic: News about AI

401 — 410 of 436 Posts ‹‹ previous 1 2 ... 39 40 41 42 43 44 next ››

Tibor Topic Opener Joined: 2009-03-23, 22:24 Posts: 1377 One Elder of Players Location: Slovakia	Posted at: 2017-11-20, 21:33 hessenfarmer wrote: Tibor wrote: hessenfarmer wrote: You mean production sites identified as recruitment, then these are built only one. Necessity of such sites is hard to find out, because carriers are not stocked in warehouse but directly send to a road - or am I wrong? No I meant the first building to recruit the second carrier of the tribe (e.g. horses for atlanteans). I never saw the AI build such a building. Of course on crossing the horizon this is not necesdsary but I watched some games on ice wars as well and never saw any of them built which resulted in really weird road networks due to blockage of flags. Just wanted to know whether the alternative carriers are covered by the current necessity algorithm. Don't get me wrong I just want to understand whether it is a matter of training or if we could do something in the algorithm to give the AI the possibility to improve in a certain capability. Those site are internally in AI identified as "recruitment" one. The willingness to build them is controlled by genetic algoithm, also, you can look at the code here: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai.cc#L4404 The AI almost never builds a military building just to gain control over more of the mountain and by this misses the necessary gold on crossing the horizon. this means if the last military building is just controlling the space up to the mountain the AI never built even a sentry to own some of the mountains even after gold has been identified as a shortage. I'm not sure whether this could be solved by training. Positioning of new training sites if very complex and accessible raw material is one of many inputs. Should be "trainable" but would take a lot of iterations I think... It's not about placing training sites. Its about conquering the mountains where the desprately needed metal ores are located. Even the fastest expanding Ai stopped at the border of the mountain, if not "accidentally conquered by a bigger military building. It would have cost them only a sentry to take control over the mountains but they never build one although building lots are constantly available. Sorry, militarysites of course... And still I think training would help this. But you need maps with a lot of such setups... Regarding the check for unreachable ressources or build spaces perhaps this could be done by scanning the map once for all impassable fields and include them in a table which could be checked before the building is placed, if this would be not so much consuming. No, such list of such fields would be completely useless. Reading the map directly is not more time consuming. Connectivity between two points can be verified only with pathfinding algorithm... Top Quote

GunChleoc Joined: 2013-10-07, 14:56 Posts: 3324 One Elder of Players Location: RenderedRect	Posted at: 2017-11-21, 07:36 Tibor wrote: Those site are internally in AI identified as "recruitment" one. The willingness to build them is controlled by genetic algoithm, also, you can look at the code here: Maybe the AI could read if there is a full flag, or if there is a busy road without a carrier2, and have that influence the training? hessenfarmer wrote: Regarding the check for unreachable ressources or build spaces perhaps this could be done by scanning the map once for all impassable fields and include them in a table which could be checked before the building is placed, if this would be not so much consuming. I agree with Tibor here. Terrains can be changed by scripting, so that's not possible. Also, nodes with rocks or trees on them are impassable, and those will obviously change all the time. It would be better to first find candidate fields the same way it is done right now, and then do a reachability test for the candidates before placing the building. Retry this for a maximum number of times before rescheduling the task. Code can probably be adapted from the run_find... worker programs. Busy indexing nil values Top Quote

Tibor Topic Opener Joined: 2009-03-23, 22:24 Posts: 1377 One Elder of Players Location: Slovakia	Posted at: 2017-11-21, 12:42 GunChleoc wrote: Tibor wrote: Those site are internally in AI identified as "recruitment" one. The willingness to build them is controlled by genetic algoithm, also, you can look at the code here: Maybe the AI could read if there is a full flag, or if there is a busy road without a carrier2, and have that influence the training? Yes, count of busy roads, the time when the recruitment site was built (how long ago), whether it is stocked with inputs and so on can be considered. But the problem is that this will make tiny difference during AI playing/testing so good mutations in this area are not strongly propagated.... It would be better to first find candidate fields the same way it is done right now, and then do a reachability test for the candidates before placing the building. Retry this for a maximum number of times before rescheduling the task. Code can probably be adapted from the run_find... worker programs. The problem is that first you calculate this for field x,y, then for x+1,y, then x,y+1, then x-1, y-1 and next and next, and basically we are repeating pathfinding algorithm over and over while it would be enough to pass one result to neighbours... "microregions" concept could mitigate this.... Edited: 2017-11-21, 16:05 Top Quote

GunChleoc Joined: 2013-10-07, 14:56 Posts: 3324 One Elder of Players Location: RenderedRect	Posted at: 2017-11-21, 17:01 This should do for a connectivity check: `CheckStepWalkOn cstep(tribe_.get_worker_descr(tribe_carrier()).movecaps(), false); const Map& map = game.map(); Area<FCoords> area(map.get_fcoords(<proposed position for new site>), 0); for (;; ++area.radius) { std::vector<ImmovableFound> list; map.find_reachable_immovables(area, &list, cstep, FindImmovableAttribute("rocks")); // Do something break; }` Edited: 2017-11-21, 17:02 Busy indexing nil values Top Quote

hessenfarmer Joined: 2014-12-11, 22:16 Posts: 2648 One Elder of Players Location: Bavaria	Posted at: 2017-11-21, 20:47 Tibor wrote: Those site are internally in AI identified as "recruitment" one. The willingness to build them is controlled by genetic algoithm, also, you can look at the code here: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai.cc#L4404 ok had a look to the code If I got it right two military numbers are influencing this behaviour together with the surrounding code. What I couldn't check is if the values calculated for necessity could ever lead to a building built and which values would be needed for the military numbers to get a high ranking in the building algorithm. Sorry, militarysites of course... And still I think training would help this. But you need maps with a lot of such setups... could you give a hint to the line in the code where the decision is calculated where to place a military building? Just to get an understanding of what is done in there. thanks. Top Quote

Tibor Topic Opener Joined: 2009-03-23, 22:24 Posts: 1377 One Elder of Players Location: Slovakia	Posted at: 2017-11-21, 21:54 hessenfarmer wrote: Tibor wrote: Those site are internally in AI identified as "recruitment" one. The willingness to build them is controlled by genetic algoithm, also, you can look at the code here: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai.cc#L4404 ok had a look to the code If I got it right two military numbers are influencing this behaviour together with the surrounding code. What I couldn't check is if the values calculated for necessity could ever lead to a building built and which values would be needed for the military numbers to get a high ranking in the building algorithm. You can enter simple printf into code to verify if the BuildingNecessity::kNeeded is returned and with what primary priority... Overall priority includes probably some impact of actual field considered for construction of this site. But there is no hard limit that guarantees that the site will be built.... What you can do it to modify manually these two military numbers and check if the behavior is changed.... Sorry, militarysites of course... And still I think training would help this. But you need maps with a lot of such setups... could you give a hint to the line in the code where the decision is calculated where to place a military building? Just to get an understanding of what is done in there. AI first decides if particular type of militarysite would be considered, using this function: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai_warfare.cc#L957 And here is scoring specific field for specific militarysite: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai.cc#L2765 Top Quote

hessenfarmer Joined: 2014-12-11, 22:16 Posts: 2648 One Elder of Players Location: Bavaria	Posted at: 2017-11-22, 19:40 Tibor wrote: .. What you can do it to modify manually these two military numbers and check if the behavior is changed.... That is exactly what came to my mind today. Will give it a try. AI first decides if particular type of militarysite would be considered, using this function: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai_warfare.cc#L957 And here is scoring specific field for specific militarysite: http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/ai/defaultai.cc#L2765 Ok I think I found an issue in the code which explains the noticed behaviour. In Line 2772 there is a check included whether buildable fiels are in the distance that would be conquered. Although the comment in the code is mentioning mining sites I traced the definition of buildable thriugh the code and found in the lines followin line 1052 that buildable is defined as has Buildcaps small or medium or big. This does not include has buildcaps mine which is a different attribute. Therefore I think AI will never build a military building to conquer mountains. During my research I noticed that the attribute is_mountain_conqueror is set only for some of the military buildings on which basis this attribute was set? If you can confirm my findings we should open a bug report and fix this. (at least line 2787 suggests that it was desired to conquer mountains to get more mineable fields) regards hessenfarmer Top Quote

Tibor Topic Opener Joined: 2009-03-23, 22:24 Posts: 1377 One Elder of Players Location: Slovakia	Posted at: 2017-11-22, 20:55 hessenfarmer wrote: Ok I think I found an issue in the code which explains the noticed behaviour. In Line 2772 there is a check included whether buildable fiels are in the distance that would be conquered. Although the comment in the code is mentioning mining sites I traced the definition of buildable thriugh the code and found in the lines followin line 1052 that buildable is defined as has Buildcaps small or medium or big. This does not include has buildcaps mine which is a different attribute. Therefore I think AI will never build a military building to conquer mountains. This is quite good comment. As I remember the logic here it is to allow conquering new buildable spots to be able to build new militarysites and expand. However including mines here makes sense as well. As this change will have some impact on scoring and everything, some amount of training is desired afterwards. During my research I noticed that the attribute is_mountain_conqueror is set only for some of the military buildings on which basis this attribute was set? There was some discussioin and some guy created these attributes for various military sites. This is just another hint for AI If you can confirm my findings we should open a bug report and fix this. (at least line 2787 suggests that it was desired to conquer mountains to get more mineable fields) Yes, I think such change can be reasonable, however some play-testing would be nice... Top Quote

hessenfarmer Joined: 2014-12-11, 22:16 Posts: 2648 One Elder of Players Location: Bavaria	Posted at: 2017-11-26, 21:52 ok playtesting should not be the problem. Shall I open a bug for this? Top Quote

Tibor Topic Opener Joined: 2009-03-23, 22:24 Posts: 1377 One Elder of Players Location: Slovakia	Posted at: 2017-11-27, 06:38 Yes, do it please Top Quote

‹‹ previous 1 2 ... 39 40 41 42 43 44 next ››