[micro_ai] slow

The place to post your WML questions and answers.

Moderator: Forum Moderators

Forum rules
  • Please use [code] BBCode tags in your posts for embedding WML snippets.
  • To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

[micro_ai] slow

Post by enclave »

Hi I have a [micro_ai] for specific units with ability "hc_build_new_city", it should avoid going in 3 hex radius around villages, and it works.

Code: Select all

[micro_ai]
		side=$side_number
		ai_type=goto
		action=add
		ca_id=qc_settlers_$side_number
	[filter]
		ability=hc_build_new_city
	[/filter]
  	[filter_location]
		[not]
		terrain=*^V*
		radius=3
		[/not]
	[/filter_location]
	ca_score=210001
	avoid_enemies=1
  [/micro_ai]
But it is performed very very slow, freezes the screen.. what could be done to make it faster?
(I tried extra radius and things.. but ai either stops going anywhere at all or starts to completely ignore the village 3 hex rule.)
-----------------------------------
Well first update is that it takes ages to have just [not] in it:

Code: Select all

  	[filter_location]
		[not]
		terrain=*^V*
		[/not]
	[/filter_location]
Without not it was working quickly. So ill go further with it... somehow...
mattsc
Inactive Developer
Posts: 1217
Joined: October 13th, 2010, 6:14 pm

Re: [micro_ai] slow

Post by mattsc »

Indeed. As is stated at Micro_AIs#Generalized_Goto_Micro_AI_.28ai_type.3Dgoto.29:
Depending on the parameters used, the Goto Micro AI might require a lot of path finding to be done. Thus, while it is possible to set up this AI to move many units to many different locations, a usage like that might require quite a long calculation time.
That location filter you are using probably matches a lot of hexes on the map. There really isn't much that can be done about that by the Goto MAI and you need to come up with a different way of doing this.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

Thanks mattsc, at least after your reply I know that I don't do it completely wrong :) I will try to figure out something ;)

Actually in the past I tried to use *^F* with other micro_ai, but it was only for king, there was a lot of forest and speed was really fast (without [NOT] in it)
So it was also matching a lot of locations.. but still possibly less...
mattsc
Inactive Developer
Posts: 1217
Joined: October 13th, 2010, 6:14 pm

Re: [micro_ai] slow

Post by mattsc »

You're not doing anything wrong at all, it's just that the Goto Micro AI was not built for this use case. :) You should still be able to use this MAI if you can come up with a sparser set of hexes for the SLF. Or it's probably possible to do this in WML. Or even writing a different custom AI for this doesn't sound too hard. I could help with that if that's what it comes down to, but my first suggestion would be to try to find a better SLF.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

Could anyone write what I would need to write into filter to shorten the amount of hexes?
For example to make it only look in radius of 10 hex from the unit with that ability?
I'm sometimes really really bad with filters... specially radius..
I assume it might be something like this?

Code: Select all

[filter_location]
   [filter]
   ability=hc_build_new_city
   [/filter]
   radius=10
	[not]
	terrain=*^V*
	radius=3
	[/not]
[/filter_location]
PS. I tried it and it obviously doesn't work :)
Last edited by enclave on May 5th, 2018, 10:34 pm, edited 1 time in total.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

mattsc wrote: May 5th, 2018, 9:54 pm You're not doing anything wrong at all, it's just that the Goto Micro AI was not built for this use case. :) You should still be able to use this MAI if you can come up with a sparser set of hexes for the SLF. Or it's probably possible to do this in WML. Or even writing a different custom AI for this doesn't sound too hard. I could help with that if that's what it comes down to, but my first suggestion would be to try to find a better SLF.
I was thinking I could limit the field of affection to 5-10 hexes... and maybe create another more important rule (with higher ca_score) for same units with this ability, which would just make them go to corners of the map.. So ideally they would all go to the corners, but avoid villages hex radius on their path... Am i thinking anywhere near that 2 rules could work together? IF only limiting field of 3 hex rule would help the speed gain..
mattsc
Inactive Developer
Posts: 1217
Joined: October 13th, 2010, 6:14 pm

Re: [micro_ai] slow

Post by mattsc »

Umm, before I say anything else, there seems to be a misunderstanding here. Either you are misunderstanding what the Goto MAI does, or I am misunderstanding what you are saying. Whatever you put into the SLF only sets the goals of the units' moves. It has no effect whatsoever on which hexes a unit steps on (or stops because it runs out of MP) on the way to the goal. So if you want these units not to end their moves within 3 hexes of villages, the Goto MAI cannot be used for that.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

