X-Plugins - Dev Log

Gizmo Change Log - 11.5.25 > 11.10.31

2011-10-31T14:50:00.001+11:00

Below is a summary of the changes Gizmo has seen in the last few months.

There are additional items that have not been listed here because the finer details are still being worked out.

Add gui.setWidgetSize(l,t,w,h)
Add gui.getWidgetSize() and gui.getWindowSize()
"Adds code to change X-Planes widget behaviours. Attempts to make focus change from mouse clicks feel more evolved."
Add OnMouseWheel event support for custom widget regions.
Nagware dialog converted to smaller window with no minimum time on screen, endlessly re-shows at random intervals between 0 and 300 seconds.
Fixed dox for trig.distanceBetweenWorldPoints() - thanks Theo.
Fixed bug with timer.reset( timer_id ) - thanks Tom.
Fixed bug with URL-encoded chars being sent to system() calls.
Added a second low-priority flight-loop-callback to handle low priority tasks.
Adds code to avoid creating datarefs with duplicate names.
Adds gui.setFocus() and gui.blur()
Mutes xp.newCommand() function from outputing various debug info to the Log.txt
Cleaned up gui.apu handler code, better cleaner focus handling.
Created "About Gizmo" menu item which calls into Script to display a nice Gizmo-driven GUI for credit call-outs.
Created "Developer" menu and buried some dev-tool items inside it.
Started adding performance counters so that performance profiling can be done on scripts. (alpha)
Adds new dref.api which includes near-full access to the Array-Datarefs SDK functions.
Modified the way we use std::vectors, should reduce RAM usage/thrash.
Adds gizmo.getBuildDate()
Adds code to help pinpoint GUI code erros with custom widgets; draws the name of the broken callback function that Gizmo can't find or can't run.
Adds new OnLiveryChanged() event and support functions: acf.getLiveryPath() and acf.getLiveryName()
Adds additional code to various scripting API's to prevent C2D events due to syntax errors.
Adds nav.not_found type. Adds full wild-card support to nav.findNavAid()
Adds support for guiWindow_OnUpdate() event calls. Allows for clean place to update text box values, etc.
Adds code to allow gui.setWidgetValue() and gui.getWidgetValue() to work with radio-buttons and check-boxes.
Fixes bug with creating gui.checkboxes and gui.radiobuttons, can now specify the default "checked" value when creating the element.
MAJOR rework of the fmc.api. Please review your code.
Adds timer-delay to the GUI Haiku Error box, should allow meaningful data capture in cases where we have a clash like that with the "Dream Engine" sound plugin where the box is re-shown very rapidly.

Gizmo 11.5.25

2011-05-25T19:46:00.000+10:00

Fixes nagware dialog not respecting serial numbers.
Nagware dialog can now be dismissed again after a delay instead of forcing itself permanently onto the screen.
Now using "lowest common denominator" OpenAL example code so will hopefully work on Windows machines that have poor sound drivers.
http://www.xsquawkbox.net/xpsdk/mediawiki/OpenAL_Shared_Example
Fixed xp.getDataref() so that it works with sim/weather/ datarefs that have "part number notation"... ( square brackets [ ] ) in the dataref names.
Additional physics.api functions are now active, review API docs for more info.
NEW: glu.api - GL Utilities.
Auto release camera control on reboot. May affect other plugins but better than leaving the camera locked by a dud script.
Nagware dialog now always-on-top and always-centered. Can be dismissed after short delay or registration.

Gizmo 11.5.18

2011-05-19T15:04:00.002+10:00

Tweaked OpenAL again after re-reading SDK guidelines.
Please report any clashes, thanks!
New: gui.getCustomWidgetMouseXY()
Returns canvas-relative mouse coords for drawing in Custom Widgets more easily.
Fixed: Event: OnMouseWheel( x,y, wheel,clicks )
This event hook has been documented and tested in sim.
Custom mouse-wheel functionality is now a few lines of code away.
New: gizmo.getActivated()
Returns: boolean; true if a valid serial number is in use, false if not registered.
New:

