LordHelmchen wrote: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
LordHelmchen wrote: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.
LordHelmchen wrote: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"
LordHelmchen wrote: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.
LordHelmchen wrote: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.
LordHelmchen wrote: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.