nono, i don't mean they shouldn't step there.. I just want their goal to be not to step there... it works fine with the first filter, I just want it to work quicker... without freezing the game.. for that I would need to limit the area of the affect, according to the idea that there was too many hexes in the filter. So smaller area of possible hexes, faster speed?
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

I'm creating a filter tester at the moment.. I think I'm too tired to battle filters... and it's time to make a filter tester add-on for people like me who keep pressing F5 for 5 hours after tweaking the filter in 100000000 ways.
mattsc
Inactive Developer
Posts: 1217
Joined: October 13th, 2010, 6:14 pm

Re: [micro_ai] slow

Post by mattsc »

enclave wrote: May 5th, 2018, 10:49 pm nono, i don't mean they shouldn't step there.. I just want their goal to be not to step there... it works fine with the first filter, I just want it to work quicker... without freezing the game.. for that I would need to limit the area of the affect, according to the idea that there was too many hexes in the filter. So smaller area of possible hexes, faster speed?
Okay, in that case, yes. The Goto MAI does path finding for each unit to each goal hex. So the number of paths it finds is the number of units times the number of goal hexes. You can see how that can blow up very quickly. In addition, path finding takes longer for hexes that are farther away.

An SLF tester is very simply built. For example (not tested, so I might have a typo in it, but I have used this kind of thing many times):

Code: Select all

[event]
    name=moveto
    first_time_only=no
    
    [terrain]
        terrain=Qlf
        <insert your SLF of choice here>
    [/terrain]
[/event]
All you have to do is move a unit, and all terrain matching your filter gets transformed. It's crude and brute force, but it works.

The only thing you need to be careful with is if your SLF also contains a terrain. You need to put that ino [and][/and] then.
User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: [micro_ai] slow

Post by Celtic_Minstrel »

From your post in the other thread I would definitely say the goto MicroAI is not very suitable for this. I think it would make more sense to use a custom-written AI instead. (That said, it's nice that you've managed to get it working with the goto MicroAI, so if you're satisfied with that...)
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

Ok I made it work and it works perfectly fast and just as equired :)
Here is a link for more details: viewtopic.php?f=21&t=44934&p=627439#p627439
And here is the short example of how it was done:

Code: Select all

 	[micro_ai]
		side=$side_number
		ai_type=goto
		action=add
		ca_id=qc_settlers_$side_number
	[filter]
		ability=hc_build_new_city
	[/filter]
[filter_location]
	   [not]
	terrain=*^V*
	radius=3
	[/not]
[and]  ## this AND was the critical part.. but it wasn't obvious while I was trying million different things..
   [filter]
   ability=hc_build_new_city
   [/filter]
	radius=3
[/and] 
[/filter_location]
	ca_score=210001
	avoid_enemies=1
  [/micro_ai]
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

Celtic_Minstrel wrote: May 6th, 2018, 3:18 am From your post in the other thread I would definitely say the goto MicroAI is not very suitable for this. I think it would make more sense to use a custom-written AI instead. (That said, it's nice that you've managed to get it working with the goto MicroAI, so if you're satisfied with that...)
Yeah.. Thanks very much, I think I'm very happy now :) It works very well.. I don't know how to write custom AI so it would take a bit of time to learn..
Maybe some day I will be ready for it... but currently there is enough of other things to keep me occupied =] Thanks again anyway!
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

mattsc wrote: May 5th, 2018, 9:54 pm You're not doing anything wrong at all, it's just that the Goto Micro AI was not built for this use case. :) You should still be able to use this MAI if you can come up with a sparser set of hexes for the SLF. Or it's probably possible to do this in WML. Or even writing a different custom AI for this doesn't sound too hard. I could help with that if that's what it comes down to, but my first suggestion would be to try to find a better SLF.
Ok, last time you gave me a great clue on how to make it faster.. less filtered locations increased the speed to perfectly playable without noticing any slow motion..
Now I hope you could help me again because it's hard to believe that the filter is so slow... for "simple_attack", there must be something that can help it become faster...
Here is my micro_ai...

Code: Select all

[micro_ai]
            side=$side_number
            ai_type=simple_attack
            action=add
            ca_id=qc_attack_village_$side_number
            [filter]
				canrecruit=false
				[not]
                                      ability=qc_worker,hc_build_new_city
				[/not]
				  [filter_location]
				     terrain=*^V*
				  [filter_owner]
				  [enemy_of]
				    side=$side_number
				  [/enemy_of]
				 [/filter_owner]
				 radius=3
				[and]
			          [filter]
				  [/filter]
				[/and]
				[/filter_location]
           [/filter]
			[filter_second]
          [filter_location]
                terrain=*^V*
				[filter_owner]
			            [enemy_of]
				         side=$side_number
				     [/enemy_of]
				[/filter_owner]
					[and]
				            [filter]
				            [/filter]
				        [/and]
				         [and]
				            [filter]
				               side=$side_number
				           [/filter]
				           radius=3
				      [/and]
            [/filter_location]
		[/filter_second]
		weapon=1
 			ca_score=210004
 [/micro_ai]
