License Changes, and progress report.

I have been hemming and hawing on which open source license to assign Suite GM 4 to. I at first just went with GPL, but after getting burned in GFDL with out magazine efforts, and learning how much more restrictive the GPL is, I've (for now) switched it to the MPL 1.1. I'm still trying to get my head around the dozens of licenses and which is the best map for this. I WANT folks to get it for free, and be able to contribute, fork, whatever, while keeping attribution to the original creator(s) (myself, and anyone else who joins in). I also don't want some commercial fork to come back and harass me. And I would like to leave open the possibility of going commercial with this, but still offer the source code readily. Anyhow, I'll be researching that more over time.

Meanwhile, made a lot of progress. The file reader is getting better and better, and populates anything I want very well. it's abstracted out so very reusable. at least for plain text files. I still haven't managed to get it's XML read file methods to return the data in a format that the Swing components can have in a properly formatted fashion. I moved on after being stuck for days on it.

So, I now have the license agreement dialog populated with any license text from a file named "licenseSuiteGM.txt". Which makes it easy to change the license text by just swapping the file, without having to recompile the app (but the file must remain with the app as part of the license agreement when it's distributed.

I found out why I couldn't get the text to populate, it was because i needed to put the JTextArea.setText(String) AFTER the initComponents() call, I had been putting it before.

Also I created a utility class called DiceRollerUtil. This will accept a number of different combinations for different dice roll returns. rollDie() just accepts one int, which is the max number the die can roll. So a d6 would simply be 6. rollDiceRange() accepts two ints. one min, and one max. min is the lowest possible range (0, 1, 2, whatever), and max is the highest possible). This is likely to be the most frequently called method, and it's possible I will eliminate the others if I don't use them.

There's a third method that might be useless, but I created just in case. It's rollDiceSim(int qty, int min, int max, int mod). It accepts 4 ints. The purpose is to closely map the typical RPG thinking about number generation. An RPGer doesn't always think "2-12", they frequently think 2d6. And/or add modifiers such as 2d6+2. In math terms that translates as 4-14, but maybe it will be easier for gamers when filling out the data entry forms, if it can handle the entries more like: number of dice:__2__ size of die:__6___ Modifier:___+4___ (note that it needs to be able to accept either positive or negative values on the modifier.

We'll see if these methods get used or not. If not, then I'll clean up the class later on.

Anyhow, it's daily progress. UI tweaks a little bit too.

Late not, almost 1:00 am, and have to get up around 6:00 am again. So ciao for now.