Error in XPOI

[Dutchman]

Just purchased XPOI. During my first flight. after about ten minutes, the following error occurred:

couatl v3.0 (build 3187)
panic log started on Thu Apr 21 19:10:18 2016

problem raised by engine or unspecified addon
{'Airport': 'CYVR', 'User Pos': (48.181813961256005, -123.299265999545, 4349.44 m, 4349.44 m, 168.47722193308854)}

I ran the demo version for a few days and encountered no errors.

Any suggestions?

[virtuali]

The message is not very telling. What features you had enabled ? It's possible that in some very dense areas, the program simply cannot keep up with too many objects.

The most demanding features are usually the "S" class, do you had them on ? Did you had many POIs on screen when the error came out ?

[Dutchman]

Sorry if the message is not informative. It's all that it gave me.
I am running ORBX Pacific North West in this location.  No other add-ons except POI. had everything turned on, not sure what S class objects are.

[virtuali]

had everything turned on

Which exactly what I suspected what the problem might be. In some areas, the POI density can be so high, that might even go over what Simconnect itself might be able to process.

That's why we don't have everything turned on by default. Try to turn off all features, then start one by one, adding more classes, and see how much that area can handle.

not sure what S class objects are.

The "Spot" super-class.

[Dutchman]

Well, I did turn off many things (most of which I do want to see) and the error rate is reduced. But it still happens, and if I can only turn on one or two things, that makes the program rather useless. If the engine has a limit to the number of items it can process, why does the software not have a check that limits the number of items it processes rather than unceremoniously crashing. Seems a rather poor software design in my opinion.

[virtuali]

If the engine has a limit to the number of items it can process

The "engine", if you are referring to our own Couatl engine, doesn't have ANY limit, except a maximum of 4GB of RAM it can address as a *SEPARATE* 32 bit app (Couatl.exe doesn't take a single byte of RAM from FSX, since it has its own address space)

There might be a limit of objects than can be handled by the sim, and a limit how fast Simconnect can receive commands from client applications.

1) the limit on the number of Simobject displayed by the sim is not documented.

2) the limit on the number of commands handled by Simconnect, is not documented either but, DEPENDS on how many other 3rd party Simconnect applications you run, and how many commands they sent to the sim.

If another (and/or several of them together) 3rd party application "floods" Simconnect with too many commands at a time, it's possible the sim cannot keep up with everybody.

There are reports from users that gets different results (this is unrelated to XPOI, of course, it affects every combination of addons), just using different weather engines, like ASN vs OPUS and, it looks like OPUS is less intensive.

why does the software not have a check that limits the number of items it processes rather than unceremoniously crashing. Seems a rather poor software design in my opinion.

You are making a judgement about the design without knowing anything about it.  There's IS obviously a limit and, in fact, there are *many* limits, to prevent possible overflow of data:

- Not more than 30 rows of results are queried from geonames.org

- Not more than 100 objects are ever processed per frame

Those limit always worked with no issues so far. In addition to that, you have many settings to control the POI density, like the number of visible categories, the drawing distance of the POI itself AND the drawing distance of the TITLES.

The TITLES can be very demanding, depending on their *length* and since we cannot possibly foresee the length, there's a separate control for the drawing distance of the title. Each letter of the title is a separate object so, each POI will create several FSX visual objects, depending on the length of its name.

That's why we don't draw the names from very far (unless you play with the slider and increase it), and that's why there's a slider the control the drawing distance of the title separately.

If you are using several 3rd party modules that send many commands using Simconnect, you might need to adjust these parameters.

The default always worked for everybody but, of course, since we cannot anticipate how many 3rd party modules that can potentially flood the Simconnect communication pipeline you use, the only option is to have such sliders and options to control the POI density.

[Dutchman]

Thank you for your comprehensive response. You are right, I do not know anything about your software. However, I have been a software programmer for over 30 years and I do know a little about programming. The first thing I was taught in 'programming school' many years ago was that my software could never crash! As a programmer, it was my responsibility to intercept any event that might cause a crash and then either prevent it or, if that is not possible, exit gracefully. For example, instead of issuing a message that means nothing to even the developer, perhaps it should just shut down with a message that suggest restarting the add-on at a different position. Right now, I have to exit my flight and restart it at a different airport and hope it does not crash again. That is hardly satisfactory, I would suggest.

[virtuali]

The first thing I was taught in 'programming school' many years ago was that my software could never crash! As a programmer, it was my responsibility to intercept any event that might cause a crash and then either prevent it or, if that is not possible, exit gracefully.

You might be right, if you were discussing about a software which would run entirely self-contained with no interactions with other software.

Yes, of course, since XPOI is written in Python, if we had the luxury to be able to intercept every possible event, we could use the extensive Python exception handling, which we obviously do, for all the things that DO happen in our code.

Unfortunately, the likely cause of what you see, is happening outside what we can intercept, such an excessive number of objects not handled correctly by the sim, or an excessive number of calls made by too many other addons running at the same time. In the last case, the WHOLE point is that if we cannot communicate with Simconnect (because of the traffic), we cannot even *know* there has been a problem.

And in fact, what you are looking at, it's NOT a "crash".

It IS a "graceful exit", which is what you suggest should happen: the problem has been correctly logged, and NOTHING has "crashed", Couatl.exe simply gracefully quit.

Not being a Python error ( an error in OUR code), the description of the error wasn't very informative, because that's the only thing we can print out, if the problem is unknown, because it happened elsewhere.

Right now, I have to exit my flight and restart it at a different airport and hope it does not crash again. That is hardly satisfactory, I would suggest.

No, you don't have to do that. Since Couatl.exe is an external exe that has "gracefully quit", it won't affect FSX and your flight in the slightest way, so you can just restart it and continue where you left.

Of course, the real solution would be finding why you are the only one with that problem, which suggest some kind of compatibility problem caused by another addon that nobody reported before.

There was only ONE similar report ( but not identical ), about the error here:

http://www.fsdreamteam.com/forum/index.php/topic,12931.msg97126.html#msg97126

But the user had also more diagnostic messages, which identified the problem being a bug in one of the objects (and there's a solution for it), so I don't think it's the same as in your case, unless you could clearly identify a specific category that, if enabled, will always result in the error, and if disabled, will remove it.