Collectible Card Game Headquarters

RumbleBBU wrote:Could that also be the underlying cause of the Draft game problem observed by Sloth?
viewtopic.php?f=52&t=8029&start=45#p99790

Most probably.

I have to finish removing getXXXPlayer calls from UI and AI, after that I'll pay attention to matchmaking to find a way to launch human vs human or ai vs ai matches.
That involves storing player's decks somewhere bettwen matches and choosing propper deck for the next game in series.

Whoever keeps committing main.properties, can you please put it on your ignore list. I put my cardpics in a separate folder so multiple instances of forge can access them, and it's really annoying to see it conflict every day after a new round of commits.

Updated today and tried to Run from Eclipse, and am getting this:

Code: Select all

java.lang.ExceptionInInitializerError
   at forge.model.FModel.<init>(FModel.java:150)
   at forge.model.FModel.<clinit>(FModel.java:72)
   at forge.view.Main.main(Main.java:48)
Caused by: java.lang.NullPointerException: CardDb has not yet been initialized, run setup() first
   at forge.item.CardDb.instance(CardDb.java:62)
   at forge.deck.DeckSection.set(DeckSection.java:60)
   at forge.deck.Deck.fromSections(Deck.java:198)
   at forge.deck.Deck.fromSections(Deck.java:175)
   at forge.item.PreconDeck.<init>(PreconDeck.java:86)
   at forge.quest.io.PreconReader.read(PreconReader.java:49)
   at forge.quest.io.PreconReader.read(PreconReader.java:1)
   at forge.util.StorageReaderFolder.readAll(StorageReaderFolder.java:99)
   at forge.util.StorageView.<init>(StorageView.java:46)
   at forge.quest.QuestController.<clinit>(QuestController.java:73)
   ... 3 more

I've done a clean and restart of Eclipse, but no luck. Any ideas?

Forge appears to be broken yet again. I get a NPE when I start r17441 inside Eclipse. It is really frustrating that Forge has basically been in a non-working state for the past five days. I understand people are working on major changes but that's why branches were invented!!! You can check in you're partial fixes without affecting the trunk.

Yea, looks like 17439 is instantiating QuestController way earlier than it used to be instantiated, since it's dependent on CardDB to load some data in. (It's specifically complaining about precon decks, but there may be other things QuestController is dependent on.)

Edit: I put a temporary fix in, so it won't create QC until the first time it's requested. Max, feel free to handle this in a different way. I just wanted to have things running.

friarsol wrote:Edit: I put a temporary fix in, so it won't create QC until the first time it's requested. Max, feel free to handle this in a different way. I just wanted to have things running.

Thanks, that's fine for now.
My version does not compile at all atm, so I am not able to fix it any better now.

ArsenalNut wrote::x Forge appears to be broken yet again. I get a NPE when I start r17441 inside Eclipse. It is really frustrating that Forge has basically been in a non-working state for the past five days. I understand people are working on major changes but that's why branches were invented!!! You can check in you're partial fixes without affecting the trunk.

Although I'm loath to admit it, I find I have to agree 100% with what ArsenalNut is saying here. I too was under the impression that it was considered good practice to use branches, and not the trunk, to commit changes that are not quite complete yet and may break core functionality. The situation now is unbearable - SVN and the snapshots have been more or less broken and unplayable ever since the last beta. My last working local codebase (where all major features work as intended) is in fact a copy of the last beta code with my Quest mode modifications thrown in.

At the moment, the SVN version seems to contain several problems (or semi-complete code) introduced by other coders that breaks stuff I really need in order to implement what I'm currently working on, like all of a sudden not being able to edit any quest decks, and it really irks me. My current stance is that I'm postponing any further development on my part until we have a working core codebase again.

RumbleBBU wrote:At the moment, the SVN version seems to contain several problems (or semi-complete code) introduced by other coders that breaks stuff I really need in order to implement what I'm currently working on, like all of a sudden not being able to edit any quest decks, and it really irks me. My current stance is that I'm postponing any further development on my part until we have a working core codebase again.

Some bugs are the fruit of removal of singletons and global variables forge has used for years.
Some people just got used to store everyting in global variables, and this system obviously breaks once codebase needs to evolve.

