enumerations would be a welcome addition
Yes, but this is a MAX issue, not a MAXSCRIPT issue.
totally agree with you.
the same as new UI elements. it’s also not about the language and the way its running.
Yes, it is a Max issue. Sorry I didn’t specify that, but as it is a known limitation I thought I wouldn’t need to.
BTW, which is the longest double you have been able to work with, including points, matrices, etc.?
Many methods are trimmed to 4-5 decimal places accuracy.
But hey, this is a tool for artists not engineers, so we don’t need such accuracy.:arteest:
max script (same as sdk) uses full float value… it’s only limited by float itself. the 6 decimal numbers that you see in listener is just what max shows you.
unfortunately the max prints (using print or format) the same cut value to any stream (string, memory, file, etc.)
so to avoid this cut is safer to use formattedprint
but as we already said the float precision is not enough for very big and very small objects.
that means there is no way to design microcheaps in real units using MAX
I meant “trimmed” in calculations not in the Listener.
Error Threshold usually set to 4-5 decimal places.
Because it is for artistic pourposes, so precision does not matter
as i know it doesn’t trim anything. it uses whole float in all calculations. doubles are more likely trimmed to float.
got it finally yes. you are right. there is an epsilon defined by sdk for equality of float.
it’s 1E-6f. and there is no way to use smaller in mxs.
IMHO they should not improve MAXSCRIPT… AD should be better integrate Python in max to replace maxscript…
it’s almost impossible to replace mxs with anything else. it’s like to rewrite whole MAX.
Someone could say that we already have a full C++ SDK so they could simply remove MXS and improve the SDK.
I think the utility and popularity of Python in Tech Art circles Makes it a far more practical choice than either improving the SDK or MXS.
sorry… but it’s a dilettante point. python is good, but it can rule the max only if the max will be completely rewritten. what will never be happened.
I’d settle for improving the documentation :banghead:
better implementation of “undo context”… sometimes script with undo context do not generate undo’s. this is a useful feature if you keep modifying scene objects and want to keep the previous action.
When you say ‘maxscript compiler’, you really mean a process which translates maxscript commands to their equivalent C++ SDK code, and then compiles, no?
doesn’t have to, a compiler just needs to collect code & data into a single “executable” file. (where data can be icons, pics, binary data, text data etc)
Though if it ends up eventually just running maxscript code, it’s really just a runtime packaging system.
I would prefer the script to go down to Assembly.
If the compiler is just to be used as a “zipper”, then I would put the effort in a different place.
i want true compiler which compiles mxs to machine code. because practically impossible to remove mxs from the system i see it as ‘hybrid’ code. some sort of instructions in mxs code which tell to compile a specified piece of code on the fly in something better, faster and memory friendly. it’s actually what we do using c++ sdk publishing system (mxs extensions).
i don’t want extra files, i don’t want to convert ms to exe or dll.
I’m so far behind… what about the limitation of having to use “execute” as temporary work-around in naming (…and accessing those custom named…) scene objects, or accessing into custom named struct objects?
I’m not sure what you mean, could you give an example? I don’t think I’ve ever had to use execute for anything.
See the String Values section of Maxscript Reference…
You must use execute() as a temporary work-around to the current limitation in naming scene objects – there is currently no way to name an object using a computed name.
For example:
obj = execute (“$foo/” + child_name)
would retrieve the child of $foo named in the variable child_name. Here’s a more complex example:
side = "left" finger = 2 limb = "arm" obj = execute ("$torso/" + limb + "/" + side + "/finger/" + finger as string)
…and in this import script I wrote( http://forums.cgsociety.org/showthread.php?f=98&t=1255265 ), I had to use the “execute” command to get access to the properties of a material struct variable created with a computed name.
I guess I never faced that issue because I don’t rely on object names in scripts. And even then, you can always use GetNodebyName.
I took a look at your script, I don’t really understand why you have to use execute there either.
Why this:
tempStruct = execute ( mtlNum + " = SI_Material()" )
(execute mtlNum).faceColor.r = ( readValue inFile )*255
Instead of this:
tempStruct = SI_Material()
tempStruct.faceColor.r = ( readValue inFile )*255
…Because (If I recall correctly…) I was using tempStruct as a temporary mechanism to create computed-named structures (from the material templates in the XSI file– which has problem of duplicating same materials with different names). So I only wanted to capture and store unique materials (skipping duplicates): Material1, Material24, Material121, etc., whose data I stored in structs of SI_Material() and I was keeping track of each unique material in an array as part of importing the XSI Material Library into 3ds Max. Feel free to PM me to discuss further.
I’m sure the maxscript code I wrote could be greatly optimized… but it works for my purposes.
@DenisT – my apologies for causing this detour in your thread… now back to the topic at hand…
As far as the actual language itself goes, my biggest wish is to disallow use of undeclared variables, rather than implicitly declare and set them to undefined
For example:
x = 5 --this is fine, delcare and initialize x in whatever scope and set to 5
x = bob --somehow also fine, even if bob is previously undeclared!