Forge Beta Release: 11-02-2016 ver 1.5.57

[Marek14]

Humility doesn't turn of Painter's Servant's ability of changing card colors.

That's actually correct. Color-changing effects are applied in layer 5 of static abilities, while ability-removing effects are applied in layer 6. This means that Painter's Servant has its ability removed only after it has already applied, and thus the removal of the ability actually doesn't have any effect. (It's the same reason why Humility won't actually disable the changeling ability.)

I think this change (giving color-changing effects their own layere) was sometime around M10, probably to simplify commonly-occuring dependencies of such cards as the Mentor cycle in Shadowmoor.

[Seravy]

Oh wow, they managed to make the already most complicated effect layering rules even more complicated.
10th edition huh, no wonder I didn't know about it. Then again I didn't play the game for 8 or so years so maybe i just forgot, I wonder.
I suppose it's to make stuff like "all black creatures gain" interact with "all creatures are black" properly...but still very counter intuitive if the ability is not enabling effects to work on permanents but is the thing that would be removed itself.
Will stay on 1.5.56 anyway, I had enough of Wall of Junk not returning to hand in drafts and similar real bugs.

[sriracha]

I believe there's a bug in the handling of Insidious Will.
The AI casts a Stasis Snare.
In response I cast Insidious Will and target Stasis Snare.
I am prompted to confirm I wish to play Insidious Will, then asked to pay the casting cost, and do so.
I am asked if I want to play Stasis Snare, and hit the "OK" button.
The AI then does not ask me to choose a target, and it proceeds to target and apply Stasis Snare to one of my creatures.

I've replicated it twice so far.

[edit]
Maybe this is because the effect takes place after it enters the battlefield?

[friarsol]

I believe there's a bug in the handling of Insidious Will.
The AI casts a Stasis Snare.
In response I cast Insidious Will and target Stasis Snare.
I am prompted to confirm I wish to play Insidious Will, then asked to pay the casting cost, and do so.
I am asked if I want to play Stasis Snare, and hit the "OK" button.
The AI then does not ask me to choose a target, and it proceeds to target and apply Stasis Snare to one of my creatures.

I've replicated it twice so far.

[edit]
Maybe this is because the effect takes place after it enters the battlefield?

Which mode of Insidious Will are you trying to select?

[sriracha]

Which mode of Insidious Will are you trying to select?

Ah - yeah, should have noted that, eh?

The second mode: choose new targets for target spell.

The more I think about this the more I start to think that mode doesn't apply...thoughts?

[friarsol]

Which mode of Insidious Will are you trying to select?

Ah - yeah, should have noted that, eh?

The second mode: choose new targets for target spell.

The more I think about this the more I start to think that mode doesn't apply...thoughts?

Right. It's an enchantment with a triggered ability that targets. Casting it is still legal, it just doesn't do what you want.

[gos]

My opponent cast Corrosion. On his next upkeep, he put a counter on the only artifact he controlled and destroyed it (it had CMC 1). The Corrosion remains in play without his paying any upkeep for many rounds...

Cumulative upkeep in general seems to be having no effect.

Correction - AI doesn't seem to need to pay for cumulative upkeep. Works normally for creatures I control.

[Turbomoose]

Description: AI Player cast Lightform in Quest Draft. Picture included.

RuntimeException | Open

Code: Select all

Forge Version:    1.5.56-r-1
Operating System: Windows 8.1 6.3 x86
Java Version:     1.8.0_31 Oracle Corporation

java.lang.RuntimeException: AbilityFactory : getAbility -- no API in :
   at forge.game.ability.AbilityFactory.getAbility(AbilityFactory.java:107)
   at forge.game.ability.effects.CharmEffect.makePossibleOptions(CharmEffect.java:40)
   at forge.game.ability.effects.CharmEffect.makeFormatedDescription(CharmEffect.java:89)
   at forge.game.card.Card.formatSpellAbility(Card.java:1921)
   at forge.game.card.Card.abilityTextInstantSorcery(Card.java:1757)
   at forge.game.card.Card.getAbilityText(Card.java:1614)
   at forge.game.card.CardView$CardStateView.updateAbilityText(CardView.java:1005)
   at forge.game.card.CardView$CardStateView.updateKeywords(CardView.java:1016)
   at forge.game.card.CardView.updateState(CardView.java:723)
   at forge.game.card.Card.setState(Card.java:376)
   at forge.game.card.Card.turnFaceDown(Card.java:518)
   at forge.game.card.Card.manifest(Card.java:491)
   at forge.game.ability.effects.ManifestEffect.resolve(ManifestEffect.java:37)
   at forge.game.spellability.AbilitySub.resolve(AbilitySub.java:119)
   at forge.game.ability.AbilityUtils.resolveApiAbility(AbilityUtils.java:1296)
   at forge.game.ability.AbilityUtils.resolve(AbilityUtils.java:1277)
   at forge.ai.ComputerUtil.playNoStack(ComputerUtil.java:288)
   at forge.ai.PlayerControllerAi.playSpellAbilityNoStack(PlayerControllerAi.java:314)
   at forge.game.trigger.WrappedAbility.resolve(WrappedAbility.java:444)
   at forge.game.ability.AbilityUtils.resolveApiAbility(AbilityUtils.java:1296)
   at forge.game.ability.AbilityUtils.resolve(AbilityUtils.java:1277)
   at forge.game.zone.MagicStack.resolveStack(MagicStack.java:521)
   at forge.game.phase.PhaseHandler.startFirstTurn(PhaseHandler.java:978)
   at forge.game.GameAction.startGame(GameAction.java:1463)
   at forge.game.Match.startGame(Match.java:95)
   at forge.match.HostedMatch$2.run(HostedMatch.java:220)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)


[RumbleBBU]

