Page 3 of 4

Re: Cost Reorganization

PostPosted: 26 Aug 2011, 23:16
by Braids
of course, the definitive solution would be to use vector graphics for all symbols and have them anti-aliased at run time. except for the card images, resizing would always look perfect. :wink: :-"

Re: Cost Reorganization

PostPosted: 27 Aug 2011, 00:13
by ArsenalNut
Sol,

How hard would it be to add color restrictions to the x cost? I was looking at Consume Spirit and the only thing keeping it from being scriptable is the black mana restriction for the x cost. I found six other cards the have similar restrictions.

Re: Cost Reorganization

PostPosted: 27 Aug 2011, 00:48
by moomarc
Braids wrote:of course, the definitive solution would be to use vector graphics for all symbols and have them anti-aliased at run time. except for the card images, resizing would always look perfect. :wink: :-"
Which vector formats are supported in java?

Re: Cost Reorganization

PostPosted: 27 Aug 2011, 01:50
by Braids
moomarc wrote:
Braids wrote:of course, the definitive solution would be to use vector graphics for all symbols and have them anti-aliased at run time. except for the card images, resizing would always look perfect. :wink: :-"
Which vector formats are supported in java?
it looks like SVG is an XML format that certain Java libraries can handle alongside the standard swing GUI toolkit.

http://juixe.com/techknow/index.php/2007/05/29/swing-vector-graphics/
http://xmlgraphics.apache.org/batik/using/swing.html
http://java.sun.com/developer/technicalArticles/GUI/svg/

edit: @moomarc, are you familiar with exporting to SVG?
edit2: the problem is, this will tax the CPU more. but it wouldn't be as taxing as a 3D interface, which i would strongly oppose.

Re: Cost Reorganization

PostPosted: 27 Aug 2011, 03:00
by friarsol
ArsenalNut wrote:Sol,

How hard would it be to add color restrictions to the x cost? I was looking at Consume Spirit and the only thing keeping it from being scriptable is the black mana restriction for the x cost. I found six other cards the have similar restrictions.
I can look into it, but I'm not sure. X can't be 0. Should be pretty simple, since I can cancel a spell that doesn't pay X properly, but Paying Mana doesn't actually occur in Cost, it happens in Input_PayManaCostUtil (which is overly complex and someone should refactor it). This would basically need to check for Mana limitations and apply them to the possible valid colors.

Ugh. On second thought, I don't really want to look into it. Maybe after I clear a few other things off my plate.

Re: Cost Reorganization

PostPosted: 27 Aug 2011, 03:08
by Chris H.
ArsenalNut wrote:I've noticed that the summoning sickness icon doesn't seem to show up until I have three or four permanents on the battlefield. Is this a related issue?

Edit: My screen resolution is set at 1900x1080
`
Your monitor is close to the same size as mine. You are seeing the same thing that I noticed.

Once there are several cards on the screen the pic size is scaled down small enough that it passes a test and the summoning sickness icon is drawn.

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 12:30
by Sloth
Sorry to bring up this thread again, but I noticed today that the CostChange keyword doesn't work anymore. Could it be rellated to you're work Sol?

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 13:12
by friarsol
Sloth wrote:Sorry to bring up this thread again, but I noticed today that the CostChange keyword doesn't work anymore. Could it be rellated to you're work Sol?
I'm not sure. I always thought CostChange didn't work very consistently. (And was secretly hoping it would be nominated for the next Static Ability). I can take a look at some point and see what it's trying to do.

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 13:28
by Sloth
friarsol wrote:
Sloth wrote:Sorry to bring up this thread again, but I noticed today that the CostChange keyword doesn't work anymore. Could it be rellated to you're work Sol?
I'm not sure. I always thought CostChange didn't work very consistently. (And was secretly hoping it would be nominated for the next Static Ability). I can take a look at some point and see what it's trying to do.
I think it's the last keyword BeachedAs left us behind with. It definitely has to be rewritten at some point. :D

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 19:13
by Sloth
I did some testing and it looks like getSpellCostChange doesn't get used when I cast a spell.

I actually think about rewriting this (using static effect), but the function will basically stay the same (the params being a spellability and a manacost and returning a manacost). Maybe you can take a look at your cost code Sol and find out, if that is still the best solution.

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 20:12
by Sloth
I just did a test for the AI and cost change works (at least Sphere of Resistance and Frogmite).

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 22:22
by friarsol
I think the functions staying the same is ok for now, we can improve things on the Cost side as a separate portion.
I see Cost_Payment.changeCost() being called from playSpellAbility(). And it seems like that's the path a Spell would come down? It's possible the new CostMana handles the CostChange just enough differently to not be functional, so I think you may be right that this is where the issue arises from. I can put the UnlessCost stuff on hold and see if I can get it resolved next.

Edit: Ah I see the issue. I grab the adjustedMana amount, but never actually use it for anything. Fix coming soon. I believe we still suffer from the issue where CostChanging doesn't add to X Mana Costs, but that's something we can look into once it's rewritten.

Re: Cost Reorganization

PostPosted: 05 Sep 2011, 23:24
by Max mtg
http://svn.slightlymagic.net/websvn/dif ... &peg=10263

Code: Select all
               if (mana != "0") {    // 11/15/10 use getTotalMana() to account for X reduction
This will always compute to true. Except if you are comaring values that are stored on the same address in memory.
Use "0".equals(mana) instead

A simple console app to check this out:
Code: Select all
class ExampleProgram {
  public static void main(String[] args) throws java.io.IOException {
    System.out.print("Type s: ");
    char c = (char) System.in.read();
    String s = new String(new char[]{c});
    System.out.println("I'm a Simple Program");
    System.out.println( "\"0\".equals(s) => " + "0".equals(s));
    System.out.println( "\"0\" == s => "+ ("0" == s));
  }
}

Re: Cost Reorganization

PostPosted: 06 Sep 2011, 08:38
by Sloth
I've tested in R10278 and CostChange still isn't applied (tested Sphere of Resistance, Frogmite and Animar, Soul of Elements).

Re: Cost Reorganization

PostPosted: 07 Sep 2011, 02:30
by friarsol
Sloth wrote:I've tested in R10278 and CostChange still isn't applied (tested Sphere of Resistance, Frogmite and Animar, Soul of Elements).
Ah, I missed the ! sign when switching to the .equals() statement. I just tested it and it works again. The only thing that doesn't work is for cards with ManaCost = 0. This is because no Mana element exists in the cost currently.

Not sure the best way to handle this quite yet, but I'll get back to it soon.