Java: CharSi Update #22

Creating the GUI for the charm generator wasn't too difficult. It basically consisted of borrowing GUI pieces from other parts of the program. Since I've been doing that all along the page was up in a very short amount of time.


As expected the difficult part was creating the listeners behind the nice GUI interface. Many were fairly simple, for example the Clear JButton and Completed Items JList listener. On the other hand, other pieces were a bit more time consuming.

The list of prefix and suffixes came from a guide from the Diii.net site. Using this as my main information source I was able to setup the lists of possible values. From here creating the listeners was 75% of the entire page. First the selected item is obtained from the appropriate JList, then in the listener it is compared to all the possible options for that JList. Unfortunately the values possible differ with the size of the charm so once the mod is located then the program looks to see which JRadioButton is selected (and whose boolean flag was set to "true"). Once the charm type is identified then the String that will be tacked onto the end of the current display in the JTextArea is created.

if(mod.compareTo(AZURE) == 0){
if(smallFlag){
value = DetermineRangeValue(3,5,"Cold Resist %");
newMod = newMod.concat("Cold resist +" + value + "%\r\n");
}
if(largeFlag){
value = DetermineRangeValue(4,7,"Cold Resist %");
newMod = newMod.concat("Cold resist +" + value + "%\r\n");
}
if(grandFlag){
value = DetermineRangeValue(7,15,"Cold Resist %");
newMod = newMod.concat("Cold resist +" + value + "%\r\n");
}
}

When the Save JButton is selected a final check is done before the item is actually saved. It is possible to have both the suffix and prefix related to the same elemental damage type. Therefore a check must be made when the Save JButton is pressed before the charm is actually saved to ensure that these values are added together into the same mod line.

if(compare.indexOf("poison damage") )

The text in the JTextArea is rewritten if this is indeed the case and then the file is saved. Once saved the charms can then be added to the virtual character via a new tab in the Equipment page.

Adding and removing charms works the same way as all of the other equipment pages. The only change is the same charm may be added multiple times if desired. This avoids the need to create more than one type of charm and saves the user the hassle of scrolling through a long list of charms looking for just one more of a certain type of skiller.

One thing that was essential to this page is the charm counter display. This keeps track of how many charms of each type is already equipped to the virtual inventory and how many inventory spaces are left open. Before a charm can be added a check is made to ensure there is in face room for this charm. It can't be done on remaining spaces alone as grand charms can't be put in horizontally so only 10 total area allowed, for example.

grandFree = grandAllowed - grandCount;
if(charmSize == 3 && (grandFree == 0 || totalCount == 2))
add = false;

The checking method itself returns a boolean that is true unless it fails one of the checks such as above. It was actually easier to setup than I thought, as I was expecting to have to create an array of arrays that would replicate the physical inventory that I would fill in as charms were added. Not the best way to deal with the situation, so I'm glad the equations worked out as a much simpler solution.

Now the virtual character can be fully equipped, both with gear and charms. This includes the Battle.net only charms such as the Hellfire Torch. My next step is to create the ability to save characters so that they can be loaded in a latter program session without having to recreated them each time.