lol… pulling out the big guns 
Here is the latest script in case anyone want to mess with it ( @Helvetosaur … =) ) and @wim, @jeff_hammond, it seems to work fine in V6, and OK on Rhino for Mac, (the labels do not draw on the mac) from RunPythonScript.
KyleMode_NoViewSnap_Label.py (8.9 KB)
and compiled for Windows V5 SR9:
AutoCPlane.rhp (18.5 KB)
-Pascal
1 Like
Hi Riccardo- so, does this mean, for example, you’d want the World Front plane to become active when you approach a ‘back’ view and you would be looking at the back of the World Front plane, (X to the left) rather than the front of the World Back plane?
thanks,
-Pascal
1 Like
oh. nice
can’t try it now but will do so later. so I’ll just run it as a python script and it stays active throughout the session? or what?
Yes, exactly it should stay active until run a second time (it’s a toggle) - you can hard code the path to an alias I suppose -
_-RunPythonScript "blah blah"
to make it more command-like. (easier to toggle on and off)
-Pascal
Yes Pascal, this was my first impression.
In my opinion, maybe it’s just me, it’s enough to have only the 3 main planes.
This way is easier to know were you are.
OK, that should be easy to test - I wonder if the color coding is still useful - light color when in the back of one of the three CPlanes, dark color when in front…? I find it helpful, I think, but still just testing not doing any real work.
-Pascal
Don’t know, but I don’t like too much color code in a cad.
There’s already the red, green, blue code for the X Y Z.
Maybe the what could change are the color of the axis, normal in front, dimmed in back.
Just a proposal.
Update that does not flicker. (Thanks Giulio!.. Scripters, use the Draw2dRectangle function for this, not DrawPolygon…)
AutoCPlane.rhp (18.5 KB)
KyleMode_NoViewSnap_Label.py (9.0 KB)
-Pascal
1 Like
hey pascal.
so, it’s buggy on (my) mac but it does appear to work properly once it gets going… within ten seconds of initiating the script, i get this:
(hmm… i guess i’d ruin the thread if i posted the message here… it’s real long.)
kyleModeErrorMac.txt (46.2 KB)
that’s with osx 10.10.0 and wenatchee dec02,2014…
it looks as if some of my system shortcuts may be affected right now (for instance, i use ⌘-space for spotlight/launching my textEdit app for placing the error message into and that appears broken now… i’ll reboot after sending this to see if kylemode has anything to do with it…
all that said, i get it that troubleshooting for mac isn’t high priority on this experimental functionality… i’ll test if you have new versions but no hurries/worries
[ADD] i rebooted and my spotlight shortcut works fine… ran a few other scripts in rhino then autoCPlane (got the long message again) then tried ⌘-space and it worked… so, false alarm on that part.
anyway, it does appear to work right for me… and yeah, something around 20 seems better, more natural…
i’m going to time machine this computer (haven’t gotten around to it yet 
) first before i keep going with experimental code though.
Hmmm- yeah, looks like maybe Mac does not like my labels at all… not sure what is possible here, I just don’t have enough knowledge to troubleshoot this I’m afraid.
-Pascal
it’s fine… don’t sweat it
an immediate thing i noticed about the mode though… (all in perspective viewport)-- say you’re in something near a Front View so the cplane is vertical to world… when rotating around towards Right View, the cPlane goes to top then back up to vertical upon nearing Right view.
it seemed like the cplane should of stayed vertical throughout the rotation from front to right. (setting at 20)… like, it should of only switched from Front to Right at some point without the top plane intermission in the middle.
Yeah, that has been a bone of contention. Bob thought it was weird not to go back to Top when not in a clear ‘other’ plane. I had it as you describe initially. With small angles, I think it makes sense, or at least it feels OK to go back to Top, but with large angles, I am not sure it is better, I’ll fool around with it.
@piac made a cool variation that I am still messing with, which has the CPlane not change until mouse-up. I’ll probably post that version before too long to see how it flies.
-Pascal
i don’t know quite how to describe it but what i’m thinking is probably more how you had it set up initially.
if my setting is 20, then that should be the angle which determines what it takes to go from world to vertical… but the number should act like 45 (if i correctly understand how this is working) for switching from front to right…
or, the ground plane acts a little different than the rest of the planes… it shouldn’t be like a box with all sides being treated equally.
(again, i tried it for about 4 minutes total… so these are only initial thoughts)
you mean like–
i run _Line
click a start point on the regular cplane
mouse up then the cplane goes vertical
?
thats sounds awesome ; )
This looks like a bug that I need to fix on Mac Rhino; could you make a youtrack item for me @pascal? thanks
Thanks, Pascal !
I like it. I’ve been missing such a feature … and making buttons to quickly change the CPlane …
When there is no plane within the cut off angle, the World Top becomes active.
Hmmm … here is where it does not feel quite right to me…
I’d prefer the CPlane to stick until another plane enters the cut off angle.
Or maybe having a lock angle and a separate unlock angle, to be able to choose when to go back to World Top.
Adding a little inertia, so to speak …
Does that make sense ?
well, maybe it sounds awesome… i guess we’d just have to try it out first but i guess there are times when mouse Up doesn’t mean i want to change the cplane… i might just want to put the second point behind (from my viewing angle) the first point on the current cplane which would require to move the mouse up…
maybe viewing angle is the better determining factor here.
re: the error message… the problem with me testing right now is that the error is shown in the command history which normally pops up in the lower left corner when need be… so if i do anything, the history shows… but when that huge error message is in the history, my screen does this after every command 
@stevebaer , I did not see the problem that Jeff saw, and I think that is sorted for him after a reboot. However, the labels do not draw at all on Rhino for Mac, that might be worth a bug report. OK, I see more errors from Jeff, I’ll test more on mac and make a bug item.
-Pascal
Yeah, that is what Jeff was saying as well. I’ll work on it a bit more and see if I can add settings to play with.
thanks,
-Pascal
Hehe - users are a real nightmare 
- never exactly two identical opinions…
Don’t you guys get that when you set the angle to 44 degrees? Then you will only land on the world CPlane in that narrow 2° window.
In my view, I’d use a small angle (somewhere between 10 and 20) and work in the regular world CPlane - just as before. It is only (in my experience, in my workflow) in rare occasions that I have to go to some plan & parallel view to construct something and then back to the perspective view.