<node3d>.spinto ?
 

I used .spinto command before but I don't see it in R3. In the VizHelp, I found a missing link to .spinto on the .spinto page. Is the command just missing or are you going to eliminate it in R3? Thanks!

I've seen a number of links in the help files are broken, this may just be part of that issue. I expect they'll re-index the help files as a part of wrapping up for the release.

It's definitely still there, my scripts haven't broken. :) Any time you're curious about what exists, and what doesn't, you can READ the source code in the python/viz.py file which is included. Now, the help file is PREFERABLE in most cases, but there are some cases where the source is really useful for double-checking things. In this case, search for "class VizNode" and then search below that for "def spinto". Voila.

In Vizard 3, we would like to move away from functions that hide the action interface. So instead of calling myNode.spinto() or myView.goto(), you would call myNode.addAction( vizact.spinto() ) or myView.addAction( vizact.goto() ).

However, we will keep the shortcut functions for backwards compatibility.

Thanks. I used the command as a trigger to the next event, but it didn't work in R3. That's why I thought there might be some change in the command. Anyway, according to the warning, the command will be deprecated in future versions of Vizard and vizact.spinto should be used instead.

I do recommend that the python/*.py files include comments when this is the case. For example:

While I agree that 95% of the users will stick to the help files, the openness of the python code is what attracted me and my colleagues to pick Vizard. It allows for working around the rare broken or not-quite-complete-enough help files, along with all the other benefits of the python platform.

Agreed! Source code is the ultimate program documentation.

What do you think of having documentation text above every function? Would this be useful to you, or would it clutter the .py file to much?

I mentioned to farshizzo once before that there were many functions that did not have docstrings. My own opinion is that anything that is not intended for outside callers should have a brief comment (deprecated, internal helper function, etc.), and anything that is intended for outside callers should have a complete and useful python docstring. Even if almost nobody using Vizard knows the python help() command, it will still be there in the *.py files to read.

There's some extra work involved in good docstrings; a one-liner is not usually sufficient. However, you might find a way to automatically include the docstrings into the online help files as a preface to any additional detail there.