Friday, November 2, 2007

Java: DII Character Simulator Update #1

Creating the GUI interface for the DII Character Simulator was the next step in this applications development. Unlike in the original draft I decided against using a JComboBox to change between equipment types. Instead I used a nested JTabbedPane for a more professional look.

Of course this became the first obstacle in that I wasn't sure how to nest a JTabbedPane instead of an already existing JTabbedPane. First attempts lead to the tabs showing up, but in a vertical line instead of horizontally, and also leaving quite a bit of wasted white space on the edges. The problem was that the Equipment class was extending a JPanel, so when this was changed to extend a JTabbedPane everything worked out nicely.

Each piece of the GUI was created in its own method and hosted on a separate JPanel, so that they could be organized and formatted independently. As work began a combination of JCheckBoxes (first time this component has ever been used by me), JButtons, JScrollPanes and JLists (also a first) was organized into the needed GUI pieces. The JList component took some research to locate as the component that would do the job I needed. Set to allow only a single selection, this component is the cornerstone to how equipment will be added (and removed) from the virtual character.

Once all of the components were created, the next task was to combine them all into a single JPanel for display purposes. This turned out to be more of a problem than anticipated. Due to the success of the GroupLayout manager with the skill panels I felt this would be the format needed to create the look and feel of the equipment panels. The problem that arose is that I have only 5 components and didn't want to leave any extra white space. The GroupLayout manager kept cutting off part of one of the components, the ItemList Panel, as I was unable to extend this panel vertically. Everything apparently has to remain in their separate rows, no overlap allowed.

Next attempt was a FlowLayout manager, but getting all of the items to line up vertically simply wasn't working. The components would push each other out of the program window. Finally I settled on a compromise. Two panels were created with the GroupLayout manager that each had two components lined up vertically. The third panel, the one containing the ItemList panel was created with FlowLayout manager. Then all three panels were added to the main panel, also using the FlowLayout manager.


I most likely used more panels and layout managers than necessary, however the final result is quite nice and the code isn't too jumbled, so I'm fine with how things worked out. Once the code was finished for the first equipment type, the helm, it could be carbon copied for all of the other equipment items. The only changes came with the weapon panel, where an option to dual wield was added to the ButtonPanel via a JCheckBox and the other change was the jewelry panel, where some of the selection options were removed or renamed such as elite/exceptional/ normal quality options do not apply.

The next step will be to create the final statistic display that will replace the LCS.

Thursday, November 1, 2007

Java: Hotline Update #4

Yet again more changes to the Hotline program. It is only a single change this time and was done in a previous update so the groundwork has already been laid. Specifically a new button needs to be added. I actually tried to argue against adding this button as once again this will leave blank spots that isn't too pretty. But since no one else seems to be worrying about this I guess I can't either.


In order to add the button a few changes were required. First the OptionPanel required a new JButton to be added, along with its associated listener, and then the GridLayout adjusted to be 6x4 instead of the previous 5x4. What I didn't realize is that by doing so the main frame would need to be extended as well. So originally the button labels were shortened due to not having enough horizontal space to fully display.

The other main change required was to alter the ReportPanel's main If/Else statement to incorporate the new button option. The previous change from the last update now needed a qualifier at the end of its If/Else section:

else if (Integer.parseInt(targetMonth) <> 9 && Integer.parseInt(targetYear) == 2007)

Then the current update could be tacked onto the end of the statement with no qualifier and would only come into play starting November 1st, 2007, which is when it will be introduced to the Call Center.

The only hitch came when call center representatives attempted to open the program after the update. Some received a message stating they could not find the main class. This was resolved by updating the version of Java on their computers to the latest copy.

Monday, October 29, 2007

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.

Wednesday, October 17, 2007

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.

Tuesday, October 16, 2007

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.

Friday, October 12, 2007

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.

Wednesday, September 12, 2007