I cannot perfectly refactor it for everyone and I highly appreciate Sloth and friarsol for being able to fix my errors coming from predicates codebase change and the current activities.


Brought back quest deck editor for you.
http://svn.slightlymagic.net/websvn/rev ... &peg=17447
Very simple. I suppose, you could have it done without my help.

@ArsenalNut, if I use a branch, people will be unaware of changes to come and will commit tons of new code using deprecated or removed routines.

Thanks, Max.

Please don't think I'm being an asshole...at least I'm trying not to come off as one. Yes, I think I can see where you're coming from, and you're making perfectly valid points. Still it makes me sad when the latest SVN versions/snapshots are not really playable for several days. It also makes testing my own code harder when something isn't working right and I don't know whether that is because of something that I've done or because of something that someone else has done...

As for the various problems that fundamental code changes cause, I believe the person who introduced the code change that broke the functionality has the best knowledge to fix them. Yes, now that I see your Quest deck editor fix, it is indeed laughably simple. But it could have taken me a long time to figure that out...

I can understand that Rome wasn't built in a day, and I do greatly appreciate your efforts to make the game better.

Max mtg wrote:

RumbleBBU wrote:Could that also be the underlying cause of the Draft game problem observed by Sloth?
viewtopic.php?f=52&t=8029&start=45#p99790

Most probably.

I have to finish removing getXXXPlayer calls from UI and AI, after that I'll pay attention to matchmaking to find a way to launch human vs human or ai vs ai matches.
That involves storing player's decks somewhere bettwen matches and choosing propper deck for the next game in series.

Ok, after slight inspection, I can now confirm that this is indeed the case.

The following commits have effectively disabled the required "Next Round" functionality in Sealed Deck and Draft gauntlets:

http://svn.slightlymagic.net/websvn/dif ... &peg=17171
http://svn.slightlymagic.net/websvn/dif ... &peg=17171

What do you suggest, how should this be fixed (to be consistent with how deck data is being implemented now)?

Let me please see the code today.
With some luck I'll be able to roll out the lightweight player and store deck there.

Is it just me or is starting new matches broken somehow? With the freshly checked out SVN source, whenever I try start a match (Sealed, Quest, any mode), Eclipse fires up debugger at this line in VMatchUI.java:

Code: Select all

lstHands.get(0).getParentCell().addDoc(lstHands.get(i));

...makes it a bit hard to test what I'm currently trying to code in QuestWinLoseHandler.java when I can't even start a match.

And no, I'm afraid I haven't a clue what should be happening in the quoted line, let alone how to fix it.

And if I go to the match, I get an empty table with no players.

RumbleBBU wrote:Is it just me or is starting new matches broken somehow? With the freshly checked out SVN source, whenever I try start a match (Sealed, Quest, any mode), Eclipse fires up debugger at this line in VMatchUI.java:

Code: Select all

lstHands.get(0).getParentCell().addDoc(lstHands.get(i));

...makes it a bit hard to test what I'm currently trying to code in QuestWinLoseHandler.java when I can't even start a match.

And no, I'm afraid I haven't a clue what should be happening in the quoted line, let alone how to fix it.

And if I go to the match, I get an empty table with no players.

 
I had a similar problem with yesterdays snapshot build but my pristine SVN local copy worked as expected.

Turns out that the older match layout files are incompatible. The original match_default.xml, match_preferred.xml and the match_preferred.xml saved to a different name files have to go.

You can keep your editor_preferred.xml file. But you will have to setup your match view panels using the new match_default.xml file. Once I did this I was good to go.

(Me has a classic "DUH!" moment...)

I had read about that and still forgot it!

Sorry about that guys, but I couldn't find a good way to handle that. Everything else worked very smoothly except for that hiccup.

Hopefully that won't be a big problem after release.

RumbleBBU wrote:lstHands.get(0).getParentCell().addDoc(lstHands.get(i));

If you were interested...this line
- gets the "hand" document at index 0 (which is always the user's)
- retrieves its parent drag cell
- adds the hand document at index i (which hadn't been added to the layout yet) to the parent cell

Long story short, it adds more hands to the existing hand panel. Crashes because in old layouts, index 0 was still empty.