Hi HAIRYKIWI :-)

I found the problems in the NACAAirfoil script:
At line 595 in the js you find this line:
"FactoryAirfoil.setInput( g, PointObjectListUpper.item(num_stations - g).pt.get );"
this ".get" seems to be not toleratet by V4
just delete the .get to "FactoryAirfoil.setInput( g, PointObjectListUpper.item(num_stations - g).pt"
repeat this to every line where you find this ".get" and it will work

Or just take the js in the attachment

Hi Michael and Ralf,

Michael - many thanks for taking a look at the .ini option for specifying locations of external scripts.

Ralf, You're a star. Thank you :)
Modifying NACAAirfoilGenerator.js as you suggested cured the problem in MoI v4 - on both PC and MAC.
Out of interest, how did you debug it? Or did you find/remember some change of method to accessing ObjectList items in v4-compatible scripts?

I've become quite rusty with scripting since I wrote it and nothing really stood out in the script documentation http://moi3d.com/wiki/Scripting especially Max's mirror of Dave Morrill's script documentation/api/

It'll be interesting to hear from Michael if this change of access was intentional :)

Hi HAIRYKIWI,

First: WOW nice script very complex! THANK YOU

the trick was actually very easy...
I wrote this line into the script: moi.ui.alert("STOP");
Than running the script. If i got the "STOP" alert before the script fault message the fault must be hidden somewhere later in the routine..
doing this step by step further in the routine i could locate these bad lines... as a fortune my script editor (TextWrangler) already marked this ".get"s as a command - so just deletet them - that was all... I'm just a hobby scripter...

I think the incompatibility of some older scripts with V4 is that it uses a newer webkit which is more nitpicking...

Great debug tip Ralf - many thanks!

Now you mention it, I guess I did used a related debug method before - for printing variable values to the screen, but also being an infrequent hobby scripter, I frequently forget such elegant methods - and it never even occurred to me to adapt it, so again, many thanks :)

Thanks Ralf for figuring it out!

So if I remember correctly in MoI V3 and prior there was a pt.get() function set up but it was only callable from C++ code and not JavaScript code because it took 3 pointer values which JavaScript is not able to express. However just the presence of that method happened to have a side effect of pt.get not being a syntax error in v3 although it would not actually do anything useful.

In v4 the script interface is no longer based on IDL/IDispatch/COM Automation to be cross platform and the new interface only supports constructs that are compatible with JavaScript so the pt.get() method has been removed in v4.

- Michael

Hi Michael,

Much appreciate the explanation - even if I don't quite understand how I interpreted the documentation to arrive at my bad code in the first place :)

- Hamish

Thank you Michael.
I bought "The Nurbs Book."
Now I just have to read it...
- Brian

Hi

The latest Mac Wacom driver (6.3.29-6) appears to have resolved the middle button issue, great!

Marc

Hi Marc,

re:
> The latest Mac Wacom driver (6.3.29-6) appears to have resolved the middle button issue, great!

Over here this driver version isn't behaving well, I seem to get kicked out to the login screen when trying to use the middle button with the pen.

If that's not happening to you maybe it's just on older systems or something.

- Michael

Hi Michael and Marc,

Just installed the 6.3.29-6 driver, and everything works fine here.

Me too.....

Hi Michael,

That's odd, I'm using 10.12.3.
It still works well after a few working sessions.

Marc

Hi Michael,

I've been using the Feb 9 beta since it was released and i'm mostly happy with it.

Yesterday i noticed a bug that i'm not sure if it's been reported or not:
- When i Join a named part with an unnamed i would expect it to retain the name, if the named part was selected first. This does not always happen with V4.

I've narrowed it down to a reproducible example, a simple box, separate it, join all sides except one, name it Box and then select the last surface(unnamed) and join it.
The box ends up being named Unnamed, rather than box.


Hope it helps!

Dinos

hi,
is that on osx?..cos i can't reproduce it here on win 10 pro. cube stays "box".

Hi Marco, yes, its in osx.

Dinos

Hi Dinos,

I'm on osx too (10.9.5) and, here, the object keeps box as name when the unnamed face is joined to the others.

Michel

Hi Michel,

i just retried my example and yes it does keep the name so its not as reproducible as i thought.
But if i select the unnamed face first and join it then it is named "box" which is still wrong.

I've noticed this issue some time ago but if no one else has it then its probably something wrong with my setup.
I'll look into it some more when i have a chance and I'll let you know.

Dinos

Hi
I can reproduce it sometimes on V4 OSX but it's OK on V3

Hi dinos, there is indeed a bug there - the bug is that a cached older version of the objects can be used by the moi_commandprocessor.exe worker process and that means that recently applied changes to names and styles can end up being ignored. It's a little finicky to reproduce because the first time you try it there aren't any cached objects and so the current object goes through and it works ok. You've got to get a mismatch between properties on your current objects and cached objects in order for it to reproduce.

It's another manifestation of the styles bug that Brian reported here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=8814.81

I've been working on a couple of different possible fixes for the next beta.

Thanks for reporting it!

- Michael

Hi Finema,

> I can reproduce it sometimes on V4 OSX but it's OK on V3

Yeah it's a new bug in V4 because of a new function in V4 where the worker process keeps hold of objects that were recently sent to it so they don't have to be resent by interprocess communication.

- Michael