Collectible Card Game Headquarters

So, any news? Or do we wait till after next release?

krishkrush wrote:So, any news? Or do we wait till after next release?

I believe Krazy said he was in the middle of moving to a new apartment(?). Don't worry, he'll report when he starts working on it.

friarsol wrote:

krishkrush wrote:So, any news? Or do we wait till after next release?

I believe Krazy said he was in the middle of moving to a new apartment(?). Don't worry, he'll report when he starts working on it.

That's correct. I found a place and have been moving all weekend, but don't have my computer set up yet. I'll be able to work on things soon.

Alright, didn't meant to be pushy. Just asking

Working on adding the support classes now. I'll have that + documentation up soon so people can get started converting the code. I'll post here again when it's available.

Alright, it begins!

Check out the wiki here for instructions (and if you need clarification, ask away): http://www.slightlymagic.net/wiki/Forge:How_to_Get_Started_Developing_Forge#Localization

Here's a sample showing the localization on the splash:



For now, the default language can't be changed from within Forge itself, so the only way to test languages is to set it manually as specified in the wiki. This is intentional for testing purposes and will be fixed when we get everything converted over.

So, uhm, i just start with the regular 1.5.24 or do i need some special version of forge? Sorry if this is a dumb question but as i am no developer and new to this...
Also, what happens when the new version is released? Do i have to start all over again?
And what about that icu4j thingie you mentioned in your first post? Do i need that? I'm just a little nervous about me messing with code

So I had to remove com.ibm.icu as a reference (r27013) as it caused problems for the Android build. That said, it seems that you were only using it for the MessageFormat class, which already lives in java.text. So it doesn't seem to be a necessary reference anyway. Or am I missing something?

krishkrush wrote:So, uhm, i just start with the regular 1.5.24 or do i need some special version of forge? Sorry if this is a dumb question but as i am no developer and new to this...
Also, what happens when the new version is released? Do i have to start all over again?
And what about that icu4j thingie you mentioned in your first post? Do i need that? I'm just a little nervous about me messing with code

Until we programmers are done with implementing the code, there's not much for you to do if you're not comfortable with helping out there. I'll be sure to let you know once it's ready to translate, though.

drdev wrote:So I had to remove com.ibm.icu as a reference (r27013) as it caused problems for the Android build. That said, it seems that you were only using it for the MessageFormat class, which already lives in java.text. So it doesn't seem to be a necessary reference anyway. Or am I missing something?

That's weird. icu4j uses almost the same classes that regular java does, just with a bunch of improvements such as pluralization. I'll see if I can figure out how to fix it. What kind of problems was it causing?

KrazyTheFox wrote:

drdev wrote:So I had to remove com.ibm.icu as a reference (r27013) as it caused problems for the Android build. That said, it seems that you were only using it for the MessageFormat class, which already lives in java.text. So it doesn't seem to be a necessary reference anyway. Or am I missing something?

That's weird. icu4j uses almost the same classes that regular java does, just with a bunch of improvements such as pluralization. I'll see if I can figure out how to fix it. What kind of problems was it causing?

The problem is it adds a lot of additional code to the Forge package that causes it to grow beyond the allowed limit for Android. It's also probably not good to continue to bloat the code for the desktop app either, as it increases the size of the install package for others to download and increases the install time I'd imagine.

Instead of pulling in that dependency, can we just write our own code for anything that java.text.MessageFormat doesn't already give us?

drdev wrote:The problem is it adds a lot of additional code to the Forge package that causes it to grow beyond the allowed limit for Android. It's also probably not good to continue to bloat the code for the desktop app either, as it increases the size of the install package for others to download and increases the install time I'd imagine.

Instead of pulling in that dependency, can we just write our own code for anything that java.text.MessageFormat doesn't already give us?

Ah, I hadn't realized it was such a large dependency. I think there's a way to get only specific parts of it, so I'll see if I can do that instead. It'd be possible to rewrite what we need, but I'd rather not if I can help it.

KrazyTheFox wrote:

krishkrush wrote:So, uhm, i just start with the regular 1.5.24 or do i need some special version of forge? Sorry if this is a dumb question but as i am no developer and new to this...
Also, what happens when the new version is released? Do i have to start all over again?
And what about that icu4j thingie you mentioned in your first post? Do i need that? I'm just a little nervous about me messing with code

Until we programmers are done with implementing the code, there's not much for you to do if you're not comfortable with helping out there. I'll be sure to let you know once it's ready to translate, though.

Ah okay thanks for clarifying this.

drdev wrote:The problem is it adds a lot of additional code to the Forge package that causes it to grow beyond the allowed limit for Android. It's also probably not good to continue to bloat the code for the desktop app either, as it increases the size of the install package for others to download and increases the install time I'd imagine.

Instead of pulling in that dependency, can we just write our own code for anything that java.text.MessageFormat doesn't already give us?

I can package it down to 6.5MB while keeping the functionality we'd need. Unfortunately it's not split up into smaller modules than that. Would this work for us? There's a lot of "gotcha"s when it comes to languages and I feel like trying to manually support that later would come back to bite us. If that's still too big, I can possibly go in and chop up the source code myself, though I don't really have the time to do that at the moment.

I can try it out I guess. We could also try trimming other libraries or parts of the code if needed.

drdev wrote:I can try it out I guess. We could also try trimming other libraries or parts of the code if needed.

I'll give it a shot after this next release. I don't have much time until Saturday for things.