Forum and Support Guidelines

Table of Contents

• Support Procedures
  • Scope of Support
  • Confidential Data
• Forum Structure and Features
  • Tagging
  • Markup and Uploading Content
  • Ask as Question
• Structure of a Question
  • Title
  • Short Description
  • Detailed Description
  • Additional Resources

Support Procedures

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.

Support Procedures: Scope of Support

Please note that all requests are bound to the scope of Cinema 4D public API support requests. This means specifically that:

• We cannot provided support for third party libraries or code design that is in direct violation of Cinema's technical requirements (e.g. Cinema 4D's threading restrictions).
• We cannot provide support on learning either C++, Python or one of its popular third party libraries.
• If necessary, we will provide code examples, but we will not provide full solutions or design applications.
• "It doesn't work" is not a support request and ultimately we will not debug code, but instead provide answers to specific problems.
• We will neither reveal non-public functionalities of Cinema 4D's API, nor will we establish a direct line of communication with the developers of Cinema 4D.
• Depending on the complexity of the problem, we are not obliged to provide any support at all and MAXON is not obliged to make any changes to the SDK at your request.

Support Procedures: Confidential Data

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.

Forum Structure

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.

• Cinema 4D Development: Questions about using the Cinema 4D APIs.
• Cineware Development: Questions about using the Cineware API.
• General Programming & Plugin Discussions: Questions not directly related to the Cinema 4D APIs.

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.

Forum Feature: Tagging

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:

• microsoft windows and/or apple macos: The operating system environment(s) in which the problem is encountered.
• r19, r20, r21, s22, r23 or rXX: The version(s) of Cinema which are relevant to the problem.
• c++ or python: The programming environment(s) that is/are being used.

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.

Forum Feature: Markup and Uploading Content

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.

Forum Feature: Ask as Question

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.

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.

Structure of a Question

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.

Structure of a Question: Title

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.

Structure of a Question: Short Description

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.

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.

Structure of a Question: Detailed Description

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 application interface with which the problem is being encountered. Examples would be a Script Manager script, an ObjectData plugin or an external application making use of the Cineware SDK.
• If the problem is a runtime error or an unexpected behavior of the SDK, one should lay out the precise steps which lead up to said behavior, and what exactly one would consider wrong about these results.

Example

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:

1. An edge case. We get the two green points but not the red one.
2. A default case. Everything is fine here, we get four points.
3. A corner case. We only get the green point but not the red one.

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.

Structure of a Question: Additional Resources

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):

1. Crash reports of Cinema 4D.
2. Any error messages or exceptions raised by Cinema in its console.
3. Console dumps of the investigations of the problem (by printing out values, nodes, etc.).
4. Additional data like images, videos, data dumps or scene files.

>>> from c4d import utils
>>> nbr = utils.Neighbor()
>>> nbr.Init(op)>True
>>> nbr.GetPointOneRingPoints(26) #edge case
[52, 27]
>>> nbr.GetPointOneRingPoints(39) #default case
[65, 38, 40, 13]
>>> nbr.GetPointOneRingPoints(25) #corner case
[24]

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.