Humility doesn't turn of Painter's Servant's ability of changing card colors. I think I had enough of this, time to downgrade to 1.5.56

By the way, a real changelog would be nice to have on releases. Something like "fixed bug X, AI now knows to do Y, changed how Z works" so we can know if there is a point risking the update or not.

There used to be one...at one stage, in the past, all new SVN commits were listed in the release notes. That is not done anymore, just the more significant changes are covered, but you can still browse the commits realtime at http://svn.slightlymagic.net

I think it's a good idea to always keep your old version of Forge anyway and install the new version in different different directory. It doesn't really take that much HD space, and you can use the same pics dir for both versions. (But you probably want to use different save data paths for the different versions, the format will in many cases not be downwards compatible.) If the new version doesn't work for you for some reason, you can just use the old version instead.

I have currently two parallel 'play' versions of Forge on my HD:

Forge 1.5.17 - It's 2 years old so it lacks 3 or 4 latest blocks but it's also one of the stablest Forge versions in recent years, aside from the battlefield GUI occasionally crashing if you play very many matches in a row (it stops updating the tapped/untapped visuals on cards when it crashes).

Forge 1.5.57 snapshot 32252 - This is actually closer to 1.5.56, since it's technically a snapshot that includes some notable bugfixes to 1.5.56. I've also manually made some minor fixes and modifications but I do that with all Forge versions I download. This snapshot is reasonably stable but seems to have some issues that 1.5.17 doesn't have.

Ideally, of course, Forge could have a separate 'stable' branch for end users (as opposed to 'dev' releases, which is all we are getting now), and I have been promoting that idea. Sadly, I haven't been able to personally contribute much towards that end yet - I'm having some moderate problems trying to get the current Forge source compile and run for me, and there's just so much time I can invest in that side project, with work and all hogging the majority of my time.

[Seravy]

First thing I do whenever I play any game is to change the save paths to point to the game's folder. I hate using documents/application data folders. So no problem there. But it isn't trivial to move the files I changed into the new version, so it would be nice if I knew in advance if it's worth the time. (mostly the editions folder, sound folder, quest folder have changed files, and ofc the user data needs to be moved as well)
I'd like to avoid moving backwards if possible, mainly due to possible incompatibility, which means I need to know in advance if the new version works or not.

those svn comments, yes that's what I was hoping for. Can't you, like, automatically generate a txt file that contains a list of all the changes since the previous version from there somehow and include that in the release? Having to browse through it one at a time like that is pretty inconvenient, and I would think there are hundreds of changes per release. If it's a simple text file we can even search to see if a specific problem was or was not fixed before upgrading.

[Listlik]

When will Kaladesh images be avaivable?

[RumbleBBU]

those svn comments, yes that's what I was hoping for. Can't you, like, automatically generate a txt file that contains a list of all the changes since the previous version from there somehow and include that in the release? Having to browse through it one at a time like that is pretty inconvenient, and I would think there are hundreds of changes per release. If it's a simple text file we can even search to see if a specific problem was or was not fixed before upgrading.

I don't think it would be impossible to write a script that dumps all SVN commit descriptions into a text file. However, that text file might not be quite as useful as you would think...

- The descriptions are just what the person committing the change chooses to write. They can be very verbose, or sparse, or vague, or even dead wrong. (You get a much better idea by viewing the actual changed code lines.)
- Often, what causes a single card to behave incorrectly is a much deeper underlying issue. A coder fixes that issue and reports doing so, and never even mentions that particular card in the commit description. If you searched by the card name, you might never find the fix and realize that it has been fixed now.
- Commits often have unforeseen consequences. Trying to fix a tiny little thing, a coder may inadvertently break a lot of other things. It might take a long time and several Forge releases before the issue is noticed and tracked down. The commit descriptions alone will not tell you what went wrong and when.
- (Etc.)

[Nekoatl]

When will Kaladesh images be avaivable?

The images aren't done by the Forge team, so there's no use asking about that here.

[Rooger]

In the deck selection panel we have 2 diferent view modes Image and List. If I choose Image View all decks are blank. Are these images implemented or are you guys testing things out? Are the pics stored in a particular folder?

For instance, Precons that already are available whitin Forge and purchasable in the quest mode via the shop have the deckbox images located inside the pics folder and they indeed show up in the shop but not in the deck selection panel.

Sorry if this is not the place to ask this but i felt that I didn't need a new thread for a simple question.

[Seravy]

those svn comments, yes that's what I was hoping for. Can't you, like, automatically generate a txt file that contains a list of all the changes since the previous version from there somehow and include that in the release? Having to browse through it one at a time like that is pretty inconvenient, and I would think there are hundreds of changes per release. If it's a simple text file we can even search to see if a specific problem was or was not fixed before upgrading.

I don't think it would be impossible to write a script that dumps all SVN commit descriptions into a text file. However, that text file might not be quite as useful as you would think...

- The descriptions are just what the person committing the change chooses to write. They can be very verbose, or sparse, or vague, or even dead wrong. (You get a much better idea by viewing the actual changed code lines.)
- Often, what causes a single card to behave incorrectly is a much deeper underlying issue. A coder fixes that issue and reports doing so, and never even mentions that particular card in the commit description. If you searched by the card name, you might never find the fix and realize that it has been fixed now.
- Commits often have unforeseen consequences. Trying to fix a tiny little thing, a coder may inadvertently break a lot of other things. It might take a long time and several Forge releases before the issue is noticed and tracked down. The commit descriptions alone will not tell you what went wrong and when.
- (Etc.)

I believe it would be useful information anyway(imperfect is better than none) and if it wasn't you wouldn't have told me where to find it. If you want to say "we don't have time to waste on this", I can understand that, but was hoping it doesn't take much time.