acf.getPositionGL()
acf.getPosition()

Fixed: Resolved custom mouse cursor bug.
Fixed: bug with acf.getSessionTime()
Builds on Linux again!

Gizmo 11.5.6 Changes

2011-05-06T14:37:00.000+10:00

Modified OpenAL code, hopefully resolves plugin clash. Not tested, but the code change was "OpenAL context sharing" related.
Added: utils.popWebBrowser( url )
- Can be used to open the default web browser pointed at the specified URL.
Fixed and tested gfx.setMaskingTape( x,y, w,h )
New Event: OnFirstFrame
A new event was added to allow for a consistent place for authors to perform init of their dataref defaults.
This event is seperate from OnBoot and runs _AFTER_ the ACF has completed loading.
Fixes acf.getKIAS() - now returns value in knots instead of meters/second.
(Thanks Lukasz!)

Gizmo 11.4.24 Released

2011-04-25T17:57:00.001+10:00

Gizmo 11.4.24 is now available for Mac and Windows - x86 CPU's only.

This is the first release of Gizmo to use the LuaJIT Virtual Machine.

LuaJIT does not support PPC "out of the box".
A PowerPC build of Gizmo 11.4.24 will be made available soon.

The PowerPC version is fully compatible with the LuaJIT enabled version.
Your scripts will still work fine, they just can't run as fast.

I consider this a non issue because PowerPC Macs are a long way behind in terms of performance anyway.

Download your updated plugin here:
http://www.x-plugins.com/gizmo/downloads

Gizmo 11.4 Changes

2011-04-22T16:38:00.001+10:00

Changes since Gizmo 11.3.15 that script authors should be aware of:

Fixed bug on Mac where Gizmo can end up loaded twice and crash X-Plane.
Added additional functions to plugins.api
Added matrix.api
Fixed OnAircraftUnload event bug.
Fixed bugs with memcache.api
Added some more protection to check argument counts being passed in from Lua scripts.
Added utils.getStringFromCPointer( pointer_address ) function.
Added ability to reboot Gizmo's script engine using an Inter-Plugin-Message.
Now using LuaJIT Virtual Machine on Intel CPUs.
Fixes custom-command event system, foo_OnStart() should now fire properly.
Fixes camera.setZoom()
Fixes OpenGL tex-units usage. Defaults to portable values.
Added acf.getSessionTime() function to script API.

I consider Gizmo 11.4 to be frozen and an update release should be available in the next couple of days at most.

Little Black Dress

2011-01-30T15:59:00.002+11:00

C

2011-01-29T19:18:00.000+11:00

minor api change - firmware functions

2011-01-29T18:29:00.000+11:00

gizmo.setFirmware() and gizmo.getFirmware() are dead functions as of 11.2

It's unlikely anyone used these.

OpenAL Software Driver

2011-01-29T16:11:00.002+11:00

Today I had a user report that their sound card wasn't working with the Creative OpenAL drivers we recommend.

Their card is unable to render sound using hardware.

With a few minutes of Googling I found this via Wikipedia:

OpenAL Soft
http://kcat.strangesoft.net/openal.html

Looks like an entirely software based renderer for OpenAL and should hopefully get you out of trouble should you need it.

New firmware loader.

2011-01-29T14:38:00.001+11:00

I've just re-worked the Gizmo firmware loader code so that it's basically the same as the rest of the scripting system to work with.

Where yesterday we had one huge fragile monolithic sacrifice-to-the-DRM-gods of a firmware system, we now have a nice clean easy to update modular system that's easy to write new tools for.

No secret altar rituals required.

If you've been looking at how to have your script run "all the time" for all your aircraft, things just got a whole lot easier.

Will ship with 11.2.

"EngineSim"

2011-01-27T21:42:00.000+11:00

Back in 2008 I ported the NASA "EngineSim" applet to C++ for use in a plugin.

