Java: Hotline Update #13

An update was needed for the Hotline program, specifically emails are now going to be tracked following the same guidelines and options as phone calls. The hard part was already done thanks not having a different set of options to select from. So the OptionPanel file was copied and renamed to EmailPanel to create the new program tab. Along with this the pop-up messages that appear were renamed to mention an email was tracked as opposed to a call.

However some changes were made as left to the current setup the user would have to log into both tabs individually, which allows the possibility of doing so incorrectly for one of them and causing significant tracking issues. So I borrowed some code from the Enguard program and required the users to log into the application upon startup, before the program window appears. Then once logged in the bottom panel displays what type of tracking that page performs as well as the individual logged in instead of the JComboBox that was there before for logging in.


In order to make it painfully obvious which tab was for calls and which for emails the email tab was recolored, I used Dark Salmon (light red) which made a nice contrast to the opaque blue of the call panel. Along with this borders were placed on all of the buttons to better distinguish them from one another.

Now that there are two reporting tools being used in the program, they each need a separate way to have reports run on them. As such a JMenu was added with two JMenuRadioButtons, one for emails and one for phones. Depending on which one was selected the report would pull the corresponding data for the Report tab.

Right now there isn't a way to combine the two reports together, but that's in the works. Along with that I will be hiding the Report JMenu from anyone who doesn't have the privileges to view the Report tab, just to avoid confusion.

Java: Hotline Update #12

It has been a little while since I was last asked to make any changes to the Hotline application. These changes weren't anything significant, same as the previous couple of updates. Basically one of the options was removed and replaced by a new options. As such this entailed a new JButton to be created with associated listener, and a new piece to the If-Else statement in the ReportPanel class to handle this new variation to the call options. One quick test to ensure that a representative can save calls and then a report can be run on that day's usage, which both passed, and the requested change is complete.

Online Game: Dungeons & Dragons: Tiny Adventures

A while back my brother convinced me to join Facebook. Being a gamer I knew I'd end up playing some of the applications there, and I was right. Thankfully one of the ones I found was simple and requires as little time as possible to still have fun. This game is Dungeons and Dragons: Tiny Adventures. In this game you take a character, equip them and send them off on a short adventure. While they are gone you need to do nothing. After a certain period of time your character completes their journey and you can read about their experience. Once they've healed up you can then send them off again on a different adventure.



It works very much the way D&D works, except just about as simplistic as possible. Each encounter during an adventure has a difficulty in one of the characteristics (strength, dexterity, wisdom...etc). A 20 sides die is virtually rolled and compared to the difficulty. Equal or higher and the character is successful, lower and the character is not. Rewards are given for being successful which can be used or equipped on the character for the next adventure.

This is a set and forget application, that was the intent. One could sit and watch each encounter and switch equipment between them for maximum effect, but personally I see that as a waste of time. This is perfect for me as I have enough other things I do and games I play that getting involved in something that took lots of time would be a major problem. Best part about this is, if you go on vacation there is no penalty. Your character simply sits idle until you return, just like a single player game (which it is). One side effect of playing this game is now I've gotten back into playing Balder's Gate II on my PC. I've only played through that twice before and definitely not seen all of the different aspects of the game, so I don't mind. I needed a bit of a break from Diablo II as I've pretty much worn that game out and played all of the builds I intended to play. There are a few more I could play if I wanted, but I think I'll wait for the 1.13 patch before that happens.

Diablo II: Classic Tournament

In the Classic Tournament by EmperorMoo the rules were extremely simply, play a hardcore character in Classic mode untwinkled. Rerunning was allowed, as were any skill and stat distributions. I haven't played Classic in years, so seemed like fun.

I should have read up on the changes between Classic and Expansion before starting, so I wasn't surprised. I was aware of several changes (no charms/runes, no equipment on the mercenary) but many I wasn't. Such as:

No potions can be given to the mercenary
Static Field has no limitations in NM/Hell
Mercenaries can't move from one act to another
No orb weapons
No weapon switch

Turns out some of these ended up being my downfall, but I'm getting ahead of myself. I played this tournament with Mirax, a Blizzballer. Never made one before but they are pretty simple and should be able to solo the game. This was especially important as the mercenary won't be doing much damage of their own.

Things started off somewhat slow, as expected with a sorceress. Hitting everything with a staff until a few points in Firebolt were available, then mowed everything down when Fireball was introduced. The rogue mercenary was a very poor tank and only vaguely distracted the monsters away from Mirax. So moving through tight areas was slow going as Mirax wouldn't move forward very fast. This changed a bit in Act II as the desert mercenary does tank fairly well, or at least well enough to hold monsters in place for a few Fireballs to finish them off. Of course any poison damage kills off the merc right away, so lots of trips back to town to be healed/resurrected were needed.

