Java: En Guard Update #2

I didn't expect to be making another post about En Guard this quickly, however I ended up having some free time yesterday afternoon to work on the one remaining bug in the program. The bug in question being the fact that the word wrapping was occurring by character and not by entire words, so it was difficult to read at times. My thought process for solving this problem was simple, yet not quite as simple as the final solution. I assumed that the reason the wrapping was occurring by character was because I was saving the file's text to a StringBuffer one character at a time. So I created a new StringBuffer, nextWord, where I saved all the characters of one work and then added this variable to the final StringBuffer as a word block. The below code was written to carry out this experiment.

while ( (c=myFile.read()) != -1 ) {
if (c != 32)
nextWord.append((char)c);

else{
textToDisplay.append(nextWord);
nextWord.delete(0, nextWord.length());
textToDisplay.append((char)c); }

}
textToDisplay.append(nextWord);

This code block replaced the original single line piece of code, which is colored above as it did remain in the block as well. For this code C is a char variable that as long as there are characters in the associated file then the loop is performed. A space character in this example is equal to 32 before it is converted to a char value, which is where the first part of the If statement comes from.

Once this code was written it was tested and lo and behold the same problem occurs. So I looked into the java API at the setLineWrap method and found that visible at the bottom of the page was a method named setWrapStyleWord. I was intrigued and once I looked into the method found that this was what I was looking for. Applying this method to both JTextAreas so that it was set to True solved my word wrapping problems. This resolved all of the outstanding issues with the En Guard Call Tracking System. I do have it in my mind to perhaps make the Platform and Entered By drop down menus alterable by the user as right now the lists are hard coded into the program. But that is for later, for now this program is considered completed for our work environment.

Java: En Guard update

The En Guard Call Tracking System had a few known bugs that we were living with for the past few months until I could find time to correct them. Specifically a record could be overwritten without any prompt and the old information lost. Also when a new record was saved the default text from the top field was added to the record on occasion. Solving the second problem was the easier of the two. At the end of the constructor the New() method was called, the one used when the Reset button is pressed. This seemed to resolve the problem as it was only happening on the very first record entered after En Guard was opened. After some testing it was found that if the Reset button was pressed after opening En Guard the issue would not arise, so this is now done automatically when En Guard is initialized.

The second issue was a little more serious, but still not too difficult. There is a test when saving that checks if the file already exists so that the old information can be inserted before the new call information. Using that check I wrote a boolean If statement that would cancel the save attempt and post an error message. This would happen only if both the file already existed and the text in the Current Record JTextArea field was still the default text instead of the output from the existing file. The user would be prompted to open the old record and copy the last call's data into the Additional Information field before saving the record.

Now the next bug to fix is the word wrapping for the JTextArea fields. Currently any text will wrap, but it does so in a way that leaves part of a word on one line and continues it on the next. It wraps separate characters instead of the entire word and I think I'll need to completely rewrite that part of the program to correct this issue.

Java: IP Analyzer

In my current position at work I help with some of our institutional customers who access our online application. In order to verify that a customer should have access we obtain their external IPs and keep them on file. The IPs used must be unique to the institution in question and cannot be gateways for location areas larger than what is on the contract. Unfortunately what happens is that we are given IP lists that are gateways by accident and since we aren't aware of this fact those IPs become active. Eventually we come to realize what happened and obtain a correct IP list from the customer.

Our problem comes from the fact that sometimes we are given the same gateway IPs from different customers and each time we go through the same difficulty when the IPs are activated. To avoid this a Microsoft Excel spreadsheet was created that listed all of the IPs we know to be gateway IPs and before we add anything to an account they are compared to this list. Unfortunately this list is rather cumbersome so I developed a java program that would do the same thing but be easy enough for the account managers to utilize without problem.

