Rotate Multiple lines of mtext to current view

[kzD1219]

Are there any tricks or lisp routines that can help me out?  My plan rotation changed and now I am stuck rotating mtext to plan view.  That is find when there is only one line of mtext, but generally we show mtext on top of one another because of size difference and layer difference of each line of mtext.  I have been rotating all 3 lines of text by eyeball and then adjusting to 90 degrees, but then the middle center justification is slightly off.

Currently looks like this:

I exaggerated this but the grip don't like up.

Need it lined up with the same spacing (blue line for lineup only)

Any help or suggestion is greatly appreciated.  The client change their mind on the orientation...grr!

[pendean]

Is you set PLAN command to "current ucs" you won't ever have to do it manually like that: look up usage in HELP.

[kzD1219]

Yes, PLAN is set to current UCS.  But not sure how to get to rotated text to be 90 degrees again with it all spaced out and lined up at mid center justification like it was before I had to rotate the UCS from world.  It certainly doesn't automatically change with the UCS like Civil 3d Points would.  

[pendean]

Can you share a portion of a DWG that exhibits the problem?

[imadHabash]

Hi,

I suggest to check if TORIENT command will help you as described here . >> Click << 

[kzD1219]

---

@imadHabash wrote:

Hi,

I suggest to check if TORIENT command will help you as described here . >> Click << 

---

Torient works fine, but doesn't keep all the text in line by insertion point.

Before TORIENT

after TORIENT, grips are now horribly off center and not lined up.  I don't want to spend extra time lining them up.

[kzD1219]

---

@pendean wrote:
Can you share a portion of a DWG that exhibits the problem?

---

Here you go.  I circled what needs to be rotated to read across the page again.

[kzD1219]

If I grouped it together and then rotated, that would work, but then I would have to ungroup which isn't productive at all.

[pendean]

@kzD1219 So this comes down to processes and workflows: you appear to not rotating your UCS first before placing the text/mtext (where PLAN command shines).
OR... these need to be a single block each with category attributes (on separate layers is fine).

I believe you are asking for the impossible with your manual floaties as is, you are basically starting from a bad spot to make something look good after the fact, when it should have been the first thing to plan for ahead of time.

You probably want a LISP routine that creates a circle around each cluster, then temp blocks inside each circle, rotates the block around the center of the circle, then self-explodes afterwards. Or some version of that. Maybe someone wants to take that on, stay tuned.

May I ask: why are you not using C3D (or possibly Map3D) for these tasks? I suspect they have the tools you need OOTB.

HTH

[kzD1219]

---

@pendean wrote:

@kzD1219So this comes down to processes and workflows: you appear to not rotating your UCS first before placing the text/mtext (where PLAN command shines).
OR... these need to be a single block each with category attributes (on separate layers is fine).

I believe you are asking for the impossible with your manual floaties as is, you are basically starting from a bad spot to make something look good after the fact, when it should have been the first thing to plan for ahead of time.

You probably want a LISP routine that creates a circle around each cluster, then temp blocks inside each circle, rotates the block around the center of the circle, then self-explodes afterwards. Or some version of that. Maybe someone wants to take that on, stay tuned.

May I ask: why are you not using C3D (or possibly Map3D) for these tasks? I suspect they have the tools you need OOTB.

HTH

---

Unfortunately the plan was in world coordinates to begin with, we were all happy and then the client changed a boundary and now it won't fit on my plan so I had no choice but the rotate the UCS and shift things around on my plan.  As far as using Civil 3d, yes that is what we use, I just thought this might be an acad thing instead.  And while I like the idea of attributed blocks and that would work pretty good in this situation, I am a drafter of one and my PMs are not acad savvy so when I am busy and they need to make changes, it has to be simple for them, even with me trying to tell them how to do it and where to find things.  So an uphill battle sometimes.  

[pendean]

>>>... As far as using Civil 3d, yes that is what we use...<<<
After the fact fixes of randomly placed (to the program) floating objects in a DWG file are always hardest to implement. Planning ahead is almost always the best solution. Unless you can come up with a defined fixed-placement position that would work for all of your floaties all across your DWG file.

As you probably know, the C3D forum is over here, ask over there for guidance on possible OOTB options to adopt moving forward in future projects/DWG files for this client https://forums.autodesk.com/t5/civil-3d-forum/bd-p/66

Good luck.

[Kent1Cooper]

See >here<.

[Kent1Cooper]

---

@kzD1219 wrote:

If I grouped it together and then rotated, that would work, but then I would have to ungroup which isn't productive at all.

---

You don't need to group things together to do things to them collectively.  Both the ROTATE command and the Rotate mode in grip-editing will work with multiple objects without grouping, as in the accepted solution in the duplicate topic over in the Customization Forum.