See the latest posts in topic "Simulate 'User Coordinate System' using 'rotate' and 'move'"
By riverbuoy in the forum "qcad-script-add-on-plug-in-challenge".
Reported by user B110

The first link for the ZIP file is funcional (first post):
https://forum.qcad.org/uploads/short-url/xkxvvxptSRCU8yjTiwIMb2lVZDe.zip

The second link for the fixed JS script is not (third post):
https://forum.qcad.org/uploads/short-url/jRNfanXk9tW9FwGNWGl7goIQngF.js

The error we get is:
"The change you wanted was rejected.
Maybe you tried to change something you didn’t have access to."

This would make any posted JS script not accessible.
That may be true for downloading or even be related to uploading JS files and other types.

In this specific case I had a copy and could describe how to fix the original Ucs.js script.

Regards,
CVH

Concerning commit: https://github.com/qcad/qcad/commit/73a3b141bbe7438f36adad7219545e7b85d4304f

The sane number limits within -1e+12 to 1e+12 are removed.
RMath::isSane(value) is now reduced to an analog of RMath::isNormal(value).

This means that every numeric value except NAN and +/-INF is normal AND sane.
About sure that I can give counter indications of that.

I do not consider the used coordinate values as sane.
Please explain why we should support things in real world size
(A chair, about 500 by 500mm)
placed at X = 3440898387387.5750mm (+/-1ULP is about +/-0.0005mm)
and Y = 15219137016394.785mm (+/-1ULP is about +/-0.002mm)
While the longest distance on Earth is about 40075017000mm.
Or about and less than 1/100 of those in the drawing file.

The origin of these insane values is probably:
"A metric unit represents one point (1/72 inch)"
"Divide the metric value by 185771 for mm"
Then the coordinates are about 84 and 82 km from some reference point.
Instead of about 8-9 times the distance to the Moon.

But that won't hold because the page border is 42000 by 29702mm.
Almost exactly A3 scaled up 100 times and used in scale 2.00.
The file data is probably edited in multiple applications.

Allowing larger numbers is one.
But why is this suddenly associated with shorter (not smaller) Arc segments?
And also with longer Arc segments.

Shorter Arc segments has always been problem.
Even when far over the common RS::AngleTolerance (Not PointTolerance).
Polyline Arc segments are considered to be straight with a bulge of less than 1e-6.
atan(0.000001)*4 = 3.9999999999986666e-6 rad
… Not the end of the story … The chord between the two vertices must be over 1e-6 long.
Otherwise the chord has always an undefined orientation equal to zero.
The center is then limited to vertically up/down from the midpoint.

The biggest flaw sits in 'Longer Arc segments'

        if (ret > 2 * M_PI - 1.0e-16) {
            ret = 0.0;
        }

IMHO, 6.283185307179586 minus 1e-16 remains 6.283185307179586
Meaning that you can subtract 1e-16 from 2Pi several times over and still end up with 2Pi.
2Pi - 1e-16 - 1e-16 - 1e-16 - 1e-16 - 1e-16 === 2Pi

1ULP of 2Pi is 8.881784197001252e-16
Subtracting about half of that would have an influence on the LSB by binary rounding.
2Pi - 5e-16 = 6.283185307179585
All depends on the rounding scheme.

As 'FIXED' a near a full circular Arc is now 2Pi or more and not a fraction less.

The so-called 'FIXES' are only applied in RArc::getAngleLength
Checking for near zero rad or near 2Pi occurs at various places.

Since some time my near 2Pi limit is defined as 6.283185307179584.
Based on a survey that DXF records values ending in 179586 or 1795862.
(The 2 is a flaw, 4 or 5 is expected)

Also defined 2Pi as 6.28318530717958647692528676655900577
(36 digits, analog to RMath)

QCAD code is riddled with the multiplication of Pi times 2 and the division by 2.
RMath specifies M_PI, M_PI_2 and M_PI_4 (36 digits) but JS and C++ may still use derivatives of Pi.

It is a bit faster with various well defined (and effectively used) constants.
A JS equation must be translated, evaluated, passed on to C++ and the result back.
Even if that is merely a binary exponent shift.

Regards,
CVH

Steps to reproduce:

Actual Result:

Expected Result:

Environment:

Requesting a keyboard shortcut for the 'Activate Layer of Entity' option in right-click menu of entity.

Implementation:
1. Entity is selected: keyboard shortcut will activate layer of that entity.

2. No Entity is selected: keyboard shortcut will activate layer of entity that is clicked next.

3. Multiple entities are selected: error message "multiple entities selected, please select a single entity".

Thankyou for all the hard work on a great piece of software.

Kind Regards, Daniel

Expected is a vector with a magnitude strictly not larger than the given range.

But the behavior is very different in regards with the shape:
- RArc: Unused, compare strictRange with distance to center minus radius
- RLine: Only applied for non-perpendicular vectors towards the nearest endpoint if limited
- RCircle: Unused, see RArc
There is always a perpendicular vector towards an RCircle
- REllipse: Unused, there are 0-4 normals for a full or limited ellipse shape
Compare strictRange with distance to (nearest) point on ellipse …
… At least, if that would be a point exactly on the ellipse or not a false positive
- RPoint: Unused, compare strictRange with distance to point
- RPolyline: Only applied for non-perpendicular vectors towards limited line segments
- RXLine: Unused, handled as unlimited RLine
There is always a perpendicular vector towards an RXLine
- RRay: Unused for unlimited, not passed on for limited ⇒ RMAXDOUBLE
- RSpline: Undocumented for proxy, otherwise handled as RPolyline
- …

Turns out that for a returned valid vector one still has to verify that it is within range or not.
getDistanceTo is itself based on getVectorTo … Doing things twice.
Or that the projected point is on the limited shape … Also doing things twice.

Then I don't understand the purpose as it is only implemented for an RLine (segment) when limited. And then only when the projected position is not on the limited shape.
What requires an extra diversification on perpendicular or not.

I only see a purpose for RLine.getVectorTo(pos, false, 1e-6)
What is equally tolerant for the start and end of a limited line (segment).
Except that the magnitude from the start is always exactly zero, even when near.

Regards,
CVH

The suggestion is to use different icons for the two features.

macOS 26.2 Tahoe
QCAD/CAM 3.32.5

Expected Behavior: Linetype patterns should scale inversely to the viewport scale. A dashed line should maintain its intended visual density (appearance) regardless of the viewport’s magnification level. This also matches the behavior of print preview / printing / PDF export.

See also:
https://qcad.org/rsforum/viewtopic.php?f=33&t=12083