Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Graphisoft Community (INT)
- :
- Forum
- :
- Libraries & objects
- :
- Re: GDL prob with text anchor pt rot and maintain ...

Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Pin this post for me
- Bookmark
- Subscribe to Topic
- Mute
- Printer Friendly Page

Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey

Libraries & objects

About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

GDL prob with text anchor pt rot and maintain text orient

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-14 08:53 PM

2009-08-14
08:53 PM

When I have the text orientation options the anchor point of the text no longer is the same as the graphical hotspots. I tried many ADD2 and ROT2 options for the text location textx and texty with no acceptable results.Can someone point me in the right direction?

! graphical hotspots seripting

!!!!!Text ----------------------------------------

PEN txtpen

IF tr=1 THEN !HORIZONTAL TEXT

ROT2 -symb_rotangle

ENDIF

IF tr=2 THEN ! VERTICLE TEXT

ROT2 -symb_rotangle+90

ENDIF

IF tr=3 THEN !SMART ORIENTATION

mul2 1-2*symb_mirrored,1

IF symb_rotangle>90 AND symb_rotangle<270 THEN

ROT2 180

ELSE

ROT2 0

ENDIF

ENDIF

DEFINE STYLE "symtextstyle" font, 1/(2.83464567)*fontsz, txtanchor, txtFaceCode

SET STYLE "symtextstyle"

TEXT2 textx,texty , switch_text

DEL 1

Erika

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

29 REPLIES 29

Anonymous

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 02:12 AM

2009-08-19
02:12 AM

Hello Erika,

I don't know what those periods are either.

What happens when you delete them ?

What happens when you move them right or left

out of the seventh decimal place from the left ?

Do you get an error when you check script ?

Isn't the seventh decimal place the one millions place ?

Maybe its some arithmetic convention like commas

between groups of three decimal places.

Thanks,

Peter Devlin

I don't know what those periods are either.

What happens when you delete them ?

What happens when you move them right or left

out of the seventh decimal place from the left ?

Do you get an error when you check script ?

Isn't the seventh decimal place the one millions place ?

Maybe its some arithmetic convention like commas

between groups of three decimal places.

Thanks,

Peter Devlin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 02:35 AM

2009-08-19
02:35 AM

When I delete the numbers after the period I get a format error message.

When I delete the period and the numbers after script is ok, but angle of line changes and length altered slightly . Original line was 12" long.

When I delete the period the second Y value I now get a very long line.

