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.
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.
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 ?
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 
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.
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.
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.
Wow! That is beautiful how the node is anchored not to go beyond the facing part of the arc.
If I understand correctly, although point A7 could not be created as an intersection node, it still gets created, just at ‘point of origin’… Could something be written to this effect in the error message? Something like “Point A7 is now located near point A” - just to let people know where to look for point A7.
Nice!!!
My intuition tells me that it might be sufficiently handy to replace “Point intersect arc and axis” &“Point from arc and tangent” with a tool that would place a point along the arc a certain percentage of the way between the two edges. 0% & 100% would take over PfAaT, leaving all the other percentages for PIAaA. My judgement just tells me, “That’s not my case.”
Hi Grace… That could be done, although the origin (0, 0) isn’t always neccesarily near the draft piece basepoint A.
I think the main thing is the issue with a point erroneously flipping 180 deg will be fixed.
Edit: How’s this? Spruced up the warning text, added the footnote, and corrected the title bar to reflect what (tool) the warning was produced by, Also removed the superfluous “Seamly2D” in the title bar.
I don’t believe either of those tools needs to be replaced. The original intent of the intersect tool in Grace’s pattern makes sense, I just happened to find an odd case where it has odd behavior.
BTW, you can already use the point along curve tool to place a point somewhere between the 180 deg and 270 deg points… but you need to use the intersect tool first the create those points first. Again, the original issue of erratically being off by 180 deg is fixed.
Hi again And, once again, you’re a star
That’s perfect 
, it’s just to let people know where to look for the point when it zips away out of the screen when one resizes a pattern or something.
Wow! @Douglas. I’ve just downloaded and installed the new release 
It’s wonderful!!! Thank you very much!.
when I go to seamly.net and download the latest linux appimage version, it gives me this (august 3 build) version. 
and when I click on check for updates, first I get a message stating that no updates are available, then I get this error message. 
Could you please let me know how to get the appimage version of this new release?
Thank you very much.
Hi Anna… I’m guessing this is the most recent stable version of the program.
I’m not a Linux user myself, but you could try getting the latest weekly build on Github here: Click the “assets” link and the app image should be there.
I’ll try taking a look at the warning the program is throwing.
Which version of Linux? In Ubuntu 18.04.5 LTS I’m not getting that error.
However, loading the July 30 appimage, I get the same “no updates available” message, so something definitely is a little wonky at the moment.
Thank you @Douglas I got the correct version from the GitHub location.
@Pneumarian this is the version I am running.
I tried to duplicate that behavior and this time I do not get the warning with either the x or the OK exit. I tried several times and in different order and it never failed again.
I tried to make that warning appear with the Sep 7 version and it did not fail. There are so many variables that I have no idea what else to try, but it is certainly not a big problem.
The fact that it did not find updates when I ran the Aug 3 version seems like a (minor) problem.
Interesting… I recently discovered that when building the program in debug mode in Creator, when closing any of the tool related dialogs with the window close X vs the OK button causes the program to crash. Hmmm.
At any rate Pneumarian is correct… something is wonky as the program should not be throwing a connection warning regardless, even if there are no new updates.
Update on the Arc/Curve Axis intersect tool… the changes are merged and should be in the next weekly build. Note that I had to add a fix to the fix to make it backwards compatible with (some) existing patterns without breaking them. It only applies when the axis point is inside an open curve, where I had to allow the intersection to flip on the axis, instead of constraining it like the initial fix did. If not then some patterns could break… or more specifically the “origin” point would be used. Not a problem if you know to just flip the angle 180 deg to fix the offending angle, but it would be a problem for existing cloud patterns.
Here’s an example of the behavior I had to keep.
