[micro_ai] slow

The place to post your WML questions and answers.

Moderators: Forum Moderators, Developers

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.
User avatar
Celtic_Minstrel
Developer
Posts: 1277
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [micro_ai] slow

Post by Celtic_Minstrel » May 26th, 2018, 1:35 am

Perhaps what's needed for reducing the filter times is that thing gfgtdf suggested - separating the "compilation" and the evaluation of the filter, so that it can be compiled once and then evaluated many times.

Obviously that won't help for 1.14, though.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

enclave
Posts: 910
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave » May 26th, 2018, 10:36 am

mattsc wrote:
May 25th, 2018, 11:47 pm
That's great to hear. As for more customizable, we're always open to suggestions. There's even a feedback thread, although that's been dead for a long time now.
That's interesting, I will write something there soon then :) I know that not all ideas are gona be accepted, I make add-ons and people often ask for soemthing and there is often a reason to politely reject it... so I understand your point of views perfectly.
mattsc wrote:
May 25th, 2018, 11:47 pm
As I mentioned, my first (very quick and superficial) look showed that more than half of the time is needed simply for evaluating the filters. And that is set up to be repeated after every move of an AI unit, because both the units and the locations might change due to the previous move. And:
No, it is not unknown at all what it does (and all AI candidate actions do this). The AI does not know up front that there is nothing left to do, it needs to figure out first if there are units/locations left to consider. Now, it does sound like that is not done very efficiently. I'll have a look into that.
Yeah it's not done efficiently since there are more or less no units with movepoints left at all.. So not much to consider (I mean it would take some 10 ms to filter all units movepoints greater than 0. There must be some more efficient way.. I will think about it too.. if I can suggest anything..
For now I don't understand how exactly it works... If it applies all filters to all units in ca_score order and only to the units with movepoints left, then I don't see where the problem with delay comes from at all... But if it's done in some other way... then how is it done exactly? I'm not sure if I understand the sequence of actions...
mattsc wrote:
May 25th, 2018, 11:47 pm
I see two ways of dealing with the long filter eval times:
  1. Reduce the time it takes to evaluate the filters (which might include moving parts into Lua). I don't know much about that, but it is probably possible. Well, I am quite certain about the part I already said in the previous paragraph, that the final evaluation, when all units have moved, can almost certainly be streamlined.
  2. If your scenario/map is such that it does not require units and/or locations to be (re)found after each AI unit move, it could be set up to be done only once at the beginning of the turn. That would obviously save a lot of evaluation time. That will not be ported to mainline though, as it would break other uses of this MAI. [Well, maybe we could add an option reevaluate_after_move=true/false or something, that defaults to the old behavior (true).]
I tried to play around with WML filters and couldn't really do anything seems to be.. I tried to add [and][/and] and filter for something less time demanding first like canrecruit=false or unit type or moves left... (unless i done something wrong, which is possible). So I was trying to make more simple filters trigger first and only then complicated filters would start working if simple filters would catch something.. it either had no affect (so i thought maybe there is a built in filter for moves left like for side_number) or I done something wrong trying.
My main idea for micro_ai customization would be to add options for more efficient AI if required.. for example separate filters into basic and more advanced like [filter] type=Footpad [/filter] and
[advanced_filter] [filter_wml] moves=3 [variables] range=5 [/variables] [/filter_wml] [filter_location.....[and][or]......
so that it wouldnt even try to evaluate the advanced filter if basic filter didn't catch anything... unless it's doable now? maybe I done something wrong trying to imitate that..?
So I will try to use lua next when I have time.. who knows ;) maybe it will gain speed...

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 26th, 2018, 6:45 pm

Rushing around, so I'm just going to make one comment for now:
enclave wrote:
May 26th, 2018, 10:36 am
Yeah it's not done efficiently since there are more or less no units with movepoints left at all..
Well, it's not done efficiently for this use case. You need to keep in mind that what you're having here is a rather complex filter, and that most other use cases are much simpler (and more common) than this.

