Thank you for the answer! Actually, that’s the first time my bitter comment was actually related by staff! Yay! With your permission i will answer gradually:
-
“With all due respect, you must have missed the other replies and workarounds given back in 2015 (including my own back in March 2015).” - Do you mean “make sure that neither you (nor libraries you use) include cmath (or re-include math.h before #include’ing PhysX headers)” ? How is this workaround permanently valid? Problems are:
a) If game designer uses any plugin, he actually has no way to know, nor manage includes of the plugin. This means, that plugins may be mutually exclusive with PhysX. Does that sound as a valid infrastructure?
b) “or re-include math.h” - didn’t work for me. And imho it’s hardly a valid solution to make someone juggle with include hierarchy, part of which he neither knows about, nor it resides on his side of the code, and generally may be altered under the hood by the whims (legitimate and logical as they may be) of other parties.
-
“The problem obviously does not affect the stock UE4” - well, my complain is, that it exactly does. Unless you consider using PhysX as non-stock of course. Correct me if i am wrong, but we are suggested to use it roguishly, as third party, instead of through the engine. Although the engine supposedly uses this library itself. Hence my suggestion about exposing some adapter to PhysX as part of engine API, to avoid exactly the situation we are at now. Please note, that this issue arose after i integrated new, PhysX utilizing feature on the machine, that underwent format and full system and Unreal re-install just before that. And that’s a machine dedicated for UE development.
Out of characters, so continuing in the comment below…