do you prefer scripts or dll plugins?

[plastic]

do you prefer scripts or dll plugins?

i wonder whats the general opinion about this.

i have the feeling than most people prefer dll plugins and stay away from scripted plugins, for reasons i'd like to hear from a non-developers point of view, before i start speculating / explaining why i ask.

 

can i have some feedback on this please?

 

[ November 06, 2002, 07:20 AM: Message edited by: plastic ]

[nisus]

Hi mark,

 

I prefer dll plugins because they are simpler to install (and don't bug that often)

Scripts are fine if they are activated by a single button in the UI, but otherwise are harder to find.

 

The most important issue for me is that I can achieve something with as less clicks as possible, because I dislike running long mouse-miles...

 

rgds

 

nisus

[quizzy]

nisus is right... but: I like script a little better because if the script is written in plain Maxscript language, you can really learn from them. And for me its no hassle to create a button or go to the maxscript button and load a script and run it.. I really don't care..

[kid]

if it does what it's supposed to I don't care either way. I have a ton of free scripts which work just as well as .dll plugins. I do admit there's usually a few more steps involved in setting up scripts, ie drop UI icons here, put scripts there, put startup script here, etc. but it doesn't put me off using them.

[Jeff Mottle]

Ahh but scripts are better for network rendering. I just recently submitted a job to commercial render farm and had to pay an extra $250 becuase my plugins used DLLs. (extra setup time) As a result they has to be manually installed on all 65 machines. Not sure if it is possible to write a DLL plugin that avoids this. Also any plugin that writes to the registry causes the same problems.

 

[ November 01, 2002, 01:13 PM: Message edited by: Jeff Mottle ]

[plastic]

ok...thanks for the feedback...

i asked because i'm currently investigating visual c++ 6.0 for plugin development, and i found myself again in nerd-hell.

i'm not a natural born programmer, i'm more a graphic artist who is very fascinated by maths, programming and computers...

however, win32 c++ is the horror. its so bloated. it took me 2 days of intensive work to make a "hello world" popup max plugin. thats a 5 seconds job for maxscript. (even for a bloody beginner)

all in one, theres hardly anything maxscript can't do. with c++ EVERYTHING is possible, but the amount of work it takes to set things up is simply ridiculous.

even with easy things like interface/dialog programming...

[nisus]

I guess marc found out why discreet developped maxscript... )

 

nisus

[quizzy]

hey jeff,

 

Those guys who charged you the extra bucks, are totally BS.. I've set up a network plugin path, and therefor I only need to copy the dll's in that path and voila.. the renderfarm is up to date again.. Maxscript don't cause many problem when network rendering: well this is partially true, if the script is a plugin script ie: it creates script depended meshes (like hdr-dome light) you also have to start it up automaticaly. So again, you have to put that script in the same network plugin path..

 

well jeff.... have fun getting those $250 back.. or find yourself another renderfarm..

 

[ November 04, 2002, 02:09 AM: Message edited by: quizzy ]

[Pierre-Felix Breton]

To add my little grain of salt...

 

Maxscript (sometimes written as MXS) is a superb tool available to all. It can do a lot of cumbersome tasks for you right on the spot.

 

I often use it as "one shot deal" to iterate through objects right in the listener:

 

for i in Lights do ......

 

It is also a great thing to handle commands that don't require a lot of interactivity. An example of this is the Region Net Render tool that ships with VIZ 4, it was done as a script.

 

However, as soon as you need to iterate through a large collection of object and perform tasks with them, it is not a good idea to consider MXS if the goal is to provide an "active" tool to a user. The execution is generally slower than C++ and there is a certain risk of errors (such as keyboard input during execution).

 

In a nutshell, stay away from iterating over a selection set for commercial applications:

 

for i in $ do ..... can make a fair amount of damage to the interactivity (and the model)

 

Best regards,

[plastic]

Originally posted by Pierre-Felix Breton:

for i in $ do ..... can make a fair amount of damage to the interactivity (and the model)

i hear you...i didn't have problems yet with routines like that, except slowdown and temporary 'freezing'. however, the lack of pointers and gc() as the only way to clean up memory seems to be a bit problematic for performance. but the fact that its so easy to work with scene nodes ($* etc) makes it a great scripting interface. its so nice and easy...

 

[ November 04, 2002, 07:59 AM: Message edited by: Marc Lorenz ]

[Jeff Mottle]

Hey Quizzy,

 

There are some plugins that write to the registry so a simple copy to a common directory will not work. Although this project used MAX4, I was told that with MAX5 all new plugins write to the registry and for that reason they were looking to invest about $20K to a program that mirrors files and regisary setting in an automated process. I'm pretty sure I wasn't take for a ride...these guys knew what they were doing.

 

Those guys who charged you the extra bucks, are totally BS..

[quizzy]

maybe Novell Snapshot is something for those guys then, install on one computer, snapshot it and distribute through the network.. It just keeps track of registry changes, file changes etc.. We use it here, and it works great!!

 

[ November 04, 2002, 11:14 AM: Message edited by: quizzy ]