MissionX Developer Blog

Almost there

26/8/2019

Hi everyone,

Mission-X v3.0.224x is nearing its final phases. Most of the features and changes were implemented and tested, there will be always something to tweak or make better but lets take a short look on the changes that will be in this build:

Shift the mission build from: "goal->objectives->tasks" to "flight leg=>objectives=>tasks".
This might look as a simple shift but I think it make more sense and make building the mission less "dramatic".
Multiple "everything" (well sort off).
You can create multiple <flight_plan>, <objectives>, <triggers> and <message_templates> elements. This should make it much easier to design your mission file as a set of flight legs with all its elements grouped together (not in the same element. see my previous rant on this matter).
Plugin is backwards compatible with v300 mission files (but I suggest to convert to the new element/attributes naming).
Renamed all "goal" elements attributes to be flight "leg" centric (I hope I have not missed anything).
Templates have been converted to the new element names.
Documentation were modified according to the new changes.
Renamed few of the attributes to represent better their meaning.
Done some UI tweaking:
- Removed the 3rd party UI library. I'll stick with the generic one and I hope to extend it in the near future.
- Done some VR UI modifications so it should be easier to read the different descriptions without them being cropping.
  The drawback is that now the VR window is bigger.
- In random missions, You should be able to see a short description of the template before you generate the mission file (if it was implemented) and after mission file has been created you should see a snippet of the briefer information.
Fixed some bugs in the Random Mission engine.
Time: when setting time it is always calculated as local time (global_settings).
Enhanced messages: I have ranted about it on other blog post, but I would like to emphasize that it should be easier to create multiple messages to fit into the "MX-pad" or just to create some kind of a dialog. You can also set the time, inject metar file or call a script when message ends.
These enhancements can greatly decrease the amount of code you need to do to achieve the same.
Added embedded functions to handle the new "time-lapse" and "inject metar" capabilities.
I suggest to first try and use the feature as part of a "message" instead of writing the same in a script.
Wrote a simple perl script to convert metar files to x-plane metar format.
Any modification to the script will be welcome and I'll publish it on other page.

These might seem like a short list, but much work was purred into it and I'm happy to reach this state of the plugin where I hope to publish it soon with the second year of version 3x.
The only thing that prevent me from publishing this build is the new mission that I'm working on and helps me test the plugin too.

Until next time
Have great simming
Saar

0 Comments

Message Empowering

18/8/2019

0 Comments

Hi All,
Some exciting news, well at least that is what I think :-)
It all began when I started writing the mission from Vancouver to Anchorage in GA when I decided to start and make some fixes and enhancements to the plugin, I mean after almost 8 month of Random Engine coding and tweaking, it is time to return to basics and enhance the plugin itself.
But.. When I started enhancing I also started tweaking the mission data file which leads to breaking changes... well not really since the plugin should be compatible with v300 missions, only the Random templates were modified in such away that they are not compatible, but for that there is a simple "find replace" list that should allow an easier transition from old to new format.

For the mission files, I strongly suggest to transition it too, I have not prepared a list of "find..replace" words but I hope to provide it in the designer guide appendixes.

So what is new
As of today, I have decided that messages should not just be a means to send a message, but they should have trigger like capabilities, meaning, messages should be able to:

All messages are flagged as mx-pad messages, you can use labels and label colors.
Call other messages ("next_msg") - this will allow to make a scripted conversation but without a player input.
Change time at the end of the message ("set_day_hours" or "timelapse_to_local_hours" or "add_minutes" ) - you should be able to set the time in few ways but only one attribute will work.
"set_day_hours" allow you to set any day of the year, while the rest are limited in time. "timelapse" is limited to 24 hours and "add_minutes" to 4 hours.
Inject METAR file ("inject_metar_file") - A simple way to inject a custom metar file at the end of the message.
Call a script ("post_script") - This has not been tested yet, but you should be able to auto execute a script or scriplet at the end of a message broadcast (after the time to display it has passed), it won't occur while the message is broadcasting.
It is important to be aware that the script scope is very narrow, it will probably won't know which "flight leg" you are in let alone an objective or task. This is still not fully tested so the limits are currently not knows, I might need to add a few functions to allow manipulation from QMM scope.

I think for a mission designer these capabilities should be useful since he/she:

won't need to write a single code to create a dialog like messages and
It would be easier to fit the message to the mxpad, we could split long ones to 2 messages and just call the second after the first one.
It will allow to make certain actions at specific moments an easy task.
Decrease the need for long or complex code in such cases (oh, I already mentioned that, so see the first reason).

I really hope to publish the first beta soon.

Here are some snippets I picked from my mission:

If you think there are other enhancements to add to to our messages, please send me an e-mail: "snagar.dev@gmail.com".

Until next time
Blue Skys

Saar

0 Comments

Legs and Time-lapse

4/8/2019

0 Comments

Hi all,

Its is time for another quick update.
So far I was able to finish the skeleton of my next mission. It is a long one so I need to add more staff into it before I can publish. One of the benefits to writing missions is you get the opportunity to test your own plugin and come up with new features.

Replacing Standard
I never want to break the work of others so any new standard or feature I try to implement alongside the original standard. The most profound addition to the current mission dialect is the use of the elements: <flight_plan> and <leg> over <goals> and <goal>.
When I use <goal> it is a little to dramatic for me, so it makes more sense, to me, that we should use "leg" as describing a part of a course.
I have added the support to only use these elements instead of the <goal> one and also modified all attributes to include the word "leg" instead of "goal", for example:
"next_goal" => "next_leg"
I'll have to update the designer guide to reflect all these additions.

