Price Manager issues

[anthonybe]

Hi Goblin Hero,

I started writing a LUA script in order to retrieve price from a Belgian website.
During development, I noticed some issues related to Price Manager and LUA api:

• ma.SetProgress(text, position): Where is the text displayed in the progress bar ? I see nothing on the progress bar in the Price Manager window.
• Update button uses SELECTED price source instead of CHECKED source(s): with the new script added to the Prices folder, the Price Manager offers me two sources: "MTG Mint Card" and "My source". I checks the check box next "My source" and uncheck the one next "MTG Mint Card". The "MTG Mint Card" source is selected (on row table level). When I click on Update button and check the log file of MA, I see that the source executed is "MTG Mint Card" instead of "My Source".
• CSV file of new script must be created: When I added the new LUA file in the Prices folder, at MA starting, I noticed an error saying that "My Source.csv" could not be opened or does not exist (I can't remember the exact message). This "requirement" is not described on the MA LUA API page. I just copied the csv of MTG Mint Card and replaced all prices with 0 value.

Anthony.

[LordHelmchen]

Hi Goblin Hero,

I started writing a LUA script in order to retrieve price from a Belgian website.
During development, I noticed some issues related to Price Manager and LUA api:

• ma.SetProgress(text, position): Where is the text displayed in the progress bar ? I see nothing on the progress bar in the Price Manager window.

I have the same problem. It seem that the progressbar lables do not display in Windows 7, but work in Windows XP...

Update button uses SELECTED price source instead of CHECKED source(s): with the new script added to the Prices folder, the Price Manager offers me two sources: "MTG Mint Card" and "My source". I checks the check box next "My source" and uncheck the one next "MTG Mint Card". The "MTG Mint Card" source is selected (on row table level). When I click on Update button and check the log file of MA, I see that the source executed is "MTG Mint Card" instead of "My Source".

I had the same problem. It is none: The checkboxes tell MA which scripts to use for min/max/average, selection tells it which scripts to run.

CSV file of new script must be created: When I added the new LUA file in the Prices folder, at MA starting, I noticed an error saying that "My Source.csv" could not be opened or does not exist (I can't remember the exact message). This "requirement" is not described on the MA LUA API page. I just copied the csv of MTG Mint Card and replaced all prices with 0 value.

Though the MA log logs the missing csvs, this doesn't stop it from working. When the script is run for the first time, the csv is created if it does not exist already.

You may want to look at my library and test if using the sitescript template works a a shortcurt for your scripting needs. I'd be interested to hear if/how it works for someone other than me, but feel free to ignore it if you prefer to work from scratch

[anthonybe]

Concerning the progress bar, is Goblin Hero aware of the problem ? Does he looking for a solution ?

Concerning the Selection and checkbox, Ok. It was not clear the distinction between. Now I know

Concerning your script template and the LHPi lib, it's amazing. I will have a look and try to create one for the Belgian website.
Is there another wiki page with a How-To configure the script template ? I will look at your script for MagicUniverse as an example.

Anthony.

[LordHelmchen]

Concerning the progress bar, is Goblin Hero aware of the problem ? Does he looking for a solution ?

As he has replied and posted a screenshot of how it should look, I'd wager he is aware of it. If it seems important to you, you could file a bug in the tracker to remind him

Concerning your script template and the LHPi lib, it's amazing. I will have a look and try to create one for the Belgian website.
Is there another wiki page with a How-To configure the script template ? I will look at your script for MagicUniverse as an example.

I tried to comment the template to make it self-explaining, but I'm open for any suggestions on how and what to document, either as additional comments in the code or in a seperate wiki page. You're practically my guinea pig for seeing if the template and library are useful to others, so I'm hoping for lots of feedback and improvement suggestions

[anthonybe]

I tried to comment the template to make it self-explaining, but I'm open for any suggestions on how and what to document, either as additional comments in the code or in a seperate wiki page. You're practically my guinea pig for seeing if the template and library are useful to others, so I'm hoping for lots of feedback and improvement suggestions

As a first remark, the missing part I found is the method chain. It would be great to have a sort of overview diagram showing the flow of your script: processUserParam, BuildUrl, ParseHtmlData, BuildCardData (with Pre & Post methods), ...

Also, how you can interact with LHpi library from the sitescript. Example with dropped card.

I don't know for now the complete process of the library but I found a case with the Belgian site where I must see how the library works.
Because the page containing card price of an edition contains both foil and regular price of a card, each one with the same regex.It would be great to have the possibility to get different regex depending foil or regular fruc.

In the HTMLParseData, I need to indicate to LHpi that the card must be ignored if foil and importFoil is not set. Same case for regular card.
I'm thinking of using something like 'drop' or something similar but as I don't know exactly the library process flow, I must check inside code.

[LordHelmchen]

As a first remark, the missing part I found is the method chain. It would be great to have a sort of overview diagram showing the flow of your script: processUserParam, BuildUrl, ParseHtmlData, BuildCardData (with Pre & Post methods), ...

I'll try to give all information you need/want. We might be able to evolve this into a real documentation later

Code: Select all

MA calls sitescript.ImportPrice
sitescript.Importprice loads the library, then calls LHpi.DoImport
LHpi.DoImport calls LHpi.ProcessUserParams and initializes
LHpi.DoImport calls LHpi.ListSources
 LHpi.ListSources loops through sets,langs,frucs and calls site.BuildUrl
LHpi.DoImport calls LHpi.MainImportCycle
LHpi.MainImportCycle loops through sets,urls and calls LHpi.GetSourceData
 LHpi.GetSourceData loops through matches with site.regex and calls site.ParseHtmlData, then returns sourceTable
LHpi.MainImportCycle loops through sourceTable and calls LHpi.BuildCardData
 LHpi.BuildCardData calls site.BCDpluginPre and site.BCDpluginPost and returns newcard
 LHpi.MainImportCycle calls LHpi.FillCardsetTable with newcard
  LHpi.FillCardsetTable might call LHpi.MergeCardrows and adds a row to cardsetTable
(optionally, LHpi.MainImportCycle calls LHpi.SaveCSV once cardsetTable is complete)
LHpi.MainImportCycle loops through cardsetTable and calls LHpi.SetPrice

Also, how you can interact with LHpi library from the sitescript. Example with dropped card.

dropping cards:

• if LHpi.BuildCardData sets card.drop=true, LHpi.FillCardsetTable is skipped.
• site.ParseHtmlData can set card.drop, which will be preserved by LHpi.BuildCardData.
• if not card.name then card.drop = true
• if string.find( card.name , "%(DROP[ %a]*%)" ) then card.drop = true
  An example is in LHpi.magicuniverseDE.lua's site.BCDpluginPre. The advantage of changing the name above setting card.drop directly is that you can also add a reason for dropping to the name, which will be loggged if LOGDROPS=true.

I don't know for now the complete process of the library but I found a case with the Belgian site where I must see how the library works.
Because the page containing card price of an edition contains both foil and regular price of a card, each one with the same regex.It would be great to have the possibility to get different regex depending foil or regular fruc.

Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop. For now, let's try to make the sitescript do some work instead of the library
site.regex matches shall include all info about a single card that one
html-file has, it will be chopped into its parts by site.ParseHtmlData. If you can grab something like "*CARDNAME*PRICE*FOILSTATUS" and we're good to go, as far as this step is concerned. Then you can have site.ParseHtmlData return card.foil=true|false, which will be honoured by LHpi.BuildCardData.
If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).

In the HTMLParseData, I need to indicate to LHpi that the card must be ignored if foil and importFoil is not set. Same case for regular card.
I'm thinking of using something like 'drop' or something similar but as I don't know exactly the library process flow, I must check inside code.

Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.

Its fascinating how much my choice of sites influenced what I considered generalization. Foil/Nonfoil on the same page is definitely something that a generally useful library needs to be able to cope with. Currently, I'm repairing breakage induced by adding more special sets to the existing sitescripts. When they work again, I will release 2.6 and concentrate on including your needs

[Goblin Hero]

If it seems important to you, you could file a bug in the tracker to remind him

I'll fix it in the next update.

[anthonybe]

I'll try to give all information you need/want. We might be able to evolve this into a real documentation later

Thanks. A section on the wiki page would be great

dropping cards:

• if LHpi.BuildCardData sets card.drop=true, LHpi.FillCardsetTable is skipped.
• site.ParseHtmlData can set card.drop, which will be preserved by LHpi.BuildCardData.
• if not card.name then card.drop = true
• if string.find( card.name , "%(DROP[ %a]*%)" ) then card.drop = true
  An example is in LHpi.magicuniverseDE.lua's site.BCDpluginPre. The advantage of changing the name above setting card.drop directly is that you can also add a reason for dropping to the name, which will be loggged if LOGDROPS=true.

This kind of information would also be welcome on the wiki page.
The impact of setting a specific property in a specific method would be great.

Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
[...]
Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.

In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.
You're right, BuildCardData should be aware of the MA importfoil. The sitescript just needs to return all info it has, and the library does "the rest"

site.regex matches shall include all info about a single card that one
html-file has, it will be chopped into its parts by site.ParseHtmlData. If you can grab something like "*CARDNAME*PRICE*FOILSTATUS" and we're good to go, as far as this step is concerned. Then you can have site.ParseHtmlData return card.foil=true|false, which will be honoured by LHpi.BuildCardData.

In my case, we are in the scenario "*CARDNAME*PRICE*FOILSTATUS". So, I'm able to set card.foil in parseHtmlDate function.
This works good except with non foil card. The card.foil is set to false, but BuildCardData consider the card as foil due to the fruc ("Foil_And_Regular") in the URL.

In BuildCardData, you have a conditional block:

Code: Select all

if sourcerow.foil then -- keep site.ParseHtmlData preset foil
      card.foil = sourcerow.foil
   else
      if urlfoil then
         card.foil = true -- believe urldata
      elseif string.find ( card.name, "%( ?[fF][oO][iI][lL]%)" ) then
         card.foil = true -- check cardname
      else
         card.foil = false
      end -- if urlfoil
   end -- if sourcerow.foil

When card.foil is set to false, you enter in the else block and check the url. As my url has fruc "Foil_And_Regular", you set the card.foil on true, doing the average between foil and non foil price, to set foil price.
I think the first test "if sourcerow.foil then" should be "if sourcerow.foil ~= nil then". If the property is set, use it and don't care about its value.
For now, I fixed the issue by removing the fruc from the url.

If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).

