this document outlines the procedures related to the SDK support MAXON does provide in this forum. Please read these guidelines carefully, as following them will not only explain if a particular request is eligible for support at all, but also increase the quality of the support you do receive.
Support requests will be discussed by us internally and then be assigned to a team member. Because of that new topics will take at least one day to be answered. This procedure is in place so that each support request can benefit from the combined knowledge of the SDK team, and subsequently give the development community the best support possible.
Please note that all requests are bound to the scope of Cinema 4D public API support requests. This means specifically that:
In complex cases where it is required to share confidential data with us, support requests with that data attached can be sent to sdk_support(at)maxon.net. However, if sensitive data requires an NDA existing upfront between the parties, please get in touch with us to settle this topic before sharing any data.
When posting on Plugin Café, please make sure to post on the correct forum. There are three sub-forums for different kinds of support requests.
The sub-forum to post to can be changed while writing a new posting. Once a posting has been submitted, this feature is no longer accessible on edits of that posting.
The forum has a tagging feature, which can be found in the posting editor. A posting should use at least the following tags to describe:
Feel free to use any other tags to describe the problem. Especially useful are the bug report tag, to report faulty API behaviors, and the documentation tag, to report problems with the documentation.
The Plugin Café posting editor recognizes Markdown syntax to format a posting. Please make sure to fence in any code with code markup. The posting editor has a button to transform a selection of text into a code listing, but one can also just type three grave accent characters (```) and a line break to both start and end a code block.
def foo(a, b):
return a + b
To make things prettier, one can also markup technical terms inline with a single grave accent, e.g. `maxon` will render as maxon. The editor also allows to attach image files and arbitrary file types to a posting. Image files will be rendered in a posting as images, while all other file types will appear as a download button. One can also hotlink any image with the standard Markdown syntax, but please make sure that the host does allow hotlinking, both from a technical and legal standpoint.
The forum has an Ask as Question feature to track solved and unsolved questions. Once one has created a topic, a Topic Tools button can be found below the first posting and clicking on it will mark that topic as a question.
Ask as Question
Once having marked a topic as a question, the topic author can flag any reply as the correct answer by opening the context menu of a reply with its three dot-button.
Which will flag the topic as Solved. Solved topics will be considered as requiring no further support by the SDK Team. But all users can still post in the topic.
A good support request usually does follow the here presented structure and will help to communicate a problem less ambiguously. The elements of this structure are the short description, the detailed description and the additional resources. Below is an example for a complete support request - which will be subject to the explanations in this category. The original topic this example has been taken from, can be found here.
Before posting a question one should always check:
The title of a posting should reflect the problem expressed in the short description. Please also remember to tag a posting and to use the ask as question functionality of the forum.
As demonstrated in the example, the title does not have to explain the entire problem, but instead should communicate what leads into the problem. In the example case that "lead in" was for me being puzzled about the behavior of said method.
The short description should express the primary objectives and the scope of the question in one sentence and up to 150 characters. The number of characters is only a rough figure, 50 or 200 characters are also okay, but 500 characters are not. This is a an important point in a posting and unfortunately also one that is often disregarded. When a topic starts with a tangent, there is a good chance that the actual problem will not be communicated properly.
Dear community, is it possible that the method c4d.utils.Neighbor.GetPointOneRingPoints() is bugged?
The short description is very similar to the title, but should also express the exact scope, here the fully qualified name of the method we are referring to, and the primary objective. Which in this case is the question if the experienced behavior is a bug or not.
The second paragraph should contextualize the primary objective with details on the circumstances in which it is being encountered. There is no length limitation here, but one should also try to eliminate all parts that are irrelevant to the primary objective. Things one could mention are:
The documentation states that it will return "the points that are attached through one edge to the given point". The problem occurs on points which are either edge or corner cases of a non-closed surface. Below is a simple example to illustrate the problem. The orange points are the inputs for the method, the green points are the output, and red points are points not included in the output - but I would expect them to be included:
In the example case we describe the problem in more detail by expressing what exactly we consider to be not working or what we do not understand. Bullet points usually work really well in this section. Illustrations or videos of the problem help, but are not needed when the rest of the descriptions are on point. If possible, one should try to express some kind of contrast here. The contrast can either be in the form of "I want this to happen, but that happens instead" or in the form of a documentation-statement to program-output contrast like shown in my posting.
Into this last section goes any information that is not expressed in sentences. This also means that one should not add any substantial amount of text here. This section should always contain the shortened code that can be used to reproduce the problem. Possible additional items are (sorted by importance in decreasing order):
One can reproduce the behavior in the console on a similar topology (and different point IDs) with the following code:
>>> from c4d import utils
>>> nbr = utils.Neighbor()
>>> nbr.GetPointOneRingPoints(26) #edge case
>>> nbr.GetPointOneRingPoints(39) #default case
[65, 38, 40, 13]
>>> nbr.GetPointOneRingPoints(25) #corner case
The important point here is to provide code that is executable or code that matches common patterns of Cinema's API, so that it very easy for us to derive executable code. In the example request here we were actually in a TagData plugin. But we quickly figured out that the plugin itself had nothing to do with the problem and wrote this small snippet demonstrating the core problem. The goal should be to cut out any unnecessary procedures and complexity. Some light commenting about what one does intend the provided code to do, is also helpful.
Happy coding and happy rendering,the MAXON SDK Team