Like all of my current programs this one is fairly basic in setup, but then again it has a simple function and therefore does not need to be more intricate anyway. The program accesses a text file on the hard drive that lists all of the IPs on the "restricted" list and this can either be added to or searched on to see if a particular IP or IP range appears on this list. When adding an IP to the list the input from the user is simply append to the end of the text document. Searching on this for a comparison is a little more difficult. The current list of "restricted" IPs are converted into an array of single IPs. Then the IP given by the user to search with is also converted into an array of IPs. Once these two steps are completed the arrays are compared and if any of the IPs are found to be present in both arrays an error message is displayed to the user with the IP in question displayed.

Obviously this is a brute strength approach to comparing the IPs and as a result has its problems. First, any IP ranges of Class B or A cannot be used as they crash the program due to the memory requirements. Thankfully this does not come up often and therefore hasn't been encountered yet. However I'd like to add internal IP ranges to this program as part of the "restricted" list but I can't do this as 10.*.*.* is internal and would crash the program every time. Secondly, IPs must be entered in an exact format or they will not be recognized by the program and the comparison will not function correctly. IPs must be entered in the four octet format with no spaces and a dash between the start and end of the IP range, such as 52.52.52.52-52.52.52.178.

Overall the program works quite well for the purpose intended. If the document containing the "restricted" list was something other than a text file, such as a database or spreadsheet, then the searching algorithm may not be quite as memory intensive. However for the purpose intended such a change is not worth the effort.

Java: En Guard Call Tracker

I haven’t been able to create any personal projects for java programming recently but thankfully the workplace creates them for me. One thing our technical support department has always lacked is the ability to keep track of what each call was about so that if that customer calls back we don’t have to recreate the wheel. I do know that my company is working on purchasing just such a program but that will be at least a year in the future. So recently I created a poor man’s call tracking system for only our technical support group and not the entire call center in general.

I named the program En Guard as I was playing with the GoldIcon program to create icons and one of the ones I liked best was a shield with swords on it, rather medieval looking. It sounds much better than the original name of “Technical Support Call Tracking System”. This program will save all call information into a text document, Microsoft Word, with the documents organized by subscriber number and saved into a central location on our network. The call information itself that is asked for is very basic: name, subscriber number, contact information, representative and product version. Beyond that the topic of the call is recorded and entered before the record itself is created and saved.

This program went through several versions before a working one was produced. The most difficulty part was getting the program to read a file already on the network and save any updates accordingly back into the same file. Thankfully something similar was done with the AMAS program so as in that program a FileWriter/Reader was created. The entire program consists of two files; one for the main window with the buttons at the bottom and the other for the panel containing the variable information. Each document is setup the same way with the variable information at top followed by the contents of the call. So the FileReader reads and erases the customer information one piece at a time to fill in those fields then takes the rest and places it into the “Current Record” field. In order for this to work the spacing of the information had to be hard coded into the system, which wasn’t the most elegant way but is effective. The Platform and Entered By fields are also hard coded into the program, so if this were to be altered for someone else’s use the basic code would need to be altered.

With this program, unlike the other ones, I was able to obtain some feedback from my colleagues to make it more user friendly. The suggestions taken were setting the JTextArea fields to accept word wrapping, automatically adding the current date to the record, adding a separator between record entries rather than a simple newline character and last but not least a skin chooser. The skin chooser was more of a joke one of my colleagues threw out at me as he didn’t like the color I had picked, light goldenrod. But I took it as a challenge and it turned out to not be as hard as originally expected. Making sure I caught all of the setBackground calls in the skin chooser method was a bit tough, but perhaps that was more because I was trying to do it manually since the entire program is about six hundred lines of code. In order to change the program’s skin I did have to ask for the RGB values, which of course no one knows off the top of their heads.

Overall not the most difficult program I’ve created however it has been very useful in the workplace, being used several times a day. Some updates do need to be made, specifically that a skin can be used that obscures the JLabels as they are defaulted to black, a record can be overwritten without prompting the user if that is really what they want to do and the Platform and Entered By fields don’t need to be hard coded. I’ll get to all of these in the future, but for not the program is working quite well for our limited needs.