For that scenario, don't need to change anything critical. The parseHtmlDate can set card.regprice and card.foilprice properties as they are used in the BuildCardData with sourcerow.regprice and sourcerow.foilprice.
However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.

Its fascinating how much my choice of sites influenced what I considered generalization. Foil/Nonfoil on the same page is definitely something that a generally useful library needs to be able to cope with. Currently, I'm repairing breakage induced by adding more special sets to the existing sitescripts. When they work again, I will release 2.6 and concentrate on including your needs

All scenarios cannot be defined in advance, especially with internet

A feature I would like to have is the possibility to fill in site.sets at runtime. Why ?
When sets are hard-coded, any new set will require an update of the lua script. If the script is able to create sets at runtime, it is possible to automatically add new set when website is updated.
Let's say the name of set in MA is identical to the one on the website, I can map easily the MA setid with the website setid and add the entry is the table site.sets.
When a new set is release and available on the website, if set name matches, the set is automatically available in the lua script.

In the case a map between MA abd Website is not easy, we can still define it by hand in LUA script.

Anthony.

[LordHelmchen]

I'll try to give all information you need/want. We might be able to evolve this into a real documentation later

Thanks. A section on the wiki page would be great

Feel free to edit the wiki page with questions and by improving the documentation. Maybe developer information should be moved into a seperate page? I could post a copy of the template into the wiki there for easier reading... Also, please tell me of any improvements that could be made to the template comments (which I originally planed to be the main developer documentation)