This is selecting the units who are in radius of 3 near enemy village with unit and then attacking that village which has attackers around it...
I will try to change radius to 1............ idk what else I can do to make it work without freeze. :(

PS. even with radius 1 the process hang for some 10 seconds... only 1 unit was matching the filter... and only 1 location....
I will now try fast_ai and see if any different..
I might have filter wrong.. but I tested them individually and they worked... not sure if they start work differently when inside [filter_second] tag..

PPS. hmm in first attempt they didnt attack at all... i will change aggression to 1
enclave
Posts: 936
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave »

Code: Select all

[micro_ai]
            side=$side_number
            ai_type=fast_ai
            action=add
            ca_id=qc_attack_village_$side_number
            [filter]
				canrecruit=false
				[not]
               ability=qc_worker,hc_build_new_city
				[/not]
				[filter_location]
				terrain=*^V*
				[filter_owner]
				[enemy_of]
				side=$side_number
				[/enemy_of]
				[/filter_owner]
				radius=1
				[and]
			[filter]
				[/filter]
				[/and]
				[/filter_location]
           [/filter]
			[filter_second]
          [filter_location]
                terrain=*^V*
				[filter_owner]
				[enemy_of]
				side=$side_number
				[/enemy_of]
				[/filter_owner]
				[and]
				[filter]
				[/filter]
				[/and]
				[and]
				[filter]
				side=$side_number
				[/filter]
				radius=1
				[/and]
			[/filter_location]	
		[/filter_second]
		##weapon=1
		aggression=1
 			ca_score=210004
 [/micro_ai]
They only sometimes attacked the village.. does it mean the filter is not working?

PS. aggression=100 same result.. dont want to attack.

PPS. Trying to read wiki help, but I really need a translator/decriptor for this one:
move_cost_factor=2: (number >= 1.1) The factor by which the move cost to a goal hex may be larger than the distance to the goal hex for a move to be considered "efficient". See description above. 1.1 is used if this is set to values smaller than 1.1. Smaller values might lead to better behavior, while larger values might speed up the AI.
What would I need to put if I don't want AI to travel distance longer than he can within 1 turn (basically I want it to attack or go there only if it is in his vision reach)
ca_score is therefore not a valid optional key.
lol I guess if i can't control the sequence of this then there is no point to use this tag... or to consider it to be one of the [micro_ai]....

PPPS. so I'm back to simple_attack, but it's completely unusable?

Code: Select all

 [micro_ai]
            side=$side_number
            ai_type=simple_attack
            action=add
			ca_id=qc_attck_villa_$side_number
			[filter]
			canrecruit=false
				[not]
                ability=qc_worker,hc_build_new_city
				[/not]
			[/filter]
			[filter_second]
			[filter_location]
                 terrain=*^V*
            [/filter_location]
			[/filter_second]
			weapon=1
			ca_score=210005
 [/micro_ai]
This is taking some 5-10 seconds to decide what to do with just 1 unit in range of attack... All is fast until AI is in attack range, then it starts the super-computing the universe... to attack just 1 unit in village..

This would bloody go x1000 faster if there was a micro_ai tag called "goto_attack" which would use goto filters and then just temporarily set AI aggression to 1000, until next unit.. cheeses...

Ok I will try one last thing, and I'm reporting this as a bug, because I just tried the MOST BASIC filter possible and it froze thinking for 10 seconds what to do with it...

Code: Select all

 [micro_ai]
            side=$side_number
            ai_type=simple_attack
            action=add
			ca_id=qc_attck_villa_$side_number
			[filter]
x=10
y=8
[/filter]
			[filter_second]
x=6
y=6
			[/filter_second]
			ca_score=210005
 [/micro_ai]
so much time wasted..

Code: Select all

[micro_ai]
            side=$side_number
            ai_type=simple_attack
            action=add
			ca_id=qc_attck_villa_$side_number
			[filter]
			[filter_location]
x=10
y=8
[/filter_location]
[/filter]
			[filter_second]
			[filter_location]
x=6
y=6
[/filter_location]
			[/filter_second]
			ca_score=210005
 [/micro_ai]
weapon=1 didnt make any difference..
Now question is only if its simple_attack micro_ai completely bugged. Or it happens because I have large list of weapon specials...
Would many weapon specials make a difference with freezing it for 10 sek on a basic filter with exact x,y coordinates?
Post Reply