Oh wait, I think I found a way. In case anybody else wants to know, here it is...

In the PrefsDialogObject:

Bool MyPrefsDialog::SetDParameter(GeListNode *node, const DescID &id,const GeData &t_data,DESCFLAGS_SET &flags)
{
	BaseContainer* bc = MyPlugin::GetPreferences();
	if (!bc)
		SUPER::SetDParameter(node, id, t_data, flags);
	
	switch (id[0].id)
	{
		// If PREFS_MYPLUGIN_SOMEVALUE was changed, store value and notify plugin objects in all open documents.
		case PREFS_MYPLUGIN_SOMEVALUE:
			bc->SetInt32(PREFS_MYPLUGIN_SOMEVALUE, t_data.GetInt32());
			flags |= DESCFLAGS_SET::PARAM_SET;
			
			// Iterate open documents
			for (BaseDocument *doc = GetFirstDocument(); doc; doc = doc->GetNext())
			{
				// Send broadcast message to each document, use unique ID
				doc->MultiMessage(MULTIMSG_ROUTE::BROADCAST, MyPlugin::UNIQUE_ID_PREFS, nullptr);
			}
			
			GeUpdateUI();
			return true;
	}
	
	return SUPER::SetDParameter(node, id, t_data, flags);
}

And then, in the plugin object:

Bool MyPluginObject::Message(GeListNode *node, Int32 type, void *data)
{
	if (type == MyPlugin::UNIQUE_ID_PREFS)
	{
		GePrint("Aha! My prefs have changed!"_s);
		return true;
	}
	return SUPER::Message(node, type, data);
}

And in deed, having the option of executing the source protector using a command line argument for Cinema 4D, or using c4dpy would be great for integration in a plugin build pipeline.

Hi,
I'll just chime in here, as I'm involved in that project, too.

So the token hook needs to access certain elements of the scene to get their values, and the problem (thankfully) is easily reproducible.

I wrote a sample plugin that recreates the behaviour by simply returning data from the first object in the scene. Download it from our dropbox: tokenhookbug.zip

Here is the code:

This is the render setting in my example scene (which just contains a Cube):

Here is the render result in the Picture Viewer, notice the correct file name:

Uploading and rendering the file on TeamRender produces this:

The debugger clearly shows that doc->GetFirstObject() returns nullptr.

Cheers,
Frank

It works like a charm!
Thank you again!

I was surprised at how little code was required.

Sharing is caring. In case anyone needs it, here's the code:

#include "ge_prepass.h"
#include "c4d_general.h"
#include "c4d_baselinkarray.h"
#include "c4d_basedocument.h"

///
/// \brief Registers observers and sends messages to them.
///
class Observable
{
public:
	///
	/// \brief Subscribes a new observer.
	///
	/// \param[in] observer Pointer to an AtomGoal
	/// \param[in] doc The document that owns the AtomGoal
	///
	/// \return A maxon error object if anything went wrong, otherwise maxon::OK
	///
	maxon::Result<void> Subscribe(C4DAtomGoal *observer, BaseDocument *doc);
		
	///
	/// \brief Unsubscribes an observer
	///
	/// \param[in] observer Pointer to an AtomGoal that has previously been subscribed
	/// \param[in] doc The document that owns the AtomGoal
	///
	void Unsubscribe(C4DAtomGoal *observer, BaseDocument *doc);
		
	///
	/// \brief Sends a messages to all subscribed observers
	///
	/// \param[in] type Message type
	/// \param[in] doc The document that owns the subscribed observers
	/// \param[in] data Optional message data
	///
	void Message(Int32 type, BaseDocument *doc, void *data = nullptr) const;

private:
	BaseLinkArray _observers;
};