So now we should think of a mission as a set of "flight_plan". In each leg we might have one or more objectives and in each objective we have one or more tasks.
I hope that this will make the mission concept easier to grasp.

You can still use the old names and the plugin should be able to parse them all, but I strongly suggest to transition to the new standard once it will be published.
The only exception is the Random Engine. All templates must be modified with the new standard.

New Features

Time-Lapse
While working on the new mission I found that the transition between one "leg" to the other was to abrupt. One of the things I wanted to allow is to change the time but not as an immediate change but to transition to the time asked in a short period of time. Example, if you finish a certain task, we would like to move the clock 2 hours into the future (never backwards). If previously I would have set the clock to the exact hour, the outcome would have been an abrupt change of the surrounding lightning.
Suggestion: provide how many minutes to add to current hour, provide in how many cycles (seconds) you would like the transition to take place and the plugin will change the time gradually over the cycles. This mimic time-lapse but in much shorter period of time. It will also transition the pilot to the new time and scenario.

To achieve that, I have added two new script functions: "fn_timelapse_add_minutes" and "fn_timelapse_to_local_hour".
The first function add minutes to current time, and the later will transition to the next closest local hour that you provide. The limit is 24 hours in one time-lapse and not more than 24 cycles (seconds) to finish the time-lapse.
Please pay attention that we are referring to local hour and not UTC/Zulu hour.

Moving items
Once of the things I wanted to add, long ago, was to allow a designer to move items between inventories.
Introducing the function: FN_MOVE_ITEM_FROM_INV. It will allow you to move and item to other inventories or to just discard them. Simple but effective.

Get task information outside "Leg" scope
Although I covered this topic more than once, I'll have to explain it again, and I'll try to add it in the designer guide: When using external scripts, their scope is not the same for all.
This means, that scripts that were called from inside Leg element will probably see most of the seeded parameters like "name of current Leg( former goal)/objective/trigger or task". But if you call a script from higher level like from a "Leg" then some information is not available since they are not in the right scope.
Example:
<link_to_trigger name="trigger_name" />
When we link to a trigger from a Leg (former goal) element, then the <task> and <objectives> are out of scope for that code. They do not exists for it, therefore we cant use some of the functions that were written for specific scope and should be deprecated to minimize confusion.
Example:
FN_GET_TASK_INFO() - Good only for <trigger/task> based scripts but not to <Leg/Goal> based scripts. The new and improve function is fn_get_task_info_in_objective. That way we can call it from any scope of code.

I hope to go over the list of functions that we can use in scripts and see if they can be used in all scopes, that way there would be less confusion when and how to use a certain function or not.

Cheers
Saar

0 Comments

Its a Goal no its a Leg

1/8/2019

0 Comments

Hi Everyone,
It has been some time since I wrote here, its not that nothing was not brewing and going with Mission-X it was concentrating work on the Mission Generator part of the plugin, some vacations and the fun of VR flying, which I haven't done for quite some time.

So what is going on
Well, I decided to start writing my crazy and long Alaska Adventure. My idea to write it has been many years back but only now I'm writing it. Currently it is just in its skeleton part but at least the first adventure will be a long one that you will need to finish in days.
This adventure is meant to fly from Vancouver Alaska to Anchorage in a bush plane (yes you heard me right) but you can pick other prop type plane if you so choose.
The main idea is to enjoy the flight and the sites. I strongly suggest to use Ortho-photo Scenery to increase the visual part of the flight.

While working on the mission file, I came across the word "Leg" which in my case means "part of a track or course". Then I thought of the <goal> element which defines "something that needs to be done", but when I thought of it over, I begin to think that "<legs>" and "<leg>"
might be more appropriate to describe the "main goal" we need to do. So instead describing goal-A and goal-B, we should describe Leg-A and Leg-B that eventually will lead to the final Goal. I also hope that using these elements to describe the mission will make it simpler to comprehend when dealing first time with the plugins concepts.
In order not to break compatibility The plugin will support the <legs> and <leg> elements, hopefully in the next build.

The image represents an unfinished flight plan and locations, so things would be change and the adventure will be split into at least two parts.

More changes

Another thing that I wanted to implement is the ability do define more than one "<goals>" or "<triggers"> element, so a mission designer could organize his/her mission file according to the Objectives at hand.
The next build will allow you to order the mission file as you wish (well almost), you will be able to create one or more elements like:
<goals>
<legs>
<objectives>
<triggers>
<messages>

By doing so, you could design each "Leg" sequentially to make focusing on specific content much easier.

Here is an example of how we did it so far, there is only one root element for each type, one <goals> one <triggers> one <objectives> and so on. This makes life hard while designing a mission, it just hard to keep track of the changes and modifications.

As opposed to the old way, In the next screen shot you can see I defined three Legs (Goals) sequentially, that way I could focus only on one part of the adventure each time. The content was easier to track and fix if needed.

while I work on this mission, I had new ideas that I would like to add to the plugin, but as of now I prefer to concentrate on finishing the first part of Alaska adventures. Their might be few iterations of this adventure, but I really hope to nail it the first time since no one will fly these routes more than once... probably.

Until next time
Saar

0 Comments

Almost there

Message Empowering

Legs and Time-lapse

Its a Goal no its a Leg

More changes

Author

Archives