Hi everyone,
The link to the Wiki (Menu > Help > Wiki) still points to the old forum and doesn’t work. It should be: Seamly2D
Would you like me to create an issue for it?
1 Like
Yes please create a github issue 
1 Like
Ok I’ve created a branch, I can fix it hopefully soon if I don’t keep getting interrupted by life 
2 Likes
Issue fixed. Should be in next build I assume.
1 Like
Thank you, @Douglas, you’re a star…
So here’s another “Minor Issue”…
I’m using Windows 10 and Seamly 
The 1st thing is that the symbol for degree has an A with a ~ on top of it before the small circle. You will see it in the image below.
The 2nd thing is that I’ve created my 1st circle using an Arc, with 3 points at 0, 90 & 180 degrees. And then created a 2nd circle off the 90 degree node of the same diameter. I need points at 0 and 180 degrees. Creating the 0 degree node was fine, but creating the 180 degree node keeps putting it at 0 degrees. If I plus or minus 0.001 degrees, it places it correctly, as in the 2nd image.
Here’s my simple pattern: Pencil Bag Pattern.val (1.7 KB)
Should I make an Issue for this?
1 Like
There’s already an issue for the 2nd thing!
Susan actually combined several instances of the issue into one issue# recently.
I feel that this one is a bit more than a minor issue, because it isn’t even consistent in how wrong it is. Try changing the size of your first circle just a smudge, & I think you’ll see what I mean. (There’s also CompassRose.val in the linked post (no .vit needed,) if you’d prefer. It has lines that are supposed to be going out in the 8 directions of a typical compass rose.)
1 Like
Ok, thanks. I did come right with my pattern, so if there’s an issue about it, that’s great
Sure. Just check and make sure theres not an existing one… I’ve seen this reported before - it might have on the “other” programs forums.
1 Like
Hi Grace,
I have to put my thinking cap back on for this one (that is I’ll have to go back and find / read some old posts) … this popped up in a discussion like 2 years ago, and if I recall it’s not related to the program per se, but rather one’s fonts settings. It a UNICODE thing. I looked at the pattern you posted and it displays the degree symbol fine on my Windows 10 laptop. You’re getting that extra A circumflex I’ll take a look tues eve and get back to you.
Now that I figured out the Github build (test) failure for the new notch options, I’ll also take a look at issue # 2.
1 Like
Ahhaaaa… So it’s only me. Hmmm… I’ll have to research how to fix it. It’s doing it on my brand new laptop, too. Thank you for your assistance so far 
Hey Grace…Sorry I didn’t get a chance to look at th his last night, but it’s starting to come back to me. I downloaded the most recent Seamly2D build and it had the same issue with the deg symbol that you experienced, where when I use a build done on my machine it’s fine. It’s definitely something to do with the Unicode encoding. Not sure how (yet) how to get a correct build off of Github. One thing I need to check is if this happening everywhere the deg symbol is used, or if it’s just in the property browser dock window.
2 Likes
Thank you, @Douglas. You’re a star 
I can’t download anything that I need to build at the moment. I had my laptop stolen & had to replace it 
, so still setting everything up.
Anyhow, now that I’m home I was able to look at the issue again, and it’s all come back. The problem is that Github is encoding the source files as something other than UTF-8
I use the Atom editor and the files are set to UTF-8 encoding. Here you can see the string definition and it displays correctly:
Switching the file encoding to ISO 8859-1 it throws the extra A char in.
I believe we need to figure out how to configure Githhub to use the source files as UTF-8 in the builds.
1 Like
soapBoxMode = ON
In more ways than one… this is another example of inconsistencies in the program that can at times be annoying if not confusing.
How so in this case? First off - 2 different tools do the same function. Secondly the tool tip(s) don’t match the “Tool Options” description - which in of itself is incorrect terminology as these are “Tool Properties” not tool options. For ex: A tool option is you have a choice to pick the hammer or a screw driver. Properties of the hammer could be that it has a wooden handle and a ball peen head. An option is a choice, a property is something you set.
In the example Grace provided you can either use the “Point intersect arc & axis” or the “Point intersect curve & axis.” But if you notice in both cases the Tool Option says "Point intersection of curve and axis.
So is it a curve? An arc? An intersect? An Intersection? Not to mention is it a “Line type:” or “Type of line” or “Pen style:?”
And yes I’m aware that there’s a bug with the Pen style… um Line type combobox. in the Arc and other curve tool dialogs.
soapBoxMode = OFF
Anyhow… I’ll have a fix for the 0 - 180 degree issue and we’ll work on the inconsistencies in grammar & terminology.
2 Likes
Update on the Intersection point… It was a simple fix to correct the erratic behavior leading to being off by 180 deg.
But testing the fix I discovered several other issues, one that I will correct, the other I’d like some feedback on how others would like to see the issue addressed. The first issue is that if the axis center point is outside the arc / circle or NOT intersecting a curve, the visualization wants to connect to the absolute zero point (center) of the scene. IMO the tool should not exit until either a point on the curve is created or esc is pressed to cancel the operation.
The other issue is that again if the axis center point is outside the arc / circle or the axis passes through a curve more than once, only the first intersection point is available.
Questions are:
-
Is the current fix good enough for now?
-
Should I come back to this issue at some point to add the option to select either point, like in the Point from tangent & circle tool ?
2 Likes
Hi @Douglas, once again I look upon all of this in awe. Thank you very much 
IMO…
Yes, most definitely. Something that at least works is much better than something that doesn’t and does strange, unexplainable things (like whizzing off to absolute point Zero) when you’re only learning how to use the program.
And also, yes. It would be nice to be able to choose either the 1st or the 2nd or even, perhaps, both in this instance. However, the “both” may not be deemed feasible.
Once again, thank you very much 
1 Like
Yay! I look forward to thwacking this fix’s tires!
What about if using a new .vit puts the axis center point outside of the arc/circle?
Compared to the physics-breaking experience of the primary problem, the rest of the related issues, though still issues, are not going to break someone’s pattern if they fail to look at it funny enough, & thus could probably wait for a subsequent update.
On the other hand, although I have not yet felt a need to get a point to the far side of a circle, I see that as it currently stands, doing so would require two (2) superfluous intermediary points, since the tool won’t work from a point on the arc. So I would agree that this probably needs addressed at some point.
1 Like
Good point… or should I say bad point. LOL
Yes there is that possibility Or there’s also the cases where the curve could be resized (see pic) or the axis angle is changed to a degree where there is no intersection point. That means as the pattern is re-parsed the intersection point can’t be created. If the point has no dependents there’s no problem, but if it has any dependents then “some” point has to be used or the program would likely crash… that’s why the “zero” point was probably a logical choice.
Will have to think on it a bit.
2 Likes
Here’s my solution so far… First is to limit the range of the intersect point to the curve when sweeping the axis - and not moving to the “origin” point when the axis moves off the curve. The effect is that the intersect point will at least be approximately set at one of the 2 tangent points. The second thing I did is to throw up a warning box if the geometry changes to cause the intersect point to no longer exist. The origin point will then be used. It’s a compromise I think we can live with. This is an example one of the pitfalls of the program - there’s no sensible way to automatically predict how objects may change in the future.
2 Likes