Content Errors

[aeronauta]

I have never had content errors in the default flight (F22 at KVPS) now every AC included the default logs an error , does not seem to have any sense and I tried every combination in the AC .cfg file ...it is a large number as you can see..

[error.994]
error=Payload station indexes should be between 1 - Number of Stations

[error.995]
error=Payload station indexes should be between 1 - Number of Stations

[error.996]
error=Payload station indexes should be between 1 - Number of Stations

[error.997]
error=Payload station indexes should be between 1 - Number of Stations

[error.998]
error=Payload station indexes should be between 1 - Number of Stations

[error.999]
error=Payload station indexes should be between 1 - Number of Stations

SDK says load.0 to ... tryed load 1... diff number of max stations ..no joy .

Looks like a HF parser problem..

Jorge

[Rob McCarthy]

Jorge,

Do you have FSUIPC running? Another user reported that disabling FSUIPC fixes this issue: http://www.prepar3d.com/forum/viewtopic ... 2&t=125545

Regards,
Rob McCarthy

[aeronauta]

Yes Rob , thank you , confirmed..but FSUIPC does not beleive it is his problem so he sends people to untick the content error box, and syas (incorrectly) that it does not affect P3D operation...hundreds of errors reported , also he points to the HF fix
"Fix for a crash when using index 0 with playload stations" the SDK says index from 0 , the error tends to indicate that the first one should be 1

[error.998]
error=Payload station indexes should be between 1 - Number of Stations

Jorge

[aeronauta]

As a test I commented out ( ?? ) the aircraft.cfg entries

//station_load.0 = 170.00, 0.0, 0.00, 0.00
//station_name.0 = "Pilot"

//max_number_of_stations = 5

and the error persists... FSUIPC??, will post this in their forum..

Jorge

[Jim Harnes]

Disabling FSUIPC5 in not an option in my case. Aside from the fine-grained control of controller axes, calibration, etc. it provides, FSUIPC is a requirement for the script which controls my flight deck hardware.

So I would appreciate a LM statement that content errors are or are not something with which to be concerned. If we need to be concerned about such errors, it seems to me that LM should identify a path which leads to a correction.

Thanks,
Jim Harnes

[WarpD]

1 - Content errors are something you should be concerned with.
2 - This particular issue is inside FSUIPC and needs to be addressed by Pete Dowson.

You can continue to use FSUIPC with this issue, simply disable content error reporting until such time as FSUIPC is updated to address the message.

[aeronauta]

Ed, Pete is blaming LM for this ...
Jorge

[Martyson]

Follow up:

In the now locked topic:
http://www.prepar3d.com/forum/viewtopic ... 2&t=125545

Rob Ainscough said:

"This error has nothing to do with FSUIPC5.

Airi,

It sounds like you installed just the Client Update and didn't do the Content update from 21686 HotFix. The content update includes some additional files specific to some of the default aircraft provided by LM such as the F16, F22, etc. Based on your error, payload stations are typically associated with Military aircraft.

So if you've only installed the client update, then install the content update also. Be aware the content update may impact other 3rd party add-ons that are NOT using the recommended "Add-On" process."



Initially I did a Client only install but later did the Content because of another problem , f16 speed brakes inop, mentioned here"
http://www.prepar3d.com/forum/viewtopic ... 2&t=125552

I am still getting these FSUIPC related Content errors [error=Payload station indexes should be between 1 - Number of Stations].

So, is their more than a Client and Content Updates required to fix this problem ?

[aeronauta]

I have also updated content...and the problem persist. Also the word payload does not appear in the F22 aircraft.cfg file.

http://fsfiles.org/flightsimshotsv2/image/GLQX

Jorge

[Mike Schroeter]

Yes, this is a result of the crash fix mentioned above. Something is querying the aircraft variable "PAYLOAD STATION NAME" with an index of 0, which is invalid. As far as I can tell, nothing in the default Prepar3D product is making this call. Prior to the hotfix, this would result in an access violation and likely crash.

Contrary to the what was stated above, this has always been a 1-based index. The only change made in the hotfix is to prevent the crash and post the content error. It is admittedly unfortunate that it gets posted on every query.

As for whether there should be concern over content errors... yes and no. The goal is to provide more feedback to developers so they can create more robust content. Without these errors, content developers are often left scratching their heads wondering why things like this just don't work. This is a new tool since P3D v1, so we are continually adding these errors as we encounter them... there are literally thousands of options and queries where we can add these, so you can expect more and more. This is aimed primarily at developers, as they are the only ones that can do anything to correct the errors. In core Prepar3D, we always attempt to handle invalid queries and inputs gracefully, so many errors are not obvious (unlike the previous payload crash). End users however should not be concerned, unless they are interested in providing feedback to content developers.

