Hi Kent,

thanks for your feedback.

Actually merging C++ and Python categories was an outcome of our beta phase, where some were of the opinion too many categories would not be desirable. But there's another reason we did so: Our C++ and Python APIs are actually so similar, that many answers hold for both languages.
And lastly, if it were just for the C++ and Python tags, we probably wouldn't even ask for the tags. It's rather tags about version or API in use, we are interested in most.
Oh, and by the way, although I have to admit it was less frequent in the old forum, but instead of asking for tags we were asking to post into the right category. Which by the way still happens with just the four we have here.
Oh, oh... Kent, can you please consider using tags? See About This Forum. Thanks!
Just kidding.

But anyway, these are our reasons, maybe others have different ones and agree with yours. Then please, provide us with your arguments and opinions. It's not that we wouldn't care. We have taken notes of all feedback we received so far and will evaluate this hopefully during November. So, it's actually a good time to provide such feedback.

Maybe we can also address your aversion of "oversized" text. We'll look into providing themes. But we also need to see, what we can actually achieve and maintain in a certain amount of time. After all we think, support work is more important than induldging in web design.
One thing I can say for sure, though. It's not your age. Because with my age increasing I definitely need larger and larger text...

Now, for the community aspect. I'm really sorry to hear this. I can only say, no, it was not our intention to kill the community in Plugin Café. Believe me, quite the opposite. I'd be really interested in more opinions and suggestions on this topic.
Here's how I see it:

• It's always risky to replace a forum, moving the site. And I'm not sure everybody has already joined us here. We had very good reasons for this move and I really hope, everybody will follow.
• With us answering in a day or two on most questions, there's often no more reason for the community to contribute. Looking into the old Plugin Café you will find many thready which took days if not weeks to get an answer from the community. So, I guess, we could revive some community aspects by simply postponing our answers, but I'm not sure that's desirable either.

For example @mp5gosu told us, how much he likes working in this new forum. And we can see him actively discussing and contributing.

Please, everybody, come in, join this thread and provide us with your feedback. Tell us what you want and need. Kent mentioned some good points here. One especially worries me. Help us make this forum the place you want to be supported in. Help us to make this the place you want to discuss your plugin development related topics in.

Cheers,
Andreas

Hi,

thanks for the additional information and setting the tags.

The BitmapButton needs to be added to the dialog via AddCustomGui().
For example like so:

        # Prepare a red bitmap for the button.
        w = 50
        h = 50
        bmpRed = c4d.bitmaps.BaseBitmap()
        bmpRed.Init(w, h)
        for y in xrange(w):
            for x in xrange(h):
                bmpRed.SetPixel(x, y, 255, 0, 0)
        # BitmapButton configuration
        bcBitmapButton = c4d.BaseContainer()
        bcBitmapButton[c4d.BITMAPBUTTON_BUTTON] = True

        # Add a BitmapButton to the dialog.
        # _bitmapButton is a member variable of the dialog class
        buttonId = 2000
        _bitmapButton = self.AddCustomGui(buttonId, c4d.CUSTOMGUI_BITMAPBUTTON, "", c4d.BFH_CENTER|c4d.BFV_CENTER, w, h, bcBitmapButton)
        if _bitmapButton is None:
            print "Handle this error!"
        # Assign the image to the button.
        # Note: Let it create an internal copy as the created bitmap will be free'd, when scope is left.
        _bitmapButton.SetImage(bmpRed, True)

Cheers,
Andreas

Thanks to everybody in this thread for all your kind words.

@C4DS said in Good Bye and Thanks for the Fish:

As mentioned earlier, this place won't be the same without you.

You may overestimate my contribution. Silently watching from the side line, my feeling is, Riccardo, Sebastian, Maxime and Manuel, though being handicapped by a little loss of man power, not only managed to continue to do a great job in here, but even managed to further improve. Just let the dust of change settle a bit and they'll excel even more.

@C4DS said in Good Bye and Thanks for the Fish:

And with the recent unraveling of the plot, this "ending of your novel" has sure taken a new twist.

I'm not quite sure where you are heading and which plot recently unraveled. But please believe me, my departure was not so much related to Maxon and certainly not connected to any announcements on Maxon's strategy of the recent past. I left a group of friends behind, mostly for private and to a certain extent selfish reasons, which I won't discuss in public. Yet, please, try not to read between the lines and do not interpret my silence against Maxon or the SDK Team. I really enjoyed being part of the ride. Having had the chance to meet all of you in here was really great. It's just sometimes you need to stop eating, when it tastes best. I'm pretty sure Forest Gump also said some fitting words, I just can't remember...

