PDA

View Full Version : MacroScript Compile error when starting max


Caprier
01-04-2011, 02:34 AM
Hi there.

Here is the deal.
I've made a mapping tool which is meant to be run from the Mapping menu of the Edit UVWs dialog. The macroscript is bundled in an .mzp file, along with an install.ms script and an mzp.run file.
mzp.run first copies the macro to the usermacros folder and then tells max to run install.ms.
install.ms evaluates the macro, so max is aware of its existence, and creates an entry for it in the appropriate menu.
And that's it.

This was written and tested (very extensively) on max 9 without any error showing up.
I had some people test it on other versions and some of them had one or both of the following problems.

1st problem:
Sometimes the .mzp file needs to be dropped twice in order for the tool to be installed.
This is bugging me but I can live with it.

2nd problem, which worries me a lot more:
After installing the macro and checking that it ran correctly (which it did), some people have an error popping up every time they restart max. It says MAXScript MacroScript Compile -, followed by the path to the macro, followed by ',offset 0; Exception: -- Unknown system exception. But still after that, the tool would run just fine. Which makes me wonder. How can max fail to compile the macro but still execute it correctly?
Once the macro is deleted (and the menu entry removed) the error disappears and everything is back to normal.

I've been trying to figure this out for more than two weeks now and I must say that I'm at my wits' end. This is especially difficult to solve since it runs smoothly on my machine.
If some of you could try it and have a look, it would help me a lot.
(you might need to change the extension of the attached file back to .mzp)

Thanks in advance for your time and help.

denisT
01-04-2011, 03:40 AM
2nd problem, which worries me a lot more:
After installing the macro and checking that it ran correctly (which it did), some people have an error popping up every time they restart max. It says MAXScript MacroScript Compile -, followed by the path to the macro, followed by ',offset 0; Exception: -- Unknown system exception. But still after that, the tool would run just fine. Which makes me wonder. How can max fail to compile the macro but still execute it correctly?


you have to check that the currently open modpanel object is UVW unwrap modifier before using its interface functions:

on isEnabled do
(
local theObj = selection[1]
local theMod = modPanel.getCurrentObject()
if not iskindof theMod UVWunwrap or theMod.getTVSubObjectMode() != 3 do return false
...

Caprier
01-04-2011, 04:53 AM
Denis, I'm not sure I'm following.

If it's the first evaluation of the macro (during installation), install.ms does just that: it creates a temporary editable mesh, adds an unwrap to it, selects it and makes sure that the command panel is the modify panel. And then it evaluates the macro. Otherwise I get an error and the macro is not 'registered', which would prevent it from being added to the menu. And that's not the case.
If it's after the first installation, the only way to run the macro is from the Edit UVWs dialog. So obviously there is an object selected with an unwrap modifier on it and the modify panel is open.
In all cases the tool works fine. It's just that error that shows up at startup. And that only on some installations. And even then, as I said in my first post, the tool is there and works fine. For the major part of the people who tried it, no error occurs. It just happens in a few cases and I'm trying to figure out why and what makes it happen.
Did you install it or look at the code?

But maybe I'm not understanding what you're saying or I didn't explain the problem well enough.

lo
01-04-2011, 08:34 AM
I have not installed or read the code, but I can say I've had similar problems which involved the heap size. try to print a heapsize on startup (before the script runs) and see if the troublesome machines have considerably less memory than the working machines. If necessary you can increase the heap before the script runs (i.e. heapsize+=10000000).

Then again, this may not be the problem at all...

Caprier
01-04-2011, 12:41 PM
I will definitely try that (I'm ready to try anything at his point)! Thanks Io.
But shouldn't the error be 'out of memory' or something similar, intead of 'macroscript compile, unknown exception'?

lo
01-04-2011, 01:11 PM
It should, but it rarely is :)

Caprier
01-05-2011, 07:23 AM
Nope. Setting the default heap size higher didn't solve the problem.

Any other idea, people?

And how about the 1st problem, the need to drop the .mzp twice?

stigatle
01-05-2011, 09:26 AM
Is the macro you give to them encrypted? or just plain text?

Caprier
01-05-2011, 09:52 AM
It's the exact same file than the one I've attached.
Nothing's encrypted.

denisT
01-05-2011, 03:07 PM
Denis, I'm not sure I'm following.

If it's the first evaluation of the macro (during installation), install.ms does just that: it creates a temporary editable mesh, adds an unwrap to it, selects it and makes sure that the command panel is the modify panel. And then it evaluates the macro.

But maybe I'm not understanding what you're saying or I didn't explain the problem well enough.

why do you create temp mesh and add unwrap? just copy macros, execute it, and createActionItem if it's necessary (don't forget menuMan.updateMenuBar()).

Caprier
01-05-2011, 03:47 PM
If you copy the macro and run it without having an object selected with an unwrap on it, you get an error. Try it.
The menuMan part is not the issue since the menu is registered correctly (see first post).
And why would I want to update the menu bar? The macro is 'run from the Mapping menu of the Edit UVWs dialog' (first post again).

The issue is not something that is not working. Everything works fine for all of the 15 or so guys who installed it. But two of them get the error I described at startup.
They do not get the error instead of the macro working.
They get the error and, after clicking the OK button, the macro works fine.
It's that error I'm trying to identify and get rid of.

denisT
01-05-2011, 03:58 PM
If you copy the macro and run it without having an object selected with an unwrap on it, you get an error.
it's why you have to fix the macros code. (see my post above)