Today I relocated the files I created in 2008 and uploaded them to the Gizmo source tree.

Hopefully we'll be able to get some of the math's from this:

NASA EngineSim 1.7a

...into some Gizmo scripts.

The C++ port of the EngineSim code is available here:

And some basic harness code to make it do something:

Nasa engine-sim example usage code

I make no claim to Copyright or I.P. over the EngineSim classes.
All I've done is port them from Java to C++.
Licenses are as stated in the files.

Are you there? Who's there?

2011-01-26T23:55:00.002+11:00

Started adding basic inter-plugin messaging support.

Gizmo can now react to messages from other .xpl plugins.

They can:

Inject lua script as C-strings. 

Inject Lua blobs. (well, almost)

Send arbitrary commands in to a scripted function handler.

That last one is not real useful at the moment because the data comes across as two numbers.

I need to add another hook so we can just pass string messages into script handlers. Much more useful, easy to use.

The source code is in the unstable branch for now.

Gory details are here...

The idea behind this is to allow for other .XPL's to draw on Gizmos functionality if Gizmo is around.

The secondary function is to "secure" chunks of script.

A third party plugin can inspect the Gizmo.plugin and see if it appears to be trust-worthy before uploading payware script data.

This allows for a form of content protection, whether it uses a serial number, activation key or webcam facial recognition to "unlock" the protected content is another matter.

Doxygen output

2011-01-19T20:45:00.001+11:00

I've invested a lot of time in documentation in the last few days. It's a good task for the summer heat.

I'm working towards a nice friendly Reference Manual - better than the X-Plugins Wiki stuff.

The Wiki works but it's becoming a chore, it's falling behind because it's "work" to keep it up to date.

So, here's some automated output, it's complete and up-to-date - if not very friendly to read.

http://benrussell.github.com/Gizmo/dox/html/files.html

Git on a Mac

2011-01-19T04:33:00.000+11:00

If you're working with Git on a Mac do yourself a favour and check out "Tower".

http://www.git-tower.com/

Very very nice, free beta at the moment.

bug: gfx.drawObject(...)

2011-01-19T00:27:00.000+11:00

Found and fixed a bug with the parameters for the function:

bug: gfx.drawObject(...)

Documentation on Wiki says params are: lat,lon,alt,p,r,h
Interncal C code was: lat,lon,alt,p, h, r

If you're trying to use this API and your results are garbage that's why.

Fixed in source, will appear in next public binaries.

Gizmo 11 now builds on Linux.

2011-01-16T10:32:00.002+11:00

Just updated the Makefiles and ran through a few tweaks - Gizmo is now building on Linux.

No public release yet but the Makefile has been updated in the git repo.
You'll have to tweak it a little for your own needs though.

Minor blackout..

2011-01-16T01:52:00.004+11:00

Had a minor blackout earlier, lost network for a few hours, not even 3G was working.

Something serious failed somewhere.

Anyway, a few hours behind planned schedule, still put the time to use doing code housework while my battery ran down.

Massive amounts of code reworking been going on to make Gizmo's source code "other programmer" friendly.

Plugin Update: Gizmo 11.1.1 - Mac Universal

2011-01-14T19:54:00.004+11:00

DRM free, built from GPLv3 Open Source code available now on Github.

No activations. No enrollments. No hassles.

Just fun.

https://github.com/downloads/benrussell/Gizmo/Gizmo.plugin-11.1.1%20-%20Mac%20Universal.zip

Enjoy.

Plugin Update: Gizmo 11.1.1 - Windows

2011-01-14T18:07:00.003+11:00

Hot off the compiler comes the first public version of Gizmo Open Source.

This version has no DRM what-so-ever inside it.

No activations, no enrollments, no registrations, no lockouts.

Go for it.

https://github.com/downloads/benrussell/Gizmo/Gizmo.plugin-11.1.1%20-%20Windows.zip

Gizmo goes ...Open Source?

2011-01-13T22:29:00.007+11:00

