The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
to use an unofficial version.

Tom

Post a reply to this message

Tom York wrote:
> The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
> to use an unofficial version.

Of course, it is also fixed in 3.7 betas.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Tom York wrote:
> > The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
> > to use an unofficial version.
>
> Of course, it is also fixed in 3.7 betas.
>
>  Thorsten

Yes. I didn't mention the beta for obvious reasons.

Tom

Post a reply to this message

> I guess it's related to the already known macro-bug: if you return results 
> via the parameters, every now and then the parameter will be returned 
> unchanged.
>
> So, if your macro works like this:
> #macro DoSomething(Variable)
>   #declare Variable=Variable+1;
> #end

A good workaround is just to pass values by substitution instead...
#macro DoSomething(Variable)
   #declare result = Variable+1;
   (result)
#end

Then call the macro from a declare.
#declare Variable = DoSomething(Variable);

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> Yes. I didn't mention the beta for obvious reasons.

  What reasons are those?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> > Yes. I didn't mention the beta for obvious reasons.
>
>   What reasons are those?
>
> --
>                                                           - Warp

Because it's a beta, not a finished release? I'm under the strong impression
that the only reason for using the beta currently is to test it. Hence the
expiry, the warnings in the beta announcements about missing/possibly
missing features, and so on.

Tom

Post a reply to this message

Thanks guys,
Unfortunately I don't think I'm out of the woods yet on this one.

I had actually run into problems sometime back when modifying variables
named by the parameter line of a macro.  So, ever since then I've made a
point of declaring a local variable to take it's place if need be.  E.g.

#macro DoSomething(Variable)
   #local TempVariable = Variable;
   #declare TempVariable = Variable + 1;
#end


So I suppose it could still somehow be related to the parameter bug, but I
suspect this is something else. Also, last night I found a case where the
"offending" line wasn't even a function or spline call... It was just a
#declare statement, in this case, still having to do with splines.  It was
something like:

#declare MySpline2 = MySpline1;

....And That's about it.   I tried adding a line above it:

#ifndef(MySpline1) #error "uh oh"  #end

....but unfortunately this line made it parse.  As I said, any little change
elsewhere up above in the code can change whether a likely offender
actually offends.

So far I've found 3 types of offenders:

1.  A call to a macro which creates triangles between 2 splines which are
passed as parameters.
2.  A call to a macro which generates a spline using points from other
splines.  A single float is passed to this macro to tell it what point
along those other splines to use.
3. #declare MySpline2 = MySpline1; //or something like this.

(None of these involve modifying parameters.)

Thanks again,
Charles



Thanks again,
Charles

Post a reply to this message

"Charles C" <nomail@nomail> wrote:
>
> #macro DoSomething(Variable)
>    #local TempVariable = Variable;
>    #declare TempVariable = Variable + 1;
> #end

It should've been a #declare in this case.  Normally there's a lot more in
the macro and I'll only #declare what I want to keep.

Post a reply to this message

I've encountered the same problem in the same situation, and my solution was
to go back to version 3.5, which doesn't have this bug (which is fine, as
long as you're not using any 3.6 features.)

Dave Matthews

Post a reply to this message

That's validating - at least I'm not alone :)
Charles


"Dave Matthews" <dav### [at] mnwestedu> wrote:
> I've encountered the same problem in the same situation, and my solution was
> to go back to version 3.5, which doesn't have this bug (which is fine, as
> long as you're not using any 3.6 features.)
>
> Dave Matthews

Post a reply to this message