Elevation symbol Background Fill

[Anonymous]

Is there any way to have my Elevation markers have a background fill?

Currenty my slab vectorial hatch(tiles) shows up through the marker, which I find unattractive. I am using the Elevation Marker_NCS.

Having an additionnal masking fill is a waste of time, and not acceptable.

Thanks.

-Nathan Brauer

[Anonymous]

Hi Nathan,

Is there any way to have my Elevation markers have a background fill?

Assume you're working in AC9?
Adding a 2D fill in the marker's 2D script might do the trick

[Anonymous]

I believe the NCS part does have a background fill.

Do you have your fill background pens set to "All Transparent"?

The setting is in Options > Display Options in AC9 and in Options > Preferences > Miscellaneous in 8.1.

[Anonymous]

Matthew and Suzanne,

Thanks for the insights.

I checked the script, and Suzanne you are right. Though I would say it is just poor programming:

IF gs_cont_pen=0 THEN gs_cont_pen=1
add2 gs_markeroffset,0
pen gs_cont_pen

define solid_fill "markerfill"
fill "markerfill"

dist=AC_MarkerSize/1000*glob_scale
mark_rad=AC_MarkerSize/1000*glob_scale*sqr(2)/2


unID=1
hotspot2 0,0,unID : unID=unID+1
hotspot2 0,dist,unID : unID=unID+1

gs_fill_pen=1 : gs_back_pen=91

IF gs_sidefill=1 then
hotspot2 dist,0,unID : unID=unID+1
hotspot2 -dist,0,unID : unID=unID+1
for i=1 to 2
poly2_b 5, 7, gs_cont_pen, gs_cont_pen,
-dist, 0, 1,
-mark_rad, 0, 1,
0, 0, 901,
mark_rad, -45, 4001,
-dist, 0, -1
mul2 -1,1
next i
del 2
ENDIF

poly2_b 5, 7, gs_cont_pen, gs_cont_pen,
0, dist, 1,
mark_rad*sqr(2)/2, mark_rad*sqr(2)/2, 1,
0, 0, 901,
mark_rad, 90, 4001,
0, dist, -1
circle2 0,0,mark_rad

The poly2_b is properly synatexed: n, frame fill, fill pen, FILL BACKGROUND PEN, xys1, xys2...xysn

The blue script defines the proper pens ( in blue, background ground pen: gs_back_pen=91) but the writer of the part didn't bother to use it (red, angry red).

WHO DO I SHOUT AT TO GET GRAPHISOFT TO PROPERLY DEBUG THEIR PARTS?!! I'M NOT PAID TO, AND IT EATS UP MY PRECIOUS TIME.

And besides, I have a bigger problem now that the markers themselves have disappeared to a different dimension. See my cry for help about vanishing markers, which are not mis-layered, or display-optioned off, but have been told to go somewhere to the infinite beyond. Saving the project to 8.1 did not fix it.

-Nathan Brauer

[Anonymous]

Nathan wrote:

gs_fill_pen=1 : gs_back_pen=91

poly2_b 5, 7, gs_cont_pen, gs_cont_pen,
0, dist, 1,
mark_rad*sqr(2)/2, mark_rad*sqr(2)/2, 1,
0, 0, 901,
mark_rad, 90, 4001,
0, dist, -1

The poly2_b is properly synatexed: n, frame fill, fill pen, FILL BACKGROUND PEN, xys1, xys2...xysn

The blue script defines the proper pens ( in blue, background ground pen: gs_back_pen=91) but the writer of the part didn't bother to use it (red, angry red).

The script you clipped here does not include a background mask. The part you have highlighted in red is the pointer. A fill mask would take the generic form:

POLY2_B 2, frame_fill, fill_pen, fill_background_pen,
 0, 0, 901,
 radius, 360, 4001

This creates a circular fill without an outline. If something like this is not in the part then there is no mask.

WHO DO I SHOUT AT TO GET GRAPHISOFT TO PROPERLY DEBUG THEIR PARTS?!! I'M NOT PAID TO, AND IT EATS UP MY PRECIOUS TIME.

And besides, I have a bigger problem now that the markers themselves have disappeared to a different dimension. See my cry for help about vanishing markers, which are not mis-layered, or display-optioned off, but have been told to go somewhere to the infinite beyond. Saving the project to 8.1 did not fix it.

-Nathan Brauer

I agree that Graphisoft needs to take steps to improve the quality of the libraries overall. Both their own and the 3rd party libraries. (I don't think that GS did the NCS parts in-house, but I may be mistaken.) This will require both establishing and publishing better standards for coding and organization, as well as providing better tools and support for the 3rd parties. I am hopeful that we will see some improvement in this area in the near future.

It is great to give people the option to fine tune (or create) library parts to do precisely what they want. It is NOT OK to create a situation where people HAVE to fuss with GDL just to get things to work properly.

[Anonymous]

Matthew wrote:

The script you clipped here does not include a background mask. The part you have highlighted in red is the pointer. A fill mask would take the generic form:

POLY2_B 2, frame_fill, fill_pen, fill_background_pen,
 0, 0, 901,
 radius, 360, 4001

This creates a circular fill without an outline. If something like this is not in the part then there is no mask.

Matthew is correct about the absence of a mask and in pointing out that the part of the script you colored red has nothing to do with the fill in the circle.

But the object's the script sets the fill for closed polygons as a solid fill

define solid_fill "markerfill"
fill "markerfill"

I believe that you would end up with a black background in your marker if you used the poly2_b drawing element. The solid fill will use the fill_pen which is defined as pen 1; there is no background pen. I believe you might want to try:

poly2_a	2, 2, 91,
		0,0,901,
		mark_rad,360,4001

this way you just say "use pen 91 for the fill"

[Anonymous]

Mischief managed. My elevation tags, and all in our office now, will hide what is beyond them.

Thanks to Woody and Matthew.

-Nathan Brauer

PS Forgive my sloppy script reading, Matthew was quite right to point out I quoted the pointer. The lib part had no mask. Why did no tester not notice this before?

[Anonymous]

woodster wrote:

Matthew wrote:


But the object's the script sets the fill for closed polygons as a solid fill

 
define solid_fill "markerfill" 
fill "markerfill" 

poly2_a	2, 2, 91, 
		0,0,901, 
		mark_rad,360,4001 

this way you just say "use pen 91 for the fill"

With the "define" it seems to me that there is a problem in the lib. part's Master script - the definition of that specific "markerfill" is missing or wrong.
Wouldn't it be easier to just rim off those 2 lines and use the

"

poly2_a	2, 2, 91, 
		0,0,901, 
		mark_rad,360,4001" 
 
but instead of the "91" use a param. value ("fill_background_pen" maybe) so that the fill's colour can be changed if needed in the future, or be none by putting the value  of 0.

[Anonymous]

Susanne wrote:
With the "define" it seems to me that there is a problem in the lib. part's Master script - the definition of that specific "markerfill" is missing or wrong.
Wouldn't it be easier to just rim off those 2 lines and use the

"

poly2_a	2, 2, 91,  
		0,0,901,  
		mark_rad,360,4001" 

but instead of the "91" use a param. value ("fill_background_pen" maybe) so that the fill's colour can be changed if needed in the future, or be none by putting the value of 0.

Since the fill definition is used in other parts of the script (arrow) it would not be easier. The fill, solid_fill "markerfill" is called by name rather and defining it in the script means it will always be there. Pen 91 has a history of being used for specific purposes and will most likely never change.