The unit filter uses the ai_helper function get_units_with_moves which applies the filter first, and then sorts out units that have no moves left. And there's a good reason for that. Filtering for MP is slow (because 'moves' is not a key that can be used directly in SUFs), so it gets separated out. And the alternative (selecting all units first, then filtering for moves, then applying the filter) is actually slower than what it is right now for simple filters (esp. early in the turn when most units still have their MP). And since simple filters are almost certainly being used more often than something complex like in your case, this should not be changed in mainline. [The idea of adding a separate advanced filter is interesting though, but if we do that, it would be for 1.15 and on only.]

I will still have a look around if there is something that can be done that would speed up the evaluation for all use cases. It's quite possible. But it also seems pretty clear that we are moving toward a custom AI for your add-on. Which, as I said, is easy to do and should result in quite a speed-up.

On all your other points, I'll comment later when I have more time. There's still no real need for you to do anything right now, I know what needs to be done next. Although ... you could tell me whether it would be good enough if this AI simply found all units once at the beginning of the turn and then reused that list for all moves. Or do things change during the AI turn that might change the list of filtered units (other than them using up their MP, of course)? Because not having to evaluate the filter at all, except for once at the beginning of the turn, would save by far the most time. :P

enclave
Posts: 910
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave » May 26th, 2018, 11:36 pm

mattsc wrote:
May 26th, 2018, 6:45 pm
[The idea of adding a separate advanced filter is interesting though, but if we do that, it would be for 1.15 and on only.]
Yeah I mean it for future... I understand that 1.14 is the way it is.. I just think we should try to improve what we can improve if it may help someone.. but it's just an idea.
mattsc wrote:
May 26th, 2018, 6:45 pm
I will still have a look around if there is something that can be done that would speed up the evaluation for all use cases. It's quite possible. But it also seems pretty clear that we are moving toward a custom AI for your add-on. Which, as I said, is easy to do and should result in quite a speed-up.
I'm probably interested in this.. since micro_ai was very very very nice and really working the way I wanted, but only until there became more of them... I'm interested to improve speeds in future.. Any hints on how to create custom ai? long time ago I was given a link for micro_ai and it was really helpful, somehow I didn't realize/know such WML existed until the link..
mattsc wrote:
May 26th, 2018, 6:45 pm
On all your other points, I'll comment later when I have more time. There's still no real need for you to do anything right now, I know what needs to be done next.
sure there is absolutely no rush.. I don't currently have time for anything deep either..
mattsc wrote:
May 26th, 2018, 6:45 pm
Although ... you could tell me whether it would be good enough if this AI simply found all units once at the beginning of the turn and then reused that list for all moves. Or do things change during the AI turn that might change the list of filtered units (other than them using up their MP, of course)? Because not having to evaluate the filter at all, except for once at the beginning of the turn, would save by far the most time. :P
Unfortunately I dont think it would work very well.. I built micro ais in a sequence.. so for example first ranged units attack, then some units already dead, so other units would take empty village (where ranged units killed somebody), then melee units would attack...
so it would still work if everything would be evaluated in beginning just once, but it wouldn't be perfect from what I understand..
Thank you for helping!!!

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 27th, 2018, 1:37 am

I'll tell you how to do the custom AI thing, but I want to do those tests that I've been talking about first. (And I assume that is clear, but with custom AI I mean a slightly modified version of the Goto MAI, that is faster for your setup but would not necessarily work as a general MAI.)

As for my last question, I didn't mean pre-evaluating everything, that definitely does not work. Only the units that would partake in a given action. So that might still work with what you write. I'll have a look into that too. Whenever I finally get to it. :roll:

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 27th, 2018, 3:17 am

