Again, I don’t think this is necessary.
– If we had solid validation, someone -selling- a scenery pack wouldn’t sell it while it was broken. It would be so obvious there is a problem, they could fix the problem ahead of time.
– For freeware, there isn’t the need to pre-warn.

The issue we have here I think is not one of malice, but rather one of inadequate tools. In the cases I have seen with serious errors in payware scenery, the authors have had no way to easily identify what was wrong because the error reporting was either:
– Too obscure
– Only ran when the error was hit, requiring flying every inch of the pack or
– Not logged at all, causing an unidentifiable crash.

This is why I want the reports – to make x-plane report properly!

A blacklist could warn other users to download or buy the broken package.

Ok, understood, thank you!

Yes! The off-line validator is a super-set of the WED validator.

But for checks in both WED and the offline validator, the check might act differently: the WED validator works on the source earth.wed.xml document, not the finished DSF file.

Let me try to explain (sorry but english is not my native language).
You said:

“An off-line validator would -not- necessarily be the same as the one in WED”

I believe that the WED validation code will work using the WED logic, is it right?
Then you said:

“WED is not the only scenery tool, and scenery can get into X-plane without ever going into WED”

Every scenery built with a tool different than WED must follow the same rules, but as those other tools can (and usually do) use more libraries than WED and use their own logic in order to generate scenery files I think (of course I can be wrong) that the off-line validation tool should be able to manage more ‘variables’ than the WED validator itself.
So if I’m not wrong the off-line validator should do anything the WED validator would do, and more when checking scenery done using other tools.

I think I’m missing your point. 🙁

Are you saying:
– WED’s validator should be -the- validator or
– WED and the offline validator should share the same code or
– WED’s validator should do anything an off-line validator would do or
something else?

“An off-line validator would -not- necessarily be the same as the one in WED – remember, WED is not the only scenery tool, and scenery can get into X-plane without ever going into WED.”

Sorry but I’m missing your point: why the off-line validator could be different than the one in WED?
I mean, WED will check for specific issues, so I’d expect that the off-line validator would check at least exactly the same, probably even more, but sure not less.
In a more user-friendly format I’d second MarRog’s proposal, but I could even think at an option inside the installer

This fix (seaport mis-handling in the ATC engine) is in progress – Philipp is working on it. It actually shows up in several points in the code. This is an example of a ‘bad’ scenery pack actually being an _X-Plane_ bug. It’s also an example of why detecting these things is hard – you have to get the sim into just the right state that the AI picks the sea port – and the aerodrome ATC picks is not necessarily the one your aircraft is at.

Right – I did consider a mode that would do something otherwise too expensive, like load -every- installed DSF. We actually have this as a test mode – internal code can set X-Plane to simply start the plane over every 6 DSF tiles, to ensure each one is loaded once. It takes a long time to run. 😉

If we validate errors, there’s no need to black list – if you have a broken scenery pack installed, you’d know.