dropping cards:

This kind of information would also be welcome on the wiki page.

wikified it

The impact of setting a specific property in a specific method would be great.

Could you elaborate what you mean? In particular, are there questions that are not answered by the luadoc comments? In answering those questions, what should go to the wiki and what is better/already done with code comments?

Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
[...]
Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.

In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.

That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.

You're right, BuildCardData should be aware of the MA importfoil. The sitescript just needs to return all info it has, and the library does "the rest"

added to planned features.

In my case, we are in the scenario "*CARDNAME*PRICE*FOILSTATUS". So, I'm able to set card.foil in parseHtmlDate function.
This works good except with non foil card. The card.foil is set to false, but BuildCardData consider the card as foil due to the fruc ("Foil_And_Regular") in the URL.

In BuildCardData, you have a conditional block:
...
When card.foil is set to false, you enter in the else block and check the url. As my url has fruc "Foil_And_Regular", you set the card.foil on true, doing the average between foil and non foil price, to set foil price.
I think the first test "if sourcerow.foil then" should be "if sourcerow.foil ~= nil then". If the property is set, use it and don't care about its value.
For now, I fixed the issue by removing the fruc from the url.

Will check BuildCardDate and probably change all instances of

Code: Select all

if sourcerow.FIELD then

to

Code: Select all

if sourcerow.FIELD~=nil then

If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).

For that scenario, don't need to change anything critical. The parseHtmlDate can set card.regprice and card.foilprice properties as they are used in the BuildCardData with sourcerow.regprice and sourcerow.foilprice.

How should cards with variants be handled in this case? Should the library just apply sourcerow.*price to card.*price (as it does now), should the library go through the versions and apply sourcerow.*price to card.price[variant] fields, or (probably the safest) make sure that version information matches and the do witchever of the previous two solutions fit best? I'm not sure if trusting the sitescript to get variants right is safe