I've now had a first closer look at this. First: wow, you have a lot of stuff in that scenario! I think we'll have to take this in stages, there's just too much to deal with all at once. So here's my first round of comments:
  1. The MAI causing the delay is the one with score 210007. I've copied the relevant code below for reference.
  2. A typical case on my computer is that the delay time from the last moveto event is ~1000 ms. Of that, ~650 ms are used by that Goto MAI. That is, 350 ms happen somewhere outside the AI and you'll have to improve on them separately, if possible.
  3. Of those 650 ms, 400 are spent on evaluating the SLF, and 250 on the SUF. (Note that each of those are 3 evaluations in total, probably because 2 other candidate actions execute after the last moveto event; two that don't actually result in a move).
  4. I haven't looked at all at the SLF yet (not sure what can be done about that), but the SUF can be dramatically improved. The [filter_wml]moves=0 bit is not necessary (the MAI won't try to move units that have no moves), and anything involving [filter_wml] is really slow. When I take that out, the SUF evaluation time goes from 250 to ~1 ms (yes, one; no typo). So by only removing that, you reduce the CA evaluation time by almost 40% (and 25% of the total delay)! Since you said that even 10% would be something, that should help you at least a bit.
  5. The way you add a custom candidate action is actually exactly the way how you are doing it in the code below. The only things to change is that you copy the mainline file 'ai/micro_ais/cas/ca_goto.lua' into your add-on (and you should probably add your add-on prefix to the file name just to avoid confusion) and change the location= line to the new file. That's all. Now you can modify the code in that file at will to suit your needs. (Depending on how general you want it to be, you can probably also reduce a lot of the [args], but we can get to that some other time.)
  6. The next step then would be to change the order of the SUF and SLF evaluation in the new custom AI file. If you do that and there are no settlers left to move at the end of the turn, you'll need 1 ms to evaluate the SUF and there's no need to evaluate the SLF any more. As a result, you have reduced the evaluation time from 650 to 1 ms. (The same does not apply at the beginning of the turn, of course, but the 40% reduction above still does apply for that.)
  7. There's a reason though why the SLF is evaluated first in the code, so why don't you get set up to the point where you're using the local MAI and then we talk again. What I've written so far is quite a bit already, let's make sure that all of this actually works first.
Hope this is useful and makes at least some sense!

Code: Select all

				[candidate_action]
					enabled=yes
					engine="lua"
					id="qc_settlers_1_move"
					location="ai/micro_ais/cas/ca_goto.lua"
					max_score=210007
					name="qc_settlers_1_move"
					score=0
					type=""
					[args]
						ai_id="mai_goto"
						avoid_enemies=5
						ca_score=210007
						unique_goals=yes
						[filter_location]
							[and]
								[and]
									radius=1
									x="1,1,48,48"
									y="1,34,1,34"
								[/and]
								[not]
									radius=3
									terrain="*^V*"
								[/not]
								[not]
									terrain="Rrc,Ai,W*,S*,Q*,X*,Ww^B*,Wo^B*,Ss^B*,Qxu^B*,Ql^B*,Mm^Xm,Md^Xm,Ms^Xm,M*,M*^*,*^V*,K*,C*"
								[/not]
								[not]
									x=0
								[/not]
								[not]
									y=0
								[/not]
								[not]
									x=""
								[/not]
								[not]
									y=""
								[/not]
							[/and]
							[or]
								[and]
									owner_side=1
									radius=4
								[/and]
								[not]
									radius=3
									terrain="*^V*"
								[/not]
								[not]
									terrain="Rrc,Ai,W*,S*,Q*,X*,Ww^B*,Wo^B*,Ss^B*,Qxu^B*,Ql^B*,Mm^Xm,Md^Xm,Ms^Xm,M*,M*^*,*^V*,K*,C*"
								[/not]
							[/or]
							[or]
								[and]
									radius=3
									[filter]
										ability="hac_build_new_city"
										side=1
									[/filter]
								[/and]
								[not]
									radius=""
									terrain="*^V*"
								[/not]
								[not]
									terrain=""
								[/not]
							[/or]
						[/filter_location]
						[filter]
							ability="hc_build_new_city"
							canrecruit=false
							[not]
								[filter_wml]
									moves=0
								[/filter_wml]
							[/not]
						[/filter]
					[/args]
				[/candidate_action]