maxon::Result<void> Observable::Subscribe(C4DAtomGoal *observer, BaseDocument *doc)
{
	if (!observer)
		return maxon::NullptrError(MAXON_SOURCE_LOCATION, "Observer must not be nullptr!"_s);

	// Check if this observer is already registered
	const Int32 observerIndex = _observers.Find(observer, doc);
	if (observerIndex != NOTOK)
		return maxon::OK;

	// Register new observer
	if (!_observers.Append(observer))
	{
		return maxon::OutOfMemoryError(MAXON_SOURCE_LOCATION, "Failed to add observer to the list!"_s);
	}

	return maxon::OK;
}

void Observable::Unsubscribe(C4DAtomGoal *observer, BaseDocument *doc)
{
	if (observer && doc)
	{
		const Int32 observerIndex = _observers.Find(observer, doc);
		if (observerIndex != NOTOK)
		{
			_observers.Remove(observerIndex);
		}
	}
}

void Observable::Message(Int32 type, BaseDocument *doc, void *data) const
{
	for (Int32 i = 0; i < _observers.GetCount(); ++i)
	{
		C4DAtomGoal *atom = _observers.GetIndex(i, doc);
		if (atom)
		{
			atom->Message(type, data);
		}
	}
}

Hi Adam, happy new year to you, too!

Since it works now, for some reason, I am pretty happy with what I have. However, since it might interest other plugin developers, I'll share more code. Maybe you have some tipps about improvements or potentially dangerous stuff, too.

