I just found that in S22 they have inverted the behaviour of a flag for GetAllAssets.

In R21 there existed a flag ASSETDATA_FLAG::MISSING.

From S22 onwards the functionality of this flag has been inverted and it is now called ASSETDATA_FLAG::NOMISSING.

The problem is that it sets the exact same bit.

So if you have a plugin that is compiled against R21 and your users use it in S22 then your code will not be getting the missing assets anymore, since this bit is set (if you use the MISSING flag) and it will now mean DO NOT get missing assets.

Compiling against the S22 SDK and removing the MISSING flag will fix your bugs if you have any.

Just something to watch out for if anyone is hearing of problems from your users relating to gather up assets. Mainly applies to people writing renderers and dealing with textures and materials.

Cheers,
Kent

@zipit Thanks for the advice. I was hoping on a quick solution from the SDK team. IE just add a flag or something quite fast to implement and get going. Unfortunately I don't have time to investigate a custom solution. Will see if Manuel comes back with something quick, otherwise I will just write to an AESFile directly myself I think and skip the loggers completely.

@m_magalhaes

Hi Manuel,

Yes know the Logger Manual. But it does not tell you how to make your own version of a maxon::LoggerType::File(). It only teaches you how to log message to the existing logger types.

What I wanted to do was create a maxon::LoggerType::EncryptedFile(), but I don't see how to do this.

I also thought maybe it is possible to use the maxon::LoggerType::File and some how create my own URL handler possibly, which seems like what you tried? If you get this working then please do let me know.

The observer is what I was going to fall back on, but it kinda defeats the entire purpose. Since I have a method that I push all my log events to anyway (which then call my custom maxon logger and it nicely writes to the console and a un-encrypted file which works great). So I could just write my own file right here and be done with it. But I was really hoping I could just easily change the unencrypted file to an encrypted one and keep using the actual Maxon API itself. But I may still use the observer so I can at least learn something more about the MAXON API.

And as @zipit said I could use the existing loggers and encrypt my messages before I log them. But that means I have to then identify each message in the log file itself so that I can decrypt them (ie some start, end points, message length etc...). Do-able, but why not just have an encrypted logger type if possible, since that is effectively what you are writing anyway. So for me it is part learning the MAXON API and part coming up with the solution. And instead of wrapping I could just open my own file, add to my own file and save my own file again, removing the logger completely from the entire workflow.

Cheers,
Kent

Is it possible to create a logger that produces an encrypted file? I can't see any option for this so I don't think it is possible.

So my next question is can we implement our own loggers? That can be attached to a LoggerTypeRef using AddLoggerType? IE writing my own "maxon::LoggerTypes". I could then write my own logger and deal with any passed in messages in my own custom way.

Note that I am already using loggers to log to console and to files. But now I want to log additional confidential information in some way, so need to either encrypt or somehow create my own logger (which I could then encrypt myself).

Thanks!
Kent

There are lots of internal plugins that use the numbers generated from the plugincafe.

A better solution would be to find the tags in the document and then check what plugin it belongs to and if it is not located in the modules folder in the installation folder of C4D then it is a 3rd party one.

Not sure why you want to remove the tags though.

I have had to do this a few times in the past. What I do is store a BaseLink to all the Shaders that are used on my Object. I register and deregister them in the SetDParameter methods of the Shader itself. IE the shader registerers itself with the objects it is added to. And when the shader is destroyed it unregisters itself from the object it is applied to. Then when the object needs the shader to update it goes through its list of shaders that are registered to it and sets its dirty flag. SetDirty(DIRTYFLAGS::ALL); This should work fine for you since you are also storing a link to the object in your shader itself, which is also required so it knows what to register and deregister itself to.

No worries @gheyret. I wasn't pointing you out in particular, I have just noticed it happen in the past as well so just wanted to put out a general reminder to all. Sometimes people spend quite a bit of time researching to come up with the answers, and we then may even want to look back and find our own posts to remind ourselves of something later down the line.

Maybe one of the Admins can re-enable your post.

Cheers,
Kent

Yesterday I helped someone out with a question. Now they have marked it as deleted. The only reason I would help out on this forum is to help everyone and add to the knowledge pool here in this forum.

So please... do NOT delete your post if you received the answer you were looking for.

@gheyret great to hear! Looking forward to seeing what it is you are creating.

@fused said in Decoupling source from SDK project:

If you don't mind maintaining your own CMake (or similar) script, the sourceprocessor in the SDK allows to specify a target directory for the generated files from R21 onwards.

I would not exactly recommend going that way, but for me it beats using the project tool.

The project tool is the most important development Maxon has provided to us developers. It allows me to make sweeping drastic changes, renaming, moving files, refactoring to my own frameworks etc.... and then with one click I run the Project Tool and all my solutions are updated for OSX and Windows. I would definitely not use CMake for these... ever. Since Maxon also updates the ProjectTool when a new version of C4D comes out and it may have new flags or optimazations and changes to the project structure for XCode and Visual Studio. Maintaining your own CMake version going forward for R20, R21, S22, RXX etc... would be a massive pain and just slow you down.