It's been a few weeks since the presentations, but I will briefly go over what has happened since. My presentation went pretty well aside from a technical difficulty. I found out that my laptop's HDMI port is broken, so when I attempted to connect it to the projector, I got nothing. Since my program was developed and tested on my laptop, I wanted to make sure the demonstration was on there because I knew it would function the way I expected. Instead of freaking out (like I was doing inside), I had everyone in the audience gather closer to the front in attempt to let them see my laptop screen. I'm not convinced everyone could see, but I think it was a better choice than the alternative of not knowing how the program would behave. The PowerPoint and explanations went smoothly, though. I did not forget any huge concepts or points that I wanted to make, and I felt like it was accessible to most of the audience members.

Last week was my project defense. There isn't much to say about it--the CSCI faculty asked questions and I answered them (tried to!). It felt like it went pretty well.

I have done a lot of documentation throughout the weekend and will continue to polish it tonight. My code has TONS of comments both before methods and throughout them. I think it is fairly clear what each section is trying to do.

I left some small bugs in the code. Originally, my idea was to fix all the little things between the presentation and now, but I had a change of heart. I had such a hard time getting started on this project, but once I was able to make some progress, things started to move right along. The idea is that if I leave a list of smaller issues that need to be fixed, the senior who takes over my project can become familiar with the code as well as make some "progress" by fixing these bugs. Hopefully those two things will help to really get the project going for that person--faster than it went for me.

Well, the good news is I have trains moving on the track. The bad news is I have run into a HUGE issue that I am not sure will be resolved in the next week considering all that needs to go into this presentation. I am stuck on a graphical representation of turnouts--showing them as either curved or straight. The way that I have set up the data structures limits my ability to do this because I have nothing that "links" elements of the track. There is nothing that says what comes "next". This is a problem with the first idea I had for implementing a graphical representation of a turnout. The idea was to draw a thicker white line under the track that would serve as a "split" between the track to be followed and the track that I don't want to go down. Since I draw curves between three points (a trackStructure), I cannot simply draw this white line from the turnout to the next sensor--it wouldn't be the same curvature because it's only defined by two points. BUT, I CAN'T draw this white line from the turnout to the next endpoint because there is a possibility that that endpoint is also a turnout. This could change the status of that one.

My second idea for representing turnouts came from Dr. Pankratz. He suggested drawing a white circle at the point necessary to "break" the track. However, since a segment can go in any direction out of the turnout, I do not know where to put that circle. I will attempt to meet with Dr. Pankratz and discuss tomorrow. If we cannot come up with a solution, I am going to move on and leave that issue.

Another issue I have been experiencing is with the train moving along the track. Sometimes the train gets "stuck" even though the track does not end. This is because the middle pixel of the circle is the one that is trying to move. I have restricted the direction to be either the same as previously, or one to the left/right. For example, a train moving East can move either east, northeast, or southeast. The problem is if the train is moving north and hits the peak of a curve, it gets stuck because it needs to move sideways--northeast/northwest are not track when it is at the peak. I am not exactly sure how to fix this. I think it might be one of those things that a user needs to be conscious of. A sharp curve isn't really plausible for a train track.

Over the course of the past week, I also implemented a dynamic populating form. When the edit form returns, it is populated with the sensors and turnouts that a user added. Currently, I need to do a little organizing with this to make sure it repopulates when edits are made and that the form opens when a simulator that has been saved is opened.

I also need to implement the increase/decrease speed buttons. That should be simple.

I think I have plenty to do this week. Hopefully it goes well and the presentation comes together. Even if there are still issues, I definitely have plenty of design and alteration to design to discuss.

I have continued to do maintenance work this weekend. I attempted to "organize" my code--in each form, I reordered code so that data members and events are declared at the top followed by properties, methods and finally event handlers. I also attempted a thorough documentation section for each method--input/output/purpose of each.

A HUGE thank you to Dr. Pankratz for helping out with the issue of moving trains on the simulator! I am in the process of converting his code from C++ to C#. I have done the majority of it, but do not currently have trains moving on the track. The logic, however, is there. I have a timer object that will tick every 10th of a second or so. Each time it ticks, it will increment the "ctr" variable of a train object. When the ctr variable reaches 10--a set # because it is the maximum speed--the move_train functions are called. That way, the trains only move based on their speed. Trains will simply follow colors along the track rather than having to "link" track pieces as I originally thought.