PC Games: Civilization: Call To Power

Civilization: Call To Power (CCTP) is one of those games I’ve had for quite a while but never played until now. I’ve have both the original version and Civilization II and played both quite a bit. CCTP is supposed to be an upgrade to Civ II but also an independent game, not an expansion pack or add-on.

In terms of general game play, not much has changed for CCTP. You are still expected to build cities, explore the planet, perform research and war with your neighbors in the pursuit of a final objective. That said many of the details did change significantly. The research was reorganized with new names and more options. As a result it takes longer to finish research, but not to worry as the final date for game play is 3000 AD, instead of 2100 AD. Hand in hand with more research is more buildings and items being available, which is my first issue with the game.

There are an absolutely ridiculous number of units available overall. They range from the traditional Settlers and Legions to the new Slavers and War Walkers. As time progresses the player must replace old units with new and as this happens quite a few times the player finds themselves constantly replacing units. Not only that but some units are stealthy and therefore traditional units can’t see them. So to combat these units and their attacks the defender must also build these same units. A player will find themselves with at least one unit, if not more, per city with the sole purpose of thwarting a specific non-military attack. Since all units now require upkeep in terms of gold this can get expensive.

Along with more units there are also more buildings. All of the traditional buildings are still in place and performing the same function, such as factories and granaries, with the additional buildings mostly giving the same effects as traditional ones. For example the Temple provides happiness to the population, and now there is a Theatre that does the same thing. This allows each city, which can get far larger than in Civ II, to exponentially increase their productivity, scientific output, gold or happiness. This leads us to a feature that makes life far easier. The larger the empire becomes the harder it is for the player to manage what each city should build. Enter the Build Queue, a very helpful feature. Instead of setting building orders one at a time, several units and/or buildings can be placed in a queue at once. Then the player need only manage a city if something happens, such as a riot or military attack, until everything is built. This saves a great deal of time and confusion for the player and was sorely missed in Civ II.

The military side of the game was also altered significantly. Before in Civ II units could stack in one space but only attack one at a time. So when attacking a city it was traditional to hold 40+ items, for example Howitzers, in place before assaulting a few enemy cities. When completed units would be scattered all over the map, some stacked and some not. This left them open to retaliation as when attacked only one item would defend for the entire stack, if it loses the battle then all units on the tile are lost. Now the battle system allows units to attack as a full stack of up to nine units. With this setup the ranged units are in back and the melee units up front. Each side takes turns until one or the other is eliminated.

As a result tactics comes into play quite a bit as the more powerful units may not win if they don’t attack in the correct combination. However this same battle system has a downside in that one side could be completely outclassing their opponent and still lose. For example in this picture I had Musketeers and Cannons and was attacking a group of Samurai and Phalanxes. I had ranged units as well as superior defensive units and should have massacred my opponent. That didn’t happen; in fact I lost badly in several reruns. Obviously the battle system is not true to real life in any sense, so care must be taken when engaging in combat. I’ve taken to bombarding my opponent for several rounds before attacking a city, this basically eliminates any resistance. As a side effect it does reduce the population and eliminate some buildings but it’s a price I’m willing to pay to avoid losing stacks of units.

A few other small changes are that after a battle the winner, if offense, moves to claim the tile where the defender had stood. Before in Civ II the attacker remained where they were once a battle was completed. This helps when attacking cities as now a second stack of units isn’t necessary to claim each city. Partisans were also removed from the game. This I definitely like as it was extremely annoying to conquer a city, then find yourself surrounded by a dozen partisan units. They weren’t strong enough to save the city, only extend the time it took to move on to the next city. Also there was an introduction of sea and space colonies so the entire map can be covered with cities leading to enormous empire populations, such as the nine billion I had in my first game.

