In the end I went with two extremely simple methods exposed to mxs, one that calls the object’s BeginEditParams (with Interface::GetIObjParam() output as the first param) and a matching one for EndEditParams, called in the scripted plugin on its own 1st rollout open and close. Maybe some time in the future I’ll rewrite it and for that, I’m definitely saving this thread. Right now, I try to avoid SDK as much as I can as I feel like I don’t really know what I’m doing most of the time.
I’ve tried using 1,2,3,4 for the rollout category ID before and it felt like those were pretty much ignored in the modify panel, will try with some more extreme numbers.
thats cool, i asked about interfaceserver as it’s one of the best features of the sdk when you need one plugin class to interact with another. If you are keeping it more mxs it’s not something you need to deal with yet.
Right now, I try to avoid SDK as much as I can as I feel like I don’t really know what I’m doing most of the time.
it’s the opposite for me now, I don’t write any tools in mxs anymore, if i use it it’s as a prototyper/validator (though even this is pretty rare these days
and usually for just custom meshes) The mind set is very different between mxs and sdk. Actual “Tools” in a mxs sense are a rarity in the sdk, custom objects and modifiers (or combinations of modifiers) are solution the of choice.