The idea is that the shader has a LINK field where the user can link an object (which is also part of my plugin). The object can (but doesn't have to) provide a list of "custom outputs" that will be added to the shader's CYCLE. In the screenshot below it's the "Difference Map".

When a rendering is started, the shader will request the according data from the linked object during InitRender(). But that's not part of this thread

The shader's GetDDescription():

Bool TerrainOperatorShader::GetDDescription(GeListNode *node, Description *description, DESCFLAGS_DESC &flags)
{
	iferr_scope_handler
	{
		GePrint(err.GetMessage());
		return false;
	};

	if (!description->LoadDescription(node->GetType()))
		return false;
	flags |= DESCFLAGS_DESC::LOADED;

	BaseDocument* doc = node->GetDocument();
	const BaseContainer& dataRef = static_cast<BaseShader*>(node)->GetDataInstanceRef();
	
	// Hide or show attributes, depending on shader mode
	const Bool slopeMode = dataRef.GetInt32(XTERRAINOPERATORSHADER_DATA) == XTERRAINOPERATORSHADER_DATA_SLOPE;
	TF4D::GUI::ShowDescription(node, description, XTERRAINOPERATORSHADER_SLOPE_DIRECTION_ENABLE, slopeMode);
	TF4D::GUI::ShowDescription(node, description, XTERRAINOPERATORSHADER_SLOPE_DIRECTION, slopeMode);

	// Get linked object
	BaseObject *linkedObject = dataRef.GetObjectLink(XTERRAINOPERATORSHADER_OPERATORLINK, doc);
	if (linkedObject)
	{
		// Get linked object's NodeData
		TF4D::BaseTerrainOperatorData* linkedOperator = linkedObject->GetNodeData<TF4D::BaseTerrainOperatorData>();

		// Get list of custom outputs (these are the elements to add to the CYCLE)
		maxon::BaseArray<TF4D::GUI::CycleElementData> customOutputs;
		if (linkedOperator->GetCustomOperatorOutputs(customOutputs))
		{
			if (!TF4D::GUI::AddCycleElements(node, description, XTERRAINOPERATORSHADER_DATA, customOutputs, true))
				iferr_throw(maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Could not add LONG CYCLE elements!"_s));
		}
	}

	return SUPER::GetDDescription(node, description, flags);
}

The linked object's NodeData's GetCustomOperatorOutputs():

Bool ErosionOperator::GetCustomOperatorOutputs(maxon::BaseArray<TF4D::GUI::CycleElementData>& customOperatorOutputs) const
{
	iferr_scope_handler
	{
		GePrint(err.GetMessage());
		return false;
	};

	customOperatorOutputs.Reset();

	// GetCustomOutputName() simply returns a maxon::String
	customOperatorOutputs.Append(TF4D::GUI::CycleElementData(TF4D_CUSTOMOUTPUT_EROSION_DIFFERENCE, GetCustomOutputName(TF4D_CUSTOMOUTPUT_EROSION_DIFFERENCE))) iferr_return;

	return true;
}

Cheers,
Frank

Ah, damn. Now I've spoiled that I'm working on erosion for Terraform4D

Why don't you avoid all those difficulties and simply implement that dialog using the C4D UI?

If you're storing data in the tag's BaseContainer, you don't need to override Write() and Read(). That's meant for private class member whose data would be lost otherwise.

Also, you can remove the "return true" at the end of the functions. As you already return in the previous line, it will never be called.

I did today, including it in projectdefinition.txt worked smoothly, thank you!
If I ever find out why copying it do the folders does not work, I'll post it here.

Oh my god. the stupidest error....
OK, question 1 solved already, thanks

Ah, great, thank for checking!
Then I don't need to worry about my bmp code

Cheers,
Frank

Interesting...

If I put all code aside, simply start Cinema 4D 2023, and do the following:

1. Create Cube
2. Make Cube editable (with "c")
3. Choose Mesh > Add > Subdivide (click the cogwheel icon)
4. Set any settings, or don't change anything
5. Click OK

--> The cube does not change at all.

Is MCOMMAND_SUBDIVIDE maybe completely broken?

Cheers,
Frank

Hi,

I have a function that looks like this:

Bool SubdividePolygonObject(PolygonObject* const objectPtr, const maxon::Int32 subdivisions, const maxon::Bool sds)
{
	// Parameters for the modeling command
	BaseContainer modelingCommandParameters;
	modelingCommandParameters.SetBool(MDATA_SUBDIVIDE_HYPER, sds);
	modelingCommandParameters.SetInt32(MDATA_SUBDIVIDE_SUB, subdivisions);

	// Execute modeling command
	ModelingCommandData modelingCommandData;
	modelingCommandData.op = objectPtr;
	modelingCommandData.bc = &modelingCommandParameters;
	if (!SendModelingCommand(MCOMMAND_SUBDIVIDE, modelingCommandData))
		return false;

	return true;
}

Example usage:

BaseContainer cubeData;
basicObjectData.SetVector(PRIM_CUBE_LEN, maxon::Vector(100.0));
cubeData.SetInt32(PRIM_CUBE_SUBX, 2);
cubeData.SetInt32(PRIM_CUBE_SUBY, 2);
cubeData.SetInt32(PRIM_CUBE_SUBZ, 2);

PolygonObject* const objectPtr = static_cast<PolygonObject*>(GeneratePrimitive(nullptr, Ocube, cubeData, 1.0, false, hh->GetThread()));
if (!SubdividePolygonObject(objectPtr, 5, true))
	GePrint("Something went wrong."_s);

This works fine in R20 - R25, but returns false in 2023.
What could be the reason?

Cheers,
Frank

Thanks, you just recieved it!

Ah, sorry, it still happens under certain circumstances. I had to set this topic back to "Unsolved".

If it helps, I have narrowed it down to specific code that has to be in a .cpp file, in order to provoke the problem.
I can send you a tiny project that demonstrates it. What's the eMail again?

Cheers,
Frank

I found it!

In deed, I added two frameworks to the solution by hand. I also added the project references in my plugin project.

Creating a project reference manually in VS results in this block in the .vcxproj file:

    <ProjectReference Include="..\..\..\frameworks\cinema.framework\project\cinema.framework.vcxproj">
      <Project>{69bf9b7d-7eb2-7fc5-0009-38cb8c5cdea3}</Project>
    </ProjectReference>

But that's not sufficient, it needs to looks like this:

    <ProjectReference Include="..\..\..\frameworks\cinema.framework\project\cinema.framework.vcxproj">
      <Project>{69bf9b7d-7eb2-7fc5-0009-38cb8c5cdea3}</Project>
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
      <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
      <LinkLibraryDependencies>true</LinkLibraryDependencies>
      <UseLibraryDependencyInputs>false</UseLibraryDependencyInputs>
    </ProjectReference>

This fixed my build problems

Did you tried to generate the project files with the latest Project Tools?

I used the S24 Project Tool, which is the recommended one for R25 plugins.

Cheers,
Frank

Hi,

I started a vey small new R25 plugin project, and I constantly get linker errors. The project was, of course, generated using the S24 Project Tool.

cinema.framework_Debug_64bit.lib(c4d_pmain.obj) : error LNK2005: DllMain already defined in MSVCRTD.lib(dll_dllmain_stub.obj)
Creating library C:\Program Files\MAXON\Cinema 4D R25\plugins\testplugin\project_obj\testplugin\x64_Debug\testplugin.xdl64.lib and object C:\Program Files\MAXON\Cinema 4D R25\plugins\testplugin\project_obj\testplugin\x64_Debug\testplugin.xdl64.exp
..\testplugin.xdl64 : fatal error LNK1169: one or more multiply defined symbols found

Is there a commonly known reason why this could happen?

I already compared the .vcxproj file to the ones from my projects that are building fine, and couldn't find any significant difference. I even copied over the project file from cinema4dsdk, and simply swapped out the source files, it didn't help.

The funny thing is that the new plugin consists only of source files that I took from another plugin, to move them into a separate plugin project. So the sources definitely can be compiled and work. No problem in their original plugin project. Therefore, I deduct that there must be something wrong with the new plugin project.

Cheers in advance,
Frank

Hi Ferdinand,

thank you! In deed, that looks pretty simple. Wonder why I couldn't get it to compile...

I'll test this and report back in case it doesn't work. Since I guess you found it in active code, I'll mark this thread as solved for now. thanks again!

Cheers,
Frank

Hi Ferdinand,

thanks for your reply!

I am managing multiply PointerArrays, each for a different purpose, and I need to move their elements from one PointerArray to another. Since the objects the array elements point to are rather complex, I want to avoid copying them when moving them to another array.

PointerArray::ErasePtr() sounds like it does exactly what I want. The documentation says:

*ResultPtr<T> ErasePtr(Int position, T** dst)
Extracts a single element from the list and returns its pointer.
The caller takes ownership of the element.

I just can't figure out how to call it correctly, so I'll have the pointer removed from the array, and I end up with a pointer to the removed element of which I now have the ownership.

Cheers,
Frank

Hi,

short question, for some reason I can't figure this out...

I have a maxon::PointerArray<MyClass>, and I need to remove one of the elements, but without freeing the pointed object (instead, I'll add it to another PointerArray later). I believe, PointerArray::ErasePtr() is the correct function for this, but I can't get rid of the compile errors.

maxon::PointerArray<MyClass> array;

// Array is filled with objects
// This is done as described in the SDK docs:
MyClass* newObjPtr = NewObj(MyClass) iferr_return;
maxon::UniqueRef<MyClass> newObjRef = newObjPtr;
array.AppendPtr(newObjRef) iferr_return;
newObjRef.Disconnect();

// Remove an element from the array, so the array gives up the ownership, but the object still exists
// This obviously not working.
MyClass* formerElemPtr = nullptr;
array.ErasePtr(index, *formerElemPtr) iferr_return;

All I want is the element to vanish from the array, but I still need a valid pointer to it. What's the correct way to do this?

Thanks in advance.

Cheers,
Frank

You can read the "Changes in SDK" page in the R21 SDK documentation. And then, if it should run in later versions, too, you should probably also read the ones for R23 and R25.

Here's the S26 one:
https://developers.maxon.net/docs/Cinema4DCPPSDK/html/page_changes_in_sdk.html