Java: DII Character Simulator

I've started working on the look & feel portion of the Diablo II character simulator program I mentioned earlier. I'm working on this one piece at a time, as I wanted to get the visual layout accomplished first before putting any functionality into the application.



The layout for the skill calculator portion ended up requiring 2273 lines of code. The main reason for this is that for each character type I needed to create and populate 3 JPanels, 30 JComboBoxes and at least 50 JLabels and then combine them together in a GroupLayout manager to display properly. I decided on the GroupLayout manager due to its versatility, I was able to display the JLabels and JComboBoxes in the format I desired. All of the other layout managers were more restrictive as to where these components could be placed and I was looking for a very specific appearance.
GroupLayout is new as of Java Platform 6 so I needed to update my software a bit. A new JRE was downloaded along with updating my browser shortcut to the API reference, as I was using version 5 up until now. I severely doubt I would have been able to create the application display as I did with any other layout manager, at least not as easily as GroupLayout made the process. There was a bit of a learning curve, as up to this point FlowLayouts and GridLayouts were my managers of choice, but I'm happy with the results.

Each of the character displays is generated in its own method and these methods are the reason for the length of the class file. I am considering separating these methods out into their own class files to cleanup the code to make it more compartmentalized, however I will deal with that once the look & feel portion of the application is accomplished.

Next up, the equipment tab appearance.

Java: Concept for DII related application

A while back I saw this post in the DiabloII.net community forum. I really liked the general concept of what the poster was intending to create and thought it would be rather helpful. At the time I was looking for a new Java oriented project and seriously considered starting my own version since the OP was using .NET programming. I decided against it as I didn't want to start a competition between myself and the OP and take away from what the OP was doing.

However it now appears the OP is a bit absent from continuing this project, that and his/her will only work on Windows computers while Java works on all operating systems. So I've decided to try and write my own similar program as there won't be any competition. I won't be telling anyone on the boards until I have some pieces completed. Some of my goals are a bit different and less ambitious so that I have a chance of actually completing it as well.


Above is a concept draft, if you can read my writing of course, of one of the pages of the planned application. Only general layout of the different pages has been seriously considered with some attention to the needed components. I've decided to write the shell of the program first, then add functionality later. The goals of this project are as follows:

1. Search for any normal, set or unique item and equip it to a character (I'm ignoring cracked/damaged/crude items on purpose).
2. Assign appropriate skills to a character and calculate their associated bonus. Basically a skill planner like the German one.
3. Display the true statistics of this character taking into account equipment worn and skills available, to replace the current LCS.

I know I have to deal with rare, magical and runeword items at some point so future goals are:

4. Be able to roll any rare or magical item as if it were dropped ingame, and then equip it to a character.
5. Be able to create any runeword item, while also choosing the base item, and then equip it to a character.
6. Be able to roll any charm as if it were dropped ingame and then place it in character's stash. This includes the Torch and Annilhus.

Obviously 1-3 are going to be done first before I even attempt 4-6. I have general ideas on how to do each part but I need to perform some research in Java to determine the best method. Specifically I need a better information storing method than text files, as used in the AMAS program. There are simply too many mods that can spawn and far too many possible items for text files alone. I'm sure I'll be living in the Statistics forum for a while as well and getting quite a bit of assistance in that regard (never my strong suit when it comes to games). I know this will be a very long project, so wish me luck.

Java: AMAS Update #1

After originally making AMAS, I mentioned I wanted to incorporate it into an installer instead of utilizing a zip file. Well I was rather lax on finishing that goal, but in the meantime I was able to make a few updates to the program itself.

Nothing extremely involved. Several spelling corrections to the text for rune descriptions and runewords, as well as adding a few more recipes to the Horadric Cube section. These changes were fairly minor but did put some finishing touches on the program.

The main change for this newest version release is the addition of an installer program. It was created using the CreateInstall Free program, a piece of freeware. There are more advanced versions of this program but for my needs, something simple is all that is required. Now the program is basically complete unless an idea for another section comes to mind. For now though, I consider this program complete.

Java: Hotline Update #3

This time the changes were drastic to the Hotline call tracking program, and so therefore had to be implemented at the beginning of this month rather than mid-month like last time. There were two requested changes; add two more call option buttons and allow the reports to be run over a day's period rather than only by month. The first change was very simple, as that has been done before, the reporting change however was far more complex.

Daily reports is something I considered when originally building Hotline, and even asked those that would run reports if it was a feature they would need. Of course the answer was no, not necessary. Really shouldn't have listened and built the option in anyway.

In order to make this change several things had to be altered. First was creating the new JComboBox for selecting the day range, which was basically a carbon copy of the current code with only minor name changing tweaks. Second was to create the file structure where the report files could be stored on a daily basis rather than monthly. This basically entailed creating 31 folders numbered appropriately 1 - 31. Inside each would be that day's files.

Now that the simple pieces were covered, on to the difficult section. The challenge was implementing this change while still retaining the ability to run reports off of the previous date on a monthly basis. Since the location of these files were different the file location variable (fileLocation) was created and replaced the current static code ("data\\" + year + "\\" + month). Depending on the date of the files requested this variable may have appended on the end the day variable ("\\" + day). For saving the needed files correctly this was the only necessary change, taking the variable fileLocation creation outside of the normal If/Then statement.

if ((year == 2007) && (month <>
fileLocation = "data\\" + year + "\\" + month;
else
fileLocation = "data\\" + year + "\\" + month + "\\" + day;

Now that the files saved correctly, it was time to make sure reports could be run off of them. What had to happen was separating out the report creation instances from those that run monthly to those that would run daily. Before all reporting was dealt with inside of the same If/Then nested statements, now they are worked on separately with a return call at the end of each statement. This way the calls to run reports on monthly dates could be done first and the IF statements for the daily report runs could be simplified. For example:

if (targetFile.equals(TECH) && Integer.parseInt(targetYear) == 2007 && Integer.parseInt
(targetMonth) <>

for the monthly report on technical only calls. The clarifying If/Then statement for the daily reports could then be written simply as:

if (targetFile.equals(TECH))

Then it was only a matter of adding a For loop that would tally all of the reports for the covered date range one at a time and input their information into an array.


Before this update when a file was not present, such as when a representative was out of the office, the report would provide an error message informing the user of this fact.

For a report run over a months time this message appeared maybe once in four months. But now that the report can be run over a shorter date range this message could appear quite often. As a result any such messages stating a file is missing were removed, the only messages retained were those that pointed out errors that would not allow the report to run, such as no month was selected.

There has been some talk of removing some of the buttons, which hasn't been done yet. I can see this requiring me to permanently assign certain variables to buttons to avoid reusing any variables and therefore avoiding combining data for the two buttons into a single report. I don't see that being difficult, it would just require a little effort to keep track of which variables belong to which call type. Something to deal with when we cross that bridge, not beforehand.