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

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

Hi,

I'm afraid, the SDK docs (C++ and Python) could need some updating to reflect the latest changes done to dialog borders in S26. It seems most flags are pretty useless, now. BORDER_ROUND doesn't seem to do anything anymore, for example.

Of course, I'd prefer to get back the old border behavior, but I'm not naive and think, this could be an options. But at least the changed behavior should be documented.

Cheers,
Andreas

Maybe the misunderstanding here comes from the normal behavior of the Attribute Manager.
One can not force a group open with this flag. The flag does only influence the open state, when the group for a given entity type (be it an object, tag or material of a certain type) gets shown first. As soon as the user touches the group (either opening or closing it), the Attribute Manager will use user's choice instead for all entities of this type.

@FSS Thanks for your looking into it and your explanation.

I'd be pretty concerned, if it's possible to destroy the C4D via the Python API (as long as I do not do any explicit file access on any installation files). If you can somehow reproduce it or at least have an idea, in which area of the API to look out for such dangers, I'd be grateful.