I have been trying to figure out a way to change the appearance of an FSX model based on visibility for a better part of the year 2012. In the end, I turned to SimConnect, and in early 2013, I began to have some success. Eventually, I realized the potential of this approach to do much more than just show models depending on one single variable in the simulator.
Later in spring, Sándor Tar from LH Simulations expressed some interest to use this approach in their upcoming product – the now released, wonderful, LHBP Liszt Ferenc scenery. And thus, objectPlacer was born.
In the course of the year I have worked on making the approach work, incorporate various functions according to needs of LHSimulations, and making it work for all end customers, and in Prepar3D.
I am very glad to call the current iteration of the product a success. Successful undertaking, as it may be, it has its own problems. Its dll format makes it sometimes problematic to load, it is not quite extensible, cumbersome to work with from a scenerymakers perspective.
With this in mind, I will be working on a new version – leaner, better, nicer, easier. Available to all to license.
This will still take a while, though. Still – I would like to present the capabilities of the current iteration – and projections for the new one – and see your feedback.
So – first – to the current objectPlacer.
As I have already mentioned, this piece of software is currently deployed in the LH Simulations LHBP scenery for FSX (and soon, P3D 1.4 and P3D 2). I can personally very much recommend trying this scenery – should you be inclined to, you can get it at lhsimulations.hu or at SimMarket.
Many structures in this scenery are placed dynamically according to various situations that can happen in the simulation. One of the most visible to a regular user, that is quite difficult, if not outright impossible to do in pure FSX scenery – is the situation in winter. You may notice, that when you fly in winter, not only the photo ground is changed to include snow, but also other places such as roofs of the buildings. After all – do you get rid of the light snow layer on the roof of your house?
I have mentioned in the beginning that my original aim was to allow me to control the lights according to weather. This – too – has been achieved. By polling the FSX weather system, and parsing the METAR received, I am able to control the appearance of any object, in this case, lights, so that they appear when the correct visibility is achieved.
Some other variables available are time of day, both in hours and in the familiar day/dawn/dusk/night structure FS assigns automatically, radio frequencies (for pilot operated lights) or squawk code – say if you wished to send a pilot with an emergency code some trucks to await him on threshold.
With availability of functions supplied by WinAPI, it is also possible to access certain files, such as scenery.cfg, or access registry etc. which also lends to some possibilities – one of which being that the DLL will check whether the scenery is active in the simulator the DLL is loaded by, and will not work its magic when the user actually wants the scenery turned off.
Now, there are many good things about the software, allowing the developer very wide and precise control about object placement… but, as it was mentioned, there are drawbacks. I hope to eliminate most drawbacks and continue to work on the good parts for the new version of objectPlacer.
So – what does it mean in practice? Let me present the preliminary ideas. I will try to build upon these and your feedback, and hopefully I will be able to provide.
The first problem – that of extensibility – was the one I knew from the beginning I would have to address. I have been thinking about it, and I hope that there is one solution that would help with several problems at once, including this one. As mentioned previously, having the software in dll form brings about several problems. I have decided to go the way of an executable application for the second generation of objectPlacer software. Making the software an executable should, among other things, enable me to load several scenery definitions and work from there. Of course, this would be possible with a DLL at least to some extent – maybe even fully – so forgive me if those more experienced of you find errors in my reasoning.
Anyway – one approach is being presented a couple of threads over by Jeffrey Stähli. Loading an xml or another similar structured plaintext file does, however, present several difficulties in my opinion. Not least of which is the actual fact that the file can be read by anybody. That does not mean a problem for everybody, but I imagine there are people developing payware products that will prefer not having all this information open to public eye. This problem, I believe, would be alleviated by using an actual compiled DLL for each scenery, which would be linked to the objectPlacer executable. Such approach would, I believe, also bring several more advantages. Some of these would include near unlimited variability to work with logical requirements for any object or group of – any combination of requisites, nested, combined with if statements, and statements, or statements or similar can be combined into one big logical switch that will, in the end, produce a simple yes or no to a group of objects placement. Another advantage would be ability to run more complex custom code for your scenery inside the DLL, which can range from reading a configuration file to a complex copy protection code that can be tailor-made to your specific requirements.
Of course, writing such code can be problematic for those of you who have no experience with programming, and/or no desire to learn and write your own code. For the more complex requests I imagine I will be able to help you with this, but for the basic ones, I plan to provide a GUI based developer tool, that should allow simplifying the writing and compiling process greatly.
I do have yet to design the GUI itself, but I imagine that the software will allow you to comfortably define each object with placement information similar to what you use currently for placement xmls, assign it to one or more object groups, and specify when any of these object groups should be shown based on available variables; and finally to generate full set of source code files and compile them using some of the available compilers.
Another possibility I would like to mention is object animation. As far as I know, there is currently no way to animate scenery objects depending on variables. The objectPlacer module does, however, enable this, and it is possible to animate objects both using FSX environmental variables as well as custom variables. In effect, this allows triggers such as weather or menu options to drive animations. A very simple example would be opening and closing hangar doors. You can see one of my early tests in this video (sorry about the audio quality) http://youtu.be/tYA4OD3obD8?t=38s
So, I would like to hear from you guys – what do you think of this then? Do you have any specific features in mind that you would like to ask about? Would you be willing to use this module? If you are developing payware sceneries, would you be willing to pay for it? Please let me know.
Later in spring, Sándor Tar from LH Simulations expressed some interest to use this approach in their upcoming product – the now released, wonderful, LHBP Liszt Ferenc scenery. And thus, objectPlacer was born.
In the course of the year I have worked on making the approach work, incorporate various functions according to needs of LHSimulations, and making it work for all end customers, and in Prepar3D.
I am very glad to call the current iteration of the product a success. Successful undertaking, as it may be, it has its own problems. Its dll format makes it sometimes problematic to load, it is not quite extensible, cumbersome to work with from a scenerymakers perspective.
With this in mind, I will be working on a new version – leaner, better, nicer, easier. Available to all to license.
This will still take a while, though. Still – I would like to present the capabilities of the current iteration – and projections for the new one – and see your feedback.
So – first – to the current objectPlacer.
As I have already mentioned, this piece of software is currently deployed in the LH Simulations LHBP scenery for FSX (and soon, P3D 1.4 and P3D 2). I can personally very much recommend trying this scenery – should you be inclined to, you can get it at lhsimulations.hu or at SimMarket.
Many structures in this scenery are placed dynamically according to various situations that can happen in the simulation. One of the most visible to a regular user, that is quite difficult, if not outright impossible to do in pure FSX scenery – is the situation in winter. You may notice, that when you fly in winter, not only the photo ground is changed to include snow, but also other places such as roofs of the buildings. After all – do you get rid of the light snow layer on the roof of your house?
I have mentioned in the beginning that my original aim was to allow me to control the lights according to weather. This – too – has been achieved. By polling the FSX weather system, and parsing the METAR received, I am able to control the appearance of any object, in this case, lights, so that they appear when the correct visibility is achieved.
Some other variables available are time of day, both in hours and in the familiar day/dawn/dusk/night structure FS assigns automatically, radio frequencies (for pilot operated lights) or squawk code – say if you wished to send a pilot with an emergency code some trucks to await him on threshold.
With availability of functions supplied by WinAPI, it is also possible to access certain files, such as scenery.cfg, or access registry etc. which also lends to some possibilities – one of which being that the DLL will check whether the scenery is active in the simulator the DLL is loaded by, and will not work its magic when the user actually wants the scenery turned off.
Now, there are many good things about the software, allowing the developer very wide and precise control about object placement… but, as it was mentioned, there are drawbacks. I hope to eliminate most drawbacks and continue to work on the good parts for the new version of objectPlacer.
So – what does it mean in practice? Let me present the preliminary ideas. I will try to build upon these and your feedback, and hopefully I will be able to provide.
The first problem – that of extensibility – was the one I knew from the beginning I would have to address. I have been thinking about it, and I hope that there is one solution that would help with several problems at once, including this one. As mentioned previously, having the software in dll form brings about several problems. I have decided to go the way of an executable application for the second generation of objectPlacer software. Making the software an executable should, among other things, enable me to load several scenery definitions and work from there. Of course, this would be possible with a DLL at least to some extent – maybe even fully – so forgive me if those more experienced of you find errors in my reasoning.
Anyway – one approach is being presented a couple of threads over by Jeffrey Stähli. Loading an xml or another similar structured plaintext file does, however, present several difficulties in my opinion. Not least of which is the actual fact that the file can be read by anybody. That does not mean a problem for everybody, but I imagine there are people developing payware products that will prefer not having all this information open to public eye. This problem, I believe, would be alleviated by using an actual compiled DLL for each scenery, which would be linked to the objectPlacer executable. Such approach would, I believe, also bring several more advantages. Some of these would include near unlimited variability to work with logical requirements for any object or group of – any combination of requisites, nested, combined with if statements, and statements, or statements or similar can be combined into one big logical switch that will, in the end, produce a simple yes or no to a group of objects placement. Another advantage would be ability to run more complex custom code for your scenery inside the DLL, which can range from reading a configuration file to a complex copy protection code that can be tailor-made to your specific requirements.
Of course, writing such code can be problematic for those of you who have no experience with programming, and/or no desire to learn and write your own code. For the more complex requests I imagine I will be able to help you with this, but for the basic ones, I plan to provide a GUI based developer tool, that should allow simplifying the writing and compiling process greatly.
I do have yet to design the GUI itself, but I imagine that the software will allow you to comfortably define each object with placement information similar to what you use currently for placement xmls, assign it to one or more object groups, and specify when any of these object groups should be shown based on available variables; and finally to generate full set of source code files and compile them using some of the available compilers.
Another possibility I would like to mention is object animation. As far as I know, there is currently no way to animate scenery objects depending on variables. The objectPlacer module does, however, enable this, and it is possible to animate objects both using FSX environmental variables as well as custom variables. In effect, this allows triggers such as weather or menu options to drive animations. A very simple example would be opening and closing hangar doors. You can see one of my early tests in this video (sorry about the audio quality) http://youtu.be/tYA4OD3obD8?t=38s
So, I would like to hear from you guys – what do you think of this then? Do you have any specific features in mind that you would like to ask about? Would you be willing to use this module? If you are developing payware sceneries, would you be willing to pay for it? Please let me know.