I have implemented the "add train" feature in the simulator. A user is able to click an "add train" button on the simulator screen (only when there is a track drawn). A message box as well as a add train form (which is completely disabled) pops up telling them that they will not be able to initialize any properties of the train (ie color, direction, speed) until they have clicked a SENSOR from which they want to start their train. When a sensor has been clicked, the add train form becomes enabled and they can choose colors, a speed, and a direction. Defaults are set in case a user does not enter proper values. Currently, I have not been able to test it, but that will be happening in the next few days.

Happy Easter!!

I can't believe it's already April!!!! Wow, March flew by.

I have done a lot of what I would call "maintenance" work this weekend. I finished implementing the delete mode. This posed a bigger challenge than I expected, but I was able to work through it. Initially, I thought it would be a simple implementation--swapping the last segment in the array with the one to be deleted and then decreasing the num_segments variable. However, this posed problems when the last segment was supposed to be deleted as well. I tried finding the last "available" segment and swapping with that. That left me "holes" in the array. For example, if I wanted to delete the second and fourth of four segments, the array should result in the first and then the third. For some reason, this just didn't quite work. I settled on using a temporary array to store the non-deleted segments and then copying those back into the myTrack array. This seemed tedious, but as far as I can tell, it works without error.

Another issue that took me longer than I expected was dealing with the "shift_factor". My simulator screen has both a tool strip and a menu strip at the top of it while the edit track screen has just a menu strip. This posed a problem when a user created a track that went near the top of the screen. I created a shift_factor variable that gets calculated and added to the Y value of every sensor and turnout ONLY if necessary... it brings the topmost point of the track down to a Y coordinate of 75 so that the user can definitely see every point on their track. When the user goes to edit the track again, all of these Y values need to be set BACK to what they were... Otherwise a user can make their track go even higher and then it gets shifted downward over and over each time they save their track in edit mode and go back to the simulator screen. One problem I ran into while implementing this was the fact that these trackPt objects are referenced by more than one place (ptA of one segment can be ptB of another and vice versa), so they were getting shifted more than once. I used a "marking" technique to ensure this didn't happen. My marking technique was to use the bool midpt variable in the trackPt structure. This variable is only really used in the edit mode to see whether or not a user can drag a point, so it was nifty to be able to use it here as well.

I also implemented the save, new, and open elements of the program. These will need to be updated as I go with the simulator (depending on whether or not more information becomes important to store), but as of now, a user can at least save a track layout and bring it back or create a completely new one.

From here, I need to find a "good" way to display the status of the simulator (meaning all of the sensors, turnouts and trains) as well as individual controls for each train. I currently do not have a way to add trains. My idea is to thread them so that each uses the same code, but they can run "simultaneously"--as we know, nothing truly runs simultaneously in the CPU, but it should feel like the trains are doing so.

I am hoping to meet with Dr. Pankratz early this week and come up with a method of moving the train along. I believe that is truly the biggest obstacle standing between where I am and finishing this simulator.

I was able to fully implement the graphical representation of the track yesterday and today! I use an array of type "trackStructure" to do this. Each trackStructure (basically a segment of track) has three trackPts in it (I have drawn a picture of the structure and plan to upload it in the near future to help visualize). The idea is that a track is defined by these segments. Each segment as a midpoint, and that is the ONLY point that can be changed. So, a user can create their desired curvature only by dragging midpoints of segments rather than by dragging ANY point on the track as I was doing before.

I have not finished the implementation of the "Delete Mode", but I have a good start and an idea of what needs to be done to accomplish the task. Currently, I populate a CheckedListBox object with the segments. When a user checks the box next to a particular segment, that curve and those three defining trackPts change color (in a sense, they get highlighted). If they uncheck the box, the segment goes back to "normal". I plan to add a final "Delete" button in which all the highlighted segments will be removed. This makes it easy for the user to remove as much or as little as they please all at one time.

I have also developed a plan for transferring the data in my graphical structure to the "simulator" structures that Dr. Pankratz and I discussed a few weeks ago. I believe I need to do some tweaking of the graphical structure, but I do not think it will be overly complicated. My idea is that if I know that endpoint A is ALWAYS counterclockwise from endpoint B, then I always know what is coming next in either the clockwise or counterclockwise direction. That is the whole idea behind the trackLink data structure and the simulator itself--knowing what comes next in the forward/backward directions.

