Thanks Pete for helping,
yes, I’ve downloaded the script at the end of the article. The line in my post is the line where the error occurs. The rollout builds nicely, but no image is created (your robot-logo should appear right?). Also my home pc (vista 32 bit) and a similar pc here at work produce the same error.
Could it be related to .NET versions maybe? Or some kind of assembly you naturally have loaded since you develop this stuff.
Klaas
hi klaas,
there aren’t any custom assemblies being loaded by this script, so im not sure why it is saying this. which version of max are you running?
is the convertclass returning a bytearray from the base64 string? it is possible, if it is pre max 2008 that it is not returning the dotnetarrays into the correct format.
try this minimal code version, line by line and see if it fails at the same place –
Pete,
I’ve tried the script line by line. It fails at the line
memstream = dotnetobject "System.IO.MemoryStream" bytearr
With the same error in the previous post. This is in max 2008 32 and 64 bit edition. Max 2010, 32 and 64 work fine.
I actually wasn’t thinking about custom assemblies (like those snazzy controls you make) but the plain asseblies you sometimes have to load to make things work. Like the “system.xml” one. And if I try
dotNet.loadAssembly "System.IO"
I get an undefined in the listener. That can’t be good, right?
Hi Klass,
After testing, It’s a max 2008 issue i’m afraid, im having the same issue as you in max2008. Max is not casting the byte array into dotnet (perhaps something to do with the fact max casts bytes to integers) and was a known bug of this release.
it was a while since i wrote that article but i must have written in after upgrading to max 2009. My GDI research tried to get around this by populating a byte array from a max array, but that is also returning the error you mentioned. So sorry, it’s kind of out of my hands in that version of max except to say i can emcompass the method into a dotnet assembly for you. One advantage to counter the need to load a custom assembly would be that it would be much faster this way. Let me know if you wanted this option and i’ll compile something for you to use in max 2008.
Hey Pete,
that’s a pity it doesn’t work, but great to have it figured out. Since our company is migrating to max 2010 anyway, we don’t really have the need for your kind offer. And as far as my own public scripts go: either distributing two icon-files, or a dotnet assembly doesn’t really make a difference (logistics wise). So thanks very much for the help, but don’t bother to make that assembly just for me.
Klaas
no problem klaas.