For a long time I've been postponing the move for the new code base for Mission-X.
The code base does not bring new features, but it's a re-design of the flow of the code to have a smaller memory footprint, and to allow a easier way to enhance the plugin features - I'll know it later when I start adding more features.
The next revision will be numbered as v2.1x, the base version will be v2.10. I'm doing my best to keep backward compatibility with version v20x, so all missions should continue and work on that revision too.
I'm going to add new beta build links to the site, and if you want to use it, go ahead and send me any issue you have, this will be appreciated by the development team (that would be me ).
What are the new features/enhancements that will be dropped into the new revision branch, well lets start with the PR:
"I'm existed to announce the soon to be, the latest and greatest and almost polished mission plugin - mission-x v2.10..."
I think we all understand the basic idea, yeah PR sometimes sound stupid, but I admit it is time to add new features, and I also admit that last months of writing missions, or helping others with their own missions introduced some drawbacks in the current architecture of the plugin, or the bugs in the features themselves.
So, the first thing to do, is to define the roadmap of the next revision and hopefully to tackle most of the "pre-mature" code that was written to allow specific options for designers.
Here is a short list that I started scribing to myself, but I can't vouch that I'll be able to implement them all:
1. solve the calculation issues when there is negative numbers (re-write the code).
2. Drop-able objects should be linked to the inventory mechanism, I believe this would be more plausible solution, and the simmer will be able to use the inventory as a counter.
3. Speaking of inventory, I'm thinking of re-writing the interface and enhance it to use textures but this is more complex and tedious codding that I'm willing to try.
4. Allow to categorize items as "simple", "drop-able" or "mission" so the plugin will not allow the simmer to remove a "mission" item by mistake. What I didn't resolve yet, is how the "store" will know when to receive a "mission" flagged item. That is not a complicated task, and I don't want to turn x-plane to an RPG like thing.
5. Revise the drop object mechanism. Currently for each target you can add "onHit" or "onHitFailed" events. If you have one target in a "step" there is no issue, but if you have more than one target then messages will crossfire between the two targets.
Scenario example:
You need to hit two objects on same step. For each object you added "onHit" and "onHitFailed" event to tell the simmer what happened.
When the simmer drop the object and misses, it will trigger the "onHitFailed" event for both targets, the plugin does not know how to distinguish between them.
If you think, well this is not such an issue, then think what the plugin will trigger when the simmer hits a target. Well, think some more, but it will throw the "onHit" event and "onHitFailed" event of the second target. Confused simmer is not a good thing in missions.
Now you understand the limitations of Drop Object under v2.0x. On v2.1x I hope to resolve this issue, but it might need a re-thinking and altering the code path. Time will tell.
There would be other things that I'll alter, but I need more time to think it over, since, as you know, time is a limiting factor.
Until next time
Cheers
Snagar