Splinterverse wrote:I'm curious what the following code is used for.
It appears in many places where life gain is occurring.
- Code: Select all
<AUTO_SKIP>
local effectController = EffectController()
if effectController:GetTeam():IsSharedLifeTotal() == true then
if effectController:GetLifeTotal() >= 30 then
return true
end
else
if effectController:GetLifeTotal() >= 20 then
return true
end
end
return false
</AUTO_SKIP>
Does this code block prevent the life gain or ?
An AUTO_SKIP block causes a spell or ability to skip the stack. It just resolves if the block returns true. It's used in places where, while there technically should be a chance to respond, the likelihood of that chance being vital is very low. For instance, if an effect causes you to gain 3 life, but you already have a bunch of life, it's unlikely that it'll matter whether or not your opponent gets a chance to respond. It technically fails in certain situations, but it's a feature the developers implemented, and we've kept things in line with that more or less. I believe it's controlled by the player setting "Automatically resolve certain abilities". When that setting is active, the auto_skip blocks are ignored, and only abilities marked as forced_skip will skip the timer.
The code you posted causes the life gain to simply happen immediately without having to wait for the timer. (I said it skips the stack, but as far as the engine is concerned, it likely uses the stack. It just doesn't initiate a timer.) However, the life gain would only be immediate if the player's life is already more than their starting life total.
Incidentally, there's a one-liner that can achieve the same thing: "return EffectController():GetLifeTotal() >= CW_General_StartingLifeTotal()"
----
Jace, Architect of Thought (not of the Mind
) will take some testing, but I'm pretty sure I see the issue. When choosing a card, it's calling ChooseItems (for splitting the piles). But ChooseItems is for use with filters. It makes the player on which the function is called choose items from the last filter. But the last filter that existed in the ability was for the players. It should be choosing from the queryDC that was created, and thus simply changing it from ChooseItems to ChooseItemsFromDC (and adding the queryDC as the first parameter) should fix it. I've gone ahead and done this, but I don't know if it will fix the issue.
----
The error you mentioned from CW_Mana is likely coming from the new mana abilities. I'm not certain off-hand why, but I've altered then functions a very small amount so now instead of an error when you close the game, it should show an error in-game telling you which card is producing the error. It's the function "CW_Mana_GetRandomProducibleColor" and the error will be "No producible color found." See if maybe it's caused by colorless lands or lands not marked properly with Riiak's marking function "RSN_MarkCanProduceMana("SOME_MANA_STRING")".
----
I don't see anything wrong with
Warden of the First Tree, but I did add in a couple of extra checks to make sure things are valid before using them. It should prevent the errors, but if it was actually misbehaving, this won't fix it.
Hissing Quagmire had a typo, which is now fixed.
Posted: 16 Jan 2017, 13:08