Cheers,
Andreas

Hi,

no worries, we'll get you there.

One recommendation: When doing Python development, have the Cinema 4D Console window open (Menu Script -> Console...). There you will be presented with errors.

I think, your problem will be, that you try to access op, probably intending to change parameters of the active object. In Script Manager doc and op are global variables predefined for convenience. In a plugin, you have to get these yourself using GetActiveDocument() and GetActiveObject().

Bye,
Andreas

Dear fellow developers,

my seasonal greetings to the entire community.

But I'd also like to take the chance to say thanks to "our" SDK Team, who served us so well during the entire year. Patiently answering even my most stupid questions, as if they had nothing else to do (which of course they most likely have)...

So, please, everybody in this community join me in saying:

Thanks for supporting us so well, Riccardo, Sebastian, Maxime and Manuel!

Everybody hopefully gets some well deserved days of rest.

Cheers,
Andreas

Hi Andre,

you can simply use SetLink(), the opposite of GetLink().

In order to clear a link box, you'd call: self.linkBox.SetLink(None)

The type you do in your code snippet is a bit unconventional in terms of Cinema 4D's API (not wrong though), but usually we recommend to stay in our API for example with CheckType() or IsInstanceOf(). But in the end, I think, you don't even need the type check, if you simply restrict the types accepted by the link box.
For example like so:

bcAcceptedObjects = c4d.BaseContainer()
bcAcceptedObjects.InsData(c4d.TakeBase, "") # only allow BaseTakes to be accepted
bcLinkBox = c4d.BaseContainer()
bcLinkBox.SetData(c4d.DESC_ACCEPT, bcAcceptedObjects)
self.linkBox = self.AddCustomGui(2001, c4d.CUSTOMGUI_LINKBOX, "My Link", c4d.BFH_SCALEFIT | c4d.BFV_CENTER, 0, 0, bcLinkBox)

I turned this thread into a question.

Cheers,
Andreas

Hi,

no your script is not wrong. There's just a bit more to it.

1. To state the obvious, there's no reason, why different tools should have the same ID for a parameter's data, even if these parameters are called identically in the user interface.
2. Just like every other NodeData derived entity, a tool does not necessarily store it's parameters in the BaseContainer. Or it may store values in the BaseContainer, only, if it's different from default. Either way, you have no guarantee to find all parameters in the BaseContainer. Rather use GetParameter() (so in your case for example tool.GetParameter(2108, c4d.DESCFLAGS_GET_0))

Cheers,
Andreas

Hi,

you can also use the Description.

With a small loop, you can get information about a tool's parameters and their type:

    toolID = doc.GetAction()
    tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL)
    desc = tool.GetDescription(c4d.DESCFLAGS_DESC_0)
    for bc, paramid, groupid in desc:              # Iterate over the parameters of the description
        print bc[c4d.DESC_NAME], paramid[0].dtype  # Print the current parameter name and type

It sounds a bit, as if you try to create some kind of undo system for tools. Something Cinema 4D does not have currently. The standard undo system for example works by cloning instances, something that is not possible with tools. But of course the cloning automatically takes care of the entire instance's state, regardless, if parameters are stored in the BaseContainer or if the complete state is really defined by parameters.
So, just be aware, even with the above approach, there might still be information stored inside of a tool, which may not be reflected by the Description, either. I have no examples for this, it is more a word of a warning, something like this might come up.

Cheers,
Andreas

Hi,

no, you are not!
Really there are no stupid questions and please do not delete such posts. Especially not, if you already invested time in posting the correct answer. We'd rather see this as knowledge others might benefit from in the future.

Cheers,
Andreas

Sorry for joining in so late. And I think, all relevant points have already brought up.
I just wanted to add one twist or slightly different point of view:

c4dpy is a so to say "standalone python interpreter" with access to Cineama 4D's api.

Actually c4dpy is a full headless Cinema 4D, which can be used as a Python interpreter in IDEs.

Cheers,
Andreas

Hi Maxime,
that's a bummer.

Just a few additions:

is done by calling HandleMouseDrag. Your code is paused until the drag operation ended

Yes, no objection. But it should be said, during this "pause" one does still receive messages, among them BFM_DRAGRECEIVE_START and BFM_DRAGRECEIVE. Just not BFM_DRAGEND. Which makes me think, if only the receiver would not "consume" this message, it could already work...