Additionally, I spent some time tonight looking through the scrap papers I've saved with ideas for how to go about aspects of the simulator. I plan to upload scanned copies of these in order to better visually document beginning to end of my project.

I am very pleased with my progress over the last week, and I feel comfortable continuing to move forward. Presentations are approaching quickly, but I have been able to really dig into the project now, so I am not as worried as I was a couple weeks back.

I started to implement the "Add Turnouts" mode, and found myself at a standstill. The data structures themselves are still usable, but when it comes to drawing the track, I really need something else. The problems arose when a user went from adding turnouts back to adding sensors. Since a turnout creates the possibility of track being added in multiple places, I had a hard time knowing where to put the new track. This could be solved by requiring a user to click endpoints of a track segment. However, this made the designer "messy" in the sense that it became inconsistent--if there are no turnouts, you do this vs. if there are turnouts you do something else, etc.

I went back to the drawing board with Dr. Pankratz this afternoon, and I believe we have come up with a pretty good solution--one in which I will be able to use some of the code I have already written as well!

We decided that graphically, a track is nothing more than segments. Each segment is defined by two endpoints and a midpoint. The midpoint is the only one of the three that can be "changed". In other words, a user can drag the midpoint to create the desired curvature. In this implementation, a user is ALWAYS required to click the two endpoints of any segment of track. Thus, a turnout is created when a second segment is added to one endpoint. This allows me, the programmer, to limit the freedom of the user while still allowing them a simple way to create a track. Another change from the previous way I was going about this is the fact that several curves are to be drawn to create the track--each defined by three points. Originally, I was trying to create a very smooth track by connecting ALL the points a user had given me. This became a serious issue when turnouts came into the picture. Now, I leave it up to the user to make the track look smooth.

I will be attempting this implementation tonight and will hopefully make some serious progress.

I was able to make some progress on the issue of adding turnouts. When a user clicks the "Add Turnout" button, they enter into turnout mode. They then click a point at which to add a turnout. If the point is within 5 pixels of the track in either direction (up, down, left, right), I consider it close enough to the track, and a new turnout is created. If not, a message pops up telling the user that they did not click close enough to the track and they should try again.

Now, I need to account for the user who wants to add track after the turnouts. I haven't decided exactly how to do this yet, but I think that having the user click "start" and "finish" points seems like the obvious idea. That way, there is no question where the sensor should connect.

From there, I plan to implement the creation of the TrackLink data structure as I will have all the sensors and turnouts and simply need to combine their information. My guess is this task is going to be easier said than done. I hope to have it completed by the end of this week, though.

As you can see, I have done some work on my site as well--nothing too extreme, but I have at least added some relevant pictures and created a link to my walk through PowerPoint on the timeline page.

Presentations are four weeks from Monday, so I need to make some serious progress these next couple weeks.

Although progress has been slow, I have been making it. In the past few days, my focus has been on transferring the first track designer program into something that fits the new data structures that I have decided to use. By default, I have the user creating sensors when they click the screen (in the edit mode). Each "sensor" gets put into my sensor data structure, and then the sensors are all connected by a curve. Each time a new one is added, the curve is redrawn so as to ensure that it is smooth. The user can then go into edit curve mode where they can then drag any of the sensors around to achieve the desired look.

My next step is to implement the turnout part of edit mode. I am currently stuck trying to decide how to allow a user to place turnouts on the track and determine where sensors are being placed after a turnout (this is difficult because of how I always connect the sensor to the previous one--with a turnout there are two possible places to connect).

I also need to decide how to deal with moving the turnouts properly when a user decides to go into edit mode and drag sensors around.

I plan to continue working on my website this weekend as well. I want to get some relevant photos on here as well as my walk through powerpoint.

