Over complicated [have_unit] wml

[The_Gnat]

Hello, i have written a quite complicated [have_unit] wml in order to find 'unique' tiles on a map. The conditions for unique tiles are as follows:

A tile that is:
- not village, impassable, or embellishments
- not adjacent to a single tall tree, a terrain tile which starts with the same letter as it, or a terrain tile that has already been marked as unique
Or is:
- a single tall tree
- not next to another single tall tree
- not next to 3 or more forest tiles
- not next to a already unique hex
Or is:
- a lillypad
- not next to another lilly pad
- not next to another already unique hex

Spoiler:

Code: Select all

	   [have_location]
		x,y=$stored_terrain[$j].x,$stored_terrain[$j].y
		[and]
		   [not]
		      terrain=*^V*
			[or]
			  terrain=*^Xm*
			[/or]
			[or]
			  terrain=*^Xo*
			[/or]
			[or]
			  terrain=*^E*
			[/or]
		   [/not]
		   [filter_adjacent_location]
			# repersents a already stored variable of the first letter of a terrain string
			terrain=$nowTerrain|*
			count=0
		   [/filter_adjacent_location]
		[not]
		   [filter_adjacent_location]
			    # variable has been already defined
			    x=$place_items.x
			    y=$place_items.y
		   [/filter_adjacent_location]
		[/not]
		[not]
		   [filter_adjacent_location]
			    terrain=*^Fet*
		   [/filter_adjacent_location]
		[/not]
		[/and]	
		[or]
		   x,y=$stored_terrain[$j].x,$stored_terrain[$j].y
		   terrain=*^Fet*
		   [and]
		   	[filter_adjacent_location]
				terrain=*^Fet*
				count=0
			[/filter_adjacent_location]
		   	[filter_adjacent_location]
				terrain=*^F*
				count=0,1,2
			[/filter_adjacent_location]
			[not]
			   [filter_adjacent_location]
				    # variable has been already defined
				    x=$place_items.x
				    y=$place_items.y
			   [/filter_adjacent_location]
			[/not]
		   [/and]
		[/or]
		[or]
		   x,y=$stored_terrain[$j].x,$stored_terrain[$j].y
		   terrain=*^Ew*
		   [and]
		   [filter_adjacent_location]
			terrain=*^Ew*
			count=0
		   [/filter_adjacent_location]
			[not]
			   [filter_adjacent_location]
				    # variable has been already defined
				    x=$place_items.x 
				    y=$place_items.y
			   [/filter_adjacent_location]
			[/not]
		   [/and]
		[/or]
	   [/have_location]

The reason am posting this is because: this is the longest have_unit code i have ever seen and it is run for every hex on the entire map (using a FOREACH statement) so my question is if this will cause problems in the game and if there are anyway to shorten this?

Thank you very much!

[gfgtdf]

It's not easy to say whether such a filter is fast enough just by looking at it, if you want to know its best to test it with s aussficiently large (for example 50x50) and nontrivial map.

Some general advices of optimising location filters are:
1) Put conditions that are easy to check first, so that the more compliates doen't even need to be looket at in case where there simpler one fail
2) Put conditions that are likeley to fail first, so that in a lot of cases the chack already ends after the firt part.


I wonder what do you intend to do with those result locations then?

PS: I wonder why i see no "expand" button besides the 'Select All' button of you code?

[The_Gnat]

It's not easy to say whether such a filter is fast enough just by looking at it, if you want to know its best to test it with s aussficiently large (for example 50x50) and nontrivial map.

Some general advices of optimising location filters are:
1) Put conditions that are easy to check first, so that the more compliates doen't even need to be looket at in case where there simpler one fail
2) Put conditions that are likeley to fail first, so that in a lot of cases the chack already ends after the firt part.

Thank you for your response, i will do that and test it on a larger map.

I wonder what do you intend to do with those result locations then?

I am creating an automatic generator that places items ([objects]) on certain tiles, if you would like i will send you the link when i am complete.

PS: I wonder why i see no "expand" button besides the 'Select All' button of you code?

It seems when you put

Code: Select all

 inside a [spoiler] or [section="Code"] tag it removes that option.

[The_Gnat]

Unfortunately it is too slow to be usable. I think i will (instead of storing every space on the map) only store the spaces that are most likely to fit my criteria.

[Tad_Carlucci]

Sounds like a job for Lua.