From a pure implementation point of view, it also does make sense since it would make no sense if each drag operation have to support all possible managers

I wouldn't want it differently. But I still think, the initiator of an action deserves result information. after all these years, I'm still wondering, what's this obsession with not delivering feedback to a caller. Yes, I'm looking at you CallCommand()...

Finally it is not possible to drag objects directly to the viewport

I didn't even consider, drag and drop could work differently for materials and objects, or objects not working at all. So, thanks for the info and avoiding even more headache on my end.

I guess, we are back to the drawing board then.

Anyway, greetings to the team.
Cheers,
Andreas

Hi,

I know, this is a topic that got discussed several times in the past. Nevertheless I can not get it to work properly.

The goal: Being able to drag a yet to be created object or material from my GeUserArea into C4D (desired targets: view port, Material Manager, Object Manager,...).

I said "yet to be created". By this I mean, it is an asset from some library, which is not yet part of the document.
I have two options:

• Create and insert the asset before the drag and then remove it again, if the drag fails (either being escaped or dropped onto some forbidden place).
• Or I do insert the asset into the document on successful drop.

The beginning looked promising, HandleMouseDrag() seems to be the function for this scenario and at first it seemed to work as expected.

But how on earth do I find out about the outcome of the drop?

I do receive BFM_DRAGRECEIVE, but I do never get BFM_DRAG_FINISHED or BFM_DRAG_ESC to be true. Only BFM_DRAG_LOST seems to hold information. It is always jumps from false to true, when the user ends the drag in whatever way (escaped, dropped successfully, dropped on forbidden area, it doesn't matter).
Yes, I do return the return value of SetDragDestination() from my Message() function, while in drag, as I found in this forum, that it's needed to notify C4D about my interest in the drag (which I started in the first place... Not being interested in the outcome of something I started feels a bit strange to me... a bit like firing a rocket and not being interested, if it actually started, exploded on the pad or actually reached its destination. Anyway...).

And then there's an additional issue with dragged materials:
The result is different, if the user drops it onto an object in viewport or Object Manager or onto the Material Manager. In the first case it works as expected (as long as I insert the material into the document), but in the latter case I end up with two material being created in the MM. So, when dropping onto an object C4D seems to assume, the material is already part of the document and only assigns it (but I am responsible for making it available in the document), while when dropping onto the MM, then C4D seems to automatically create a copy (so I should not insert it into the document myself).
But how am I to decide, what to do and what to expect?
Even if I had a way to find out about the success of the drop operation, I would still be lacking the information about the drop target.

Any help would be much appreciated.

Cheers,
Andreas

Thanks, Manuel

I do not mean to stress anybody.
But I'd say, this is quiet basic plugin functionality, which by now is not working for more than two years. So, i thought, I'd ask, if there's a chance for a fix.

Hi,
are there any chances this will ever get fixed?
Cheers,
Andreas

Thanks, Ferdinand

Not philosophical at all.

a) Why would we need to pass a list of point positions (or would have an option for it), if the information is taken from an object only. Is it only to restrict the sampled points? Why wouldn't we pass point indices instead of vectors, then?
b) FieldInfo.Create() docs clearly state the callers to be optional.

As a Python developer I do not tend to look into the C++ docs, if Python docs are existing.

And Maxime's example above does not insert the temporary poly object, does it?

Sorry to bump this thread.
But I'm also wondering, why the temporary poly object is needed.
I'm currently in R21 (as my customer) and there I also get sample values only if such poly object is passed. The pure list of positions is not enough in results in sampled values always being zero.

Hi Ferdinand,
thanks a lot!
No ETA needed, I'm grateful it will be added eventually.
Cheers,
Andreas

I had pretty mixed results with latest releases and use of RestartMe(). Somethings rings in the back of my head its use beeing discouraged.
And I think, a restart shouldn't be necessary at all. I'm even of the opinion restarting anything is almost neverr a good solution. Not even with "Be-ba-boop: Rebooting Cinema 4D...". I'd rather hope, to be able to simply save the prefs just like it is possible in the C++ SDK. So, I'll keep my fingers crossed and wait for the result of your discussion.

Hi,

is there a chance, we could get SaveWorldPreferences() in Python.

I store some licensing info inside the prefs container. If a user now manages to crash C4D after having entered the license information for my plugin, the licensing info is lost and user needs to enter it again. I would have never imagined this to get an issue. But unfortunately I was wrong...

Would be cool to be able to save the prefs manually.

Cheers,
Andreas