Yep. Gizmo is now an Open Source project. GPLv3.

DRM has been removed.
Encryption keys have been censored.

Stand by for more details.

If you're looking at the Ohloh metrics wondering how the heck it came up with that number, here's a bit of insight:

Ohloh has totalled the entire project. All contributed source code.

Some of this is things like GLee.h, a massive auto-generated header file.
Other things like Lua 5.1.4 sources are included in there as well.

It's not just my personal contribution on the Ohloh bars, it's the total value of all the Open Source / Re-Usable software that went into the making of Gizmo.

I plan on doing an Ohloh-scan of the core parts of Gizmo a bit later on...

Product Activations Restored

2011-01-13T00:14:00.000+11:00

Product activations for Corvalis and Falco products have been restored.

Gizmo customers stand by.

Gizmo goes Pro

2010-10-22T16:54:00.001+11:00

Today Gizmo goes Pro.

I am opening the door to pretty much anyone who wants to play with it.

You can check out the X-Pilot forums for more details of how to work with it and which tools you'll need.

See ya there...

Fault Lines

2010-04-29T03:21:00.000+10:00

At what point does commercial advantage start turning into emerging liability?

At time of writing there is a flurry of activity surrounding the XPlane2Blender scripts.

My colleagues and I have had access to a modified version of these scripts for about a year now, I modified the scripts to provide a way to automate the creation of manipulators in 3D cockpits.

The scripts were modified to suit the workflow of our artist Tom Kyler, you can blame him if you don't like the way it works.

We've shipped a couple of products that make use of these scripts to create some of the most immersive cockpits to be found.
What we haven't shipped already is very far down the development pipe.
I feel we have extracted quite a lot of value from the mods Tom and I made.

However, we're starting to see a competing branch of the scripts emerge on the .Org.
The need for these scripts has reached the point where people (Dan, Mike G, a couple of others..) are making an effort to make it happen.

This is good, it makes the sim stronger, we have higher quality products, people will do unexpected and amazing things like they always seem to do with new tools...

But it's also bad.

It's bad because the way that each script works to create manipulators varies slightly. Very slightly. Stupidly slightly.

To see the OBJ8 + Blender + X-Plane format "fracture" over what is literally the difference between calling an object property "mnp_dref" or "manipulator_dataref" seems completely absurd to me.

It's worrying for a couple of reasons, some of them are noble, some are purely commercial concern.

First and foremost it is concerning because it takes a huge amount of time to create this art.
Detailing these objects and filling out these forms is long, tedious, mostly thankless work.

If we have new talent emerging to create content for X-Plane, and they learn how to use the Org scripts, and they create a library of content, and they come to us at X-Aviation (I work with X-A...) and want to work with us on a team project, we have a problem.

Either their library of work doesn't work with ours, or ours doesn't work with theirs.
Somebody has to go through and re-detail the work with manipulators.

X-Planes history* is littered with this kind of trashing of content formats and it's not done any favours for the sim. (* Most formats are very stable now!)

It's not just the exporter either, I am creating additional tools that assist with either content creation or DRM protection. To have the data fracture is just painful for everyone.

The other big concern is that as time goes by our scripts and our workflow may well become a liability, OBJ8 has grown several features over its lifetime.
Maintaining the scripts and updating them to support these features has become my responsibility, the content authors working with the tools I've made should be able to expect this.

It is probable that with communal effort and attention from sympathetic and multi-skilled** programmer, the Org scripts will grow to a more advanced state than our own.
The margin we continue to hold, if any, is debatable.
Indeed I am trying to have that very debate on the Org at the moment.
(** Mike G is making a valiant effort but by his own admission does not deeply understand all facets of the X-Plane content pipe..)

By sitting on our scripts our one-time advantage could quickly become a somewhat serious disadvantage.

Even if I continue to polish our scripts so that we maintain the technical lead, we will still have diverging work flows. Eventually this is going to bite us in the ass. (See previous mention to teamwork and asset libraries.)

