Developing Bugs
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Developing Bugs
by Max mtg » 08 Oct 2012, 08:36
Most probably.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
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.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Developing Bugs
by friarsol » 08 Oct 2012, 12:21
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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Developing Bugs
by mcrawford620 » 08 Oct 2012, 22:46
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
- mcrawford620
- Posts: 112
- Joined: 25 Jun 2012, 16:59
- Has thanked: 55 times
- Been thanked: 25 times
Re: Developing Bugs
by ArsenalNut » 08 Oct 2012, 22:53
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.
So many cards, so little time
-
ArsenalNut - Posts: 512
- Joined: 08 Jul 2011, 03:49
- Has thanked: 27 times
- Been thanked: 121 times
Re: Developing Bugs
by friarsol » 08 Oct 2012, 23:15
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.
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
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Developing Bugs
by Max mtg » 09 Oct 2012, 05:31
Thanks, that's fine for now.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.
My version does not compile at all atm, so I am not able to fix it any better now.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Developing Bugs
by RumbleBBU » 09 Oct 2012, 06:52
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.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.
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.
Re: Developing Bugs
by Max mtg » 09 Oct 2012, 08:51
Some bugs are the fruit of removal of singletons and global variables forge has used for years.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 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.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Developing Bugs
by RumbleBBU » 09 Oct 2012, 11:01
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.
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.
Re: Developing Bugs
by RumbleBBU » 11 Oct 2012, 06:43
Ok, after slight inspection, I can now confirm that this is indeed the case.Max mtg wrote:Most probably.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
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.
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)?
Re: Developing Bugs
by Max mtg » 11 Oct 2012, 08:21
Let me please see the code today.
With some luck I'll be able to roll out the lightweight player and store deck there.
With some luck I'll be able to roll out the lightweight player and store deck there.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Developing Bugs
by RumbleBBU » 15 Oct 2012, 05:28
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:
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.
- Code: Select all
lstHands.get(0).getParentCell().addDoc(lstHands.get(i));
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.
Re: Developing Bugs
by Chris H. » 15 Oct 2012, 11:34
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:...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.
- Code: Select all
lstHands.get(0).getParentCell().addDoc(lstHands.get(i));
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.
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Developing Bugs
by RumbleBBU » 15 Oct 2012, 11:35
(Me has a classic "DUH!" moment...)
I had read about that and still forgot it!
I had read about that and still forgot it!
Re: Developing Bugs
by Doublestrike » 16 Oct 2012, 00:18
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.
- 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.
Hopefully that won't be a big problem after release.
If you were interested...this lineRumbleBBU wrote:lstHands.get(0).getParentCell().addDoc(lstHands.get(i));
- 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.
---
A joke is a very serious thing.
A joke is a very serious thing.
-
Doublestrike - UI Programmer
- Posts: 715
- Joined: 08 Aug 2011, 09:07
- Location: Bali
- Has thanked: 183 times
- Been thanked: 161 times
Who is online
Users browsing this forum: No registered users and 85 guests