[Bug] Shape parsing

Bananorpion · Post by **Bananorpion** » March 12th, 2018, 5:07 pm

Hello,

I've been trying to solve a couple errors within a shape meter, but the more I try, the more I think the problem doesn't come from configuration.

Basically, I have a shape meter, the shape of which is automatically built. It works pretty good, but the more I develop it, the more I have the same errors (Not exactly the same values, of course.):

Code: Select all

Formula: Unmatched brackets: (mi

or

Code: Select all

Formula: Unmatched brackets: (max(((-29.40)+180),(((-44.10)*[Measu

or even

Code: Select all

Path shape has invalid parameters: LineT
Invalid Path type: LineT

Starting from this: these errors are wrong: every bracket is matched, and every path type is valid. I've checked too many times, and moreover, these are automatically generated: the errors should appear in other circumstances as well.
Here's the thing: these errors only appear when the shape is long enough. (A 26952-character shape is valid, a 33068-character is not.) <- Ok, when I wrote this, I think I realized what may be wrong. ._.
I'm gonna try and make them all fit within 32767 characters then.

Well, so I have not written this for nothing (Maybe I haven't pinpointed the bug.), you can try it. (Eight shapes are pre-designed, you need to edit the key Visual in the meter [Visual]. 2 and 3 lines work, 4 and 18 generate pretty errors.)

EDIT: Best I could do was 7-line with 32467 char, I guess 8 lines is too many. It works, so I guess that was the right call.

Post by **eclectic-tech** » March 12th, 2018, 5:57 pm

A quick look finds this typo in your Player.inc file:

gradienterror.png

I haven't loaded the skin yet, but will see if I get the same errors...

Bananorpion · Post by **Bananorpion** » March 12th, 2018, 8:35 pm

Nice catch, I fixed it (It worked despite this, somehow.)

Post by **eclectic-tech** » March 12th, 2018, 10:11 pm

Yeah, the typo had no bearing on the errors when using 4lines or 18Lines paths.

I take it these path definitions being generated automatically by a script of some sort (it's the only reason I can think of that would create 30,000~50,000 character lines.)

I did get the same error messages when running the longer path definitions. I spent some time looking for issues and do not see any errors in the bracketing. I suspect the longer definitions are what are causing the errors.

Would it be possible to have the generation scheme create several shorter path definitions and use several shape definitions in the shape meter, rather than 1 shape definition with 1 extremely long, and difficult to troubleshoot, line?

Frankly, I would look at possible alternative ways to achieve the desired effect. I have a feeling quadratic or cubic bézier curves with external control points might be a better way to do something like this rather than a 40,000 character path statement.

I wish you well on this project, but due to the complexity, I can't spend the time to get any deeper inside your code.

Bananorpion · Post by **Bananorpion** » March 13th, 2018, 2:48 pm

eclectic-tech wrote: Would it be possible to have the generation scheme create several shorter path definitions and use several shape definitions in the shape meter, rather than 1 shape definition with 1 extremely long, and difficult to troubleshoot, line?

Of course it is. Using too many lines on the same meter isn't that interesting anyway, but the script has no limits to the number of meters it can generate. I've finished it last night, I'll share it with a couple examples and the finished skin tonight.

eclectic-tech wrote: Frankly, I would look at possible alternative ways to achieve the desired effect. I have a feeling quadratic or cubic bézier curves with external control points might be a better way to do something like this rather than a 40,000 character path statement.

I don't know the exact terms (I have no idea what "quadratic" means.), but I considered using curves instead of lines. I have not tried yet, for a calculation reason: with straight lines, each point may be calculated on its own, through the associated measure. (Like, if I have three measures A B C with values 1 5 3, the lines will be 0,1 -> 1,5 -> 2,3 .) Now, if I use curved lines, I'll have to consider the adjacent measures as well for every calculation, so the curve is in the right direction, because a line from 0,1 to 1,5 with a curve peak at 0.5,4 is not the same as a line with a curve peak 0.5,2, and I have to know the measure of the subsequent value to decide, which almost triples the total required calculation, on every update.
I'll try it for fun, but I'm not sure yet the result will be really smooth. Tell me if I missed something in your idea!

[Bug] Shape parsing

[Bug] Shape parsing

Re: [Bug] Shape parsing

Re: [Bug] Shape parsing

Re: [Bug] Shape parsing

Re: [Bug] Shape parsing