The walk throughs were this week. I received a lot of good feedback—a special thank you to everyone who offered it! Here are the suggestions I received:
    -know your data structures and write the code later (Sergii)
    -make the separation between document object/user interface right away so the amount of fix-up work is minimal at the end (Derek)
    -use 0 & 1 to differentiate curve points from straight points (Caesar)
    -keep track of first/last points on the track and force a connection between the two when finished (Chris)
    -redraw when you notice displacement to a certain degree (Sergii)
    -use a segment object to store type of segment as well as where it is going (Chris)
    -use masking for turnouts (Micah)
    -budget time to specifically work on project and utilize short breaks (Chris & Derek)
    -making progress helps with motivation (DCP)

Based on the advice that I must know and be comfortable with my underlying data structures before anything else, Dr. Pankratz and I sat down and started from square one with my track designer/simulator. Instead of answering the question of “what features should it have”, we worked toward answering “what data structures will allow us the flexibility to do everything we need”.

On the plane ride to Fort Myers, I implemented a document object set up and created all the data structure classes that we discussed. This includes a class for turnouts, trains, sensors and track links. On the way home, I hope to transfer some of the code from my first version of the track designer into this version. I do not plan to spend much time, if any, on the program throughout the week. I am taking a break to enjoy the beautiful Florida sun!

This week, I made some progress on the track design program. I did get the "click the endpoint" curve issue implemented, so when a user is in curve mode, they are now required to click only one point, and then two "control points" appear evenly spaced between the two endpoints. Then, a user can go into "edit curve" mode and drag the control points around. After they move a point, the curve automatically redraws. To expand this (and make it more user-friendly), the idea is to capture the mouse and re-draw the curve as a point is being dragged. This task does not appear to be complicated as C# has a simple way to capture the mouse. However, I am not sure if it works while the mouse is held down.

I am currently working on cleaning this program up. Currently, it simply redraws everything on the same canvas and thus gets very sloppy when several edits are made. I'm implementing a graphics/image where I draw the track to the image and then plaster the whole image to the screen by using the paint handler. As of now, I've cleared everything and redrawn all the points after an edit is made. The problem with redrawing the curves/lines is that I need to know which points are part of a curve and which aren't because I don't draw the curves through the lines--I draw the bezier based on them. I am thinking of writing a class to do this so that each point can say which type it is (straight, mid-curve, curve-endpoint). I may even be able to use this class when starting to look at moving the trains.

My walk-through is tomorrow, and I need to put something together. I am nervous because I feel like I do not have much to talk about--definitely not 20 minutes. I am looking forward to hearing my classmates' suggestions, though. I'm also looking forward to seeing where they're at on their projects. I think if I find that I am behind compared to them, that will give a little motivation to get moving. If we're all around the same place, that might make me stop worrying so much as well. 

I'm not sure if this is typical of the senior project, but I'm feeling like the progress is so slow and little that it scares me a little. This week, I did a lot of "thinking" instead of implementing. However, I do have some pseudo-code written that I hope will translate nicely to my curve issue. Currently, I have a program that allows a user to click any number of points and draw a curve between them. The idea now is to have the user click one point (the endpoint of the curve), and the program will automatically generate two "control points" in which the user can then "edit" the curve by dragging those control points to achieve their desired curve. This should be a fairly simple implementation (I hope!) and done by next week.

I meet with Dr. Pankratz and Gwynn tomorrow afternoon to see the trains work for real! Hopefully this will help give a better idea of where each of our pieces will fit into the puzzle and thus give me a little extra motivation to start making serious progress. We will also be discussing walk-throughs in class tomorrow and I hope have a better idea of how much progress should have been made so far.

I finally started programming the track designer! The program that I have right now is simple and it allows a user to click any number of points. When they are finished, they can click a button to draw a curve between the points. This is not how I want to have the whole track done, but it appears to work nicely for drawing curved parts of the track. The idea I have is a straight mode and a curved mode. When the user is in curve mode, they are allowed to click any number of times (this could be limited), and when they finish, they tell the program to draw the curve by clicking a button. Straight mode could be similar--I haven't really decided yet--except automatically drawing track between straight points. I also need to address the issue of putting in turnouts and how to create the track from there because there will be two places that track can stem from after a turnout is put in.

I did not get as far on the implementation as I wanted this week, but now that I have actually started a program, I hope this week will be better. I would also like to get the images that Brian helped me edit uploaded to the website. My timeline says I should be modifying design this week, so as long as I actually make progress with the implementation, those modifications should be able to happen simultaneously.

I have a working website now, so that is off the to-do list.