Act III proved interesting with an Iron wolf mercenary. He doesn't tank, so Mirax leads and had to go slowly to be able to deal with the fast Flayer packs in the jungle. Thankfully they have low health and fall to Fireball quickly. At least now Teleport is available and can be used to reposition the merc when needed, or save his life of course. At the end of the act Glacial Spike is also available and used to freeze any monster packs before they are eliminated, which is the exact tactic used in Act IV.

Both Mephisto and Diablo in Normal difficulty proved to be fantastic and entertaining fights, one dealt with Fireball chains and the other a constant stream of Blizzards.

Started to run into cold immunes in Nightmare and a one point Blizzard is tough to eliminate them, mostly because I have trouble aiming at single targets. Can take up to 6 casts to get rid of a single skeleton, since the merc isn't powerful enough to finish it off on her own. Most of Nightmare was a combination of Blizzard and Fireball chains, I basically forgot all about Static Field as the monsters didn't get close enough. In the end Blizzard was used almost exclusively in Act IV and against Diablo, chilled monsters is just safer.

Hell ended up being a huge jump up from NM. The mercenary died constantly and money became a real problem. However while that mean progress was slowed a bit it wasn't stopped, and Mirax continued onward through the different areas without too much difficulty. This is why her sudden end was so unexpected. Walking across the Kurast Causeway she ran into a double pack of Faithful and Sextons. The Sextons dropped Blizzards on her and with 20% cold resistance she didn't have a chance to react before the Faithful finished her off.

It was a fun tournament and a very interesting departure from my normal DII playing. Now I'll return to the land of softcore and try to finish off the last two to three builds I have in planned before I finish the list I made oh so long ago.

Diablo II: Blizzballer Skill Layout

A Blizzballer is a Sorceress that utilizes Blizzard and Fire Ball as her main skills. This is a variation of the Meteorb build with cold being the timer spell and fire the spamming spell, just a different type of cold spell being used. Generally this build should be able to deal with just about any monster encountered, and any CI/FI ones can be handled by the mercenary companion. The skill setup is as follows:

Firebolt - 1
Frozen Armor - 1
Icebolt - 1
Iceblast - 1
Static Field - 1

At level 6 some utility skills become available. Static Field is the most important, as this will be used from here onward to weaken any uniques or act bosses initially before they are finished off with other spells. Along with SF, Frozen Armor also becomes available. The Sorceress will have this spell running at all times as it is helpful when melee monsters get close enough that they are temporarily frozen after striking, giving the character time to react by either teleporting away, attacking or running in a different direction.

Telekinesis - 1
Frost Nova - 1
Fireball - 1

At level twelve one of the main offensive skills becomes available, Fireball. From here onward this skill is the main offensive weapon, especially due to it's splash damage. It is fairly mana intensive, so many mana pots will be used so the character should be stocking up their inventory with them for each venture into the wilds.

Fireball - 7
Teleport - 1
Glacial Spike - 1

At level eighteen both Teleport and Glacial Spike become available. Teleport is another utility spell that won't see much action early on. It will mainly be used to escape danger and reposition the mercenary to better tank the monster hordes. This is especially true in the Chaos Sanctuary as way to avoid death for the melee mercenaries. Glacial Spike is uses as a good way to dispose of corpses, of avoid resurrection, as well as freeze packs of monsters in their tracks.

Fireball - 13
Blizzard - 1

At level twenty-four the other main attacking skill becomes available, Blizzard. Even at one point it is a viable way to deal with packs of monsters, and those that are fire resistant. Blizzard is a quirky spell in that the areas it hits are very random and make it very possible for monsters to walk through a Blizzard wall without being touched. As such it is best to cast multiple times in slightly different spots to ensure that all areas are covered and no monsters gets by untouched. By this point Fireball is doing significant damage and monster packs don't last long, as long as the character has mana pots available.

Fireball - 19
Fire Mastery - 1
Cold Mastery - 1

At level thirty a single point is added to both fire and cold mastery, to give both main spells a boost to their damage. A single point is how they will both stay for the rest of the game, plus skill mods will have to make up any difference needed. By level thirty-one Fireball is now maxed and dealing very good damage, wiping out packs of monsters with only a few casts.

Fireball - 20
Blizzard - 20

At level forty-seven Blizzard is also maxed out and the character has two completely different ways to wipe out all of the monsters in Nightmare. Both deal enough damage to deal with any pack in short order. If the character is pressed a few SF casts and a Glacial Spike or two should slow any packs down enough to either retreat or reposition the character to better deal with them.

Firebolt - 20

Now it is time to max out the synergies for our main skills. At level sixty-three Fireball's synergy Firebolt is maxed out giving that skill an extra boost. As Meteor gives the same amount of bonus but requires a few extra skill points to reach, it is bypassed for Firebolt as skill points are at a premium with this build.

Glacial Spike - 20

At level eighty Blizzard's main synergy of Glacial Spike is maxed out. All of they synergies for Blizzard provide the same bonus, but Glacial Spike has the added bonus of being able to affect multiple monsters with it's splash damage when used. As such it can be used against monsters to freeze them in place to be dealt with by other skills. Glacial Spike by itself won't have enough power to take out many monsters in Nightmare/Hell.