Overall the game is quite enjoyable; however a few issues do remain which is why I see it wasn’t quite as popular as the other Civilization games, such as Civilization III that came out later. It almost appears as if the developers had all these great ideas and tried to cram all of them into one game, even though doing so took away from some of these same ideas. Space and sea colonies are excellent, but together with the huge amount of units and buildings takes away a bit from the general game play. The player feels more like an accountant than a gamer at times, especially near the end when the empires can be vast in size. The building queue and other such features help manage the empire and they do a decent job, and while the game is quite good, it could have been even better.

Java: AMAS

AMAS is an acronym for 'A Mini Arreat Summit', in reference to The Arreat Summit which is an online website devoted to Diablo II. AMAS has some similar information but it is organized in a way that is more convenient to view and also is available offline.

AMAS is the most complex program I've made individually to date. It incorporates everything from previous programs but expands on them quite a bit as well. The new features with this program are tabbed panels, input and output files and embedded graphics. We'll discuss each panel individually.


The newer patches of the program introduced a new concept, Runes. Up to this point only jewels and gems could be placed in open sockets of items to give those items an additional bonus. Runes each have special properties that may change depending on which item the are placed in. The runes can also be combined to create newer, more powerful runes using the Horadic Cube. This panel provides both the properties of the runes and the recipes needed to create them. The runes are laid out using a RadioPanel with the Grid layout. The rune pictures are saved on the hard drive and called for when the buttons are initialized. When a rune picture is selected the appropriate text file's content is written into the TextArea field.


Runes added a different twist, as along with having their own properties they could also be added to certain items in such a combination that would give the item special properties not inherent with the runes themselves. The items used had to be either white (normal) or grey (ethereal) and have the exact number of sockets as the number of runes used. Keeping all of these runewords straight is difficult and a quick reference is required. This panel introduced the need for multiple drop-down menus to organize the runewords in a logical manner. However only one menu could be used at a time and at the beginning of each ActionListener the other menus are reset manually so that two runewords weren't selected at the same time. Each runeword is a separate text file on the hard drive, as is each listing of the available items for the runeword itself.


This panel's information is associated with runeword creation. Only certain items may have sockets and then the number of available sockets varies greatly. Determining which items are available to create certain runewords is extremely useful in deciding if a normal item should be saved or sold ingame. The items are sorted depending on if they are class specific or by item type (shields, armor...etc). When an item is selected its associated graphic is also displayed to make recognizing them ingame easier. This panel is written so that when a selection is made in the first drop-down menu it populates the rest of the panel to correspond. Then the bottom drop-down menu is used to select the type of item to display. As a result listeners are needed for each drop-down and all of the information is saved on the hard drive in text files or as graphics.


The Horadric cube is a very useful piece of equipment, allowing the player to create wonderful items or upgrade the ones they already posses into more powerful versions, among other things. The amount of recipes available is vast, however most are not used or were already covered by the Runes panel. Therefore this panel only displays the most commonly used and useful recipes. The options are displayed in Radobutton format with each button linked to a text file on the hard drive.


Each curse from a Necromancer, or certain monsters, has a different display over the affected avatar. Some of these are fairly similar and keeping them straight can be quite difficult. The curse would be selected from the drop-down menu and this would display a graphic of the curse in action along with some statistics as to the function of this curse. The statistics are stored in individual text files on the hard drive.


Each aura for the Paladin has a different display under the Paladin's feet, or monster's feet depending on the aura. Some of these are, like the curses, fairly similar and keeping them straight can be difficult. It is also rather unhealthy to mistake one aura for another ingame. The curse would be selected from the drop-down menu, split into offensive and defensive auras for simplicity, and this would display a graphic of the aura in action along with some statistics as to the function of this aura. The statistics are stored in individual text files on the hard drive.

This program took months of coding a few hours a week to create. Due to the size of the program and all of the associated text files and graphics it is not possible to bundle the entire program into one executable. Instead AMAS works very much like a real program in that it has a folder on the hard drive containing all of its program files. The installer used is only a Zip file currently, however I am looking into freeware installers that could be used to install this program in a more official manner.