Last week, Dr. Pankratz, Gwynn and I went over to the PAC and did some rearranging in the train rooms. Unfortunately, we figured out that the trains are not exactly working right now, so we did not get to play with them.

On a better note, I feel like I got a much better understanding of the project last week. In actuality, the project splits nicely into two parts. First is the program in which users can make their own track and second is the plug-in program that the server is going to talk to in place of the "black box" from Brice's project. I have made some design progress on the first part, and I'm hoping the second will come with time--I haven't actually seen Brice's program interact with the train, so I am having a hard time envisioning how that part will work.

I would also like to give a quick thank you to Brian Milinski for showing me how to use a few features of the GIMP photo editing program. I have no experience whatsoever with graphics, but I wanted to do a little modification to Brice's logo, and Brian helped me figure it out.

In continuation of my "design issues" section of a previous journal entry, I have come up with these questions:
2. How should I go about putting track pieces together?
    The options I have come up with are drag/drop, coordinates, or "selecting" the piece to connect to and clicking an "add" button. I am leaning toward the         last option, but I need to come up with a way to "select" a piece. I have also considered making the first piece drag/drop or having one set first piece in         which users build off of.
3. When should a user be allowed to add a piece?
    If I use the method described above, then the obvious answer is when the user has selected a piece with an open end.
4. When should a user be allowed to delete a piece?
    This is not so simple as the last question. The easiest way for me to solve this seems to be to allow a user to delete only the LAST piece. However, this     does not seem user-friendly because then if they want to remove half the track they created, they have to do it all piece by piece. I haven't come up with a     good solution to this yet.
5. When should a user be allowed to add a sensor?
6. As far as colors go, should the track pieces be able to be individually colored, or should I implement a "theme" in which the background is one color and track/sensors have another?

Clearly, I have a lot to think about and decide on. One thing I definitely plan on having is a track piece object. As of now, I see that piece having data members for the coordinates, its type (straight, turnout, etc.), color, and whether it has an open front end or back end. This probably needs to be modified, but at least I have an idea now. This week, my goal is to begin actually implementing this program. Hopefully the train will be up and working soon and I can begin to move forward with the plug-in program as well.

On Thursday last week, I got the chance to see the real train over in the PAC. I haven't actually played with it and figured out how to work it, but at least I've had the chance to see it. Last week was very busy--I finished up a graduate school application and had an internship interview--so unfortunately, this project ended up below those things on the priority list. This week should be better. According to my timeline, I should be playing with the railroad and getting into the meat of the design. I also need to make sure that my website is actually working. Last week ended in a standstill where I had the site working on my own computer, but not on the compsci02 server.

_The first issue appears to be resolved. A special thank you to Gwynn for showing me what I should've seen myself. All it takes to get my website is a few clicks and I am allowed to download a zipped file containing it all. Then with WinSCP, I should be able to move that folder (once all files are extracted) to the correct directory. I have also made a quick update to my resume, so it is a current version as of 1/31/2012. I have begun to rework my philosophy statement, but that is not complete yet. I am also in the process of creating a timeline for the entire project.

Yesterday, I met with DCP and he suggested creating a "design issues" section. I like the idea, and I am going to begin here. Eventually it could evolve into another section of the site if it grows enough.
Design Issues:
1. In reality, there are only a finite number of railroad pieces (track pieces, sensors, trains, etc.). Should my simulator reflect this, or should it assume that a user can have as large or small of a railroad as they desire?

We also discussed the fact that the simulator should depict a scaled railroad. When a train moves along in the simulator, the time it takes to get from one sensor to another should be scaled with how long it would take on the actual railroad.

I am getting a much better idea of the goal of my project, but am clearly still in the research/planning stage.

_Well, the first bump in the road has been hit! I currently have the website in an editor, but I need to figure out how to get it onto the compsci02 server. As a live site is due on Thursday, my goal will be to have this done by Wednesday. I already have a resume, and I will need to re-work a personal statement that I used for graduate school.

_Today, I received my project. Before I can create a timeline and assign myself mini-projects, I need to take some time to outline the elements of the project and gain an understanding of all that actually needs to be done. Dr. Pankratz will be setting up the railroad within the next week or so, and my goal is to create that outline within a day of my first look at the railroad. In the meantime, I will do some brainstorming.