Diablo II: Plague Javelin / Lightning Fury Javazon Skill Layout

Guides for Amazons using Plague Javelin and Lightning Fury are not very abundant. There is one guide for PvP play, but none I could find that covered PvM specifically, although this guide would do fine in that regard.

The skill setup is as follows:

Jab - 1
Pierce - 1
Poison Javelin - 20
Plague Javelin - 20
Lightning Fury - 20
Valkyrie - 20

Valkyrie doesn't have to be maxed, but since I prefer a more durable tank and there isn't anywhere else to place the extra skillpoints they go into valkyrie. I like to provide a breakdown of when the points were allocated:

Jab - 1
Critical Strike - 1
Dodge - 1
Lightning Bolt - 1
Avoid - 1
Poison Javelin - 7

This brings us to character level 12 and Poison Javelin is doing decent damage, just very slowly. This is where the character is throwing javelins and then running around the screen for several seconds while the poisoned monsters chase her until they expire. The going is slow but steady.

Poison Javelin - 10
Inner Sight - 1
Slow Missile - 1
Plague Javelin - 1

At level 18 Plague Javelin finally becomes available and the damage output increases more sharply from here onwards. Plague Javelin also has a shorter poison length, causing the monsters to fall quicker and requiring less running around evading monster packs. At level 18 Andariel will be encountered; the catacombs will be a cakewalk compared to facing her.

Plague Javelin - 7
Evade - 1

Now at level 24 each point into Plague Javelin causes the monsters to fall faster and faster and most of Act II will be fairly simple, especially now with an Act II Desert mercenary to tank for the character. No longer does the character need to run away from monsters, simply let them swarm the mercenary and throw a javelin from time to time.

Decoy - 1
Plague Javelin - 13
Valkyrie - 1

At level 30 the ultimate tank becomes available, Valkyrie, taking some of the heat off of the mercenary and making the Act bosses much easier to deal with. At this point a desert mercenary is no longer required and and Act I or III mercenary may be hired for additional elemental damage.

Plague Javelin - 20

At level 37 Plague Javelin is maxed. It is doing a respectable amount of damage and monsters are starting to fall in one javelin throw, a theme that will continue through the first few Acts of Hell.

Valkyrie - 10
Penetrate - 1
Pierce - 1
Poison Javelin - 20

At level 56 Plague Javelin and its synergy are maxed, making a formidable weapon for the character. Poison resistant and immune monsters are starting to be encountered, so a backup is now needed.

Lightning Fury - 20

At level 74 all offensive skills are maxed and monster packs fall very quickly. An initial Plague Javelin is followed up by a few Lightning Fury strikes to eliminate the majority of the monsters, the few remaining ones succumb to poison soon afterwards. Bosses are still going to be difficult as neither offensive skills is designed for single opponents so the fights will be long. This is why it is better not to have a melee mercenary, the ranged ones last much longer and this saves resurrection fees.

Valkyrie - 20

By level 81 all of the skills are maxed. With plus skill bonuses the valkyrie should have around 3000 life, more than enough to tank almost anything in the game. The general gameplay for normal monsters is to allow them to surround the valkyrie and then use either Plague Javelin or Lightning Fury, depending on which type of immunity the monsters posses. Single monsters can be dealt with either a combination of the valkyrie, rogue mercenary and Jab or a single Plague Javelin. The only monsters that are immune to both offensive skills are the Black Souls of the WSK and monster bosses. This is where the rogue mercenary with elemental damage is extremely useful, equip her with a fast bow and she'll make short work of the souls, especially with the valkyrie drawing all of their fire.

For this type of build there aren't any equipment pieces that are vital, only a few that make progress much simpler. Titan's Revenge for a weapon and Trang's Gloves are the only two pieces that make a large impact to the effectiveness of this character. Questing is still possible without them, but the progress will be much slower and require far more patience and trips back to town. All other equipment is subjective to the player's playing style.