I’ve been working on 3ds Max script the past week or so that I’m just about ready to push out the doors to the UDK community however I’d like some opinions/feedback on how to maintain the script especially if it grabs a large user base.
I’ve been working on being able to push updates to users upon each 3ds Max run but so far I’ve seem to have hit a pretty intense road block in pursing this feature. Any advice you can throw my way to accomplish this in MaxScript would be awesome! Is an auto updating script overkill?
Yes, I think auto updating is overkill. Perhaps just check for newer versions on login and prompt the user, show a taskbar bubble, etc. You generally don’t want to automatically change people’s tools without them confirming.
On top of that, automatic package management solutions tend to be pretty involved. Most of the scripts in the community have a terrible lack of code reuse in them, so dependency management tends to be less of an issue, but what you’re talking about is a well known and difficult problem, especially in an archaic and limited platform like Max.
My suggestion is, go as low-tech as you can, and make your setup/install procedure as painless as possible.
Yeah, auto-update is going to be a beast to implement in MaxScript, not to mention the architecture required on the server side. Even SourceForge doesn’t have a standard auto-update for their hosted projects.
we’re close to finishing an windows update style system using SQL and P4 for script deployment. But it’s a stand alone app though which sits in the tray. Then again it works for pretty much anything (Maya, max, etc). We could probably switch out P4 for something else if we wanted to… but inside the studio it makes the most sense.
Inside the DCC apps we do what Rob suggested, pop up a bubble, or message when a script is started. We want to do this at script start opposed to at-startup because some people just tend to leave their DCC app running for days.
But since you talk about the UDK “community” let me ask you this… are the receivers of the update inside your company or people outside? And what exactly is the roadblock?
Guess if it’s just a matter of checking a version file on a http server and then downloading the new tool, this might be accomplishable using dotnet? (just guessing here - never done this)
[QUOTE=Rob Galanakis;9657]Yes, I think auto updating is overkill. Perhaps just check for newer versions on login and prompt the user, show a taskbar bubble, etc. You generally don’t want to automatically change people’s tools without them confirming.[/QUOTE]
Thats a very valid point I didn’t think about and I’ll be taking this advise.
That’s an excellent link btribble and I’ll looking at it and attempt an auto update for personal giggles.
Both. I’m developing a set of tools that we will be using in house but the same tool set will also be released publically. We’re pretty involved in UDK/UE3 and we hope that the tools that we use to ease our development process will help someone else out there.:): We’re releasing small but have many tools planned, one of the reason of me wanting auto updating to more easily push out changes. My roadblock currently is wrapping my head around the awkwardness of dotnet within maxscript. For whatever reason the past couple of days it just hasn’t clicked in my head yet, but btribble’s link has given me the nudge I was looking for.
I’d suggest writing/wrapping your .NET code in a custom dll and using a much simpler interface from MXS. Ie, that mxs_socket should be a .NET class, so you can say:
local socket = dotNetObject “MyCustomSocket” 5432
socket.Send “Hello World”
Or even better, have a static method on the MyCustomSocket class: public static void Send(int socketPort, string data)
that will internally run those two MXS methods above, for quick sending of messages like so:
(dotNetClass “MyCustomSocket”).Send 5432 “Hello, World”
Obviously if you want to send a lot, you’d want to new up a ‘MyCustomSocket’ object in mxs and use that reference, rather than repeatedly using that static method.
.NET within MXS is awkward. The only way to make it less awkward is to write .NET as .NET and simplify the MXS interface to it.
I am using an extremely simple system which creates a menu inside of max to hold our scripts and updates them if needed when the user starts up max or can be also done on demand.
It is basically a maxscript that runs when you open 3ds max, it checks the date of a custom ini file stored in the the user’s computer and compares it against the server’s ini file. If the date of the server’s file is the same then it does nothing. If the server’s ini file is newer then it opens both files, checks the differences and updates the user’s scripts accordingly. I am not prompting the user as the scripts that the system is updating are “official project scripts”. The same is done for plugins. Aside from those any user can have their own custom scripts and plugins installed localy.
Of course these relies on waiting for the user to restart 3dsmax or sending an email around and hoping that everybody will read it and update the scripts.
Our art team is not huge so by just standing up i can talk to the whole team and tell them to update the scripts so there is no need to push up notifications.
It is fast and it does the job. It is based on a system called “Aearon” but extensevely modified. I wanted to paste the link but i can’t find it anymore.
I made a system like this a while ago when i was learning maxscript and you can download it from my site: http://rubenhenares.404fs.com/scripts/script-manager/
However this one is very very limited as it was one of my first projects.
At work I point the UserScripts, UserStartupScripts, UserMacros, and UserIcons paths to our perforce project folder. That way everyone get’s the latests tools when I check them in. For updates over the internet, I’d do as Rob G. suggests. Just make the install process simple and publish updates to your scripts when needed.
Thanks again for the links guys, really useful stuff.
@swat3d Your method was actually my first attempt as copyFile does exactly what I need other than being able to input a username/password. However on a local server something very similar would have been my solution as well.
I think what I’ll end up doing is creating that custom .dll and see if I can get it going that way as it sounds pretty painless. However I’ll hold off a bit on this and work on it in my spare time. In the meantime I’ll keep the installs super simple.
