If you downloaded the latest designer guide and compare it to v1.10 designer guide, you will notice that not many features where added, more or less, but almost every feature added required a steep learning curve to implement it correctly. Now, you might say: "what is so complicated", well here is the short version of what it takes, for me anyway, until I implement a feature.
- First: There is the idea/request of a feature.
- Second: Break the feature into smaller parts, and try to explain it in short sentences what the feature means, and what is needed to achieve it.
- Third: Test in real world if the feature was already been implemented, how it was done. Search for examples, read the forums etc...
- Forth: Decide if the effort worth the work. Is the solution is cross platform in its native form, or does it need different implementation in every platform.
- Fifth: If the feature does not need the X-Plane SDK, then build a prototype and test the core of the feature. For example when I started to work on "area" with "slope", I had to re-learn basic geometry and test my calculations in C.
- Six: Implement the feature into the plugin, add it to the correct routine and call it as necessary.
Add debug information, to help narrow bugs, and unfinished or incorrect implementation of the feature. - Seven: Test the feature in X-Plane.
Do at least one test for each aspect of the feature, and analyze the debug log file, to better understand what went wrong. - Eight: If feature works correctly, then add it to the Designer Guide, and implement it into a demo mission. Get some snacks, and just stare at nothing ( tv or movies are good examples ), it helps "rebooting" the inner mind systems.
Why do I tell you all this, you ask...
Well, currently I'm working on implementing an Inventory mechanism into the plugin. It started few months ago ( relative to oct 2010 ), just before I released v1.10, but just now I found the time and strength to try and implement it.
I had a good understanding what it will take to implement this, and though there are many options and ways to implement inventory mechanism into ones code, I decided to use an embedded database solution. To my advantage, if I may add, I'm working with Databases today, so the concept is not new to me, but, I never worked with embedded databases, not to mention using C/C++ code. The search for such a database was not hard, sqlite was my first choice, and after checking other embedded databases, I decided that "sqlite" implementation is best as of features and complexity. After all, the inventory is small in size ( probably less then 100 rows ) so fetching data should be simple and fast.
After I defined the solution to use, I had to test that it compiles and work on all platforms. I found some basic examples, and tested the solution on all platforms, not in x-plane though. As expected from such a highly praised open source product, it worked quite well on all platforms which left me implementing a basic db interaction into my plugin.
I did a small test, which included connecting and reading one row of data, from a pre-defined datafile. It worked well on all my platforms, and when I sent it to my colleagues, it worked fine for them too.
This is when I stopped working on this feature. I was in the middle of adding other features to mission-x v1.20, and new that implementing such a feature will consume to much time and energy, there was the moving 3D object I worked so hard to finalize and "Area" and "Logic" which, in the overall, will benefit the plugin more in the short and long term. I also knew that the inventory was, in a way, a whim from my side, but I also believe that others can benefit from it.
So where does this feature stands....
Well, as of this writing, I have the basic classes and code that interacts with the datafile. They are not fully modified to work correctly with the plugin but the main business logic has already been tested before, so few hours of work should clean this issue too.
What is left then... lots of work, to be honest... There is the widget that need to be drawn, and to decide how the "buy/sell" mechanism will work, both visually and programmatic, in the background, and other small staff that popes when you construct such a feature. At the end, I really hope I'll implement it correctly.
Designing decisions:
- A plane can only hold 5 items in its inventory.
- Items has a counter, so one inventory slot can, for example occupy 3 items of same "bar-code".
- There are consumable items and non consumable ones ( fuel vs luggage ).
- Since Items have weight, it will be added to the payload.
- Consumable items, will be usable only on ground ( for now )
- Inventory widget will be simple and intuitive, no bells and whistles are needed.
- Inventory will not replace "Weight" element, which already been implemented.
There is much work to be done, and testings to be made.
I hope that until the end of this year I'll have a working version but if it will take much time and effort then there is always next version... ;-)
Cheers
Snagar