As I see it the time has come to share the scripts, to bring both methods together.

The Org script and workflow has only just become available, there are probably less than a dozen people in the world trying to explore it, the time to merge is now. Before people have invested too much time creating work for one set of workflow or the other.

The x-plugins branch of the scripts already has seriously detailed, shipping, payware cockpits tied to it, to try and switch now would be horrific.

The .Org branch of the scripts is new, the data is stored in a way that lends itself ever so slightly more to a conversion script. There are also less projects using it. The only serious one being the ERJ, that I know of.

On the flip side, we could just continue to sit on these scripts.
Within weeks of now the Org script will be fully stable and mature***, content will start being created with the org-way...
Content that we've already created, that has leveraged the advantage of working manip scripts, is currently in the final stages of development or has shipped already.
(*** The Org scripts are already highly functional, they have some Python call requirements that exclude PPC Mac users, and there are a few hackish things in the src code, but they may well be fully capable of writing a complete, working, manipulated OBJ8 file already. I'm not sure, I'm on a PPC Mac.)

So, content being created from this point on, that would "leverage any value" we have by with-holding our scripts, doesn't really have that much advantage as the Org scripts are almost on par anyway.

Where a year ago withholding the scripts provided 100% advantage, now it provides perhaps 5%, and as detailed in previous ranting, will very likely soon be a liability.

Cattle thieves.

2009-01-14T18:24:00.029+11:00

Date of writing: 29th April 2010.
I have used blogger to file it under 2009 for the sake of chronological reading convenience.

Two weeks ago we published the Mu-2.
The last few days have been consumed with chasing down pirates, sending cease and desist letters, the usual bullshit dance they (the torrenters) love to ignore.

Some success were made, mostly it's just pain and wasted time.

Seeing people rip off the Mu-2 after so much hard work going into making it is very dissapointing.

It reminds me of back in 2006. Getting ripped off, or seeing a good friend get ripped off, is so much fun.

Anyway.

I suggest a DRM solution, one that extends the code that I wrote for XNO2 way back when.
One that ties the new fangled custom aircraft plugins that we're creating too a customers machine, so they can't share it.

When you're watching two years of work go up in a pile of smoking torrents these kind of ideas start to sound pretty good.

Don't think that we underestimate the user apprehension about DRM systems though, it doesn't have a good name.

In general it's invasive, intrusive, restrictive and generally just annoys legitimate users who aren't interested in finding a cracked version.

The development of DRM is usually driven by purely corporate goals, user experience isn't really high priority on the trade off against I.P. that has taken literally millions of dollars to develop.

I'm trying to turn that on it's head. I want to find a nice balance between time investment, security provided and user imposition.

The end result is that we created a DRM system that, 17 months on, still has not been cracked.

New X-Aviation products continue to ship, secured by our DRM system, which continues to improve in capability and user-friendliness.

