Hi guys, glad to see this thing is still going strong …
Heres a small issue i m running into … When i m loading Krakatoa using the latest TP ( unreleased) , i m getting this beautifull message Saying something like " cannot reconized the tp license etc…etc…" and boom no render possible.
I do understand that as the SDK change, krakatoa is detecting is and decides to stop .
My question to the Dev team is , could we have an " at your own risk approach" where it could pop a message saying " hey , you have a version of tp wer not sure to support yet , use it at your own risk" and still allow us to try to use Tp ? i checked with ed and it seems that most the function calls are the same even thought the sdk change…
I m just wondering if it could be possible and if its as simple as my head seems to think it is … or if theirs more to it and its impossible , would like to know it …
Not sure why Krakatoa would even care about the TP license at all. Sounds more like TP doesn’t offer backwards compatibility for functions used by 3rd parties. Though that still doesn’t explain why the license would be involved.
I’m curious though, why doesn’t TP just support Krakatoa instead of the other way around? If TP could write PRT files (which have only a spec, no libraries to worry about linking to other than zlib), then you wouldn’t need to worry about Krakatoa playing catch-up.
When the “Thinking Particles” button in the Krakatoa GUI is checked, Krakatoa will load the ThinkingParticles.dll in order to use their SDK to extract particle data directly from the TP object in the scene. If the version of the DLL does not match the SDK we were provided Krakatoa will put up a message and refuse to continue. This is neccessary because of the nature of C++. Loads of functionality is not directly stored in the DLL, but is inferred from the header files provided by the TP SDK. Even minor changes such as adding a new data member to an object will throw off the memory layout of the TP SDK and cause undefined (and likely a crash to desktop).
We used to just try and load it anyways before we had the TP 4 SDK and the results were disastrous, so the behavior was changed to what you have now.
Given my experience with the TP SDK, I feel confident saying that allowing you to try and use an older SDK implementation would be like adding a “crash now” button. And that’s not very professional.
I spoke to Ed , theirs a new SDK … its Beta but its their …
Now let me ask you something , if you , by getting the new SDK , enable compatibility with it… you dont break older compatibilitys corrects ? like other users can still use the 4.5 releases etc…etc… ?
I can add support for newer TP builds without breaking existing functionality because we use the TP dll’s version number to direct Krakatoa the appropriate implementation.