Forum and Support Guidelines

Table of Contents

• Support Procedures
  • Scope of Support
  • Rules of Conduct
  • 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: Rules of Conduct

Please note that all postings must follow these rules of conduct.

• Both forum and email support requests must be in English. Off-topic threads in the forum are also bound by this rule. Maxon Computer reserves the right to not answer support requests in other languages. Users who repeatedly violate this rule might be banned.
• Postings that contain views that could be construed as discriminatory against race, sex, religion, sexual orientation, or gender expression will be deleted. In severe or repeated cases, the user(s) will be banned.
• Postings that breach Non-Disclosure-Agreements, especially these of Maxon Computer, will be deleted and the user(s) will be banned.
• Postings that are of inflammatory nature or that fail to maintain a civilized tone will be deleted and the user(s) might be optionally banned.
• Postings that are outside of the scope of Computer Graphics, specifically Cinema 4D and its APIs, might be closed by us. This especially applies to political discussions.
• Maxon Computer reserves the right to otherwise close, delete, or moderate topics as necessary for maintaining the functionality of this forum.

Additionally, all postings that ask a question which is meant to be answered by the SDK Team must adhere to the rules listed below. These rules do exist to ensure that questions are in an answerable form, and equally important, that the questions and their answers form a searchable knowledge base for future readers.

• A topic must cover a singular subject; the initial posting must be a singular question.
• Users can ask follow-up questions, asking for clarification or alternative approaches, but follow-up questions cannot change the subject.
• When the subject of the topic is "How to create a cube object?", then a follow-up question cannot be "How to add a material to that cube?" as this would change the subject.
• A valid follow-up question would be "Are there other ways to create a cube object, as the proposed solution has the drawback X for my use-case?" or "Could you please clarify the thing Y you did mention in your answer, as this is still unclear to me?".
• There is some leverage-room for this rule, but it is rather small. Small changes in the subject are allowed, large changes are not.
• The initial question of a topic author must be consolidated into a singular posting. Diary style topics with multiple postings are not allowed. See Structure of a Question for more information on how to make a good initial posting. When you want to add information at a later point, please use the edit function.
• The topic subjects must be sparse and tied to a specific problem. "My Nodes API Questions" is not a valid topic.
• Maxon reserves the right to not answer postings which violate these rules.

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(dot)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.