I’m wondering if I can add a script to max (stdscripts) that will extend the current VFB.ms. So I want to add an extra and not replace the original rollouts. I want to add another rollout to to the Rendered Frame Window and keep the originals… in the new rollout I want to add some custom buttons. I have been reading into VFB and the mxs help and I think it cannot be done, without replacing the original VFB.ms and there seems to be also a limit to how many rollouts can be added (3 max.: topleft, ropright and bottom)… can anyone confirm or deny this.
What I simply want is to add another script without removing any existing callbacks and add a new rollout to the renderedframe window
Any suggestions pointers would be great! Right now I’m just hacking VFB.ms…
-Johan
No can do. You’d have to take one of the original rollout definitions, extend that with what you’d want, then insert that into the VFB methods struct.
Correct. Would be nice to have an API to completely randomly attach <rollout> to <dialog> at position <one of 8 natural positions (+ offset)>, but no can do. The three rollouts – of which topleft and topright are fairly limiting because they’re inside the same dialog area – are it.
Which is, more or less, what you’d need to do.
If you don’t want to mess with the source file / re-define the entire vfb_methods struct, then you can replace rollouts / slip in your own (e.g. renderer-specific) rollout using something like…
callbacks.removeScripts id:#test
fn VFBthing = (
VFBArray = vfb_methods.VFB_RolloutInfo_Array
for i = VFBArray.count to 1 by -1 do (
if (VFBArray[i].placement_ == #Bottom) do ( deleteItem VFBArray i )
)
struct VFB_RolloutInfo (rollout_,floater_,placement_,size_,renderer_)
rollout roll_test "test" width:300 height:100 ( button btn_test "test" )
myRolloutInfo = VFB_RolloutInfo rollout_:roll_test placement_:#bottom size_:[roll_test.width + 2,roll_test.height + 6]
append VFBArray myRolloutInfo
)
callbacks.addScript #preImageViewerDisplay "VFBthing()" id:#test
You’d probably want to back up the original array (when your own script gets disabled, for example), and grab the original rollout (in whatever area you’re replacing), and using that as a subRollout in your own rollout so that you can easily ‘add’ to one of the existing rollouts (it will appear as a rubrollout, of course – not much you can do about that without grabbing the source code and re-using that directly).
This may-or-may-not work nice with otherd third party vfb extensions – there’s certainly no reason that the above wouldn’t work with multiple rollouts specified for the same area, as each rollout just gets redefined as a subrollout of eachother… but there’s no way you can set the order of things. So which rollout ends up as a subrollout of which will probably depend on the order in which the callbacks are handled.
See… there’s reasons why most just replace the struct altogether
http://forums.cgsociety.org/showthread.php?f=98&t=626014
Richard, thanks I figured something like that… I think I chose the name for this thread correctly… hacking… I will continue adding buttons to the existing rollout for the time being.
Thanks for all the feedback maybe I will build my own from scratch some day… but it’s probably going to take more time then I can afford… Another feature that could have gotten a little more thought, imo, everybody wants to extend the render options if they could easily do this… I think I spend at least an hour or so trying to figure out what was going on in VFB_struct.ms…
Anyway,
Thanks again!
-Johan