Collectible Card Game Headquarters

this is a "sample" from Goblin Grappler I made. To code the "Provoke" ability I used the second ability from Vortex Elemental (coded by NEO I think..)

| Open

Code: Select all

<?xml version='1.0' encoding='UTF-8'?>
<CARD_V2 ExportVersion="1">
  <FILENAME text="GOBLIN_GRAPPLER_45125" />
  <CARDNAME text="GOBLIN_GRAPPLER" />
  <TITLE>
    <LOCALISED_TEXT LanguageCode="en-US"><![CDATA[Goblin Grappler]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="fr-FR"><![CDATA[Accrocheur gobelin]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="es-ES"><![CDATA[Peleador trasgo]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="de-DE"><![CDATA[Goblin-Kettenkämpfer]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="it-IT"><![CDATA[Rampinatore Goblin]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="jp-JA"><![CDATA[Goblin Grappler]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ko-KR"><![CDATA[Goblin Grappler]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ru-RU"><![CDATA[Goblin Grappler]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="pt-BR"><![CDATA[Goblin Agarrador]]></LOCALISED_TEXT>
  </TITLE>
  <MULTIVERSEID value="45125" />
  <ARTID value="A45125" />
  <ARTIST name="Christopher Moeller" />
  <CASTING_COST cost="{R}" />
  <FLAVOURTEXT>
    <LOCALISED_TEXT LanguageCode="en-US"><![CDATA[Daru soldiers learned it’s better to have a clean death from a sharp blade than to tangle with a goblin’s rusted chains.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="fr-FR"><![CDATA[Les soldats daru préfèrent la mort rapide causée par une lame aiguisée à l’agonie causée par les chaînes rouillées des gobelins.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="es-ES"><![CDATA[Los soldados de Daru aprendieron que es mejor que los maten rápidamente con una hoja afilada que lidiar con las cadenas oxidadas de un trasgo.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="de-DE"><![CDATA[Daru-Soldaten lernten schnell, dass ein sauberer Tod durch eine scharfe Klinge den rostigen Ketten der Goblins bei weitem vorzuziehen ist.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="it-IT"><![CDATA[I soldati daru hanno imparato che è meglio una morte pulita per un colpo di spada che non uno scontro con le catene arrugginite dei goblin.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="jp-JA"><![CDATA[Daru soldiers learned it’s better to have a clean death from a sharp blade than to tangle with a goblin’s rusted chains.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ko-KR"><![CDATA[Daru soldiers learned it’s better to have a clean death from a sharp blade than to tangle with a goblin’s rusted chains.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ru-RU"><![CDATA[Daru soldiers learned it’s better to have a clean death from a sharp blade than to tangle with a goblin’s rusted chains.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="pt-BR"><![CDATA[Os soldados de Daru aprenderam que é melhor ter uma morte limpa vinda de uma lâmina afiada a se emaranhar nas correntes enferrujadas de um goblin.]]></LOCALISED_TEXT>
  </FLAVOURTEXT>
  <TYPE metaname="Creature" />
  <SUB_TYPE metaname="Goblin" />
  <EXPANSION value="LGN" />
  <RARITY metaname="C" />
  <POWER value="1" />
  <TOUGHNESS value="1" />
  <TRIGGERED_ABILITY>
    <LOCALISED_TEXT LanguageCode="en-US"><![CDATA[Provoke]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="fr-FR"><![CDATA[Provocation]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="es-ES"><![CDATA[Provocar.]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="de-DE"><![CDATA[Provozieren]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="it-IT"><![CDATA[Provocazione |(Quando questa creatura attacca, puoi decidere che una creatura bersaglio controllata dal giocatore in difesa STAPpi e la blocchi se può farlo.)|]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="jp-JA"><![CDATA[Provoke]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ko-KR"><![CDATA[Provoke]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="ru-RU"><![CDATA[Provoke]]></LOCALISED_TEXT>
    <LOCALISED_TEXT LanguageCode="pt-BR"><![CDATA[Provocar]]></LOCALISED_TEXT>
   <TRIGGER value="ATTACKING" simple_qualifier="self" />
    <TARGET tag="CARD_QUERY_CHOOSE_CREATURE_UNTAP" definition="0" compartment="0" count="1" />
   <TARGET_DEFINITION id="0">
    local filter = ClearFilter()
    filter:Add( FE_TYPE, OP_IS, CARD_TYPE_CREATURE )
    filter:Add( FE_CONTROLLER, OP_IS, TriggerPlayer() )
    </TARGET_DEFINITION>
    <RESOLUTION_TIME_ACTION>
   local delayDC = EffectDC():Make_Chest(1)
   local target = EffectDC():Get_Targets(0):Get_CardPtr(0)
    if target ~= nil then
       delayDC:Set_CardPtr(0, target)
       MTG():CreateDelayedTrigger(2, delayDC)
    end
    </RESOLUTION_TIME_ACTION>
   <RESOLUTION_TIME_ACTION>
    local target = EffectDC():Get_Targets(0):Get_CardPtr(0)
    if target ~= nil then
        target:Untap()
    end
    </RESOLUTION_TIME_ACTION>
   <CONTINUOUS_ACTION layer="6">
    local target = EffectDC():Get_Targets(0):Get_CardPtr(0)
    if target ~= nil then
       local characteristics = target:GetCurrentCharacteristics()
       characteristics:Bool_Set( CHARACTERISTIC_MUST_BLOCK, 1 )
    end
    </CONTINUOUS_ACTION>
   <DURATION simple_duration="UntilEOT" />
   <AI_SIMPLIFIED_TARGETING compartment="0" hint="HINT_ENEMY_ONLY" />
  </TRIGGERED_ABILITY>
  <MAY />

  <TRIGGERED_ABILITY resource_id="2" replacement_effect="1">
   <TRIGGER value="EVASION_TEST" pre_trigger="1">
      local card = EffectDC():Get_CardPtr(0)
      if card ~= nil then
         return TriggerObject() == card and SecondaryObject() ~= Object()
      end
   </TRIGGER>
   <CLEANUP simple_cleanup="EndOfTurn"/>
  </TRIGGERED_ABILITY>

  <SFX text="COMBAT_BLUNT_LARGE_ATTACK" power_boundary_min="4" power_boundary_max="-1" />
  <SFX text="COMBAT_BLUNT_SMALL_ATTACK" power_boundary_min="1" power_boundary_max="3" />
</CARD_V2>

to those who are not familiar with Provoke, here you are the rules:

| Open

702.38. Provoke
702.38a Provoke is a triggered ability. “Provoke” means “Whenever this creature attacks, you may choose to have target creature defending player controls block this creature this combat if able. If you do, untap that creature.”
702.38b If a creature has multiple instances of provoke, each triggers separately

There's something not ok with the code though: when I attack with two different Goblins and provoke two different creatures, at first the blocking creatures are assigned as expected, but then the AI can decide to let both of them block only 1 Goblin.. the Provoke ability shouldn't allow that.
Can it be "fixed" to work properly?

"Creature A must block creature B if able" is simply not currently possible. However, with the Community Wad working and with RiiakShiNal's Custom Characteristics, we might actually finally be able to manage it. I had the thought a long time ago to give the blocker the ability to block a certain characteristic. Then, give the blocked creature that ability, and then force the blocker to block. This had problems with cards like Hunted Ghoul. (Not to mention there was a more basic mistake.)

It might be possible to recode Hunted Ghoul with a new characteristic which informs us who it can block. Then, cards like this one with provoke would check that characteristic before applying its effect. The effect applied would be to tell it it must block, but can't block creatures with a certain characteristic, and then all OTHER creatures the defending player controls would be given that characteristic. It should be possible to set it up in a data chest format so that it wouldn't matter how many of these there are. It would get complicated, but we've solved just about every other problem we've come across: transform (TFM), morph (Neo), bestow (Neo), delve (Neo and myself... mostly him lol), soulbond (Sumo), and arguably the most important one: the entire freaking mana pool (RSN).

I remember thefiremind explaining that the biggest hindrance was the "if able" part of the ability where cards like Hunted Ghoul are concerned, and that since we couldn't check that, we couldn't code it properly. But we might finally be able to... Unfortunately, the code you have is doing it the simple way, which will simply never work, I'm afraid.

I'd have to rework the functions I made for colorless mana cost manipulation awhile back for delve. (Actually, I just realized that doing it that way wouldn't require modifying the blocking cards themselves, but rather only the one controlling the blocking...) I've got some ideas on this. I'll look into it later.

Riiak, if you see a gaping hole I'm missing, please help me not waste my time haha

I was thinking about using the "CanOnlyBlock_Set" function, but: a) it wouldn't work ok with creatures able to block more than 1 creatures b) I haven't found a single card that uses that Function, so I still have no clue on how to use it..

The "if able" part screws the whole thing up considering we don't have engine support. Though with some unified functions and a lot of recoding you could cover just about all but 1 case.

The case you would not be able to cover would be if you have use "Creature A must block creature B if able" on a creature that can block multiple creatures. The reason for this is while Creature A must still block Creature B, if Creature A can block 3 creatures then Creature A should still be able to block 2 other creatures and there is no way to do this even with lots of card recoding and an awesome set of functions.

With custom characteristics you can make an ability that would check for advertised blocking limitations compared to the the known abilities of the attacking card (it would also have to advertise any special limitations on blocking such as "can only be blocked by creatures with flying or reach") such as Fear, Flying, Intimidate, Unblockable, Protection, etc.... If by comparing the limitations from both cards it is determined that it would be possible to block then you would force the CHARACTERISTIC_MUST_BLOCK onto Creature A and CHARACTERISTIC_MUST_BE_BLOCKED_IF_ABLE onto Creature B as well you would need another ability to limit the blocking choices to just Creature B. The reason this doesn't work for creatures that can block multiple creatures is that if we use the second ability to limit Creature A to blocking Creature B is that Creature A should be able to block more creatures but can't due to the additional ability. If we eliminate the second ability then if the player blocks with more than just Creature A then Creature C could block Creature B and Creature A could block a different set of creatures.

So no matter how it is coded there will always be a limitation when dealing with creatures that can block multiple creatures. If that is acceptable then a complex workaround could theoretically be made though it will still require recoding lots of cards.

I'm aware it would have been extremely hard to code it for creatures who can blocks multiple creatures (and my post was not even intended to ask you to do that), but is there a chance to make it work for "regular" creatures?

Zambooo wrote:I'm aware it would have been extremely hard to code it for creatures who can blocks multiple creatures (and my post was not even intended to ask you to do that), but is there a chance to make it work for "regular" creatures?

Not just extremely hard for those creatures, but impossible. There's no way to force a creature to block another creature without restricting them to blocking only that creature. For the "regular" ones, that's largely what we're discussing. That's already the hard part. It's a bit easier for creatures with only keyword abilities that have characteristics we can check for, but even those will require checking for the relevant conditions for that blocking restriction and granting abilities to force the block if valid.
1) Creature A -> Must block.
2) Creature A -> Can't block Characteristic X.
3) Creature B -> Must be blocked.
4) All Others -> Characteristic X.

For any creature with a special restriction, it'll need a special function to check the card's name against a known list of special conditions (or something similar). That's what I'm considering working on if I get the time.


@Riiak
Yeah, I'd considered Palace Guard when typing that up and didn't think that kind of ability would play very nicely. I looked at how many cards we actually have with abilities like that and I count 28. That's NOT including creatures that limit blockers based on the number of blockers like Underworld Cerberus. There are 15 like that, but they would all have nearly identical coding IF that would even work (I don't think it would). That count is only using the search "be blocked except" (because "only be blocked" returned none). Can you think of any other phrases that might have been used?

However, I don't think it would be necessary to recode those cards. If, say, any card with a provoke type ability created an abilities active manager (which we've already gotten working back when we were working on delve), and then the restriction checking function checked that characteristic before considering the creature's restrictions, then the creatures themselves wouldn't need touched. Instead, all of the restrictions would be handled in one place through a single function.

Or they could be directly modified. I'm not sure which would be easier or better, but either approach should be possible. As for whether or not it's an acceptable limitation: I would personally say yes. It seems at least fairly uncommon for a situation like that to occur (mainly because those creature are already pretty uncommon), and 2015 doesn't seem to be working out, so we might be stuck with 2014. So, I say why not make as much as we can, even if it's not perfect? We can get it pretty close.

Zambooo wrote:I'm aware it would have been extremely hard to code it for creatures who can blocks multiple creatures (and my post was not even intended to ask you to do that), but is there a chance to make it work for "regular" creatures?

Can never work properly for creatures that can block multiple creatures (regardless where the effect comes from).

Theoretically, yes it could work for regular creatures which is why our posts are so long at the moment as we are discussing the ways it could work.

Xander9009 wrote:Not just extremely hard for those creatures, but impossible. There's no way to force a creature to block another creature without restricting them to blocking only that creature. For the "regular" ones, that's largely what we're discussing. That's already the hard part. It's a bit easier for creatures with only keyword abilities that have characteristics we can check for, but even those will require checking for the relevant conditions for that blocking restriction and granting abilities to force the block if valid.
1) Creature A -> Must block.
2) Creature A -> Can't block Characteristic X.
3) Creature B -> Must be blocked.
4) All Others -> Characteristic X.

For any creature with a special restriction, it'll need a special function to check the card's name against a known list of special conditions (or something similar). That's what I'm considering working on if I get the time.

Unfortunately, that won't work right. If you have 2 cards with provoke and each selects a different creature those creatures should be forced to block the creature that owned the ability that targeted them. Using your method if you have 2 cards with provoke that select different creatures either all attackers would become unblockable (as they would all have Characteristic X) or the selected creatures could choose the opposite attacker (as neither would have Characteristic X) depending on the implementation.

To make it work properly "2" would need to be can only block Creature B reference (card pointer) and there would be no item "4".

Xander9009 wrote:Yeah, I'd considered Palace Guard when typing that up and didn't think that kind of ability would play very nicely. I looked at how many cards we actually have with abilities like that and I count 28. That's NOT including creatures that limit blockers based on the number of blockers like Underworld Cerberus. There are 15 like that, but they would all have nearly identical coding IF that would even work (I don't think it would). That count is only using the search "be blocked except" (because "only be blocked" returned none). Can you think of any other phrases that might have been used?

Cards like Brave the Sands and Cenn's Tactician would screw up combat completely with abilities like Provoke as they can affect any/all creatures.

I had forgotten about cards like Underworld Cerberus, though it might be able to account for some situations for those cards by taking into account the number and blocking capabilities of the other untapped creatures that opponent (or team) has. Though then we also have to take into account abilities that would limit blockers for those other cards (like Provoke used from a different card). Ultimately, though that would be another limitation because if there are enough valid blockers, but the defending player doesn't want to use some of them to block the Underworld Cerberus then technically the Cerberus should be unblockable and should not be given the must be blocked characteristic meaning to make it work properly we would have to ask the question of if they wanted to block the Cerberus in this case before other later processing.

Xander9009 wrote:However, I don't think it would be necessary to recode those cards. If, say, any card with a provoke type ability created an abilities active manager (which we've already gotten working back when we were working on delve), and then the restriction checking function checked that characteristic before considering the creature's restrictions, then the creatures themselves wouldn't need touched. Instead, all of the restrictions would be handled in one place through a single function.

This would probably be a bad idea due to the high number of creatures with blocking limitations (and those cards that can assign them). If you do a large lookup table then you have to run through the entire table for every card meaning lots of cycles for string compares (which are notoriously slow) which would create a lot of lag. Also, it won't be able to cope with many effects that would add blocking limitations (such as from say Akroma's Blessing). Cards with such effects would have to be directly modified anyway as they can't be handled properly otherwise.

Xander9009 wrote:Or they could be directly modified. I'm not sure which would be easier or better, but either approach should be possible. As for whether or not it's an acceptable limitation: I would personally say yes. It seems at least fairly uncommon for a situation like that to occur (mainly because those creature are already pretty uncommon), and 2015 doesn't seem to be working out, so we might be stuck with 2014. So, I say why not make as much as we can, even if it's not perfect? We can get it pretty close.

They would likely need to be directly modified (at least some cards) because we have cards that can create blocking limitations for a creature that normally wouldn't have the limitations. Some of these can be checked because they use characteristics (like Treetop Bracers), but others aren't as convenient (such as Artifact Ward).

@Zambooo
Really random, but I noticed you have a <May /> tag outside of an ability block. Those are used inside the ability block so the game knows that ability is optional. It could just be moved immediately after the AI_SIMPLIFIED_TARGETING tag. It won't fix your issues, of course, but just generally.

RiiakShiNal wrote:To make it work properly "2" would need to be can only block Creature B reference (card pointer) and there would be no item "4".

Ah. I wasn't aware you could use pointers for blocking like that. (I've never actually worked with blocking; I just knew we couldn't do it right and why.) That actually simplifies it a bit, so that's fortunate. Realizing it's just a return true/false thing based on the secondary object being the creature it might be blocking, that makes sense.

RiiakShiNal wrote:Cards like Brave the Sands and Cenn's Tactician would screw up combat completely with abilities like Provoke as they can affect any/all creatures.

Yeah, you're right. And unfortunately, that's not done with a characteristic; it's a function, so we can't even check the card directly; we'd have to scan for those cards. I think the only option is to disable the function completely while something like that is out.

RiiakShiNal wrote:I had forgotten about cards like Underworld Cerberus, though it might be able to account for some situations for those cards by taking into account the number and blocking capabilities of the other untapped creatures that opponent (or team) has. Though then we also have to take into account abilities that would limit blockers for those other cards (like Provoke used from a different card). Ultimately, though that would be another limitation because if there are enough valid blockers, but the defending player doesn't want to use some of them to block the Underworld Cerberus then technically the Cerberus should be unblockable and should not be given the must be blocked characteristic meaning to make it work properly we would have to ask the question of if they wanted to block the Cerberus in this case before other later processing.

Asking about it is probably the only good solution. Let the player choose whether or not the cerberus will be blocked and then grant it he must be blocked/can't be blocked characteristic accordingly? For safety, it could ask again if any abilities or spells resolve. (And of course don't even try if there aren't enough blockers total...)

RiiakShiNal wrote:This would probably be a bad idea due to the high number of creatures with blocking limitations (and those cards that can assign them). If you do a large lookup table then you have to run through the entire table for every card meaning lots of cycles for string compares (which are notoriously slow) which would create a lot of lag. Also, it won't be able to cope with many effects that would add blocking limitations (such as from say Akroma's Blessing). Cards with such effects would have to be directly modified anyway as they can't be handled properly otherwise.

Well, as long as the granting is done through attaching (auras and equipment), then we could scan for the cards that grant those abilities and then get their parent, couldn't we? Of course the ones that affect everything would cause a lot more trouble, and some might not be possible (ignoring that some definitely aren't because their effect is multi-blocking). I don't know if there are cards that mass-grant things like "Can't be blocked except by walls" or anything.

Also, to limit how long it take to run through it, we could have a master list which is an array with the card names and indices for the function to use, and remove all of the cards from the array except those actually found in someone's deck in the current game. Then it would end up being a function with only 2 or 3 cards to check usually. The only lag would be at the very beginning when scanning everything and then during a game with a decks or a combination of decks with a particularly large variety of relevant cards. I'm not suggesting I'd want to go this route, as that's about twice as much effort for the same result; just that it should theoretically be possible to work around those issues mostly (I'm in a thinking mood...). But yeah, you've convinced me it would almost definitely be best to simply modify the cards directly. At least there are only about 30.


On a barely related note: do you happen to know how exactly functions work? More specifically, can a function in a lol file do anything that could be done from within the block the function is called from? Or are there limitations? I know it can't do anything that requires separate actions, which is why your annihilation functions take place over the course of three actions (or at least, I assume that's the reason). The way I imagine it is that the program pseudo-virtually inserts the function's code directly where it's called, meaning anything that could be done from the action could be done from within the function. I just don't know if that's right. If I'm going to get into messing with functions again, this would be useful to know.

Xander9009 wrote:Well, as long as the granting is done through attaching (auras and equipment), then we could scan for the cards that grant those abilities and then get their parent, couldn't we? Of course the ones that affect everything would cause a lot more trouble, and some might not be possible (ignoring that some definitely aren't because their effect is multi-blocking). I don't know if there are cards that mass-grant things like "Can't be blocked except by walls" or anything.

Except there are so many cards that offer things like Protection (which can limit blocking) which don't attach and only affect the card through an effect (Such as Akroma's Blessing which is an Instant so it is cast then the card is gone, but the effect remains). However, if the effect also added to the "advertised" blocking limitations that would solve the problem, but would mean rewriting all those cards.

Xander9009 wrote:Also, to limit how long it take to run through it, we could have a master list which is an array with the card names and indices for the function to use, and remove all of the cards from the array except those actually found in someone's deck in the current game. Then it would end up being a function with only 2 or 3 cards to check usually. The only lag would be at the very beginning when scanning everything and then during a game with a decks or a combination of decks with a particularly large variety of relevant cards. I'm not suggesting I'd want to go this route, as that's about twice as much effort for the same result; just that it should theoretically be possible to work around those issues mostly (I'm in a thinking mood...). But yeah, you've convinced me it would almost definitely be best to simply modify the cards directly. At least there are only about 30.

No, in several decks you could have dozens of cards, plus if a token gets created that has a special ability that should be noted (like protection) your scan would remove that from the list because the token isn't in the deck. Again the way to fix that would be to have the token "advertise" the limitations (which would mean the token would need to be rewritten).

There would be many, many more than just 30 because "Protection" is everywhere and it affects blocking and can't be detected through characteristics or any functions we have. Meaning every card that has protection or can grant protection would need to be directly modified to advertise that protection was given and exactly what protection was given (how to advertise protection is fairly complex in itself because it could be based on color, subtype, type, power, CMC, etc...).

Xander9009 wrote:On a barely related note: do you happen to know how exactly functions work? More specifically, can a function in a lol file do anything that could be done from within the block the function is called from? Or are there limitations? I know it can't do anything that requires separate actions, which is why your annihilation functions take place over the course of three actions (or at least, I assume that's the reason). The way I imagine it is that the program pseudo-virtually inserts the function's code directly where it's called, meaning anything that could be done from the action could be done from within the function. I just don't know if that's right. If I'm going to get into messing with functions again, this would be useful to know.

Yes, functions in a LOL file can do anything that could be done from within an action block. Functions/LOL files don't really provide true global variables (so arrays have to be recreated every action to be used) nor do they provide any persistent storage (which is why we keep going back to data chests).

It actually doesn't insert (not even psuedo inserting), it actually loads up the function in memory sets up a stack push for the arguments (including a return jump pointer) and does a jump to the function code then once the function returns it uses the jump pointer to go back to the regular code path and pops the allocated stack memory. It's quite technical in how it works, but for simplicity you can think about the function code being inlined where the calls are made.

However, it is important to note that locals set in an action can't be accessed from a function unless they are passed to the function as parameters and locals in a function can't be accessed from the action (because once back in the action the locals have been deallocated).

I had obviously completely forgotten about protection. Dang that's a lot of cards. I can at least think of one fairly easy way (compared to the other ways) of dealing with protection, but that'll be a real hassle.

For the functions, thanks. I knew the locals weren't accessible, but I'd forgotten about that limitation; making it obvious I was wrong. Yes, that is quite technical But it's alright, I actually know just enough about computers and programming to understand it.