However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.

Right...although that is just to divide the price by 100 again (see comments in code. I could add a check for card.price~=nil to prevent errors and forcing the sitescript to set unneeded properties. Should I add a check for ~=nil and division by 100 for card.regprice and card.foilprice there as well, to keep the way prices are handed over consistent? Would potentially need to loop through variants there, then.

When they work again, I will release 2.6 and concentrate on including your needs

2.6 is released with all that previously worked working again. All changes for your needs shall be 2.7, of which the first version will appear shortly.

A feature I would like to have is the possibility to fill in site.sets at runtime. Why ?
When sets are hard-coded, any new set will require an update of the lua script. If the script is able to create sets at runtime, it is possible to automatically add new set when website is updated.
Let's say the name of set in MA is identical to the one on the website, I can map easily the MA setid with the website setid and add the entry is the table site.sets.
When a new set is release and available on the website, if set name matches, the set is automatically available in the lua script.

In the case a map between MA abd Website is not easy, we can still define it by hand in LUA script.

I was aiming at the scripts being easily updateable, but this is even more ambitious
For a new set, As long as I cannot ask MA for the information, I need to add the set's cardcounts and variant tables (usually, for sets with basic lands) anyway. The first for LHpi's ungodly amount of sanity checks, the second because I want to minimize the need to repeat the table in each sitescript and prefer to have namereplacement to full variant tables therein.
The sitescript needs to have the set's url (which is not trivially guessable for some sites), langs, frucs and (for mtgmintcard) pagecount set correctly to prevent unneccessary calls for empty/nonexisting pages. Also, I have rarely seen a set that does not need any namereplacing done across all sites. Lastly, Due to different foil/nonfoil and available languages, guessing the number of applied namereplacements from the length of the namereplace table alone seems almost impossible, so the expected count for the sanity checks need to be adjusted by hand anyway.
All that said, if you like, feel free to submit patches to (start to) implement site.sets at runtime. As long as nothing breakes, more features in the library are a good thing, and minimizing the need for manual updates on new sets is even better than making those updates easy

[LordHelmchen]

Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
[...]
Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.

In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.

That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.

Actually, now that I have thought about it for a while, the way LHpi.ProcessUserParams currently configures the script, what you need to do is:
define two frucs, {"foil","nonfoil"}, but don't append fruc[frucid] in site.BuildUrl, but instead return the same url for both frucids. Now ProcessUserParams can configure what to import with the assumption that fruc[1] is foil and other frucs are nonfoil. LHpi.ListSources will then try to add the same url twice, overwrite the first copy with the identical second copy, so LHpi.MainImportCycle will see no difference to a single fruc. Starting with 2.7, LHpi.BuildCardData will then drop unwanted foil/nonfoil according to importfoil, to be compatible with a foil-and-nonfoil-in-one-page site. I will update the template comments to make this more obvious.

Btw, in case you haven't seen it yet, a prerelease of 2.7 is available on the wiki for you to try.

[anthonybe]

I will have a look at 2.7-pre-release.
Your proposition with two fruc but same url looks good to me. I will have a try.

Concerning documentation, I will think about what to put in comment in sitescript and what to put in the wiki to help new sitescript creators. Let sometime to do it and I will return to you

[LordHelmchen]

2.7 is done, with a hopefully better documented template
Here's another wiki link so you don't have to scroll back up to find it

[anthonybe]

Hi Lord,

I added a wiki page explaining how to write LHpi sitescript file.
The formating must still be done but I don't have the time for now (I quickly added the page during a travel with internet access ).

Could you please read it and given me your feedbacks ?
Some point must be developped in order to get full information. I described some property/function how I think it should work, but as I actually don't use all of them, I cannot verify it.

Anthony.

[LordHelmchen]

Hi Lord,

I added a wiki page explaining how to write LHpi sitescript file.
The formating must still be done but I don't have the time for now (I quickly added the page during a travel with internet access ).

Could you please read it and given me your feedbacks ?
Some point must be developped in order to get full information. I described some property/function how I think it should work, but as I actually don't use all of them, I cannot verify it.

Anthony.

Thanks for helping out with the documentation. Please be assured that any critique that follows is not meant to diminish your work.
On first sight, I feel like there's a lot of information that is duplicated between the howto and the template, and I wonder if that is necessary. I think it's safe to assume that a sitescript developer would look at the template for examples and function definitions.

But then, I can't know how it looks to someone who did not write the library, so it is probably better if I don't interfere much with deciding what should be in the howto, and restrict myself to make sure the template comments are correct. Those can then be copied over to the howto and expanded according to actual user's needs.
My role in writing the howto should therefore probably be to fill in blanks, correct mistakes and answer questions. Please do point out anything that you're unsure about, so I can verify it.

As for the howto's structure, I will wait a few revisions before changing anything major. Like with the content, it's probably better to see a user's perspective instead of me copying the template's stucture into the howto.
I would propose to seperate general information and hints, properties (like site.regex), functions (like site.BuildUrl) and options (like VERBOSE). Within theese categories, the entries could be ordered by appearance in the script or in some order that seems useful to follow when starting to write your own script.

Should the paragraphs from the Hints for developers section stay seperate or be moved over to the howto?

Shall I add information about the return values that LHpi expects from the sitescript functions, or are the template comments enough for this?

[anthonybe]

On first sight, I feel like there's a lot of information that is duplicated between the howto and the template, and I wonder if that is necessary. I think it's safe to assume that a sitescript developer would look at the template for examples and function definitions.

But then, I can't know how it looks to someone who did not write the library, so it is probably better if I don't interfere much with deciding what should be in the howto, and restrict myself to make sure the template comments are correct. Those can then be copied over to the howto and expanded according to actual user's needs.
My role in writing the howto should therefore probably be to fill in blanks, correct mistakes and answer questions.

You're right about template/how-to duplicate. I started the How-to based on what I found in the template and completed with some information from my experience.
From my opinion, the template file should contain the minimal information about properties/functions and their usages (e.g. examples), and the How-to should be a reference where developers can find/share more completed examples (e.g. different scenarios like the foil/regular prices on same page).

Please do point out anything that you're unsure about, so I can verify it.

You can find some "TODO" in the how-to for points that i'm not sure about it or I didn't know how to describe in the good way

As for the howto's structure, I will wait a few revisions before changing anything major. Like with the content, it's probably better to see a user's perspective instead of me copying the template's stucture into the howto.
I would propose to seperate general information and hints, properties (like site.regex), functions (like site.BuildUrl) and options (like VERBOSE). Within theese categories, the entries could be ordered by appearance in the script or in some order that seems useful to follow when starting to write your own script.

For the structure, I tried to make it like a wizard where each required properties are coming first and afterwards optional properties and LHpi properties. At the end, the functions to define.
In my case, I "reformatted" your sitescript template in that order.

If the how-tov and template file have the same structure, developpers can read the how-to and complete their sitescript at the same time. They know what the property/function does and how-to fill it.

Should the paragraphs from the Hints for developers section stay seperate or be moved over to the howto?

The hint are welcome in the how-to, in the appropriate section.
"multiple copies of the same script" could be added in the "(semi-optional) Name of sitescript".
"procedure of funtions call" could be added in separate section (e.g. annexes ?).
"Dropping card" could be added to the appropriate function definition (ParseHtmlDate, BuildCardData, ...) depending the usage developpers do.
"non trivial tables" could be added as a general tips in the properties introduction.

Shall I add information about the return values that LHpi expects from the sitescript functions, or are the template comments enough for this?

You're welcome to add these infos in the how-to.

-----------------------
Apart of the wiki page, I have another question about LHpi.

1. Library updade
   
   I started my sitescript with version 2.6.1 of the template and libver 2.6. Afterwards, you proposed libver 2.7 with sitescript 2.7.1.
   How developers should do in order to "upgrade" their sitescript to the latest version of the library and template ?
   Do they need to edit the new sitescript template version and copy/paste their properties/function in there ?
   Or is it another way to "merge" their existing sitescript with new properties/functions of the latest template ? For example, the latest version of the template could give a list of new properties/functions added or dropped ?
   
   
2. Different url infix for same set
   
   In the last days, the Belgian website did an important update, causing the failure of the my sitescipt.
   Now, the foil and regular prices are not on the same page anymore but splitted in two distinct pages.
   The difference between both is the ID of the collection in the url. So, 1 set --> 2 ids (foil, regular).
   
   I'm thinking to solve the situation by defining 'url' property of 'site.sets' as a table where the index is the FRUC_ID and value the website's ID.
   Something like:
   
   

   Code: Select all

   [800]={id = 800, lang = { true, [4]=true}, fruc = {true, true }, url = { "<foil collection id>", "regular collection id"}, -- Theros

   if site.frucs is defined like this:
   
   

   Code: Select all

   site.frucs = { "foil", "regular" }

   Afterward, in the site.buildUrl function, I would retrieve the id infix with:
   
   

   Code: Select all

   site.sets[setid].url[frucid]

   Do you think it's the correct way ? Or you see another one ?
   (Still a good example to add in the how-to )

Anthony.