• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Filter in CreateXmlLibObj step

A

apollon01

Messages
163
Country
luxembourg
Hi Arno,

This is just to make you aware that I have found that the filter for CreateXmlLibObj step when creating xml placements from a point shape file is not happy with anything else than = in it. When I tried to use filter containing <, > or <=, >= it returned 0 objects created. With = it works just fine.

Not a big deal as there is always a workaround. This is just a heads-up.

Regards,

Milan
 
Hi Milan,

The filter logic should be the same for all steps. What kind of attribute are you testing (string, int, double)?
 
I tried with Integer.

Interestingly, I have a poly shp and point shp with the same attributes. The filter runs OK on the poly but not on the point shp.
 
Hi guys
I'm having no problem with any of the operators except where I had problems with different types being mixed (see http://www.fsdeveloper.com/forum/threads/couple-of-quick-observations.439162/ http://www.fsdeveloper.com/forum/threads/couple-of-quick-observations.439162/). Note Arno's response in
http://www.fsdeveloper.com/forum/threads/broken-filter-in-the-8-1-2017-update.439206/ I found following the advice here fixed the problem I'd been having that I'd attributed to a problem with RND(1).
ian
 
iangbusa said:
I'm having no problem with any of the operators except where I had problems with different types being mixed (see http://www.fsdeveloper.com/forum/threads/couple-of-quick-observations.439162/ http://www.fsdeveloper.com/forum/threads/couple-of-quick-observations.439162/). Note Arno's response in
http://www.fsdeveloper.com/forum/threads/broken-filter-in-the-8-1-2017-update.439206/ I found following the advice here fixed the problem I'd been having that I'd attributed to a problem with RND(1).
Click to expand...

The random issue is still open, but the issues of comparing different types are fixed in the last release.
 
apollon01 said:
I tried with Integer.

Interestingly, I have a poly shp and point shp with the same attributes. The filter runs OK on the poly but not on the point shp.
Click to expand...

Humm, the CreateXMLLibObj step should work with any feature type. Some steps, like CreateAGNLibObj require polygons as input, so in that case feeding point features into it will result in no objects being created. But for the XML version that's not the case.

Do you have a small sample I can use to reproduce this issue? Then I can check if it's a bug.
 
Hi Arno,

yesterday I checked again the data I was working with and realized that the filter was run on numbers which were however in String attributes rather than in Integer attributes. I converted the attribute format to Integer and it is now OK, of course.

Sorry and thanks help.

Regards,

Milan
 
Hi,

That makes sense. scenProc doesn't try to interpret strings as numbers when comparing them. Would it makes sense to do so?
 
No I don't think so.

Only the users of scenProc need to be sure of the type and format of the data they work with (which was the culprit in my case).
 
For integer and double I have implemented that you can mix them, as both are numbers that makes sense in a way.

For the strings I'll leave it like it is now in that case.
 
You must log in or register to reply here.
Back
Top