ErrorContentLog after Hot fix

[ChaoticBeauty]

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.

 

Have you received a reply by now?

[vonmar]

Yes, I got a reply from Carenado ... and I have not responded back to them yet.:

 

"Carenado Support, Mar 06 17:41:

Greetings.

Those issues began to occur with Prepar3D v2.1, but they should be error logs that don't affect the simulation. So unless they interfere with the way the aircraft works on P3D there shouldn't be much of a problem in having those messages. We have mostly tested the aircraft on v2.1 without paying much attention to the error logs as we know that the new parser logs most things, even if they isn't anything intrinsically wrong with the aircraft behavior.

Regards.

Carenado Team."

[ChaoticBeauty]

I knew it, they are not going to fix the errors.

 

Well, maybe someone should tell them that those errors consume more VAS and the graphical glitches are still in there. Also, what happened to all the full Prepar3D 2.0 installers for older aircraft?

[vgbaron]

Be fair CB - *IF* the errors are causing OOM's they will fix them. If they are simply annotated syntax errors - they will be ignored. I don't think it's fair to jump on Carendao about OOM's unless you can PROVE the specific error affects VAS.

 

Some errors MIGHT affect VAS depending on specific error and frequency but you can't paint everything with the same brush.

 

Error logging is not on internally all the time and uses NO VAS.

 

consider it this way:

 

program encounters error

 

error handler decides if error is critical -

 

if yes - end program -

if no - check if error logging is on

if yes - write to log.txt

if no - resume

 

Personally I wish they had not announced the error logging generally - I think it will create more problems than it solves. The majority of the errors are syntax related and have no effect and IMHO that excess clouds the issue of which errors are important.

 

But I guess it's better than nothing.

 

Vic

[Guest RWFeldman]

Though the errors may or may not cause OOM's, it is possible they can cause performance problems! Why not just do the correct thing and make it right?

[vonmar]

Though the errors may or may not cause OOM's, it is possible they can cause performance problems! Why not just do the correct thing and make it right?

 

+1

 

Not only that .. but sim pilots would not know how to "prove" which error is causing a VAS (or other) problem.

 

It is easier for me to just not purchase a product that is known to be logging code errors.

[spirit_66]

........

 

Personally I wish they had not announced the error logging generally - I think it will create more problems than it solves. The majority of the errors are syntax related and have no effect and IMHO that excess clouds the issue of which errors are important........

How come this weird idea that syntax errors have no effect? Every error in a program has an effect and can lead to malfunctions. I'm very happy about the error log but some people shouldn't look at it.

Spirit

[anthony31]

How come this weird idea that syntax errors have no effect? Every error in a program has an effect and can lead to malfunctions. I'm very happy about the error log but some people shouldn't look at it.

Spirit

 

Because that is how it works in the real world.

 

From my experience the FSX XML parser would read each line of code one by one. If it encountered a syntax error it would still process the line up to the point of the syntax error and then throw away the rest of the line.

 

So, in FSX you can have code like this:

 

(>K:LANDING_LIGHTS_TOGGLE))

 

and the gauge would still run and work perfectly well.

 

While in P3D the gauge will fail due to the syntax error with the extra closed bracket at the end of the line.

 

Note that in C++ this kind of syntax error would be easily picked up during the compilation process.

[vonmar]

Personally I wish they had not announced the error logging generally - I think it will create more problems than it solves. The majority of the errors are syntax related and have no effect and IMHO that excess clouds the issue of which errors are important.

 

I like error logs.

 

I used to do machine language programming ... and we had to get rid of all errors prior to compiling our exe files. If we messed up the compiler would flag errors. Then we could do it all over again!

 

So I know the drill .......... the syntax errors need fixing IMO .... by the developers before releasing their products.

 

BTW, the computer I was programming ... was a Lockheed SUE computer.

[spirit_66]

Because that is how it works in the real world......

Better say how you think it works. Anyway go for it if it makes you happy.

Spirit

[anthony31]

Better say how you think it works. Anyway go for it if it makes you happy.

Spirit

No. I was right the first time.

 

I didn't write that because that was how I think it works. It's because a few weeks ago I had to go through my XML gauges and fix up the errors found in the new P3D V2.1 error logging. Gauges which ran perfectly fine in FSX and P3D V2.0 but didn't in V2.1.

 

Now, if you have any sort of useful experience in the matter of writing XML gauges for FSX or P3D then maybe your comments will be worth reading.

[spirit_66]

.........It's because a few weeks ago I had to go through my XML gauges and fix up the errors found in the new P3D V2.1 error logging. Gauges which ran perfectly fine in FSX and P3D V2.0 but didn't in V2.1.......

So your gauges were not perfect at all with all the errors. That's the kind of products I can check now and avoid to use. That's why the error log is good in my idea and obviously not good for you. But anyway go on dreaming about the "perfect" stuff.

Spirit

[vgbaron]

So your gauges were not perfect at all with all the errors. That's the kind of products I can check now and avoid to use. That's why the error log is good in my idea and obviously not good for you. But anyway go on dreaming about the "perfect" stuff.

Spirit

As a "purist" you might be right but in the real world, you are SO wrong. As Anthony said, it IS the way it is done. Some syntax errors could have negative impact but, in XML they can be very benign. All those "BAD" gauges are the same ones you have been using for years - now all of a sudden someone tells you they have errors and they are no good.

 

Syntax errors are like using bad language - sometimes they get you into trouble but most times not.

 

Thank you - you have made my point about why I think the release of error logging to the uninitiated is a bad idea.

 

 

Vic

 

EDIT: Let me try to clarify what I mean -

 

The majority of the errors reported by the 'tool' are of the syntax variety and have no operating effect on the gauge. Those that DO cause issues generally can NOT be corrected by the user. SO what do we get? An increase in the noise level in the sim forums about all the "errors" in the product and "I won't be buying from them again" garbage. As a tool for the developer, it's great - for the user it can nothing but cause problems, IMHO.

[Guest RWFeldman]

Syntax errors are like using bad language - sometimes they get you into trouble but most times not.

 

You defending lazy programming? I like they called them out and there are those out there working very hard to fix them!. Ie Fr Bill/Milviz. Those are the ones I will give my business to.

[n4gix]

You defending lazy programming? I like they called them out and there are those out there working very hard to fix them!. Ie Fr Bill/Milviz. Those are the ones I will give my business to.

Yo! Rendi! You've never heard of typographical errors?

 

It's remarkably easy to mistype something, particularly when speaking of thousands of lines of RPN gibberish.

 

I'm absolutely delighted that L-M finally have created a method by which I can find and fix my typos.

 

On the other hand, L-M themselves managed to introduce some of their own "errors" with their changes to the XML parsing algorithim, which some of us have pointed out to them with some examples of things that "used to work, but don't work now..." B)

 

The task that L-M have set for themselves is truly monumental, as they have had to reconstruct the ESP (FSX/A) source code in order to get a handle on "how it works" and occasionally have made some incorrect conclusions, which in turn has resulted in some "unintended consequences."

 

By communicating directly with the nice folks at L-M, these problems are being resolved. :Big Grin: