THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/11/2012 at 01:43, xxxxxxxx wrote:
I've recieved the message, thank you.
It's rather simple, but it didn't occurr to me earlier. As I already said, the
way you store the frame, offset and zoom data is not OOP style. And that is
actually why your plugin doesn't behave the way you want it.
When tags are executed in Cinema 4D, they are invoked one after another. (Ok,
sometimes even parallel, but not every tag at once!) When the tag on the first
object is being executed, it does its stuff and checking, etc. AND (now comes
the fatal thing) : It sets the global information of the last frame, offset and zoom.
The problem here is the word global. When the first tag was executed,
the frame, offset and zoom values are already updated, and therefore, all other
tags will work on different data than the first tag.
However, it's rather easy to solve. In general, it's considered
bad style using globals in Python (and many other languages as well). They
cannot be ommited sometimes, but their use can be reduced.
You can imagine the current situation like the following : Every tag is a pupil
in school, and they all have to do the same task.
- What you are doing, is let them solve it on the chalkboard. And after the
first pupil has solved it, all other pupils don't have to do it anymore.
- What a teacher should do, if all pupils must do the work on their own, is
to give each pupil their own sheet.
Transferred to the world of OOP programming: Store the information in the
Tag-instance instead of in the global scope.
class TagPlugin(c4d.plugins.TagData) : def __init__(self) : super(TagPlugin, self).__init__() self.last_frame = -1 # etc.. def Execute(self, tag, doc, op, bt, priority, flags) : frame = doc.GetTime().GetFrame(doc.GetFps()) if frame != self.last_frame: # ... self.last_frame = frame # etc..
Some other notable things:
- visible = 1, Rather use a boolean, like visible = True
- Rather use implicit boolean checking, like if not visible:
- I personally prefer spaces rather than tabs. This way, you have more control
over the look of your code.
- Class names are usually CamelCase. It's not a must, but widely accepted in
- It's very unusual to write variable-names CamelCase with the first letter
being uppercase. CamelCase with starting with a lowercase letter (mostly found
in Java) or even underscore separated variable names (and all lowercase, the
more Pythonic way) are more conform.
- As I already stated, you don't have to define your description symbols in the
plugin-file. They are embedded in the c4d module. You can
See the PEP8 for information about the Python style-guideline
(which, again, is not a must, just a guideline).