enclave
Posts: 910
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave » May 27th, 2018, 1:33 pm

mattsc wrote:
May 27th, 2018, 3:17 am
350 ms happen somewhere outside the AI and you'll have to improve on them separately, if possible.
yeah that looks like true, because that's same what I get if I disable all micro_ai (no idea what exactly it is, but I'm not worried about that because I don't think I can do anything about it and investigating may take a while too, I was thinking it's something to do with default ai.. not even my scenario codes, not sure though at all.. and nobody ever complained about ai taking long when it was just 350ms, I would say up to 1000 is perfectly acceptable, but currently it would mean only half of the micro_ai enabled or even less)
mattsc wrote:
May 27th, 2018, 3:17 am
[*]Of those 650 ms, 400 are spent on evaluating the SLF, and 250 on the SUF.
what exactly is SLF and SUF (F - filter?)
mattsc wrote:
May 27th, 2018, 3:17 am
[filter_wml]moves=0 bit is not necessary (the MAI won't try to move units that have no moves), and anything involving [filter_wml] is really slow. When I take that out, the SUF evaluation time goes from 250 to ~1 ms (yes, one; no typo). So by only removing that, you reduce the CA evaluation time by almost 40% (and 25% of the total delay)! Since you said that even 10% would be something, that should help you at least a bit.
That definitly helps a lot! The only thing I will have to test it, since I added moves=0 in hopes to improve speed, but didn't see any gain and just forgot to remove it.. I would be suprised if it goes down to 1ms, but I have no reasons not to believe ;) It's just when I put it I was already not happy with speed as it was without moves=0. But it's still great (I just somehow didnt notice any difference between moves=0 and it's absence at all when was testing.. looks like I mistaken somehow), I might never spotted it, thanks for noticing!
By the way I think I once tried to compare filters speed and filter_wml wasnt as slow as if you add [not] and [and] tags... I might do the tests again in future... maybe compare it with lua filters too... I know wiki says filter_wml is very slow, but I noticed the opposite.. Need to find my tests to see what it was.. viewtopic.php?f=10&t=46370&start=45#p625766 (I'm not sure why results were so strange.. need to get into testing filters more..)

mattsc wrote:
May 27th, 2018, 3:17 am
[*]The way you add a custom candidate action is actually exactly the way how you are doing it in the code below. The only things to change is that you copy the mainline file 'ai/micro_ais/cas/ca_goto.lua' into your add-on (and you should probably add your add-on prefix to the file name just to avoid confusion) and change the location= line to the new file. That's all. Now you can modify the code in that file at will to suit your needs. (Depending on how general you want it to be, you can probably also reduce a lot of the [args], but we can get to that some other time.)
[*]The next step then would be to change the order of the SUF and SLF evaluation in the new custom AI file. If you do that and there are no settlers left to move at the end of the turn, you'll need 1 ms to evaluate the SUF and there's no need to evaluate the SLF any more. As a result, you have reduced the evaluation time from 650 to 1 ms. (The same does not apply at the beginning of the turn, of course, but the 40% reduction above still does apply for that.)
[*]There's a reason though why the SLF is evaluated first in the code, so why don't you get set up to the point where you're using the local MAI and then we talk again. What I've written so far is quite a bit already, let's make sure that all of this actually works first.
[/list]

Hope this is useful and makes at least some sense!

