Forge version 1.3.11

[Chris H.]

Tentative target release date: Friday March 29.

[Chris H.]

I just noticed that when I launch forge from within Eclipse that a message is printed to the console view and it now states how many cards were read.

Thank you Max, can we keep this message and not delete it at some point in the future?

Sol had mentioned in the past that using the total number of cards found in the constructed mode deck editor left out the avatars, planes, etc.

I think that doing a copy and paste from this new console message would give us a more accurate total number of cards for our beta releases.

[Max mtg]

Thank you Max, can we keep this message and not delete it at some point in the future?

I think that doing a copy and paste from this new console message would give us a more accurate total number of cards for our beta releases.

Of course, especially if it's that helpful.
Yes, it's most accurate - that's the total number of .txt files read over time displayed in the same line.


Regarding to 1.3.11 release, if no branches are going to be merged before friday, I suggest an earlier release of 1.3.11.

Because - you see - I am concentrated on input_sync branch, myk has two other branches, Sloth is on vacation and others (AFAIK) don't plan to make any major changes this week.
If we release the beta soon and I merge down the inputs right after that, there will be more people to test the new system as it will appear in daylies. I also feel lonely working inside that branch without communication or feedback from other people.

[Chris H.]

Regarding to 1.3.11 release, if no branches are going to be merged before friday, I suggest an earlier release of 1.3.11.

Because - you see - I am concentrated on input_sync branch, myk has two other branches, Sloth is on vacation and others (AFAIK) don't plan to make any major changes this week.
If we release the beta soon and I merge down the inputs right after that, there will be more people to test the new system as it will appear in daylies. I also feel lonely working inside that branch without communication or feedback from other people.

 
I will release the beta on Wednesday March 26 and I think that it would be best to go ahead and release it early so that people can start to get used to the new user data locations.

[myk]

There is no need to hurry the merge to trunk, or not have testing from other people, though. The main reason to have feature branches is to keep them out of trunk until they are tested. I just didn't know you were ready for code reviews and bug reports. I'd be happy to check out the input_sync branch and test it (and others should too!). What is the test plan we should follow so we can be sure to cover all the new code paths? How closely did you end up following your original plan?

[Max mtg]

myk, there is noone to test my trunk. Noone in the three days after I declared that it works on 23rd.

The test plan... I don't have a definite one. (Asked for it here - viewtopic.php?p=113471#p113471)
You should cast spells with different additional costs, have abilities request costs payment during different phases - such as upkeep, declare attackers, end of turn.
Cast spells with X in cost, including those with restrictions on X (X can't be null, must spend only black mana)

The plan is accomplished. Goals are reached.

See an example method | Open

Code: Select all

    @Override
    public final boolean payHuman(final SpellAbility ability, final GameState game) {
        final Card source = ability.getSourceCard();
        int manaToAdd = 0;
        if (!this.hasNoXManaCost()) {
            // if X cost is a defined value, other than xPaid
            if (!ability.getSVar("X").equals("Count$xPaid")) {
                // this currently only works for things about Targeted object
                manaToAdd = AbilityUtils.calculateAmount(source, "X", ability) * this.getXMana();
            }
        }
       

        if (!"0".equals(this.getManaToPay()) || manaToAdd > 0) {
            InputPayment inpPayment = new InputPayManaOfCostPayment(game, this, ability, manaToAdd);
            FThreads.setInputAndWait(inpPayment);
            if(!inpPayment.isPaid())
                return false;
        }
        if (this.getXMana() > 0) {
            source.setXManaCostPaid(0);
            InputPayment inpPayment = new InputPayManaX(game, ability, this);
            FThreads.setInputAndWait(inpPayment);
            if(!inpPayment.isPaid())
                return false;
        }
        return true;

    }

In trunk this code cannot just wait for inputs to complete, it had to set an input, and then have that input manipulate cost part objects and invoke another input if needed and then come back to check with other cost parts remain unpaid.

PS: Since you wrote nothing about terms for beta 1.3.11, I guess you don't mind a release tomorrow.

[myk]

You should cast spells with different additional costs, have abilities request costs payment during different phases - such as upkeep, declare attackers, end of turn.
Cast spells with X in cost, including those with restrictions on X (X can't be null, must spend only black mana)

I'll give it a run-through.

I guess you don't mind a release tomorrow.

It's fine either way. I have code to check in, but it can wait until the next release.