1.4E+15 in the coordinates box (tracker doesn't show in the gdl windows). I wrote the number as it showed in the coordinates box.

Back in the main window of AC with this line placed I the x,y and r values all have E+ numbers when measuring the line.

Same with changing millimeters to meters for modeling.

When I change units to feet & inches, I get a real value for the x499811'-5 13/16" but the Y and r values are empty.

So no exponents in imperial measuring in AC.

When I delete the period and the numbers after script is ok, but angle of line changes and length altered slightly . Original line was 12" long.

When I delete the period the second Y value I now get a very long line.

1.4E+15 in the coordinates box (tracker doesn't show in the gdl windows). I wrote the number as it showed in the coordinates box.

Back in the main window of AC with this line placed I the x,y and r values all have E+ numbers when measuring the line.

Same with changing millimeters to meters for modeling.

When I change units to feet & inches, I get a real value for the x499811'-5 13/16" but the Y and r values are empty.

So no exponents in imperial measuring in AC.

Erika

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

Anonymous

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 02:56 AM

2009-08-19
02:56 AM

Hello Erika,

There's that e again. I think you can get that e in imperial units.

You have to make the lengths bigger.

You might be interested in this thread where Oleg explains

what e means and I did an experiment with the Print command

that printed numbers with e in them.

http://archicad-talk.graphisoft.com/viewtopic.php?p=11694&highlight=rnd#11694

As to the other weird things you are discovering, I don't know.

But fascinating non the less.

Thanks,

Peter Devlin

There's that e again. I think you can get that e in imperial units.

You have to make the lengths bigger.

You might be interested in this thread where Oleg explains

what e means and I did an experiment with the Print command

that printed numbers with e in them.

As to the other weird things you are discovering, I don't know.

But fascinating non the less.

Thanks,

Peter Devlin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 04:05 AM

2009-08-19
04:05 AM

Erika wrote:You can REQUEST the height of the text once you have defined it.

Juha,

You jumped ahead to the anchor point problem. Some symbols have two lines of text. How do you keep them from running into one another when the scale changes? Or when someone changes the font size?

thanks!

You would think that if you add 2mm high text it would be 2mm high - but no, you have to allow for the line spacing.

REQUEST ("Height_of_style", "name", height) will give you the height in meters.

You can then divide by 1000 to get millimeters and multiply by a scale factor for various scales.

Here is a bit of code from one of my objects with multiple lines of text that will adjust to suit any scale.

DEFINE STYLE "style_large" fnt_sltn,

txt_title_size, 5, 1

xx=REQUEST ("Height_of_style", "style_large", style_large_hgt)

style_large_hgt=style_large_hgt/1000 * GLOB_SCALE *(100/GLOB_SCALE)

Of course I work in metric so will have to leave you to sort out the Imperial side of things.

The E-014 as has been mentioned means add 14 more decimal places to the number.

i.e almost zero.

I quite often just substitue 0.0 for the entire figure as it is easier to read the script.

It appears often with auto scripted objects but only when the point is close to zero.

Here is a 1000mm radius arc (drawn 90° anti-clockwise) with centre at 0,0

A line joins the ends of the arc (i.e. the segment).

Two more lines are drawn from the origin to the ends of the arc.

ARC2 0, 0, 1, 0, 90

LINE2 0, 0, 1, 0

LINE2 0, 0, 6.123031769112E-017, 1

LINE2 1, 0, 6.123031769112E-017, 1

Archicad has decided that the end of the arc is not quite at zero even though it was drawn snapping to the vertical constraint.

It seems sometimes zero is not always exactly zero.

Barry.

One of the forum moderators.

*Versions 6.5 to 27*

i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10

Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11

i7-10700 @ 2.9Ghz, 32GB ram, GeForce RTX 2060 (6GB), Windows 10

Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 09:21 AM

2009-08-19
09:21 AM

Thanks Barry. I'll give that a try.

Peter, that's an interesting discussion in the link. I will see if decimal feet or inches might have the e's show up in Imperial.

Peter, that's an interesting discussion in the link. I will see if decimal feet or inches might have the e's show up in Imperial.

Erika

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

Architect, Consultant

MacBook Pro Retina, 15-inch Yosemite 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3

Mac OSX 10.11.1

AC5-18

Onuma System

"Implementing Successful Building Information Modeling"

Anonymous

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 12:35 PM

2009-08-19
12:35 PM

Hi Folks,

to Peter,

For Erika's object I used autoscripted code from lines and arcs located at the main origin of the 2d window simply dragged and dropped to the object 2d script.

Actually I did some tests... and it seems that I can see a pattern here...

The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

Could you guys please try to reproduce this?...

to Erika,

IMO... This periods between long numbers seems to occur when a coordinate is pointed with no precision... like an aleatory pick pointing...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...

It would be great if someone from GS could give us some light here...

I seems that we have discovered another giant cavern... Using Djordge's Speleology analogy for ArchiCAD hidden secrets...

to Peter,

For Erika's object I used autoscripted code from lines and arcs located at the main origin of the 2d window simply dragged and dropped to the object 2d script.

Actually I did some tests... and it seems that I can see a pattern here...

The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

Could you guys please try to reproduce this?...

to Erika,

IMO... This periods between long numbers seems to occur when a coordinate is pointed with no precision... like an aleatory pick pointing...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...

It would be great if someone from GS could give us some light here...

I seems that we have discovered another giant cavern... Using Djordge's Speleology analogy for ArchiCAD hidden secrets...

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 01:51 PM

2009-08-19
01:51 PM

Barry wrote:For one explanation of scientific notation, including the use of "E", see:

The E-014 as has been mentioned means add 14 more decimal places to the number.

i.e almost zero.

Scientific Notation

and scroll down to E notation.

David

David Maudlin / Architect

www.davidmaudlin.com

Digital Architecture

AC27 USA • iMac 27" 4.0GHz Quad-core i7 OSX11 | 24 gb ram • MacBook Pro M3 Pro | 36 gb ram OSX14

www.davidmaudlin.com

Digital Architecture

AC27 USA • iMac 27" 4.0GHz Quad-core i7 OSX11 | 24 gb ram • MacBook Pro M3 Pro | 36 gb ram OSX14

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 04:23 PM

2009-08-19
04:23 PM

Hi All,

You figured out quite exactly what's happening. ArchiCAD stores the coordinates of placed elements at the highest available precision but it runs on computers which use a binary representation. So totally round decimal numbers get infinite binaries (which get truncated, of course) and finite binary numbers could produce infinite decimals (which get rounded, too). So 3.5 times 2 almost never equals 7 on computers - it's rather 6.999... or 7.00...00157... for example. If the difference is smaller than the rounding limit, you get 7 and don't notice anything. And as you guessed, computers use the scientific representation for very small and very large numbers. This usually happens for values very close to zero.

Consequence nr.1. When I create a script using AC drawing tools, I like to remove the 'almost zero' values, i.e. 1.34E-14 and its friends.

Consequence nr.2. Never compare real numbers using the equal and not-equal operators but use a small epsylon like the Technical Standards recommends.

Regards,

Zsolt

Braza wrote:Sorry for my being late but in the final production phase of AC13 I'm pretty busy.

...

The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...

It would be great if someone from GS could give us some light here...

You figured out quite exactly what's happening. ArchiCAD stores the coordinates of placed elements at the highest available precision but it runs on computers which use a binary representation. So totally round decimal numbers get infinite binaries (which get truncated, of course) and finite binary numbers could produce infinite decimals (which get rounded, too). So 3.5 times 2 almost never equals 7 on computers - it's rather 6.999... or 7.00...00157... for example. If the difference is smaller than the rounding limit, you get 7 and don't notice anything. And as you guessed, computers use the scientific representation for very small and very large numbers. This usually happens for values very close to zero.

Consequence nr.1. When I create a script using AC drawing tools, I like to remove the 'almost zero' values, i.e. 1.34E-14 and its friends.

Consequence nr.2. Never compare real numbers using the equal and not-equal operators but use a small epsylon like the Technical Standards recommends.

Regards,

Zsolt

Zsolt Táskai

ArchiCAD Development - GDL Team

AC13, AC14 and upwards...

ArchiCAD Development - GDL Team

AC13, AC14 and upwards...

Anonymous

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 06:41 PM

2009-08-19
06:41 PM

Hello David,

Thanks for the link to the Wikipedia article. It is now clear to me

there are two meanings of "e". Big E is scientific notation standing

for exponent and little e standing for the mathematical constant e

an irrational number approximately equal to 2.718. Which is what

was referred to in the GDL manual.

"EXP (x) Returns the xth power of e (e=2.7182818)".

Hello Paulo,

Thank you for your investigations and , as verified by Zsolt, correct analysis.

Thanks to all,

Peter Devlin

Thanks for the link to the Wikipedia article. It is now clear to me

there are two meanings of "e". Big E is scientific notation standing

for exponent and little e standing for the mathematical constant e

an irrational number approximately equal to 2.718. Which is what

was referred to in the GDL manual.

"EXP (x) Returns the xth power of e (e=2.7182818)".

Hello Paulo,

Thank you for your investigations and , as verified by Zsolt, correct analysis.

Thanks to all,

Peter Devlin

Anonymous

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

2009-08-19 08:50 PM

2009-08-19
08:50 PM

Thanks for the clarification Zsolt.

ztaskai wrote:So... Next tasks... Buy some boxes of Champaign and call that cool DJ, right?...

Sorry for my being late but in the final production phase of AC13 I'm pretty busy.

- « Previous
- Next »

- « Previous
- Next »