Lukas Tenbrink
Lukas Tenbrink
I was able to get axis support for any / all pretty easily using the reduction macros: ```c++ using namespace xt; XTENSOR_REDUCER_FUNCTION(va_any, xt::detail::logical_or, bool, true) XTENSOR_REDUCER_FUNCTION(va_all, xt::detail::logical_and, bool, false) ```...
You may not have the same experience. I used `nix` cmake specifically. Nix is very big on encapsulation, and if it used the system clang instead of shipping its own...
It is notable that a rather annoying bug currently exists that makes the `.framework` approach rather unattractive: https://github.com/godotengine/godot/issues/96403 (edit: though notably in 4.3 only, not 4.4 dev) I've narrowed it...
> As you sure? I remember the requirement on windows to link by abs path and linkflags You mean regarding my .framework problem? It may have to do with the...
Superseded by multiple PRs that came since I opened this one.
> Should I update `set_time_scale`? > > ```c++ > void Engine::set_time_scale(double p_scale) { > _time_scale_game = p_scale / _time_scale_user; > _update_time_scale(); > } > ``` No, this would unnecessarily break...
> > No, this would unnecessarily break compatibility to modules. > > This change should fix [#107273 (comment)](https://github.com/godotengine/godot/pull/107273#issuecomment-2962575692) and doesn't affect release export because _time_scale_user is always 1 Ah... I...
> this removes the _time_scale_user effect, as I'd tested This should be true only if you ignore the second half of my comment.
> While the logic is correct and I do agree it's nice to be specific in the code about whether something is uninitialized, I'm slightly concerned it might be compat...
> That's an alternative but I think is better to get some consensus at next meeting. It might e.g. be an opportunity to introduce a safer resize for non-bottleneck stuff....