Reading autogen configurations

I have changed the way the autogen configurations are read into scenProc. From tomorrow the development release will use the Flight Toolkit SimProp library to read the autogen configurations, instead of using spb2xml in the background to decompile to XML.

This change should not really be noticeable, since the new approach should return the same information for the auto completion. While switching to the new library I have also improved the way the autogen configuration is read a bit, so it should be even more stable. But if you notice any issues with the development release, just let me know.

Cell attributes and some other changes

Now that the stable release of scenProc is out, I can finally put some changes I have been working on in the past weeks in the development release. So here is a quick update of the things that I have added today:

  • The CamelCase step names I talked about before have been introduced. There is an option in the options to use UPPERCASE if you like that more.
  • Gridcells can now also have attributes. Before only features could have attributes, but cells can now also. These are now used to filter which cells should be assigned a texture or height settings. Obviously you also need steps then to add these cell attributes, three options are available now: AddCellAttribute, AddCellAttributeFeatureCount, AddCellAttributeIfInside. Hopefully the names speak for themselves, and else check the help tooltip.
  • You can compare two attributes in a filter now. Before you could only say attr>10, but now you can also say attr1>attr2.
  • And probably some other small changes I have forgotten about now…

Especially the changes in the second bullet can mean that you old script doesn’t work as before anymore. So be careful to check your script when updating to this release.

scenProc 1.0 released!

balloon-bouquetIt’s party time! The release of the first stable version of scenProc is there, I have just put scenProc 1.0 online.

Obviously it’s based on the latest development release, if you download the stable release now you will notice the main difference is the completed manual.

Now that I have a stable release out, I can go ahead and implement some of the changes I have planned for scenProc. These will change how certain things work and might give some discussion initially, but that’s why I think it’s good to have a stable release to fall back to in case of emergency.

So let’s celebrate this release now and from tomorrow I’ll continue to improve this tool in the 1.1 development release.

To save or not to save

save_dont_saveAbout a week ago I changed the default behaviour of scenProc. Before the configuration file was saved automatically every time you run it, but some users complained that this was not what they expected. Since I agreed it was not very “nice” to automatically save on each run, I changed the behaviour to only save when the save button was pressed.

All sounds fine so far, but since this change I noticed that I often lost changes I wanted to save, because I forgot to press the save button. So today I decided to add a warning when there are unsaved changes when you quit or try to load another document. The message will just ask you if you want to save before continuing or not. So hopefully this will minimize lost edits.

And to make clear there are unsaved changes I do now also display the asterisk behind the filename in the window tile when there are unsaved changes.

scenProc stable release almost there

Just this morning I realised that I have fixed all the remain issues I had marked for the scenProc 1.0 release. So except for finishing the user manual, release 1.0 of scenProc is done. So I think I’ll try to focus on the user manual first now. Having a stable release as a fallback is probably a good idea, since I have some new features in mind that will mean some things have to be recoded in scenProc. Such actions might always give new bugs, so then it’s good to have a stable fallback. Hopefully I can have the manual done in a week or two.

Bring out the camels

While working on some new scenProc feature I also decided to experiment with a new naming scheme for the steps. This was suggested on the forum a while ago to make the script more readable. I’m using CamelCase now for the step names. So that means that a step like ADDATTRIBUTEIFINSIDE would now become AddAttributeIfInside.

I think it’s an improvement so I plan to make this the default for all steps soon. To not break old scripts I’ll make sure the old names keep working as well of course (scenProc is case sensitive when it comes to validating the script).

SPLITGRID additional attribute

The scenProc SPLITGRID step has been updated and now requires an additional attribute. So if you just run your existing script with the latest development release you will notice an error. But it is very easy to fix this. If your line now is:


Just change it to:


What does the additional attribute do? It is a bounding rectangle for the area you want to process with the SPLITGRID step. This way you can process only part of the loaded data. Especially when running batch jobs I needed a way to make sure features outside the desired area were not processed. So that’s why I added this.

If you would like to process all features between N51 E5 and N52 E6, you would now write:


Of course the manual has also been updated for this change, so you can find the information there as well.

The wishlist

WhishlistOn the forum you will quite often read that I put some feature or bug on the wishlist. But how do you know as a user which items are on the list?

Until now you could not see my wishlist. But I have now made the list public. So from now on you can see what’s on the list and which things have already been reported.

For the different tools there is some priority defined with different versions. But I have to warn you that I don’t follow these very well, when implementing features I jump around based on the priority of the day.


Finally the date we will move to our new house is nearly there. In a few days we will be moving, so at the moment we are busy packing all our stuff in boxes. Needless to say I’ll be offline for a while, while we are packing and unpacking.

I’m looking forward to have some more time after we have finally moved houses, there are a lot of interesting ideas for my tools I would like to look at.

Merging autogen configurations

Now that I can use scenProc to easily create new autogen, the urge to add custom autogen models increases as well. To make the autogen even more realistic I want to add custom roofs, custom vegetation models, etcetera. But all these modifications to the autogen configuration files give developers some headache when trying to deploy their scenery. How to make sure that the end user gets these modifications as well?

The problem is that there is one autogen configuration that all developers modify. So if not done correctly a developer might wipe out the modifications done by another developer. There are a few approaches that are used nowadays:

  1. Some developers just copy their modifications over the existing files, whiping out previous modifications
  2. Some developers merge their modifications into the autogen configurations files
  3. Some developers merge their modifications and the modifications of sceneries often used together with their product into the autogen configuration files

Obviously one approach 2 is the right way! Approach 1 is bad because it just erases any modification done by other developers. Your scenery will work fine, but others will stop working. Approach 3 might sound like a nice service to the end user, but what happens if the other scenery you include the modifications from update their custom autogen configuration? In that case your product would still include the old one and in that case the order of install will determine the result the end user gets. That’s not good.

So I would say the only way developers should distribute their custom autogen configurations is to only distribute their own modifications (not the default MS configurations, not those of other developers). And developers should properly merge their configurations into the main configuration file.

But of course we will have the issue of developers who don’t play it nice and remove other developers modifications, how do we deal with that? It would be annoying that end users have to reinstall your scenery again just to restore the autogen configuration files.

So I would propose that we make a tool that mimics the behaviour the Microsoft should have added out of the box already. A tool that allows each scenery to have their own local autogen configuration files. Each developer will put his own modifications in a folder within his scenery and the tool will scan all these custom autogen configurations at startup of FS and merge them into one main autogen configuration file. And if this is done at each startup of the sim, developers who wipe out your configurations don’t do any hurt anymore.

I plan to try to create such a tool soon. But I would love to hear back from other developers if this sounds like a good approach. Do you have other use cases in mind that such a tool should cover? Or would you like to help me develop and test this tool? Just let me know!