FANDOM


It is late, like 2AM and I am about to call it a "night". I just spent the last few hours, er...half a day, working on a better way to do heavy array testing with sidekicks. Instead of just adding RegEx support like I had planned, I opted for a longer, yet more user friendly method. I allowed sidekick tests to have kids properties!

Now instead of building your sidekick to do linear ordered tests, you can nest tests to speed up the process and also to make your tests more effective. Here's an example of all the tests required to determine just random building parts for FV using the array test method with linear order tests:

//building materials by building
//these searches are terribly long for what you get from them thanks to the people who make FV
{body:"addition of a station to the Craftshop",ret:"FVmat_craftshop"},
{body:"Japanese Barn for their farm with and is over half-way",ret:"FVmat_japanesebarn"},
{body:"addition of a station to the Craftshop",ret:"FVmat_craftshop"},
{body:"finished adding a station to the Craftshop",ret:"FVmat_craftshop"},
{body:"progress adding stations to the Craftshop",ret:"FVmat_craftshop"},
{body:"{%1} to decorate their farm and is over half-way", subTests:buildings, ret:"FVmat_{%1}"},
{body:"{%1} and is over half-way", subTests:buildings, ret:"FVmat_{%1}"},
{body:"{%1} and is over halfway", subTests:buildings, ret:"FVmat_{%1}"},
{body:"{%1} and is half-way", subTests:buildings, ret:"FVmat_{%1}"},
{body:"{%1} and is halfway", subTests:buildings, ret:"FVmat_{%1}"},
{body:"{%1} is halfway", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished with upgrading their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished upgrading their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished constructing a {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished expanding the {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished building their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished building an {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished building a {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"upgrade of their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"completion of a {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"completion of the {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"progress on upgrading their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"progress on a {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"progress on the {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"progress on their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"finished their {%1}", subTests:buildings, ret:"FVmat_{%1}"},
{body:"built a {%1}", subTests:buildings, ret:"FVmat_{%1}"},

And now here is the same test pattern using nested tests:

{body:"{%1}", ret:"none",
	subTests:["addition of a station","half-way","halfway","finished","completion of","upgrade of","progress on","built a","adding stations","adding a station"],
	kids:[{body:"{%1}",ret:"FVmat_{%1}",subTests:buildings}]
},

As you can see, it first checks for the texts you would expect to find on building stages that offer materials. If those don't exist, it doesn't do anything else, saving time and speed. However, if it does find those words, it then simply looks for the building name. It is no longer having to read the same array over and over again. The array is only called ONCE!

You may also notice that built into the first test is a return of "none". This is the default return value if the "kids" don't return a value. "none" allows the testing process to continue even if the initial tests's texts were found. However if you knew for a fact that these texts ONLY existed for building materials, you could return something like "FVmat_unknown" and make a menu entry for generally unknown materials. I didn't.

Currently (WM version 1.5.14) there is no limit to the depth of "kids" you can have in a test!

Tests do have some other advantages, like being able to avoid an array entirely if a certain word is not available. Here is an example of the wrong way to do a nested test, although it seems sound:

//bushels
{body:"bushel", ret:"FVbushel", kids:[
	{body:"super {%1}", subTests:bushelTypes, ret:"FVbushel_super{%1}"},
	{body:"{%1}", subTests:bushelTypes, ret:"FVbushel_{%1}"},
]},

And here is the better way to do it:

//bushels
{body:"bushel", ret:"FVbushel", kids:[
	{body:"super", ret:"FVbushel",kids:[
		{body:"{%1}", subTests:bushelTypes, ret:"FVbushel_super{%1}"},
	]},
	{body:"{%1}", subTests:bushelTypes, ret:"FVbushel_{%1}"},
]},

As you can see, there is one less arrayed search being done in the better way. It first checks for the word bushel, then checks again for the word super. If super is found, finally it determines bushel type. In the first example, it checks for bushel, then immediately checks for every combination of super and bushel names. But what if its not a supercrop bushel? The test got run anyway and the bushel array is quite long. That's wasted time. Here's one more way to do it, and its the worst thing you can do:

//bushels
{body:"super {%1} bushel", subTests:bushelTypes, ret:"FVbushel_super{%1}"},
{body:"{%1} bushel", subTests:bushelTypes, ret:"FVbushel_{%1}"},

In this horrid example (which was how the last version worked) the test is run for every supercrop and every normal bushel even if the post does not contain the word bushel. Needless to say, it was inefficient and slow.

I will be editing the Sidekick Tutorial probably on Monday to include these changes, as well as some others that will be available by then.

This version is not yet released as I am still bug checking the main WM section so it doesn't screw up the majority of users. Look for 1.5.14 later tomorrow afternoon as well as an update to the FV sidekick.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.