Hi Michael,

Hope you and everyone else on the forum had a nice Thanksgiving.

I've been doing some MoI scripting and it's been going pretty well, but I think I've found a bug
with an object's 'locked' property that's triggered when using the factory 'move' command.

This is on Windows (XP 32bit & Win7 64bit) and happens in the most recent betas and v2.
You should be able to reproduce the problem with the embedded scripts.

Two questions about forum code embedding. First: Is there a way to control the width of the code box?
Second: Double clicking on the box to grab all the code will get will get a 2nd blank line so pasting that
directly into a MoI shortcut is a no go. Is there a way to avoid this?


* Start with a completely empty MoI project.

* Add one object. The scripts assumes there's only one object so things will get messed up if there's
any more. The type doesn't matter. It can be a solid, a curve, a point, whatever you'd like.

* Add the first script to a key. This is just a test to show that the locking unlocking code does work for
this object without a factory move command. Pressing the key should toggle the objects locking on and off.

 script:/*tester_01*/ var gd = moi.geometryDatabase; gd.deselectAll(); var pts = gd.getObjects(); var leng = pts.length; for(var i = 0; i < leng; i += 1) { if(pts.item(i).locked === true) pts.item(i).locked = false; else pts.item(i).locked = true; };

* Add the second script to a key. In theory the object should be moved to 16,16,16 and it's locked state should
be switched. Run it a couple times. Notice it will never toggle to 'locked' in the UI. Also note if you start locked, it will unlock it.

script:/*tester_02*/ var gd = moi.geometryDatabase; gd.deselectAll(); var test  = 0;  var sds = gd.getObjects(); var bb =  sds.getHighAccuracyBoundingBox();  if(sds.item(0).locked === true) test = 1;  var vm = moi.vectorMath; var target = vm.createPoint(16,16,16);  sds.item(0).locked = false; sds.item(0).selected = true;  var factory = moi.command.createFactory( 'move' ); factory.setInput( 0, sds); factory.setInput( 1, bb.center ); factory.setInput( 2, target ); factory.commit();  if(test === 1) { sds.item(0).locked = false; } else { sds.item(0).locked = true; };  gd.deselectAll(); moi.copyTextToClipboard(sds.item(0).locked );

In the 2nd script there's an added 'copyTextToClipboard' for the object's locked property. If you start with the
object unlocked, so that the end result should be a locked object at 16,16,16, then run the script and paste the
clipboard into a text document, you'll see the property's value is indeed set to 'true'. Internally the object thinks
it's locked. Externally and in practice it's not locked at all, just a bit confused.

-Jeff

Hi Jeff, to answer these questions first:


> Two questions about forum code embedding. First: Is there a way to control the width of the code box?

Not that I know of - for larger ones I actually will usually not put them in a <code> </code> block at all, that way they'll word wrap within the post.



> Second: Double clicking on the box to grab all the code will get will get a 2nd blank line so pasting that
> directly into a MoI shortcut is a no go. Is there a way to avoid this?

I guess this is dependent on your web browser, over here using Firefox it does not behave like that, I have to triple click inside of the box to select everything and I have never gotten an extra blank line.

What web browser are you using?

- Michael

Hi Jeff, also one thing that may be more convenient for when you're developing these scripts would be to put the script as a separate .js file in some spot like c:\scripts .

Then in the shortcut key if you put in a full path to a script file, it should load it and run it as "inline executed script" (as opposed to a "command" which has other kinds of setup and cleanup done before running) the same as code directly pasted into the shortcut key entry itself would do.

Then in moi.ini also set:

[UI]
...
DisableFileCaching=y

So that MoI will read in that script file from disk every time you run it rather than caching it.

- Michael

Hi Jeff, so when you run a factory, it's more like the objects you put into it are deleted and new objects are created, this happens even for things like transformations.

In your script here, the objects you've got in the 'sds' variable are not in the geometry database anymore at the time that you're trying to lock them. They're removed from the geometry database during the call to factory.commit(), and they're only still around at all at that point because the script is referencing them.

The objects that you want to lock are the newly created objects that are generated by the factory.

There is a bit of a trick for getting the newly created objects in a script, because a factory is basically reset to a clean state after you've called .commit() on it.

So try this - before calling commit do this:

factory.update();
var sds2 = factory.getCreatedObjects();


Do that right before you call .commit() and then in sds2 you'll have an object list of the output from that factory, those are the ones that you want to manipulate by setting locked or whatever on them.

Let me know if you are still stuck after that.

- Michael

Hi Michael,

>What web browser are you using?

Chrome. I Just tested it with Opera and IE 8(I generally access the internet through the older XP machine
and newer IE versions aren't supported). Opera doesn't a have this problem, but IE 8 does.

>So that MoI will read in that script file from disk every time you run it rather than caching it.

This is a really great tip. it makes things much easier.

Thanks!

-Jeff

Your faster your big replies than I am with my short ones :)

>so when you run a factory, it's more like the objects you put into it are deleted and new objects are >created, this happens even for things like transformations.

Ah, this explains a lot. While testing scripts somethings things would break part way through and I'd
occasionally end up with duplicates and couldn't figure why, since I wasn't doing any duplicating.
But it makes sense in hindsight, a 'factory' manufactures things. This was really a missing puzzle piece
for me and one I didn't know I was missing.

>and they're only still around at all at that point because the script is referencing them.

I'm going to be a little lazy here ask this rather testing it myself. How much of these delete objects'
data is still accessible? I could see it being useful at times if it is.

Thanks again,

-Jeff

Hi Jeff,

> I'm going to be a little lazy here ask this rather testing it myself. How much of these delete objects'
> data is still accessible? I could see it being useful at times if it is.

Well, you can access properties on it the same as any other object.

I guess it would be more accurate to say that it's "removed from the geometry database" at that point, it's not actually deleted entirely from memory until the last reference count on the object is released.

- Michael