It's Airtight Now

Alright, maybe it isn't quite airtight.

SVN r15 fixed bug 3220471. That bug is the one which reported major memory leaks. These leaks have been tracked down to the Python modules, and dealt with. These memory leaks are no longer detectable.

On my other computer, I started developing a moving map display. It's present in r13&14. r13 lacks some required images, but r14 includes these images. It's a little bit simplistic at the moment, as shown in the screenshot below, but you can switch back and forth to periscope view by pressing the 'L' key.

Man, I'm loving this screenshot feature! Why didn't I do it sooner?

On a related note, I'm working on a contour map generator. It's not in the repository yet, but it will be soon. I'm considering moving it into the Blue November core engine so that it'll be generated automagically at runtime, but that's a ways down the road.

As predicted, it's been a slow week, just like last week. Next week will also be slow, since I'll be at a robotics competition for half of the week. The week after will be much faster.

Stay tuned :)

All Good On X11 Crash

It's been a while since I got some good time to work on Blue November. Unfortunate, really.

But, the good news is that bug 3223835 is fixed! This means that the previous warning on running Blue November on certain systems is fixed! And it still has the new & improved graphics that I added in SVN r10!

Sadly, that's the only bug that's been fixed. It still leaks memory, so that should be fixed by next time around.

My dad forwarded me this. Apparently Cornell is doing a cool genetic algorithm algorithm finder. Is that an awkward phrase or what? But my thinking is that data could come from Blue November through Eureqa, which would reverse-engineer the physics of a specific ship so that PIDTune could use this to tune the PID loops even more accurately. I say this because while the current PIDTune works better than nothing, it still requires manual tuning afterwards. Even if Blue November doesn't end up using Eureqa, it is still Freakin' Cool!

At some point since Spring Break I started working on a contour creator. It isn't in the SVN repo, so I didn't think of it until now. But hey, here's a demo image for the moment:

At some point I want to add depth markings to this. I also want to potentially replace the periscope view with this map, overlayed with current submarine position, enemy positions, and whatever else. Perhaps there can be a key to switch between the two (or even a voice command!).

It's been a slow week, and the next little while will be slow as well, although hopefully a little bit faster than this past week. One thing I want to do at some point is something along the lines of basic website style thing, because the current site is... non-existent.

*WARNING* X Error

Greetings:

SVN revision 10 has a fatal bug causing it (X) to crash (fatally) on certain systems. See bug 3223835 for more information. Bottom line: use only with extreme caution. I'm still working on why exactly it happens, so stay tuned. The last revision that is known to work on the broken computer (X version 1.2) is r7. My higher end computer (X version 1.4) doesn't have the problem.

On a lighter note: I noticed that I don't get E-mails when bugs are submitted, causing me to miss a memory leak bug that I should have been fixing. Instead, I decided to add lighting and blow up the program. Oh well. Live and learn. But now we have lighting!

Spring Break Halftime

Well, SVN r7 and r8 just went in (I just love developing on two machines simultaneously).  So far this Spring Break, I've managed to add a manual (LOL), fix a large number of undocumented bugs, improve the control systems of both the submarine and the torpedo a lot, added a screenshot feature, etc, etc.

The PID tuner that I mentioned previously worked out incredibly well. It still takes some tweaking to figure out what the environment is, and the PIDTune UI could be improved, but it is infinitely better than the PIDLS (PID Learning Service) stuff. PIDLS gave us SVN r1-6, which sucks. PIDTune, however, is in r7, and it took a mere two days to write the program and tune both object's rudders. A little bit of overshoot here and there, but nothing major.

Joy to the world - We have an actual map! Well, more actual, at any rate. Here's a land mask for it (white is land, black is water):

Did I mention that I added a screenshot feature? The funny thing is that it's been there all along, but it's just been commented. It used to be that all rendering went into a series of screenshots. Now just press the 's' key, it'll save it into ./Screenshots. Here's a picture of the new and improved UI:

Notice the speed-o-meter just to the left of the pitch gauge. That's the only change.

Halfway through Spring Break!!!!!!!!!! :'(

PID Loops

I've been playing around with the SF bug tracker - it really comes in handy!

Anyhoo, I think I found the cause of bug 3198106, which was starting to vex me. However, the solution is also elusive: Either we do a server side clipping of all contacts under, say, a Newton or we have the client report which ships should record contacts. Or maybe both. For instance, the testShip doesn't even have a function to deal with contacts, so no point sending the data across. But, as long as we don't crash them into each other, we should be safe ;)


Oh yes - Bullet, the physics library, does all collisions in terms of contact points. The Python files have callbacks for these contact points. For example, the torpedo uses it to acts as an explosive trigger. Bullet is running on the server, and the Python files are running on the client.


I think that 0.0.1 will be released at the end of Spring Break. When it is released, I want to have the destroyer model up and running. I also want to have MUCH BETTER PID LOOPS for every model.


Have I mentioned my bipolar view of PID loops? They are incredibly useful in ship control, so I love them. However, for some reason or another I can never get my PID loops to tune correctly, so I hate them. The average image of me trying to tune them is me sitting in front of my computer for hours (days?) on end, downing bottles of Advil along the way. I've tried to setup automatic PID loop tuners, but it didn't work too well. The one I tried is the 'PIDLS' in the torpedo.py and base/Ships/pid-trainer.py files. I'm considering empirically getting the response curves for the system and plugging that into a PID loop simulator (which are hard to find for free, so I'll have to write one), just so that I can get faster turnaround times.