![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
That's validating - at least I'm not alone :)
Charles
"Dave Matthews" <dav### [at] mnwest edu> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |