I had the urge over the last week to play some more with Blender. After brushing up on the excellent tutorial “Blender 3D: Noob to Pro”, found at http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro, I was back at it. I began by creating a couple of simple models, shown here — a bench and an umbrella, as found at EPCOT: Future World West.
I’ve once again been delighted with the elegance of Blender. Although intimidating at first, once you get the hang of the basic controls, you’ll wish more applications were like this.
I’ve recently added AJAX capability to the flightphys site, which was my first foray into the world of AJAX. I also took advantage of the excellent Shadowbox library. I’ve walked away with a few lessons:
Making simple AJAX calls is really simple once you’ve gone through a few tutorials. I initially tried to use a few different libraries and couldn’t quite get things to work the way I wanted to. So I buckled down and learned some raw AJAX. A good tutorial is at w3schools. After letting the material sink in, I was able to process a form by running some server-side PHP and returning HTML through an AJAX call.
Shadowbox does not like to be auto-initialized when using AJAX. Usually, you set up Shadowbox in your page’s <head> section and wait for the page’s elements to make the calls. However, if you’re making AJAX calls, you may not want Shadowbox to run until you’ve loaded the correct elements. To accomplish this, modify the skipSetup property in shadowbox.js from false to true. Then, after your AJAX call, add calls to Shadowbox.setup() and Shadowbox.init().
If you are calling AJAX from a form, chances are you do not want to actually submit the form. So you add an onClick() event to the form’s button (which, by the way, is now just a type=”button” and not a type=”submit”) and everything is fine right? Almost. If the user presses the Enter key, the form will still try and submit. To prevent this behavior, you’ll want to add an onkeydown() handler to your form. In the handler, check if the Enter key was pressed, and handle it there.
These were just quick overviews of the solutions. If you’d like more detail, please let me know.
Obviously, radio communications are at the heart of this sim, so here is an example of how a transmission from an aircraft object, makes it to an air traffic controller object:
The Aircraft queries the Frequency Manager to see if it is clear to transmit on the frequency currently tuned to by its Radio. It also passes the message, so the Frequency Manager can determine the context. For example, if NWA123 has not yet contacted the controller, the Frequency Manager will check if the controller or any other vehicle is waiting for a reply. If not, it will pass on the message and return a “transmitted” notification back to the aircraft.
If the frequency is clear, the Frequency Manager dispatches the message to the ATC Collection.
The ATC Collection then attempts to find the controller that the message is intended for, and passes the message to it.
The Frequency Manager object was created to keep track of all the logistics associated with each frequency in use. Without it, you could simply pass a message directly, say from a human controller to a particular aircraft, but then you wouldn’t have any entitly tracking things like: is someone currently talking on this frequency?, is someone waiting for a reply? The Frequency Manager becomes the object that all other objects implementing the Radio interface can talk to, without knowing about the other types of objects capable of receiving the transmission. Another example where this setup makes sense: a controller transmits to an emergency vehicle without having to know how to get it’s message to an “emergency vehicle” object. It just has to transmit to the Frequency Manager.
The last few days I’ve been stepping through the documentation and tutorial videos for Microsoft’s XNA Game Studio. This is a framework library for developing games for Windows and XBOX 360. It looks pretty sweet, and best of all, I can develop games in C#.