Hm. I just tried it in Seamly2D 0.6.0.1 just to be sure, it worked, and I think it worked again since I have Seamly2D. I had an error like that in the time I used a newer Valentina, before Seamly2d came out. If it were, it would be a bug, but I cannot find that error in my actual version of Seamly2D
You should have access to the length of lines in creating increments. In fact works for me in seamly 0.6.0.1 if you click on the f(x) right after you have clicked on the + sign to create a new increment. At that point, if you select length of lines, they all show up, at least for me. If you create the increment and assign it a name (or just accept the default name) then go back later and attempt to use f(x) to enter a formula, the length of lines list is empty. If you go back and use + to create a new increment, you can access the line lengths for that increment.
Open your history (Ctrl+h), scroll down to the very last entry and click in the square provided in front of the last line. A curved arrow should be placed in the square which means that the next drawing piece will be placed after this line and anything that was created before will be listed to be used in the formulas. Click on OK to close it and try again.
If this doesn’t work, please post both your .val and .vit files so that someone can try a few things and see where the problem is.
My understanding is that you deliberately can’t use line lengths in increments. The code does not attempt to deduce a dependency order (AFAIK) and so you can only use things that have been created ‘earlier’.
Measurements are defined first, then increments, then each piece (in order) and within each piece, each object in creation order. So, within an increment you can only reference measurements and other increments that were created before it.
I’m happy to be proved wrong.
I understand that only things that are created “earlier” can be used to define things that are created “later” as you stated it, @MrDoo. With that in mind, I have proven to myself that it is possible to define an increment with a formula that includes the length of a line that was previously created.
Keep in mind that Increments are meant to be global variables that are defined when the pattern is opened.
By using a line length to define an increment you may introduce processing problems. I can’t guarantee that you will achieve a pattern that is easily updated. It may crash on you unexpectedly.
@slpencer, that is a good point. I was getting hung up on how to make it possible to use a line length as part of a formula within an increment and not thinking about WHY one would want to do that. To prove it could be done, I created a “pattern” that contained simply a reference square (4 lines). If I then create a new increment, it is technically possible to do so, but that does not represent a “real world” pattern creation.
For basic patterns, the difficulty in processing delayed variables might not be a problem. But for a tailored jacket which might have 70 pieces (!) the drag on memory and CPU might prove to be frustrating, and might even cause the pattern to hang indefinitely.
I see the point of memory/CPU load and understand, that it can be a challenge.
In the way I construct there are sometimes lenght of lines or curves that are measured and transfered, for example the front and back armpoint from armhole to sleeve. So it would be a wonderful feature for me and the other ones who follow the same construction.
I am unfamiliar with Hofenbitzer, but I will look it up. Meanwhile, can I suggest a “hack” that might work for you. Create a line (you pick the length, based on your best random guess of what “might” be a good length for the line you will use in your construction.) Name the second point on the line something like “reference_length”. Save that early before you proceed far with your pattern. Use the known symbol of “Line_A_Reference_Length” (replacing A with the actual name of the origin point of the reference line. That symbol should appear in the variables table once you have created the line.
Sometime later in your construction, you can always go back and update the value of reference_length to contain the actual measurement. I firmly believe you will decide later that you did not need to do this, but I may be wrong. Please post an update on how this works for you