17 hours ago, Brutus911 said:an error is not about whether it will have harmful effects or not. I am confirming to you that a 'warning' is still an error whether it crashes the game or not. That's what a warning means, you have an error, and then it goes on to tell you exactly what your error is. In the example you provided, the error is the programmer unsupported shaders/diffuse and cured the 'error' by removing them. Hope this make sense to you now.
Last try to get to some sort of common ground: The word error means different things in different context. In the "computer science" context a warning is not an error, though you could consider it an error, misjudgement, fault or carelessness of the programmer in the "general language" context. In the general language sense we could view it an error to let a warning message occur, it is usually considered a bad practice in programming. If you wanted to say this then I partly agree.
In the "programming" context most warnings are either informational or just loose threads hanging there that could generate problems in edge cases or after other code changes, or they are even expected to happen. Or they actually lead to a failure state, which makes them an actual error but that is something a programmer has to judge. Same in the "operating system" context
The most common warning in programming is happening because programmers use implicit conversion of numbers. This is obviously not an error because the compiler creates exactly the same code whether you use implicit conversion or not. But it is considered bad pactice because it could theoretically lead to errors if you change code at some other place later and don't remember that this conversion would not be working correctly anymore. The compiler warns you that it has to guess what the programmer means and its guess could be wrong.
The warnings that some shaders are unsupported for example is coming from the library that something unexpected is happening that someone should be aware of. But the library has not the context to know if it is expected or not. The programmer using the library knows a lot more context, for example that the program was started as a headless server or the shaders are never used. And in those case this is fully expected. It is cutting corners, sure, it is saving time at the cost of safety. But to the programmer it is not an error. Every programmer inside TFP must know those shader warnings and they are ignored.
You might consider this behaviour an error in the "general sense", but in the computer science context it is not. And TFP likewise does not see a warning as an error. Try reporting a warning as a bug and you'll see that they will refuse to act on it unless you also report something not working (which is the bug or error they act upon).