After some beta releases (we went to Beta after the last news post) which involved tweaking the UI layout more and some basic Kisok Mode implementation, ESS-STS125 has been released to the public. It can be downloaded from the Educational Spacewalk Simulation page on the NASA website.

I've just finished putting up the next Alpha of the ESS-STS125 space. Significant changes include:

• Text captions
• Sound and caption timing is now specified in an external file, no more script editing to tweak.
• Easter Egg mouse detection
• Preliminary implementation, but the hard part is working, we can tell where in 2D screen space a 3D object is. Hooking up clicking etc is straightforward.
• Added a highlight/sparkle effect to the easter eggs, to improve visibility and user interest.
• Easter Egg initial UI
• Gives an idea of how it may look. Buttons will have graphics on them when produced.
• Camera position tweaks
• UI tweaks (Spacewalk naming)

Today I replaced the very rudimentary audio sample system used in the ESS-STS125 space with a reusable module. Instead of having the loading and triggering code scattered throughout the ESS code, it has been brought into one place and given an API. Once this was done, naturally I extended it, adding functions to load an external details file, which now means all timing for audio samples is no longer hard coded in the script.

Once this was implemented, I then added code for the configuration file to contain captions (or subtitles). These are required for 508 compliance. The captions are specified in time as relative to the "containing" sound, which means the samples can be moved around and the same caption information used. Unfortunately, the sound sample timing infomation is still a little clunky, being specified in absolute time (in heartbeats no less, not seconds).

While I've been forgetting to update this blog, I have been working in Digital Spaces related work. Today I demo'd the latest build of the STS125 space. This has been somewhat re-purposed, with the earlier "less is more" philosophy being replaced with a "have as much helpful text on screen as possible" design. Hopefully, this will make it much more accessible to the perpetually new users when this is placed in a kiosk environment.

This demo was built with the 0.12.3 release (oh yes, I put that up on the site), which includes:

• Better handling of OGRE errors
• New input signals which combine mouse movement with a mouse button being held
• The Settings menu has been replaced with a Settings dialogue
• The installer detects Intel based graphics chipsets, and attempts to work around their quirks
• Bugfixes

I am currently working on replacing the scheduler system used by Digital Spaces. The current system expects Components to take a certain amount of time to execute, and if they take longer, it accelerates time to attempt to catch up, while reducing the calling frequency of the delaying Component. The new design separates Components into two types, ones that work purely in simulated time and ones that work purely in real time. The ones that work in real time have no expectations about how long they will take to execute. Instead, the scheduler will look at how long they took, then run the simulated time components in a tight loop until the simulated time (advanced 10ms per cycle, as per the Heartbeat concept) catches up with the real time. Real Time components may also specify a minimum calling rate, to ensure they receive input smoothly. This assumes that simulated time components take less then 10ms (a heartbeat) to execute, however this has shown to be the case. There may need to be some interrupt system put in place if this turns out to not be the case, such as when there is excessive looping in a script file.

Pen-and-paper walkthroughs of this scheduling design show that this will result in more a consistant simulated time to real time relationship. It will also remove the "hurry up and wait" experience that some users are running into, where the current scheduler will attempt to run the system as fast as possible, dropping as many frames as possible, until it catches up, at which point the lowered framerate, which wasn't obvious due to accelerated time, becomes abruptly obvious. And if expectations are correct, it should also result in an increased rendering framerate, as the core scheduler will not be trying to second-guess the delay caused by the renderer, which has generally been innaccurate and resulted in the system spending time sleeping.