by PalladiaMors » 14 Jun 2015, 18:19
p.s: I confused Akroma's Blessing with Akroma's Vengeance on the attached file above, besides the other issues you mentioned. Submitted it through web interface now.
by melvin » 15 Jun 2015, 01:49
https://github.com/PalladiaMors/magaren ... 3e770a9362
https://github.com/PalladiaMors/magaren ... cf1b5c1935
https://github.com/PalladiaMors/magaren ... e977c9affc
https://github.com/PalladiaMors/magaren ... 11bfe0ba81
Should any of these be merged?
I'm not sure how you are currently using the website. One way to do it is as follows:
1. open https://github.com/PalladiaMors/magarena/find/master
2. find the file to edit
3. click to open the file, click "edit" icon
3. make changes
5. if there are more cards, goto 1 (shortcut press 't')
When you are ready to make a pull request, goto https://github.com/PalladiaMors/magarena and click on "Pull request"
by PalladiaMors » 15 Jun 2015, 16:04
by melvin » 16 Jun 2015, 02:27
I found a way to have an updated copy without recreating the fork!
The first commit should be by editing a file from https://github.com/magarena/magarena
This will create an updated branch on your fork, eg. patch-98. This is the name of the new branch, it will be at the same commit as the main repo.
Subsequently, on https://github.com/PalladiaMors/magarena select that branch from the "branch: master" dropdown box. eg. Choose patch-98
Then make further commits to the "patch-98" branch as necessary. When done, submit pull request for patch-98 branch.
by PalladiaMors » 14 Nov 2015, 18:00
While I believe it's an improvement, this is definitely not an ideal solution. For instance, Arcbound Ravager used to be often paired with Disciple of the Vault, and there's the rare hypothetical situation where the opponent is down to low health and you could want to use the sac Ravager to his own ability trick, even when there are no other artifacts you control. Also, some plays aren't much better than the insta-sac Ravger tech: turn 1 artifact land, turn 2 artifact land, play Ravager and sac both lands to get a 3/3 - really bad on most situations.
The restriction is a slight improvement, but ultimately I think these problems are a result of the fact that the AI doesn't seem to consider card advantage and card disadvantage at all in its line evaluations. This is a massive problem, since this is one of the main strategical aspects of the game. Obviously this isn't quite so simple but as a general rule, if you're spending a card in order to disable one of the opponent's cards, you've made an "average" play; if you spend a card and don't "get" any of the opponent's in return, you've made a bad play; if you spent a card and "got" two or more of the opponent's in return, you've made a good play. The exception is if you can finish the game, because then it doesn't matter how many cards you're down in order to do that since you've already won (relevant for strategies such as Burn). My opinion is that somehow the calculations should take this into account.
Edit: another very commonly played card that could use the restriction is Welding Jar.
Updating OP with "cards that can sacrifice themselves" group.
by ShawnieBoy » 14 Nov 2015, 18:18
These changes will not effect the activation of these abilities for the player, and while effecting corner-cases, will help certain cards to remain on the battlefield instead of being sacrificed immediately to themselves.
I've only changed abilities where the effects are intrinsically linked to the source. Essentially all effects with a Sacrifice as a cost could have this AI restriction if a target is of the same type as the Sacrifice type involved.
It would be preferable for the AI that if a Sacrifice type matches the source, and the 'target' of the effect is SN, then to use 'Sacrifice another <type>'.
Similarly if the Sacrifice is SN, then to use 'target other'. These can't be scripted without restricting these options to the player as well, so would/could be included into the AI options somehow.
edit: More thoughts
by muppet » 15 Mar 2016, 15:39
by ShawnieBoy » 16 Mar 2016, 16:54
Activating and declining to perform it is a possible action (if something changes since it was on the stack) but trying to activate it when the AI can't is another matter - added AI condition, will have a look at other hand->battlefield activationsmuppet wrote:Using Stoneforge Mystic tap ability with no equipment in hand is a common error and I can't see almost any reason why it would ever be useful.
by ShawnieBoy » 16 Mar 2016, 17:14
by muppet » 17 Mar 2016, 10:07
by ShawnieBoy » 17 Mar 2016, 10:49
AI hinting won't override may choices - they are only there to ensure that the situation to activate/cast are valid. For Stoneforge Mystic, the important part is that there is an Equipment card in hand. If the AI is trying to activate the ability without an Equipment in hand, then AI hinting would help.muppet wrote:It isn't a bug. You can always use the ability if you want to even though it just uses 2 mana for no reason. I am just saying I can think of almost no time using 2 mana and tapping a creature for no reason is good so you could add a don't do this.
If the AI is declining to play an Equipment, then that's more of an AI engine issue.
As a rule, may choices should remain. Although looking at the ability on it's own you'd think "Why would I choose 'No'", it all depends on other cards and all other possible scenarios.
by muppet » 23 Mar 2016, 16:03
by ShawnieBoy » 30 Mar 2016, 17:20
That's quite a specific casting restrictionmuppet wrote:It could do with an if you have a legendary permanent in play un tapped with the same name as the one you are trying to cast don't bother unless they have an effect when they both die e.g. the black dragon. or If it is a planeswalker you might want to activate it twice I guess.
Situations like this would be best applied within the AI logic. I normally see these plays as the AI not having, or able to find, a valid play to turn the game around.
by muppet » 31 Mar 2016, 09:22
I was just trying to cover all the options by making it so specific.
More general things might cause unintended problems in a really tiny number of cases that probably don't come up much. e.g. simply not casting another legendary permanent of the same name is a 70% better fix than allowing it.
Having a switch that says don't do this unless the returned value is overwhelmingly better than other options for a lot of things might well be good.
Who is online
Users browsing this forum: No registered users and 1 guest