Well… exactly that. To be a bit more specific.
In maxscript you create a mouse tool by using something like this:
tool foo(
)
starttool foo
In pymxs im not so sure as by importing pymxs runtime i get
from pymxs import runtime as rt
rt.MouseTool()
And that of course generates an error.
I simply dont know, probably missing something here but I would like to have some indication on how to proceed.
I think the tool construct is unique to maxscript and not wrappable in python.
They would have to have exposed it as a constructable class or callable function.
What is the error that is produced when you try to instantiate rt.MouseTool?
Hi. I posted this question simultaneously to Autodesk forum. They took some days but you can see the answer here.
Although pymxs closely mimics Maxscript, unfortunately, it does not support creating plugins or tools. Examples of these unsupported constructs are Custom Attributes, Scripted Plugins, Scripted Tools. These will have to be written in Maxscript.
We are continuously working on improving the pymxs documentation (link), and so your feedback in this regard is highly appreciated.
Thank you for your understanding.
The documentation is a bit better now for 2022 release.
Yeah - pretty much as I thought.
You could write a helper function in python that constructs a string of a maxscript code to create the tool, then execute it to evaluate the maxscript using
pymxs.runtime.execute
If mouse tools is something I would use regularly that’s what I would do to make it more pythonic to set one up. Implementation isn’t great but once it’s in a function you don’t really have to care.
My request is kind of complex, it requires inputs and outputs i need to feed to the MouseTool, so the rt.execute thing turns very cumbersome rather quick. The point it is not straightforward and if you end up running a bunch of execute (or doing so on very big maxscript files) then whats the point of using python?
We use python as we want to integrate in a workflow, there are serious issues of limitations on how pymxs actually wraps maxscript and a lot of those issues go down to lack of documentation, which is a thing I already elaborated in another post.
In my mind part of the solution is to raise the problem of lack of documentation to Autodesk (which as stated above is being taken care of little by little). The lack of support of Tools should have been stated in a documentation somewhere, thats all what Im asking.
The point of using execute is to get what you want working. If you refuse to use it because it isn’t how it should be in am ideal world then shrug.
I could write up a wrapper function that would return a pointer to a fully parameterised mouse tool from mxs to python in 30 mins - not perfect but once you have done it then it is there the next time you use it.
Is it a bit annoying that you can’t directly call maxscript only constructs in python? Sure.
Is it even more annoying that the documentation didn’t state this, yerp. But there is a viable way of doing what you want all the same, it just took a little longer to find it ( all hail the internet ) - your company should understand this about Max, and all software really, and make valid accomodation for scenarios not being straightforward in your schedule.
Anyways - as I said in my other post, good luck to you…