Code: Select all

				[candidate_action]
					enabled=yes
					engine="lua"
					id="qc_settlers_1_move"
					location="ai/micro_ais/cas/ca_goto.lua"
					max_score=210007
					name="qc_settlers_1_move"
					score=0
					type=""
					[args]
						ai_id="mai_goto"
						avoid_enemies=5
						ca_score=210007
						unique_goals=yes
						[filter_location]
							[and]
								[and]
									radius=1
									x="1,1,48,48"
									y="1,34,1,34"
								[/and]
								[not]
									radius=3
									terrain="*^V*"
								[/not]
								[not]
									terrain="Rrc,Ai,W*,S*,Q*,X*,Ww^B*,Wo^B*,Ss^B*,Qxu^B*,Ql^B*,Mm^Xm,Md^Xm,Ms^Xm,M*,M*^*,*^V*,K*,C*"
								[/not]
								[not]
									x=0
								[/not]
								[not]
									y=0
								[/not]
								[not]
									x=""
								[/not]
								[not]
									y=""
								[/not]
							[/and]
							[or]
								[and]
									owner_side=1
									radius=4
								[/and]
								[not]
									radius=3
									terrain="*^V*"
								[/not]
								[not]
									terrain="Rrc,Ai,W*,S*,Q*,X*,Ww^B*,Wo^B*,Ss^B*,Qxu^B*,Ql^B*,Mm^Xm,Md^Xm,Ms^Xm,M*,M*^*,*^V*,K*,C*"
								[/not]
							[/or]
							[or]
								[and]
									radius=3
									[filter]
										ability="hac_build_new_city"
										side=1
									[/filter]
								[/and]
								[not]
									radius=""
									terrain="*^V*"
								[/not]
								[not]
									terrain=""
								[/not]
							[/or]
						[/filter_location]
						[filter]
							ability="hc_build_new_city"
							canrecruit=false
							[not]
								[filter_wml]
									moves=0
								[/filter_wml]
							[/not]
						[/filter]
					[/args]
				[/candidate_action]
Thanks a lot! I will try that thing at some point. Any chance you know if this will require others to download my add-on to join? location="ai/micro_ais/cas/ca_goto.lua" this line in particular..
(Would it require it on 1.12? I'm still trying to create add-ons without custom unit types and other things that will make need to download add-on for at least 2 reasons:
1) The versions may become incompatible and will need updating to avoid OOS. 2) Many people would still avoid downloading even though now it's much easier and can be done right in the lobby, but the more add-ons you have the more problems there may be with compatibility and may cause different lags/bugs.. so I am the person who prefers not download eras from lobby to observe or join game.. so there would be more of people like me)

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 27th, 2018, 1:51 pm

enclave wrote:
May 27th, 2018, 1:33 pm
what exactly is SLF and SUF (F - filter?)
SLF = StandardLocationFilter (what's in [filter_location] and SUF = StandardUnitFilter is the content of [filter]. So what that means is that the entire 650 ms delay at the end is for evaluating the filters by the engine, it has nothing to do with the AI code itself, which needs less than 1 ms in addition to that (at the end of the turn).

The reason why you did not notice the effect of [filter-wml] is most likely that it's hard to notice a quarter second delay, especially when it is added to something. And just to reemphasize, the 40% improvement is only at the end, when the AI does not have anything left to do, and it is only 25% of the total delay, so I'd say there is pretty much no chance you will notice this by just watching the game. But those are actual numbers from timing events I inserted into the MAI, not rough estimates (they are approximate in the sense that they vary with the situation on the map, but the values I wrote down in my previous post are representative for what I see on average).

As far as I know, the AI is only run on the host, so there's no need for the clients to also have the add-on when there is a local AI running. Should be easy to test though.

enclave
Posts: 910
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave » May 27th, 2018, 2:27 pm

mattsc wrote:
May 27th, 2018, 1:51 pm
The MAI causing the delay is the one with score 210007. I've copied the relevant code below for reference.
I just noticed that I have 2 MAI with 210007 (one is for filtering ranged units, another one for filtering settlers), would this matter for speed at all, what do you think?
Settlers filter:

Code: Select all

	[filter]
		canrecruit=false
		ability=hc_build_new_city
	[/filter]
Ranged filter:

Code: Select all

            [filter]
				type=Dune Windrider,Lieutenant,Longbowman,Bowman,Poacher,Footpad
					[filter_location]
					[filter]
					[filter_side]
					[enemy_of]
					side=$side_number
					[/enemy_of]
					[/filter_side]
					[/filter]
					radius=4
					[/filter_location]
            [/filter]
The settlers would never be the same type as ranged unit.. or have same ability.. but I wonder if I should make settlers filter by type too?

I actually also noticed that latest version doesnt have filter_wml for moves=0, so I remembered to remove it :) just it was still there for replays I provided..
Last edited by enclave on May 27th, 2018, 5:01 pm, edited 1 time in total.

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 27th, 2018, 2:37 pm

