Collectible Card Game Headquarters

Rob Cashwalker wrote:I don't think Mercurial Eclipse is a good idea. You have to signup with JavaForge.com just to download it.

You don't have to there is a public eclipse update repo at http://cbes.javaforge.com/update and it's on their site!

Snacko wrote:

Rob Cashwalker wrote:I don't think Mercurial Eclipse is a good idea. You have to signup with JavaForge.com just to download it.

You don't have to there is a public eclipse update repo at http://cbes.javaforge.com/update and it's on their site!

Link is DOA.

http://javaforge.com/project/HGE#download

Requires login.

The register thing is old and obsolete. You don't have to register just to download it via update repositories.

Didn't register, pop into update repositories, download, profit ?

And yes the repository is non browsable as they use a blank page.

Update process failed in the middle, not being able to deal with some certificate rejection...

Regarding "reducing waste", I have started giving some thought to refactoring parts of the code and removing obselete code. Since I am new around here I wanted to toss some ideas off the top of my head before I start doing anything too invasive.

1. Remove the old Quest*.java code. I have been cleaning it up, but it looks like it has not been used for a awhile since it has been superseded.
2. Remove the old GUI. Do people use the old GUI much?
3. Consolidate the GenerateDeck code to some extent. While the classes are similar there is no use of inheritance or interfaces.
4. Could the minlog code (400 lines) be replaced with the use of java.util.log?
5. Remove org.jdesktop. This functionality is included in the Java 1.6 libraries. Of course this would have to wait until Forge dropped 1.5 compatibility.

Anything else? Thoughts?

jendave wrote:Regarding "reducing waste", I have started giving some thought to refactoring parts of the code and removing obselete code. Since I am new around here I wanted to toss some ideas off the top of my head before I start doing anything too invasive.

1. Remove the old Quest*.java code. I have been cleaning it up, but it looks like it has not been used for a awhile since it has been superseded.
2. Remove the old GUI. Do people use the old GUI much?
3. Consolidate the GenerateDeck code to some extent. While the classes are similar there is no use of inheritance or interfaces.
4. Could the minlog code (400 lines) be replaced with the use of java.util.log?
5. Remove org.jdesktop. This functionality is included in the Java 1.6 libraries. Of course this would have to wait until Forge dropped 1.5 compatibility.

Anything else? Thoughts?

1. Old quest java code had been left around to help people using an old Quest file convert to a new one. I think at this point if the last Forge you played was 4 months ago and you are finally upgrading, it's not unreasonable to ask that you start a new Quest.

2. I think some people still use Gui3 due to things not working right on Gui4. We could probably ask on the forums how many people still use Gui3. The only thing Gui2 is used for is initialization. I'm not sure why we need to use it at all as opposed to Gui4. I'd love to see a completely new Gui in Swing. We had a user come in and design some possibilities some time ago. A new Gui would allow us to combine much of the Player info area, and move the Mana Pool off the Battlefield. Noone here has done much UI work in general I think. I've done a fair amount, but mostly on the Web front, so it doesn't translate over as much.

3. Sounds reasonable.

4. I'm not even sure if the minlog is used for anything? I don't know how long it's been around, but it'd be good to have an Event Log that was actually used and available through the UI. Someone else should probably comment regarding this.

5. I definitely don't have a problem moving to 1.6 compatibility. Java 1.6 came out 5 years ago, I think the world is finally upgrading from it's IE 6 days, so I think it's reasonable that we stop supporting 1.5 (which came out 7 years ago!) for the future good of it all.

I'm working on the cleanup efforts as well.

I spent last evening removing ReadBoosterPack from the CardShop. (see quest commentary thread in main section for important question I have for discussion)

3 - On my list. I know I have the land-counting code copied in 5 different classes right now... I want to fix that, at the very least. The old deck generators still use archaic functions, and we've been meaning to remove them anyway.

5 - didn't we already break 1.5 with the last release?

Dave, thanks to your maven script, we now have a huge laundry list of bits and pieces we can fix that will ultimately reduce our footprint. The previous betas had 11 MB jar files, we're now down to 8, so we're on the right track.

Rob Cashwalker wrote:
5 - didn't we already break 1.5 with the last release?

Dave, thanks to your maven script, we now have a huge laundry list of bits and pieces we can fix that will ultimately reduce our footprint. The previous betas had 11 MB jar files, we're now down to 8, so we're on the right track.

Great. I'll update the Maven script to compile against 1.6. I'll start looking at removing the org.jdesktop code use the standard library version.

I'll glad that Maven reporting features help!

jendave wrote:5. Remove org.jdesktop. This functionality is included in the Java 1.6 libraries...

May have spoken too soon on this one... Some classes are included in 1.6 but not the ones Forge uses . Still I can remove the code and use a dependency instead. That will reduce the code maintenance.

Braids -
Back to one of your issues.... I know you have a number of small changes to lots of code, like adding Serializing code to just about everything. I think that sort of preparatory stuff can be done in the live branch, since it's minimally invasive. Static references of variables and arrays, is one of the biggest issues listed in the Maven reports. I can't see how too much harm can come from fixing that. Given the example, all future "static reference" needs can follow the same patterns.

The biggest participation I have in this process is trying to break it after you make your changes. Having said that, I want to encourage each of you in your work to make Forge better!

Rob Cashwalker wrote:5 - didn't we already break 1.5 with the last release?

i specifically put in code to support java 5 in the release, but someone else might have broken it.

if we're going with java 6, we should find the weird code i wrote that uses reflection, and use ordinary method calls and field use instead.

Rob Cashwalker wrote:Braids -
Back to one of your issues.... I know you have a number of small changes to lots of code, like adding Serializing code to just about everything. I think that sort of preparatory stuff can be done in the live branch, since it's minimally invasive.

ok, thanks. i was planning on getting to that once i've put down another project i was toying with while waiting for the beta.

Rob Cashwalker wrote:Static references of variables and arrays, is one of the biggest issues listed in the Maven reports. I can't see how too much harm can come from fixing that. Given the example, all future "static reference" needs can follow the same patterns.

which patterns? i'm a little confused. i know i changed a lot of direct access into method calls; that was to prepare to eventually move all static game state data into nonstatic fields of a class that could be accessed statically. if you search the AI Evolution topic for Unstatic, you'll see more about that.

less over your head version: there could be a GameState class that houses fields that were formerly static. it has no static fields of its own. then there is a gatekeeper class called Unstatic, like being undead, which has a static method to get the "current" GameState instance.

besides AllZone, there are a few weird places where static fields are used and probably shouldn't be. Phase is one of them. i can't recall the other at the moment... was it Combat? i'm too tired to check right now.

Jaedayr wrote:The biggest participation I have in this process is trying to break it after you make your changes. Having said that, I want to encourage each of you in your work to make Forge better!

so. totally. needed. thank you.
i don't have a lot of patience for testing. i usually see if it starts up, play two turns of constructed, claim success, and commit. as time goes by, i'll be running unit tests before starting it up, so i will get better.

Braids wrote:besides AllZone, there are a few weird places where static fields are used and probably shouldn't be. Phase is one of them. i can't recall the other at the moment... was it Combat? i'm too tired to check right now.

Constant is almost nothing but static String arrays with single elements. Some of the things in there get modified during runtime, so they're not really constant...