View Full Version : Modeler Plugin checklist

06-17-2004, 10:12 AM
I would like to start to build a checklist for plugin developers. This should be available to everyone so that some basics are not missed when developing new plugins.

Good naming/categorizing conventions
The plugin should probable match the name you have given the file.
If you plan to release multiple plugins. You Might want to add a prefix to the name to make finding your plugin easier
Or if itís a plugin have them placed inside there own catgory. Like davids ikedaís tools

Multiple layer support
If your plugin could be used on multiple layers it should support it. If not it should be clearly stated.

Consistent falloff types
Plugins should try to support the default falloff system as much as possible. If they have a better system try to add on top of the existing system.

Support for the Com Ring
New plugin should try to make available hooks through the com ring as much as possible

Establish some basic Com Ring standard

Be aware of undo and try support them if possible

Support affected Vmaps
UV and Morphs (not breaking existing maps, etc.)

Support Symmetry

Support center action

Support apply

Support numeric value

I will need to start breaking things into categories for the types of plugin soon

Off the top of my head I'd say there would be two main categories to start with plus the basic selection types



Please, Iíd love to here more input on what else we should see on this list.

06-18-2004, 12:05 AM
Great Idea cas :p

06-19-2004, 08:52 PM
Sounds good, but might be hard to implement.

06-20-2004, 05:31 AM
Yea if it was that easy...

But i wonder what this thread does in the LScript section :confused:

Anyway, i don't think i'd ever develope according to such a list, first priority is that the planed features are robust, then you will want to get some user feedback and implement what users think is most important and not what is left on some checklist.
Also i'm no advocate of mimicking every part of Lightwave just because someone might be accustomed to it, i know some users always want it behave like some other existing tool without trying the new way and see if it's better, but that's not how innovation works IMHO :P

06-20-2004, 04:09 PM
Lynx3d I completely agree following the leader does not always produce innovation. But pointing out the obvious does prevent simple mistakes, which can make room for innovation.

It's in the Lscript section because I think hearing from more developers will give me more clear feedback at this stage of the list. Eventfully it will make itís way to the community section where we can hear a wider range of feedback. I donít want this to turn into a feature request list at this point.

Iím constantly blinded by my own inpatients to get to the outcome of a new plugin. Itís possible that a new developer if they had this list and simple examples would look into incorporating falloff from the start. These things can be forgotten in the beginning because we are so caught up with the desired outcome of our new plugin. Planning for then could in reality induce innovation by forcing the developer to think about it before hand. knowledge of what I need in my scripts in order to prevent me from making more mistakes than necessary. So Iím making this list to help me create innovated plugins and Iím involving the community because it is invaluable to itself.

Knowledge is power and the more you make mistakes the more clear that statement becomes.

06-20-2004, 04:56 PM
Yea ok, checking a list of most common features (like falloff or providing commands for scripting, and other things users will most likely ask for) before starting to produce code is no bad idea, it can save trouble implementing stuff afterwards.

I first understood this as list of features that every (modeling) plugin should have.
I am currently not writing commercial plugins, so it's basically me deciding the core features and add others as my time allows. And things like multiple layer support etc. is really stuff you can add anytime, but fixing other bugs is often just more important (to mee at least)

06-20-2004, 07:37 PM
Ya It will just a general checklist.

Like say i'm going to try to make an alternate bevel tool. To prevent bugs i'd want to ask myself what would happen if your not on layer one, or what will happen or if muliple layers are selected. That kind of thing.

Got any you would like to contribute?