on isEnabled do
(
local theObj = selection[1]
local theMod = modPanel.getCurrentObject()
if not iskindof theMod UVWUnwrap or theMod.getTVSubObjectMode() != 3 do return false
... )--end on isEnabled


on execute do
(
rollout rltStraightenUVstrip "Straighten UV Strip"
(
checkBox cbAvU "Average Us"
checkBox cbAvV "Average Vs" across:2
button btnOk "OK" width:90 align:#right
checkBox cbNorm "Normalize" across:2
button btnCancel "Cancel" width:90 align:#right

local theObj
local theMod = modPanel.getCurrentObject()
...
local setpos = if iskindof theMod UVWUnwrap do theMod.setVertexPosition

-- map channel in current unwrap modifier
local mCh = if iskindof theMod UVWUnwrap do theMod.getMapChannel()
...

Caprier
01-05-2011, 04:03 PM
Denis, are you pulling my leg?

denisT
01-05-2011, 04:08 PM
Denis, are you pulling my leg?

YOU USE unwrap interface functions and DON'T CHECK if the current modpanel object is Unwrap_UVW modifier.

Caprier
01-05-2011, 04:36 PM
I had that test in earlier versions (though in the form of testing the class of modPanel.getCurrentObject()) and the error was already there.
I removed that test later for the reasons stated in my second post.

But I'll have one of the guy with the error try it again with the correction you suggest.
The thing is, if not having that test is a mistake, why is the compile error showing for only 2 guys out of 15 or 18?

I'll post the result of the test as soon as I have it (doesn't depend only on me).

denisT
01-05-2011, 04:49 PM
I had that test in earlier versions (though in the form of testing the class of modPanel.getCurrentObject()) and the error was already there.
I removed that test later for the reasons stated in my second post.

But I'll have one of the guy with the error try it again with the correction you suggest.
The thing is, if not having that test is a mistake, why is the compile error showing for only 2 guys out of 15 or 18?

I'll post the result of the test as soon as I have it (doesn't depend only on me).

this error has to be shown for every user. including yourself. the puzzle is why it doesn't show ;)

Caprier
01-05-2011, 05:06 PM
I'll have the test done later tonight so won't post the result before tomorrow.

In the meantime to answer your question, let me put it this way. How can you possibly execute the macro from the mapping menu of the edit dialog without an object with an unwrap?
Or better, can you even open that dialog without first having an object selected, with an unwrap modifier in its stack and being at the unwrap level?

Please intall the script and try it yourself.

denisT
01-05-2011, 06:14 PM
Please intall the script and try it yourself.

I don't want to install any not working scripts...

it's all that you need to install the FIXED macro:

(
local macro = "$userMacros\\UVW Unwrap-straightenUVstrip.mcr"
if doesfileexist macro do
(
fileIn macro

if (theMenu = menuMan.findMenu "UVW Unwrap - UVW Mapping") != undefined do
(
local num = theMenu.numItems()
local noItem = true
local theTitle = "Straighten UV Strip..."

for i = 1 to num while noItem do noItem = ((theMenu.getItem i).getTitle() != theTitle)

if noItem do
(
if not (theMenu.getItem num).getIsSeparator() do
(
local theSep = menuMan.createSeparatorItem()
theMenu.addItem theSep -1
)
local theItem = menuMan.createActionItem "straightenUVstrip" "UVW Unwrap"
theItem.setTitle theTitle
theItem.setUseCustomTitle true
theMenu.addItem theItem -1
menuMan.updateMenuBar()
)
)
)
)

it's safe to put this code into scripts startup (it's how I do it).

Caprier
01-06-2011, 01:27 AM
Thanks for that, Denis.

I've sent a new .mzp with your corrections both in install.ms and in the macro to one of the guys with the error.
I first tried it myself of course and that went well, which is a good omen (but then I didn't have the error in the first place).
I'm waiting for his answer (fingers crossed).

Caprier
01-06-2011, 03:06 AM
BINGO!
The compile error is gone!
And also the other problem with the double drop (?!).

Thanks a ton Denis. Especially for insisting and keeping up with me despite a good deal of thickness on my part.
Much much appreciated :thumbsup:

denisT
01-06-2011, 04:33 AM
The compile error is gone!
And also the other problem with the double drop (?!).

i am glad to be helping you. but i suggest you to go on trimesh level. the number of faces might be different but the number of map verts is the same. you always can convert map verts to map faces. also i suggest to support unwrap applied to multiple nodes.

Caprier
01-06-2011, 05:36 AM
The macro works only on the trimesh, through meshOp methods: theObj = selection[1].mesh
The whole topology check is based on that.
It also makes an extensive use of verts-to-faces and faces-to-verts conversions:
local f2v = meshOp.getMapVertsUsingMapFace
local v2f = meshOp.getMapFacesUsingMapVert
Is this what you mean?

Support for multiple nodes would be great. It's vaguely on the to-do list.
Right now, I'm looking into extending the algorithm to work on strips that are more than 1 face wide.
This proves a lot more complicated than expected: some configurations are undetermined, considering only their topology.
A simple example is a 2x2 quads configuration, with all diagonal edges pointing toward the center vertex. The topology is identical to that of an octagon with a center vertex: no way to define width and length directions.
If you have an idea, I'm buying! :)

CGTalk Moderation
01-06-2011, 05:36 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.