A quick look through Google for various keywords that suggest other competitive payware items for X-Plane yeilds leads on the very first page. :(

3am, Monday Morning.

2007-04-29T20:36:00.023+10:00

Date of writing: 29th April 2010

From sometime around the middle of 2006 through the middle of about 2008 ish I was running "The Org flight server."

This included reverse engineering the flight server protocol that Vatsim and IVAO were using, creating our own server deamon, upgrading and patching, and most importantly, making sure it was running on Monday mornings (I'm in Australia.) so that people could fly!

A lot of people gave me some very very generous donations over the life span of the flight server, a few times I had to hold it to ransom which was not so fun, but the community responded well and chipped in some funding to keep it going. To those generous people that Donated I say Thank You, Thank You, Thank You. You're donations to freeware projects mean more than you probably think. Their value is far more than monetary.

Anyway, eventually I just lost interest, the old client protocols that X-IvAp and VATSIM use are pretty limiting. Debugging the server was difficult, most issues would only crop up under peak loads.
For a long time we had a long standing memory leak bug and I would simply restart the flight server process every two or three weeks.

I did get to develop a good understanding and appreciation for what the whole community would like from a multiplay experience though. It varies from "I'm a geek, I can make it work, just get me flying with my friend." all the way through to "I don't want to have to do anything except install the plugin and connect".

With a large and diverse model library available for X-Plane, many custom sceneries, custom airports, the emergence of payware and aircraft plugins, and especially custom-animated OBJ8 fueselage shells, this is all getting rather "fun".

I've toyed with the idea of making a new client/server to solve a lot of the problems, only recently have I really created the tech to put together the solution I really want. ;)

Rip off artists.

2006-06-07T14:53:00.042+10:00

Date of writing: 29th April 2010.
This post is a recollection of the events of 2006 to provide some back-story on the DRM.
I have used blogger to file it under 2006 for the sake of chronological reading convenience.

Back in 2006 we were working on the little black number, the H500D helicopter.

Working with Brett and Alex on this was great fun, we pushed animation to where it hadn't been, set the bar and created one of the essential X-Plane add-ons.

Unfortunately, around this time, there was another guy starting to sell helo's for X-Plane.

He approached me wanting some of the same features that I was putting into the H500D.

When I quoted him a figure to do the work, he wanted it for payware after-all, he baulked.

Seemingly uninterested I dismissed it and moved on.

Anyway, he came out with his "own" plugin that he had apparently had a programmer create for him.

Not a real big stretch, they're not hard things to make, life goes on.

So, users start reporting that if you have the H500D plugin and this new payware helo plugin installed at the same time, the sim crashes.
(This is due to a thing called symbol clashing, basically the guts of the plugin are the same and can't coexist inside X-Plane happily.)

Right around now I start getting curious.

A copy of his helo was purchased for forensic diagnosis, upon inspection it was found that he had basically stolen most of what he was selling. This included the ACF mesh and a few other things.

Having my freeware plugin stolen, hex edited (Authors and dataref names changed) and then re-sold was pretty boring.
(This ties into the DRM later...)

It was discussed openly on the Org, with facts well proven, the merchant in question provided various evasive half-apologies to some of the people involved but never admitted to stealing the plugin.

This amuses me greatly because the plugin contains a "signature" about page that contains several hundred lines of hand-carved OpenGL graphics code, stuff that is statistically impossible to duplicate without the intention of ripping me off. A dataref name clash I could accept. Custom graphics routines? Come on.

Note:
This post is a loose recollection of what happened four years ago.
There was for a time a thread on the Org that collected all the details for public record and verification.

If you would like cross reference of the facts and accusations made here please feel free to talk to any long standing member of the X-Plane community.

Day dot

2004-03-06T20:34:00.000+11:00

This post was written 2010-04-29.
I'm using blogger to chronologically sort this stuff out and provide a back story.

According to my profile on the Org I signed up on the 6th of March 2004.

I'd been lurking for a couple of weeks at least and I signed up to announce my XNO utility.

XNO was a small, stand-alone Windows app that talked to X-Plane using UDP 7.15.

The UDP format was quickly broken, I started learning how to put plugins together.

Sometime later XNO2 was born as a native plugin for Mac and Windows. I can't remember if I did linux.

This plugin contained my very first incarnation of the DRM system, it used a license key system that contained the users email address as a deterrent, the idea being that everyone hates spam, and I'd know who was sharing.

The plugin sold moderately, most people would purchase first and try and figure it out later, not really the idea behind demo-ware. You could try it before you bought it, for about 10 minutes.

The result was that a lot of Mac users were eagerly sending me money and then finding out that they had purchased a Windows only product. A lot of refunds were issued.

Eventually I released XNO2 as freeware with a donation requestion, very few people ever donated. Occasionally people send me a dollar. Come on, seriously, a buck?

Oh, the purpose of the plugin? To talk to the GNS-530 package.

You can still find all this stuff out there, people keep it alive, just Google for XNO2/GNS-530/X-Plane and you should find it.

Personally, I recommend just grabbing the Reality-XP add-on.