The most likely situation is that you are no longer classified as a TO for one reason or another. If you haven't run an event and got your TO status from being a L1+ judge, those expired relatively recently due to policy changes. The login screen on WER is setup to only allow TOs to access the program.
There are currently no plans I've heard of that will allow judges to access WER through the login system. Currently, I use one of a few DCI#/password combinations of other TOs who I regularly work with as a method to get into the system.
Check your Windows Updates under the optional updates, install _all_ updates that say ".NET framework", even if they're older versions. (unlike a lot of language frameworks, different versions are not necessarily compatible with each other)
While you're doing that, reinstall WER to be safe.
Okay so I went to the midnight release of this at my local GameStop and picked up Portal and played it for several hours and picked it back up today after some sleep. However, I've gotten to a point in the game where I'm generally concerned about how to proceed. For those who have gotten far enough or beaten I'd like a little help, if you can. I'm late into Chapter 6;
I'm going through the basement. I've used the bounce gel a couple of times. And I'm at a part where I've climbed down onto a platform. There are three or four pillars, and a door on the other side of the room. There is no way for me to walk there, as there is water between us. There are a couple of panels on my side to put the portals, but I have yet to see any panels on the other side of the room, or anywhere at all. I use the word 'room' lightly because it's still under ground. The exit is also very, very high up. If anyone knows what I'm talking about please give me some tips.
There should be a scaffolding that you can walk on to get over to the pillars. Once your there, the path you need to take brings you up, not to that other door.
You're pretty early into this section, but unlike the parts of the game before this, you're dealing with a lot less guidance when it comes to the between-puzzle movement. You'll be shooting some very long portals here and moving around a lot.
The PT change may be so that they can go back to making the PTQ win a major reward in two ways: PT invite, plus a trip to someplace nice. PTs in San Juan or Honolulu (from years past) just don't make sense as a public attraction as they were trying to move PTs towards this year.
That mailing that they did was a special promotion for judges over a period of a couple months. Essentially, it was "play in an FNM and get a Meddling Mage. Play in some more and get the wishes. Get a new location setup with FNM and get some events going there, and you'll get some number of fetches for it."
There has been talk of an actual "judge rewards" system being implemented in the past 6 months or so, to slightly counteract the contraction of events which judge promos are being given for, but there is nothing official about that as of yet.
As far as I'm aware [I'm kinda shaky on it myself], once you're at least a Level 1 DCI-Sanctioned Judge, whenever you judge an event like a Pro Tour/Grand Prix, or higher, you get a pack of Judge foils as part of your payment. It's not like the MPR used to be, where you judge X events and get mailed a foil for every X events.
That's essentially correct. They are currently given out for Nationals, Grand Prix, and Pro Tours. For a period of about a year, they were also given out for more regional events like SCG 5ks, MMS Qualifiers, etc., but that was shut down as of this year.
This is either really easy, or just next to impossible to do, but I can't find out which.
Let's say I have a program which accesses several different databases to get it's information. Let's call the classes that do the individual accessing DAO_1, DAO_2, etc. Each of these classes extends an interface/abstract class, called "DAO". So, pretty straightforward polymorphism here.
What I want to do is two things:
- Remove the concrete DAO classes themselves from the main codebase. (so, have them be their own .jar files)
- Have the program both find and access these .jars at runtime.
The main reasoning for this (besides the "to see if I can" factor) is that there are some DAO objects that are by-default used universally, but there are others which are either rarely used or ones which are special requests by users to have. By separating them, I:
- Shrink my primary code base and shipping program size by about 15-20%
- Diversify my update options (a bug fix doesn't mean a full program recompile/redownload)
- Potentially give a route for others to implement their own DAO interfaces.
Does anyone know of a solid way of accomplishing this?
I remember hearing a few months back that some sleeve companies were making their sleeves just a tad smaller. The reasoning was specifically to reduce that wear that you get with cards being in sleeves - not normal no-sleeve play wear, but the wear that makes foils get those scuff marks on them, which comes from the sleeves giving room for cards to shift around in the sleeves.
I won't argue on points, but there is something firefox added recently (I believe some 3.6 builds had it) that may interest you:
Hit Command+Shift+E (I assume this is CTRL+Shift+E in Windows) and you'll get an interesting interface which is essentially a grouping system for multiple groups of tabs. On a mac, this is also the button on the far right of all tabs.
I will say that I get what you're saying on the keyboard shortcuts being different on different OSs; I actually work with three different laptops daily, each with different placements of the CTRL/Command key. (one of the PCs has CTRL as the furthest-right, the other has a function key) I'd honestly just say that this is something that you need to force yourself to just work with. The incorrect entries (accidentally pressing CTRL+N on a mac or ALT+N on PC) don't really affect anything, so it's something where doing it wrong is just something I occasionally get hit with, and the adjustment remains when I use that machine the rest of the day.
$120 (+ a Mana Vault) for a half share on a Mox Sapphire with my roommate, so the group I was around had a Sapphire for Vintage events. Normally, I generally don't straight-up buy cards, (most my duals/FoW/Workshops/other expensive cards I have/have had are via trades) but this one was just an exception because I had the money available at the time.
This is just some random jumbling of thoughts on this code. Fair warning.
---
When you are working with a limited set of possibilities of values, you can make a data type called an enumerated type. Your use of "fetch"/"land"/"spell" would work well here. So, you could have code like this:
public enum CardType {
Fetch, Land, Spell
}
and from there use those wherever you currently use strings. Your relevant ArrayLists can just be changed into ArrayList<CardType> as well. When you use it in your code, you can just do "CardType.Fetch" everywhere you have the strings now.* By doing this, the big thing is that you avoid any issues coming from misspelling the words or mis-capitalizing; also, you can easily add new card types later, if you had the need to.
*there is a way to do it without the "CardType." in front, but I wouldn't recommend it here, as it is useful for context in the code as to what that is referring to.
---
When you're shuffling the deck, I know that instinctively you want to randomize multiple times like you would IRL, but programmatically, doing it more than once is redundant. In fact, if I recall correctly the article that discussed this, Collections.shuffle() does the same kind of randomization as MTGO's shuffling algorithm. (when it first was released, at least)
---
One thing you want to avoid in coding is having the same code written in multiple locations. This is simply because that, if you want to change how a piece of code does something, you don't want to go around and change it in several places, potentially missing a location.
The reason I bring this up is that you have two locations where the action of drawing a card is handled: in the "drawHand" method and the "drawCard" method. There's two ways you make this more efficient:
1. drawHand calls drawCard when it wants to draw a card.
public void drawHand() {
for (int h = 0; h < maxHandSize; h++)
drawCard();
}
public void drawCard() {
hand.add(deck.remove(0));
}
2. Have one method called "draw", which draws cards. It takes, as input, the number of cards to draw. Any time you need to draw a number of cards, you just do so through this one method.
public void draw(int numCards) {
for (int h = 0; h < numCards; h++)
hand.add(deck.remove(0));
}
---
An important thing to note in Java, as you have this in your code and it won't work as you expect.
You would expect that "Match" would be displayed, but you'll get "No Match". This is because in Java, when equality (==) is tested on an Object (anything that isn't an int, double, boolean, long, short, float, byte, or char) you are comparing the memory locations of those objects, and not those objects themselves. Since you are creating a memory location with "Sentence" in it twice (on the first line, and again on the second) the locations don't match, and you'll get the else statement.
To fix this, every object has a method in it called .equals(); this is the method that tests the values of the objects, rather than the memory locations. Fixing the above code, it would look like this.
String str = "Sentence";
if (str.equals("Sentence"))
System.out.println("Match");
else
System.out.println("No Match");
---
Another random thing: in both endGame() and runGames(), you are checking "gameCount < simsToRun", and doing slightly different things based on the result. I believe, the way this runs, the if() in runGames() never returns true, as it is continuously checked in the endGame() if statement before it ever is done in the runGames() method.
---
Want a cool trick in Java? All objects have implicit methods inside them due to the structure of Java classes. (.equals() is one of these) If you do System.out.println(obj), where "obj" is some random object class, what actually happens is that Java searches for a method in the class called "public String toString()" and displays whatever is returned from that method. If it doesn't find that class, it goes to whatever class "obj" _inherits_ from.
For example, if ArrayList (for some reason) didn't have a toString() method, Java would look in the methods that "AbstractList" has, as ArrayList extends that class; it keeps going higher in this way, until it reaches the "Object" class, which all classes in Java extend.
So, if I were to have this code:
public Deck deck = new Deck([some variables]);
System.out.println(deck);
What would be displayed would be something along the lines of "Deck@3e25a5"; essentially, the name of the class, and the memory location of the class. This is what Object's toString() method does, as Deck does not have such a method in it.
Now, why do I bring all this up? showZones looks like a perfect candidate to be a toString() method. Hint: "\n" in a string does a newline in the console.
---
You probably don't need to have variables that are incrementing whenever you sac a fetch or play a land, as that information is already there in where certain cards are in various zones.
fetchesUsed = the number of fetchlands in the graveyard.
landsInPlay = the number of fetchlands + lands in play.
landDropsMissed = the number of turns - the number of lands in play.
---
This entire codebase would probably look a lot cleaner if you made a few classes, rather than just bunching everything up in one. For instance, let me just write a dummy setup for this:
public class Main {
public static void main(String[] args) {
for (int i=0;i<numGames;i++) {
// The constructor for Deck just builds the deck, shuffles it, and prepares it.
Deck d = new Deck([some variables]);
// Run some turns
for (int j=0;j<numTurnsToPlay; j++)
// This method draws a card, plays fetch/land based on an variable set in the constructor. (i.e. the preference is made when the deck is created)
d.takeTurn();
// This is the implicit toString() call; here, we just want the output to be the stats of the lands played, and any other useful pieces of informaiton.
System.out.println(d);
}
}
}
public class Deck {
...
// Some variables are here for holding things like the deck.
public enum CardType {
Fetch, Land, Nonland // Nonland, just because that is more relevant to this testing setup than "spell"
}
public Deck([some variables]) {
...
// Sets relevant variables, puts those variables into a state of being ready for turn 1 of a game.
}
public void takeTurn() {
...
// Draws a card, plays the turn based on variables set in the constructor
}
public String toString() {
...
// Creates and returns a string to be displayed, which includes all the relevant information you want on the deck and it's state.
}
...
// Some other helper methods, such as drawing a card, shuffling the deck, etc.
}
Benefits:
- You don't need to end a game in the code and reset things: you're simply just making a new deck each time.
- It's very easy to change info on what the contents of the deck that is being tested.
- You could test things much more by making changes to the main method. For instance, I could save the finished decks when I go through the loop, and later average the number of lands played in each simulation. Then, I could run another for loop worth of simulations, this time with different variables used. (say, 8 fetches out of 24 lands in one simulation set, 12 fetches in another) Then, I can compare those all in just one running of the program.
Yahoo Japan Auction is far better than the stores. You'll find deals, but they will be few and far between. You'll mostly find overpriced T2.
Post Hobby is far better in Akihabara. Ogre in Tsudanuma is even better.
...but know your Legacy prices; when I was there in '08, I had some insane deals offered to me for some Legacy/Vintage cards from a Yellow Sub in Osaka. I think I made $150 from that one $250 purchase, just going back to the states and selling later.
WotC provides a standardized decklist here that you could use your PDF reader's annotation features to write directly on and print off of.
If you just want to print off a Word document of your decklist, I haven't heard of a TO that would not allow this, but three pieces of advice, from someone who has read their fair share of these:
- Use the full page. Don't make it a half-page decklist and especially don't only hand in a half-sheet of paper.
- Use a larger font than normal. Judges can read 12 pt. font, but you have the room on the decklist for somewhat larger, so why not?
- Don't forget to put your name on the decklist.
There are currently no plans I've heard of that will allow judges to access WER through the login system. Currently, I use one of a few DCI#/password combinations of other TOs who I regularly work with as a method to get into the system.
While you're doing that, reinstall WER to be safe.
There should be a scaffolding that you can walk on to get over to the pillars. Once your there, the path you need to take brings you up, not to that other door.
You're pretty early into this section, but unlike the parts of the game before this, you're dealing with a lot less guidance when it comes to the between-puzzle movement. You'll be shooting some very long portals here and moving around a lot.
That mailing that they did was a special promotion for judges over a period of a couple months. Essentially, it was "play in an FNM and get a Meddling Mage. Play in some more and get the wishes. Get a new location setup with FNM and get some events going there, and you'll get some number of fetches for it."
There has been talk of an actual "judge rewards" system being implemented in the past 6 months or so, to slightly counteract the contraction of events which judge promos are being given for, but there is nothing official about that as of yet.
That's essentially correct. They are currently given out for Nationals, Grand Prix, and Pro Tours. For a period of about a year, they were also given out for more regional events like SCG 5ks, MMS Qualifiers, etc., but that was shut down as of this year.
Let's say I have a program which accesses several different databases to get it's information. Let's call the classes that do the individual accessing DAO_1, DAO_2, etc. Each of these classes extends an interface/abstract class, called "DAO". So, pretty straightforward polymorphism here.
What I want to do is two things:
- Remove the concrete DAO classes themselves from the main codebase. (so, have them be their own .jar files)
- Have the program both find and access these .jars at runtime.
The main reasoning for this (besides the "to see if I can" factor) is that there are some DAO objects that are by-default used universally, but there are others which are either rarely used or ones which are special requests by users to have. By separating them, I:
- Shrink my primary code base and shipping program size by about 15-20%
- Diversify my update options (a bug fix doesn't mean a full program recompile/redownload)
- Potentially give a route for others to implement their own DAO interfaces.
Does anyone know of a solid way of accomplishing this?
Hit Command+Shift+E (I assume this is CTRL+Shift+E in Windows) and you'll get an interesting interface which is essentially a grouping system for multiple groups of tabs. On a mac, this is also the button on the far right of all tabs.
I will say that I get what you're saying on the keyboard shortcuts being different on different OSs; I actually work with three different laptops daily, each with different placements of the CTRL/Command key. (one of the PCs has CTRL as the furthest-right, the other has a function key) I'd honestly just say that this is something that you need to force yourself to just work with. The incorrect entries (accidentally pressing CTRL+N on a mac or ALT+N on PC) don't really affect anything, so it's something where doing it wrong is just something I occasionally get hit with, and the adjustment remains when I use that machine the rest of the day.
---
When you are working with a limited set of possibilities of values, you can make a data type called an enumerated type. Your use of "fetch"/"land"/"spell" would work well here. So, you could have code like this:
public enum CardType {
Fetch, Land, Spell
}
and from there use those wherever you currently use strings. Your relevant ArrayLists can just be changed into ArrayList<CardType> as well. When you use it in your code, you can just do "CardType.Fetch" everywhere you have the strings now.* By doing this, the big thing is that you avoid any issues coming from misspelling the words or mis-capitalizing; also, you can easily add new card types later, if you had the need to.
*there is a way to do it without the "CardType." in front, but I wouldn't recommend it here, as it is useful for context in the code as to what that is referring to.
---
When you're shuffling the deck, I know that instinctively you want to randomize multiple times like you would IRL, but programmatically, doing it more than once is redundant. In fact, if I recall correctly the article that discussed this, Collections.shuffle() does the same kind of randomization as MTGO's shuffling algorithm. (when it first was released, at least)
---
One thing you want to avoid in coding is having the same code written in multiple locations. This is simply because that, if you want to change how a piece of code does something, you don't want to go around and change it in several places, potentially missing a location.
The reason I bring this up is that you have two locations where the action of drawing a card is handled: in the "drawHand" method and the "drawCard" method. There's two ways you make this more efficient:
1. drawHand calls drawCard when it wants to draw a card.
public void drawHand() {
for (int h = 0; h < maxHandSize; h++)
drawCard();
}
public void drawCard() {
hand.add(deck.remove(0));
}
2. Have one method called "draw", which draws cards. It takes, as input, the number of cards to draw. Any time you need to draw a number of cards, you just do so through this one method.
public void draw(int numCards) {
for (int h = 0; h < numCards; h++)
hand.add(deck.remove(0));
}
---
An important thing to note in Java, as you have this in your code and it won't work as you expect.
Let's say I have this code:
String str = "Sentence";
if (str == "Sentence")
System.out.println("Match");
else
System.out.println("No Match");
You would expect that "Match" would be displayed, but you'll get "No Match". This is because in Java, when equality (==) is tested on an Object (anything that isn't an int, double, boolean, long, short, float, byte, or char) you are comparing the memory locations of those objects, and not those objects themselves. Since you are creating a memory location with "Sentence" in it twice (on the first line, and again on the second) the locations don't match, and you'll get the else statement.
To fix this, every object has a method in it called .equals(); this is the method that tests the values of the objects, rather than the memory locations. Fixing the above code, it would look like this.
String str = "Sentence";
if (str.equals("Sentence"))
System.out.println("Match");
else
System.out.println("No Match");
---
Another random thing: in both endGame() and runGames(), you are checking "gameCount < simsToRun", and doing slightly different things based on the result. I believe, the way this runs, the if() in runGames() never returns true, as it is continuously checked in the endGame() if statement before it ever is done in the runGames() method.
---
Want a cool trick in Java? All objects have implicit methods inside them due to the structure of Java classes. (.equals() is one of these) If you do System.out.println(obj), where "obj" is some random object class, what actually happens is that Java searches for a method in the class called "public String toString()" and displays whatever is returned from that method. If it doesn't find that class, it goes to whatever class "obj" _inherits_ from.
For example, if ArrayList (for some reason) didn't have a toString() method, Java would look in the methods that "AbstractList" has, as ArrayList extends that class; it keeps going higher in this way, until it reaches the "Object" class, which all classes in Java extend.
So, if I were to have this code:
public Deck deck = new Deck([some variables]);
System.out.println(deck);
What would be displayed would be something along the lines of "Deck@3e25a5"; essentially, the name of the class, and the memory location of the class. This is what Object's toString() method does, as Deck does not have such a method in it.
Now, why do I bring all this up? showZones looks like a perfect candidate to be a toString() method. Hint: "\n" in a string does a newline in the console.
---
You probably don't need to have variables that are incrementing whenever you sac a fetch or play a land, as that information is already there in where certain cards are in various zones.
fetchesUsed = the number of fetchlands in the graveyard.
landsInPlay = the number of fetchlands + lands in play.
landDropsMissed = the number of turns - the number of lands in play.
---
This entire codebase would probably look a lot cleaner if you made a few classes, rather than just bunching everything up in one. For instance, let me just write a dummy setup for this:
public class Main {
public static void main(String[] args) {
for (int i=0;i<numGames;i++) {
// The constructor for Deck just builds the deck, shuffles it, and prepares it.
Deck d = new Deck([some variables]);
// Run some turns
for (int j=0;j<numTurnsToPlay; j++)
// This method draws a card, plays fetch/land based on an variable set in the constructor. (i.e. the preference is made when the deck is created)
d.takeTurn();
// This is the implicit toString() call; here, we just want the output to be the stats of the lands played, and any other useful pieces of informaiton.
System.out.println(d);
}
}
}
public class Deck {
...
// Some variables are here for holding things like the deck.
public enum CardType {
Fetch, Land, Nonland // Nonland, just because that is more relevant to this testing setup than "spell"
}
public Deck([some variables]) {
...
// Sets relevant variables, puts those variables into a state of being ready for turn 1 of a game.
}
public void takeTurn() {
...
// Draws a card, plays the turn based on variables set in the constructor
}
public String toString() {
...
// Creates and returns a string to be displayed, which includes all the relevant information you want on the deck and it's state.
}
...
// Some other helper methods, such as drawing a card, shuffling the deck, etc.
}
Benefits:
- You don't need to end a game in the code and reset things: you're simply just making a new deck each time.
- It's very easy to change info on what the contents of the deck that is being tested.
- You could test things much more by making changes to the main method. For instance, I could save the finished decks when I go through the loop, and later average the number of lands played in each simulation. Then, I could run another for loop worth of simulations, this time with different variables used. (say, 8 fetches out of 24 lands in one simulation set, 12 fetches in another) Then, I can compare those all in just one running of the program.
...but know your Legacy prices; when I was there in '08, I had some insane deals offered to me for some Legacy/Vintage cards from a Yellow Sub in Osaka. I think I made $150 from that one $250 purchase, just going back to the states and selling later.
If you just want to print off a Word document of your decklist, I haven't heard of a TO that would not allow this, but three pieces of advice, from someone who has read their fair share of these:
- Use the full page. Don't make it a half-page decklist and especially don't only hand in a half-sheet of paper.
- Use a larger font than normal. Judges can read 12 pt. font, but you have the room on the decklist for somewhat larger, so why not?
- Don't forget to put your name on the decklist.