I repost my question here, bcause the Area-SDK forum seems to be an empty, dead space
So now i have successfully chewed through the FP mechanims to be able to expose some core functionality to maxscript (beginning max plugin development at the same time …)
So my question is:
how do i define arguments which are optional (or use some default value if not given) in the function map and interface descriptor ? Meaning i want to be able to pass a variable number of arguments via maxscript…
currently i have to pass all arguments all the time, and that gets a bit tedious soon…
or is there a way using the maxscript key mechanism ?
Let’s assume i have published a function called “somecall” using the FN_2 macro which would result in:
somecall 200 100
given the last example from above, i want to be able to do the following without maxscript giving an argument count error and taking some default value for the missing arguments…
somecall 200
or even using keys..
somecall width:200 height:100
So – is that possible ? any help would be appreciated…
fn somecall width:200 height:200 =
(
format ("
The width is:"+(width as string)+", and height is:"+(height as string)+".
")
)
somecall width:30 height:250
somecall()
–or
fn somecall width:undefined height:undefined =
(
if width != undefined and height != undefined then format ("
The width is:"+(width as string)+", and height is:"+(height as string)+".
")
)
Normally OOP programming allows overloading of functions.
So you have to define multiple functions in the source with the same name but width different parameters. But I think you know this and now the question is if Function publishing allows this, right, I think it should be possible as maxscript has several core functions that allows optional parameters (mostly named parameters). But about the actual implementation… I really don’t know.
-Johan
Yes – normal OOP programming would be easy
but even if the Function Publishing mechanism in the SDK is far easier than the standard way of dealing with Maxscript “Value *” arguments when doing old style mxs plugin development ( vs. the global utility approach ), one has to use tons and tons of preprocessor macros to expose those functions to maxscript
there goes the OOP function overloading approach…
thx rabby for the post
I guess i was not clear enough:
I’m not looking for a Maxscript function definition with variable arguments,
It’s a 3ds Max SDK / C++ coding related question:
How to expose plugin functions via Function Publishing and allow those functions being called from maxscript with variable argument count…
see check_arg_count_with_keys and key_arg_or_default in max SDK docs…
thanks for digging those up for me Denis…
i hope those macros can be used when dealing with the function publishing mechanism, because i think they require arguments being passed as type Value*…
I will wade through the SDK docs again and report back how it went
thx again
all arguments pass as type Value*. to use them in c++ you have to cast them to whatever you need.
there are some another macros those automatically cast the value:
[b]int_key_arg(key, var, def);[/b]
get named key arg into Value* ‘var’ variable and return it as a C++ int, return ‘def’ if not supplied.
float_key_arg(key, var, def);
get named key arg into Value* ‘var’ variable and return it as a C++ float, return ‘def’ if not supplied.
bool_key_arg(key, var, def);
get named key arg into Value* ‘var’ variable and return it as a C++ BOOL, return ‘def’ if not supplied.
thanks for the reply , sorry for the late answer …
You answer is valid for the “old way” of using the Maxscript SDK, where you indeed have to deal with Value types…
The way which it’s promoted now by Autodesk/Chris Diggins is to use the Function publishing mechansims, which does the argument passing/return to and from maxscript transparently. And it is more convenient to some degree.See Chris’s Blog Entry HERE
- We want to move away from the MAXScript SDK is that it very hard to use, very poorly documented, and for the most part redundant. IMHO it was a mistake for it to have been exposed as an “API” in the first place. It is simply an exposure pf the internals of our scripting engine. By focusing on a single relatively easy to understand API (e.g. the Function Publishing API) we have a better hope of doing a good job in documentation and support.
But now the problem arises for me:
how can i pass a variable amount of arguments to my published function if i have to specify the exact type in the function publishing descriptor
I guess i will contact Chris Diggins directly how that would be done – if it’s even possible…
Okay – after digging through the various SDK header files, i found the way to do this:
To allow a variable number of arguments for maxscript functions, one has to use the “key” argument syntax, that is passing the function parameters using “key:argument”
like “width:100” etc…
those arguments are optional and pick a default value if not given…
For using the Function Publishing mechanism in the Max SDK, that means you have to mark the parameters as “key” parameters in the Function descriptor by adding “f_keyArgDefault” , followed by the default value ( has to be the same type as the function parameter type);
so in the case i wanted to have an optional integer and an optional string argument for my function “varargsTest” ( maxscript name), i would write
...
MYFPCLass::mfp_VarArgsTest, _M("varargsTest"), 0, TYPE_VOID, 0 , 2,
_M("sillyParameterOne"), 0 , TYPE_INT, f_keyArgDefault, 0, // marks this as an optional keyArg param and gives default value which must me of type to match param type
_M("sillyParameterTwo"), 0 , TYPE_STRING, f_keyArgDefault, "mydefaultstring", // marks this as an optional keyArg param and gives default value which must me of type to match param type
...
the above would result in a function in maxscript, allowing to have the OPTIONAL parameters passed
varargstest sillyParameterOne:10 sillyParameterTwo:"Hoolabaloo"
if those argument-keys would’nt be given, the function would use the defaults of 0 and “mydefaultstring” respectively. The cool thing about the FP mechanism now is, that maxscript itself is telling me if i call the function with wrong parameter types ( int instead of string etc… ) and i don’t have to deal with “Value” instances, argument-counting or type checking and so on by myself…
It’s all done transparently for me via the FP mechanism…
thanks Josef,
I’ve immediately started use it, and already rewrote couple my classes. The performance seems the same, but memory handling is must better.
after several tests i can say that the same functions called from Static Interface (FPInterfaceDesc) work slower than function called from SDK (old way)