I just got a ticket response from Carenado (B1900D) saying the Hot fix fixed their errors ..

 

I wrote back saying it (the hot fix) did not correct anything.

 

So, the developers need to run the logging (which in this case they are not) on their own products ... we should not have to do this (run the log and report the errors to them).

 

Anyway ... it is all a bit of a mess at the moment.

 

Did they reply back to you since then? Not only do they have to correct errors, but the hotfix only "fixed" the gauge/panel issues... the graphics glitches are still in there.

"

Posted Today, 02:59 PM

vonmar, on 28 Feb 2014 - 4:28 PM, said:

I just got a ticket response from Carenado (B1900D) saying the Hot fix fixed their errors ..

 

I wrote back saying it (the hot fix) did not correct anything.

 

So, the developers need to run the logging (which in this case they are not) on their own products ... we should not have to do this (run the log and report the errors to them).

 

Anyway ... it is all a bit of a mess at the moment.

 

"Did they reply back to you since then?"

 

No.

No.

 

I won't be surprised if you never receive a response...  <_<

I won't be surprised if you never receive a response...  <_<

The 28th was last Friday ...

 

Now, it is still the weekend. So, not expecting a reply on weekend.

 

So far, I have received a reply to each ticket I submitted.

The 28th was last Friday ...

 

Now, it is still the weekend. So, not expecting a reply on weekend.

 

So far, I have received a reply to each ticket I submitted.

 

Hopefully they will be willing to fix the errors. I would be surprised if they started patching aircraft as old as the C208B.

Okay, just to put some much needed perspective on this...

 

...if you look very closely, you'll find that the "errors reported" are being repeated, many, many, M A N Y times!

 

As a practical example, after I excised the duplicates in a 573 item error report, I wound up with a mere 15 unique errors!  :good: 

 

So, don't despair!  :drinks:

 

EDIT: I should have added that some types of errors will be reported endlessly as long as the aircraft is loaded!!!  Now think about how that is going to affect your VAS...  :Nail Biting:

 

 

Writing to a flat text file is not very resource intensive... so they can log to their hearts content. Too bad there is no switch to turn that 'feature' off for non-developers LOL

 

Sounds like they're going to fill our hard disks with error logs

Writing to a flat text file is not very resource intensive... so they can log to their hearts content. Too bad there is no switch to turn that 'feature' off for non-developers LOL

 

Sounds like they're going to fill our hard disks with error logs

 

In the P3D.cfg file

 

[Main]

ContentErrorLogging=0

 

Does that turn it off? I know that before the latest patch developers had to turn on Error Logging by adding ContentErrorLogging=1 manually. Maybe that is the new default position for all users?

Writing to a flat text file is not very resource intensive... so they can log to their hearts content. Too bad there is no switch to turn that 'feature' off for non-developers LOL

 

Sounds like they're going to fill our hard disks with error logs

Who says that it can't be switched off? Remove the statement ContentErrorLogging and it is off.

Spirit

 

 

Too bad there is no switch to turn that 'feature' off for non-developers LOL

 

The line isn't in the cfg by default so it is already off by default...

I think he means the error log is running all the time .. internally ... the cfg switch allows a dump of it to the outside world .. a txt file output.

I think he means the error log is running all the time .. internally ... the cfg switch allows a dump of it to the outside world .. a txt file output.

 

I am no expert but that would be odd. That would/could mean EVERY option you can turn off in the cfg would still be running internally. Errors obviously are always 'seen' by the sim (because for instance the code tells them something is coming and it's not coming or it sees something it doesn't recognize): the sim will always have to deal with this one way or the other. But I don't think there is an internal log logging to nothing...

I really don't think the error logging would be anything more than trivial... The error itself should be more resource-intensive.

I am no expert but that would be odd. That would/could mean EVERY option you can turn off in the cfg would still be running internally. Errors obviously are always 'seen' by the sim (because for instance the code tells them something is coming and it's not coming or it sees something it doesn't recognize): the sim will always have to deal with this one way or the other. But I don't think there is an internal log logging to nothing...

 

Let me say it another way.

 

I think he means the error log is running all the time .. internally ... 

Which could eventually cause an OOM.

The cfg switch allows a dump of it to the outside world .. a txt file output.

 

I think Bill mentioned earlier something about continuously logging the same error over and over again ... building up to an OOM.

So, if logging is off by default in the cfg then OOM would not be generated by the logging .. rather internally.

 

It all is rather confusing.

 

But, being able to look at the log gives us a tool to check where errors are coming from.

Writing to a flat text file is not very resource intensive... so they can log to their hearts content. Too bad there is no switch to turn that 'feature' off for non-developers LOL

 

Sounds like they're going to fill our hard disks with error logs

It isn't the error log that will consume VAS, but the errors themselves that potentially may consume VAS... :Worried:

 

The ContentErrorLog.txt file is deleted and written freshly from each aircraft load. That's why one must be quick to copy/paste/rename the file before loading another aircraft if one wishes to actually use the log as a resource while debugging their project's boo-boos. :He He:

 

 

It isn't the error log that will consume VAS, but the errors themselves that potentially may consume VAS... :Worried:

 

My point exactly. ^_^