enclave wrote:
May 27th, 2018, 2:27 pm
I just noticed that I have 2 MAI with 210007 (one is for filtering ranged units, another one for filtering settlers), would this matter for speed at all, what do you think?
No, makes no difference for speed at all. It only means that it is undetermined which of them gets executed first, so if you want one to happen before the other, you need to give them different scores.
enclave wrote:
May 27th, 2018, 2:27 pm
The settlers would never be the same type as ranged unit.. or have same ability.. but I wonder if I should make settlers filter by type too?
Filtering by ability seems to be plenty fast based on my tests, so that's a question of (your) personal preference really.

User avatar
Celtic_Minstrel
Developer
Posts: 1277
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [micro_ai] slow

Post by Celtic_Minstrel » May 27th, 2018, 6:19 pm

mattsc wrote:
May 26th, 2018, 6:45 pm
The unit filter uses the ai_helper function get_units_with_moves which applies the filter first, and then sorts out units that have no moves left. And there's a good reason for that. Filtering for MP is slow (because 'moves' is not a key that can be used directly in SUFs), so it gets separated out. And the alternative (selecting all units first, then filtering for moves, then applying the filter) is actually slower than what it is right now for simple filters (esp. early in the turn when most units still have their MP). And since simple filters are almost certainly being used more often than something complex like in your case, this should not be changed in mainline. [The idea of adding a separate advanced filter is interesting though, but if we do that, it would be for 1.15 and on only.]
I'm not sure I like the idea of adding a separate advanced filter. Why not just add the requirement of moves>0 to the filter? Either add moves as an allowed SUF key, or use formula="moves > 0" (which should even work in 1.14). Since we're talking 1.15 anyway, both of these would seem to be better options than complicating the AI interface with yet another filter.
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

mattsc
Posts: 1068
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: [micro_ai] slow

Post by mattsc » May 27th, 2018, 8:10 pm

Celtic_Minstrel wrote:
May 27th, 2018, 6:19 pm
I'm not sure I like the idea of adding a separate advanced filter. Why not just add the requirement of moves>0 to the filter? Either add moves as an allowed SUF key, or use formula="moves > 0" (which should even work in 1.14). Since we're talking 1.15 anyway, both of these would seem to be better options than complicating the AI interface with yet another filter.
Let me start by saying that I am not sure yet whether I think this should be added to the mainline MAI. It might be sufficiently "advanced" usage that people should copy the Lua code into their add-on and modify it as needed instead.

Having said that, this is entirely about speeding up the evaluation, it has nothing to do with excluding units with zero moves left. Eliminating units without MP is always done (click on the link in the block of text you quoted) as this is the Goto MAI. There's no point in keeping units without MP around. If you want to do this efficiently/quickly there are two ways (that I am aware of) of doing so:
  1. Get all units that match the filter, then eliminate those with zero moves left.
  2. Get all units, eliminate those that have zero moves left, then only keep those that match the filter.
Method 1 is usually faster for simple filters, while method two is sometimes faster for complex filters, esp. after some units have moved already. So in either case, there are settings when using the other method would be quicker. By adopting two filters, one could use a third type of method: Get all units that match the simple filter, eliminate those that have no moves left, then find those that match the advanced (slower to evaluate) filter. That would mean it is possible for the user to optimize evaluation speed in either case, by using either one or both filters, without having to dig into the Lua code itself.

