At that point it becomes so important it almost seems worthwhile to try and automate it
With CI
Excuse my ignorance, but what's the point? I feel like this is one of the least irritating problems ATM. Sure it would be cool, but it does seem like a thing where a sensible default would be good enough for very long. If anything, having a single feature flag for that would extend that "very long" period even further.
I might as well be totally wrong on this, If you see any crucial use-case for that, I'll happily learn about it :)
Eh, I'm not sure I have a specific use-case. The general problem is how you balance verbosity for runtime errors. Just logging warnings/errors allows the developers to put off fixing those issues if doing so isn't critical at the moment, but means they can't turn those runtime warnings into hard errors (which is often desirable during testing to ensure you don't forget to cleanup warnings before release). Always panicking means developers can't forget to fix those issues, but also means that they may be disrupted from their current task to address an otherwise low-impact issue that might have been fine as a warning. I agree that having a single switch to flip to turn all logged errors/warnings into panicks would be a reasonable first step, but I expect that larger games will very quickly outgrow that solution and will want the ability to customize at a finer granularity
Especially if there are any warnings that are more about enforcing a specific style/structure in game code
Well, this is very project specific. If anything, you can turn any warning into a hard error in your CI and you can catch any error in the debugger by settimg a breakpoint. I'm not saying this is the best way you can have it, but there are many other things that prevent larger games from being created right now.
Like you can crash the program with a simple typo
Yes. This seems unreasonable. It must be impossible to crash program by crafting special input.
Input must be checked before usage. Obviously incorrect values should be filtered by inspector.
If user-provided code add constraints to values then it must handle errors by itself.
Skipping processing an object in case of constraints not met might be the best option in most cases.
And I think it must log error! instead of warn!.
I was thinking about that and I agree to some degree, but the "incorrect values" are hard to define. For example the matrix in
GlobalTransform is only invalid due to camera code that's specific to amethyst's default renderer. Should we treat that as a hard constraint? It doesn't really have to be used by the end user.
If user-provided code add constraints to values then it must handle errors by itself.
I think we should include "engine-provided user-facing code" to that group.
Any matrix that you can't invert
How about using Result in the render pass instead?
Result returned from renderpass will overcompicate stuff
You can create a
trait Inspectable with associated type that you will map onto UI to edit. And a function to convert associated type into Inspectable implementation
but derive is a next step
Problem with
Inspectable is that you can't define that trait for foreign types, like a matrix from different math library.
So instead I'm creating new structs deriving
Inspector that are able to work with specific types
Well, how would you expect to inspect it otherwise? :D
Derive won't work here.
Currently you have to manually register every one of them in a setup somewhere.
(stacks of inspectors for given type is a resource, registering an inspector potentially creates this stack and pushes that inspector into it)
Switch to std after stabilization