Hope this helps,
Mike

[aeronauta]

Mike thank you for your comment, I incorrectly assumed that the station payload was referring to the station load , given that the error popped up to me the first time in a civilian AC, then I realize that the error was everywhere and tested the F22 , the only place the F22 shows payload station is in the attachments.xml and it is incorrect as it starts the station index at 0 and the SDK shows it starting at 1 in the xml example., now is the problem with P3D or FSUIPC?
Your comment re ignoring the errors seems odd as I have repeated many times in this and other forums the SDK part of Content errors reporting causing unnecesary load on the system.

I develop scenery and these errors are filling the log every time I test something.

Should we expect a solution from P3D ?

Jorge

[Pete Dowson]

Yes, this is a result of the crash fix mentioned above. Something is querying the aircraft variable "PAYLOAD STATION NAME" with an index of 0, which is invalid.

If it is invalid and really being used, why isn't it rejected by SimConnect?

Anyway, FSUIPC requests payload stations 1-61 using "PAYLOAD STATION WEIGHT:1" and "PAYLOAD STATION NAME:1" through to the same with :61. (The number being requested is related to the space originally allocated in the "offsets area" for this data). These names and numbers are hard-coded into the table relating them to the pre-processing of the data received and the location for the results.

There is no loop incrementing numbers which could go wrong, and no where else are these values referenced. The same table is used for writing different weights on request from applications.

FSUIPC has done this ever since FSX was in Beta (i.e. since 2005) and it has never generated any errors before. Something has changed in the recent HotFix to bring this on.

The errors might only arise when FSUIPC is running and reading these values, but it is certainly something going wrong in the checking in P3D since the HotFix.

Before putting the blame on FSUIPC, which is the easiest get-out, L-M shoud be examiing what change is responsible for these misleading error reports. I don't mind changing something if necessary, but there is nothing to change without reducing FSUIPC's facilities for those applications using it.

As a test here I'll try starting the PayLoad Station requests at :2 instead of :1. Not that I think there's any hope of this eliminating the errors, but if it does then it surely indicated a simple numerical checking error within P3D, maybe a <= instead of < comparison.

Pete

[Pete Dowson]

Results of some tests done here:
1. Starting FSUIPC's requests at 2 instead of 1 doesn't help. It simply means I don't receive the first.
2. Ending the requests at 10 (the number of payload stations in my default aircraft) does not help either.

In any case, these are not actually "content errors" so they are incorrectly reported. Any such error reports should be contained in the Client-Simconnect interface like all other such errors.

FSUIPC asks for all the data it might need up front, and this is not changed from aircraft to aircraft. Since the requests for data are all "supply when changed", those payload stations which do not (currently) exist should not be returning any information, or possibly just null on the first time (though there is no reason to do that -- only when an aircraft is loaded with fewer stations than the previous one need null values be returned as a change).

This arrangements goes for many things, like Engine 2, 3, and 4 data requested when the current aircraft has only one engine. The amount of changes required to be done for each aircraft re-load would really amount to a restart of the SimConnect interface in FSUIPC -- i.e. closing the client and opening a new one with a host of different requests, and in a different order (needing things like payload counts and engines before requesting other items). As well as a major code upheaval it is a large overhead on reloading aircraft, and it should absolutely not be necessary.

The Client-Simconnect interface has worked well and smoothly for all these years. A Hotfix change for one problem should not be allowed to generate such a re-write and unnecessary overhead for applications.

So, please L-M, re-evaluate you diagnosis and look again at the change you made. Something is certainly wrong, and undesirably so.

Pete

[Jim Harnes]

Hi Mike,

Thanks for the information you posted above. To be clear I am not a developer; however, I do manage a support forum for a software distributor and developer. I am not at all interested in having to responding to user posts stating that "content errors are affecting my (simulated) aircraft's performance and do something to get it fixed".

I hope that LM would want to get this matter under control as a matter of urgency.

Best,
Jim Harnes

[Mike Schroeter]

Pete,

Respectfully, I never mentioned FSUIPC. I simply said it does not occur with the base product, as far as I can tell. It is impossible for me to make a determination about FSUIPC.

PAYLOAD STATION NAME requires a 1-based index. 0, or no index, will result in the content error.

Mike