I did something similar scanning the entire map. It took almost a minute on a medium map and was almost instantaneous when rewritten using Lua,

[The_Gnat]

Sounds like a job for Lua.

I did something similar scanning the entire map. It took almost a minute on a medium map and was almost instantaneous when rewritten using Lua,

That would be great, could i have an example of the code you wrote since i don't have experience writing Lua? Thank you!

[zookeeper]

Unfortunately it is too slow to be usable. I think i will (instead of storing every space on the map) only store the spaces that are most likely to fit my criteria.

Well, yes, that absolutely makes more sense. Looping over every hex to check which ones match a filter is going to be a lot slower than storing the hexes which match a filter and then looping over those.

[Tad_Carlucci]

Sounds like a job for Lua.

I did something similar scanning the entire map. It took almost a minute on a medium map and was almost instantaneous when rewritten using Lua,

That would be great, could i have an example of the code you wrote since i don't have experience writing Lua? Thank you!

HttT Dwarven Doors loops over the entire map checking and changing terrain

[The_Gnat]

HttT Dwarven Doors loops over the entire map checking and changing terrain

I apologize but i have read through scenario 13 of Heir to the throne (Dwarven Doors) and i do not see any events or code that loops through the map and changes terrain.

I am sorry, i obviously am missing it , do you know what line it can be found on?

And again Thank you!

[The_Gnat]

Well, yes, that absolutely makes more sense. Looping over every hex to check which ones match a filter is going to be a lot slower than storing the hexes which match a filter and then looping over those.

My main problem is that my key filter criteria are 1. terrain tiles not next to other tiles already selected and 2. terrain tiles not next to terrain of a similar type, and i don't believe either of those criteria can be put into a [store_locations] tag.

[gfgtdf]

I am creating an automatic generator that places items ([objects]) on certain tiles, if you would like i will send you the link when i am complete.

I fouy onl want to place very few items whilte there are a lot possible locations it might also make sense to first select any random location, then check whetehr it match the filter and of no just to choose another rnaodm location until you placed enough items. Of yourse you can also doa mix of both ways: foirst do a simple filter filter for a initial list, then choost randomply locations from that initial list and check for each chosen location whether it matches the detailed filter.

[The_Gnat]

I fouy onl want to place very few items whilte there are a lot possible locations it might also make sense to first select any random location, then check whetehr it match the filter and of no just to choose another rnaodm location until you placed enough items. Of yourse you can also doa mix of both ways: foirst do a simple filter filter for a initial list, then choost randomply locations from that initial list and check for each chosen location whether it matches the detailed filter.

Currently i am doing similar to that (pseudo code):

Code: Select all

for (each terrain tile stored) {
     run randomizer

     if (random = 1) {
           if (current location fits criteria) {
                 #place item
           }
     }
    else {

          run second randomizer

          if (random2 = 1) {
               if (current location fits second criteria) {
                      #place other type of item
                }
           }

    }
}

Now you are probably going to say "put both items under one randomizer". However the reason i am not is because my randomizers are determined by (1..$number_supplied_by_sliderbar). Because of this i have to use a separate randomizer for each item place event.

Currently the slider bar takes the input number (for example 34) and then gets 100/34 rounded to the nearest number and uses that as the variable.

(a question: is it good to create a rand=1..100000 if the user sets the slider bar to 0, or should i just put a [if] statement instead)

Since [acronym="anyone's opinions are welcome"]you[/acronym] are probably more experience at writing code: what do you think of this method?

Thank you!

EDIT: another question: how do you not store tiles covered in fog like on the edges of many scenarios (for example 8p morituri)?

[Tad_Carlucci]

https://github.com/wesnoth/wesnoth/blob ... s.cfg#L163

What's not obvious from the initial selection on terrain type is that it is virtually the entire map .. anyplace which is not snow/ice-covered for which there is a show/ice version of the tile.

[The_Gnat]

Thank you! That is very helpful!

[Sapient]

It would be pretty simple and efficient to do this with store_locations, except for this one part:

- not adjacent to a terrain tile which starts with the same letter as it

To do that with FilterWML you would need to have automatically stored this_location and other_location (similar to this_unit and other_unit), and that would allow you to use a formula to check if substring($this_location.terrain, 0, 1) equals substring($other_location.terrain, 0, 1).

Maybe a good future WML enhancement... should be easy, too.

Until then, you would have to add a condition for every possible letter. If that's too ugly, best to use Lua for now I guess.