MSE again


Many developers can say - “WTF, I spent months looking for this solution, and I have to post it free, haven’t I?”

Yes… Or find another way to deliver the code


I understand where you’re coming from (or better yet, where you wanna go to).

But this decision you’re thinking about making is too serious to be made by one person because that person can do it. Even if the underlying reasons are sound. Why? Because you will be hurting people who have nothing to do with the wrongdoings (stealing code, or hiding bad code).

This should be part of a larger discussion, with the involvement of many more people. But that’s just a thought from someone who can’t touch your feet coding wise, so take that for what it’s worth.


Don’t worry… Of course I will never post a MSE decrypter public.

I just want to say it again - The MSE encryption is WRONG. It kills third-party MAX tools development


it’s a sad conclusion… I’m here for many years giving an examples, trying to teach max coding… my private mail-box is always full.


I guess you have fair points on your side, and I can agree with them.

But I’m not a user of MSE (I don’t encrypt, and AFAIK I only have 5 MSE in my script folder (that I rarely use, if ever). But this conversation have to happen with other devs, so we can hear and weight their perspectives as well. I appreciate your initiative to tackle this. Maybe the Ideas forum is the place for that? So maybe in the future ADSK strips this feature entirely?


I know you are! You have helped me (and many people I know) in many many instances! Don’t look down on this, it’s just that coding is not everyone’s thing!

Just like modeling (or any other area), there are people who model REALLY well, with perfect loops and geometry density, and those who make models that pass as OK-ish, even though if you look at the wireframe, it’s a complete mess.

So, I admire your skills, and I know it’s not something that you learn from overnight. Many stuff you must have build up from sheer experience, trial and error, and digging on uncharted (undocumented) stuff :slight_smile: It’s not easy to get to your level (even close to it) but I see some people walking the same avenue, and becoming quite good coders themselves. It just takes time, and the notion that this is not for everyone, so you can’t have too high expectations, or force it. People are just different :slight_smile:


i delivered more than 300 tools for my clients. the tools were never been encrypted. sometimes my clients asked me, what if we use outsource and don’t want to share code which we paid you…this is not my business.


Based on your story, it seems to me that the problem you faced has nothing to do with MSE encryption but with the MXS architecture and coding habits, and until now, there is nothing we can do except trying to create safer code.

If the scripts that caused you so many problems would had been encrypted with a custom tool, you would have had the same or a much harder time figuring it out.

I don’t know exactly how this could be solved but I think it should be addressed from the inside of the MXS architecture. Surely removing the build-in encryption solves nothing and certainly you can’t expect every developer out there to code the way you think is correct, even if you were right.

Perhaps a new kind of plugin (plugin tool) that keeps everything in its context safe?
A new type of variable superGlobal?

What do you think could be easy to implement without breaking the current architecture?

I wonder what the developers that have access to the code think would be possible without having to re-write the whole MXS core.


the MSE made me a lot problems when I was looking for issue. I saw some suspicies events and callbacks… But could’t identify their sources. I tried to search functions, names and ids in all scripts. But I couldn’t search in MSE files.Problem number two was that the author of that MSE creates another MSE file on the fly and deletes it on MAX closing. So the broken script doesn’t exist on the disk when MAX is not loaded.

So, you are right, the final problem can be in any not encrypted script, but it would be very easy for me to find this script. It is also very possible that “bad code and coding methods” could be found while using the script.


I have encrypted scripts in the past but not anymore. At the beginning to hide my horrible code (yes, I think that’s something every beginner goes through), then because I thought I might, one day, develop it into a commercial tool but release a less feature rich version for free until then.
Quite frankly, mse is more an annoyance than anything else these days, I absolutely agree with that. Someone who can’t script doesn’t care if the script is encrypted or not, someone who can and can’t figure out to get around it is probably rare - so it’s definitely not usable as a copy protection. I don’t really think it would make much of a difference if you would actually post a decryption script here on the forums or not… but that’s not the point.
I try to prevent anyone in the studio to install script without me having a look at it first for the very reasons that were discussed already but I also think that some way of protection can actually benefit the community greatly. Maxscripts are easy and fast to write but you can’t protect them, c++ plugins would be the solution but way to cumbersome to get into (I wanted to get into it for years but all the stories I hear and all the frustration about random sdk behavior very much prevents that, I just don’t have the time for that kinda stuff). This means I just don’t publish any commercial scripts - just free ones and just a fraction of my more useful ones. So unless there is a middle ground solution I don’t see mse going anywhere - even though encrypted scripts are basically pointless.


I like it. Because my learning of scripts is it analysis how other do the things. I’m not coder, mostly I’m artist but some times needs small maxscript tools to achieve a goal.

BTW Spend 5 min in google allows you to find free decrypter for .mse… so, use or not is mostly ethic problem not technical…


A big issue with MSE can be seen with the ALC/CRP “viruses” that self replicate through files. The ALC is attached to MSE and MSEX files.



Oh!!! I know this problem, perhaps better than anyone else :slight_smile:
I specially made startup cleanup script to fight it.

BTW Does anyone know who the author of this rubbish is?


there is another “bad” but commonly had script… many of you can have it in the script/startup:

here is it’s body:

-- Auto assign a proper material while rendering PointCloud
-- NOTE: after each modification, use "encryptScript <filePath> version: 1" to encrypt it as a *.mse and copy the mse file into startup directory.

fn UpdatePointCloudMaterial obj =
    m = obj.material
    if (classof(m) == adsk_Mtl_PointCloudMaterial) do (
        m.rampShader          = obj.baseobject.gradientTexmap
        m.displayTech         = obj.baseobject.displayTechnique
       return true

fn createPointCloudMaterial obj =
   m = obj.material
   mMtl = adsk_Mtl_PointCloudMaterial()
   mMtl.rampShader  = obj.baseobject.gradientTexmap
   mMtl.displayTech  = obj.baseobject.displayTechnique
   assignNewName mMtl
   obj.material = mMtl

as you can see there are two GLOBAL functions which both don’t check an object’s (that passed as argument) type. I met situation when it caused the script crash… It’s Autodesk’s as I understand, isn’t it?

Why is it encrypted? WHAT WAS THE REASON?


The funny story about this issue … I met some also third-party scripts that tried to “fix” this issue. They worked bad and… were ENCRYPTED! :stuck_out_tongue:


mse cannot encrypt your code ,if you want to sell your script , you should find another way , make a maxscript lock in c++ or c#


c# might be decompiled very easy


My .02 on mse:

While it can be decrypted (somewhat) easily by many, it still provides a legal barrier.
Even if the encryption is weak, it is still illegal to break it.

So basically I treat .mse as a flag to indicate ‘you are breaking the law if you decrypt this’.

I actually like the fact that .mse can be decrypted with a bit of effort; at least then we can check code for errors or malicious elements.


i’m not sure that there is any law you break… To exclude this ambiguity, Autodesk must either really protect it by law in the contract, or, providing a public encryptor, should provide the public decryptor as well. Otherwise, Autodesk must be held responsible for any harm caused to its customers through hidden code.


no one will be surprised by the situation when a food delivery company will open containers, transfer food to others containers, perhaps add some ingredients, but do not bear any responsibility for food after that?