From here on skill points can be used in a few different ways. Cold Mastery could receive the rest of the points to make Blizzard more dangerous. If CIs are causing issues then Fire Mastery or Meteor could receive the points to balance the character's damage out. It depends on where problems are being encountered for where to put the last few points.

Final Skill Distribution:

Blizzard - 20
Glacial Spike - 20
Fireball - 20
Firebolt - 20
Cold Mastery - 1
Fire Mastery - 1
Static Field - 1
Frozen Armor - 1
Teleport - 1

Java: CharSi Update #24

While using the program I, and others, ran into a few equipment pieces that didn't add the bonuses they should. This was due to either typos on my part or miswording of the mod itself, such as the "+2 to Combat skills" mod was spelled "+2 to Combat" instead. These were all very minor changes to about a half dozen different text files. There might be more out there, but I haven't found them yet.

A code clean-up was also performed to remove some unused variables and code pieces as well as remove all of the "public" identifiers from the variables and methods, as it wasn't necessary. This shortened the number of code lines a bit, not extremely noticable but more a personal preference than anything else.

Next on my To-Do list was to add some additional checks to the system to ensure that when creating items in the generator or selecting a value for a variable mod the value input was valid. Up to this point a Breast Plate could technically have a defense value of 100k. That is no longer possible. Now there is a check that will only allow values that fall between the given minimum and maximum mod values. This required a couple code lines addition to the DetermineRangeValue method in all of the class files.

if(CharSi.userInput){
while(rangeWrong){
userInput = Integer.parseInt(JOptionPane.showInputDialog(helmBackPanel, "Choose a value between " + start + " and " + end, modName, JOptionPane.PLAIN_MESSAGE));
if(userInput > Integer.parseInt(end) || userInput <>
JOptionPane.showMessageDialog(helmBackPanel, "Value given outside the allowed range. Retry.", "Input Error", JOptionPane.ERROR_MESSAGE);
rangeWrong = true;
}else
rangeWrong = false;
}
}

This piece is only active if the user is manually inputting values for variable mods. The rangeWrong boolean variable is initially set to True until the check is made. The user input is then compared to the given minimum and maximum values and if it passes is accepted, otherwise the error appears and the user has to try again until a valid input is given.

Lastly I wanted to ensure that runewords could not be created in the generator in illegal base items, such as a Spirit shield in a buckler that allows less than 4 sockets. This required several changes to the GenerateRunewords class file. First I had to decide how to store the information for how many sockets each piece of equipment allows. This I did with several array of arrays. Each sub-array was two values long, the first for the name of the item and the second for the maximum number of sockets. The array of arrays were grouped by item type available in the item generator, so one for armor, another for hammers and so forth. This method was called when the GUI is created.

Next I needed to be able to obtain the number of sockets the runeword required. To do this I altered the text file of each runeword item so that it displayed the number of runes used in the description in parentheses.

Runes(3):
Thul + Io + Nef

When the runeword is selected in the GUI this number is saved in a variable in integer form for later comparison.

Lastly I needed a way to compare this rune number with the number of sockets that each item could have, then eliminate from the available list those items that don't qualify. This was done with another method, ComapreSocketNumbers. Basically this method would see which JRadioButton was selected in the GUI and compare the rune number with each available item. Those that had less sockets than runes needed were removed from the DefaultListModel.

if(shieldFlag){ //if shield radiobutton marked
for(int i = 0; i <>
if(Integer.parseInt(shieldSocketArray[i][1]) <>
if(baseListModel.contains(shieldSocketArray[i][0])){
int index = baseListModel.indexOf(shieldSocketArray[i][0]);
baseListModel.remove(index);
}
}
}
}

This method is called when either the Display Base JButton is pressed or a runeword is selected from the available list. However to ensure that items removed from the baseListModel can be returned a doClick() call is made on the Display Base JButton to repopulate the listModel fully before it is checked for illegal items. Otherwise once an item is removed, it is gone until the program is closed and reopened, which isn't too convenient.

My next projected changes to the program is to take into account aura bonuses from equipment and also the +O skill mods.

Java: Hotline Update #11

This time around the Hotline program did not lose any current options. Instead only two options were added, which made things extremely simple to update. In the OptionPanel class the new JButton variables were created and added to the very end of the GUI. Then the file output was updated to add the number of calls taken for these new categories to the very end of the file, so as not to displace any current call values.

This took care of the OptionPanel, the ReportPanel required just as few changes. Basically a new qualifier had to be created that covered the time from the last update (April 2009) to the new one (June 2009). Then the default qualifier, everything from June 2009 onward, covered the two new call categories. Those were the only changes required to include the new call categories. Now the page actually is full, before there were empty spots for JButtons in the display as I didn't have the correct number of options for full rows. Now I do so the GUI looks more complete.