Whether that should be in mainline is a separate question.

enclave
Posts: 910
Joined: December 15th, 2007, 8:52 am

Re: [micro_ai] slow

Post by enclave » May 27th, 2018, 10:00 pm

Celtic_Minstrel wrote:
May 27th, 2018, 6:19 pm
or use formula="moves > 0"
Oh something new for me... Could you confirm the usage?
Would it be right to say that this code:

Code: Select all

[filter]
 [filter_wml]
  [variables]
    range=2
  [/variables]
   [or]
   [variables]
    range=3
   [/variables]
   [/or]
  [/filter_wml]
[/filter]
Would be exactly the same as this code:

Code: Select all

[filter]
 [filter_wml]
  [variables]
   formula="range>1"
  [/variables]
 [/filter_wml]
[/filter]
?
If yes then would it be the same speed-efficient?
mattsc wrote:
May 27th, 2018, 8:10 pm
By adopting two filters, one could use a third type of method: Get all units that match the simple filter, eliminate those that have no moves left, then find those that match the advanced (slower to evaluate) filter. That would mean it is possible for the user to optimize evaluation speed in either case, by using either one or both filters, without having to dig into the Lua code itself.
That's exactly what I meant.. the [advanced_filter] would be optional... and would only help in certain cases to optimize the speed of MAI without need of advanced lua knowledge. Or something like that...

User avatar
Ravana
Moderator
Posts: 1887
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: [micro_ai] slow

Post by Ravana » May 27th, 2018, 10:06 pm

2 or 3 is not same as >1. You might need $this_unit.variables.range instead of range, not sure what fields are implicitly available.

Also, formula is part of SUF, do not attempt to use it in [filter_wml].

User avatar
Celtic_Minstrel
Developer
Posts: 1277
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: [micro_ai] slow

Post by Celtic_Minstrel » May 27th, 2018, 10:50 pm

mattsc wrote:
May 27th, 2018, 8:10 pm
Having said that, this is entirely about speeding up the evaluation, it has nothing to do with excluding units with zero moves left. Eliminating units without MP is always done (click on the link in the block of text you quoted) as this is the Goto MAI. There's no point in keeping units without MP around. If you want to do this efficiently/quickly there are two ways (that I am aware of) of doing so:
  1. Get all units that match the filter, then eliminate those with zero moves left.
  2. Get all units, eliminate those that have zero moves left, then only keep those that match the filter.
Method 1 is usually faster for simple filters, while method two is sometimes faster for complex filters, esp. after some units have moved already.
Yeah, I get what you're saying, but my point is, why not just combine the two steps? Wouldn't that be always faster? You can easily build a filter that combines formula="moves > 0" with whatever filter the user passed in (you already do this frequently to prevent matching units of a different side).
enclave wrote:
May 27th, 2018, 10:00 pm
Celtic_Minstrel wrote:
May 27th, 2018, 6:19 pm
or use formula="moves > 0"
Oh something new for me... Could you confirm the usage?
Would it be right to say that this code:

Code: Select all

[filter]
 [filter_wml]
  [variables]
    range=2
  [/variables]
   [or]
   [variables]
    range=3
   [/variables]
   [/or]
  [/filter_wml]
[/filter]
Would be exactly the same as this code:
{code redacted}
?
If yes then would it be the same speed-efficient?
No. Like Ravana said, formula cannot be used in filter_wml. Also, "greater than 1" is not the same as "equal to 2 or 3".

Your first example could still be implemented with formula, but it would look more like this:

Code: Select all

[filter]
  formula="wml_vars.range = 2 or wml_vars.range = 3"
[/filter]
(I think wml_vars is undocumented, but it's basically the WFL way to access [variables] if I recall correctly.)
Author of The Black Cross of Aleron campaign and Default++ era.
Maintainer of Steelhive.

Post Reply