OOTB Multiple Visibility States - SOLUTION!

[Libbya]

I have done a fair amount of thinking on how to create multiple visibility states without using the broken vis-add-eng LISP and have come up with a workaround solution!  Obviously, doing all the itterations for multiple visbility states is a bit cumbersome, but at least there IS a workaround.  See attached.

[Libbya]

I don't.  Personally, I don't like BACTIONBARMODE=1 for anything other than selecting all objects/parameters without selecting actions.  99.9% of the time I have it =0.

I did write a little lisp routine that uses the command BA to switch BACTIONBARMODE for those rare occasions.  

(defun c:BA
  ( / )
  (if (= (getvar "bactionbarmode") 1)
	(setvar "bactionbarmode" 0)
	(setvar "bactionbarmode" 1))
  (princ)
  )

[jarredmonday]

I've beed working on a couple blocks that someone may find useful. The hardest part was knowing all the available combination.

[Libbya]

Nice blocks although it seems there are still a couple issues with each of them.  The CeilingBoot block does not 'keep' the flip state visibility change when changing box size.  The issue is that the box size lookup changes the visibility state directly rather than changing an input parameter that is used with the bridge double-lookup.  The result is that the bridge and box lookup parameters are fighting over the visibility state.

The Trunk block does not flip the center piece when rotating to the left.  This is because that duct section is not part of the flip01 selection set.  Also, the way it is currently set up if you have added another section to the duct by changing the rotate and then go back to one of the earlier rotate grips, the block will break down.  For example if you rotate the first grip to 90, then when the second rotate appears rotate it to 90 to get another section of tube, then go back to the 1st grip and rotate to 45, the block breaks as you do not have that occurrence on the bridge table and it reverts to CUSTOM.  You can solve this by either hiding the 1st rotate parameter in the later visibility states so you are forced to go to straight on the later grip to have the earlier grip appear or by adding the additional angle values to the table to accommodate the change.  Bear in mind that your input table can be read only and so you can have more than row that has the same lookup property on the right or you can have more than one value for a given parameter on the left although in this case your rotate parameters are lists so they are dropdown single selections.  You could change your rotates to interval and limit the min/max so that you could have multiple values on the left side of the lookup table and reduce the number of rows.

As a final point of advice, you may want to have some parameters not show in properties and the ones that do show you may want to rename so the names make intuitive sense to a user who uses the properties palette for block manipulation.  

[josie.scherrer]

Hey guys,

Long time reader, first time writer. 

I cannot for the life of me figure out why this is not working. When I test out my block I can see my "invisibile" point moving around which is good. But I cannot figure out why this isn't flipping my visibility state. I have the double look up table set up. Did I set something up in correctly?

Help!!!!!

[Libbya]

In order for the bridge lookup to work, the input values must all match a row on the table.  If there is not a row that matches the current values of all of the input properties used then the lookup reverts to the 'unmatched' row.  On insertion, all of the block geometry is placed where it is located within the block iteself.  In your block none of the input points are placed within the block at a location that matches a row on the bridge lookup input table.  Place each of your input properties so that their base Y and base Y match a row on your bridge table and the lookup will start working.  It is also good practice to have the default visibility state match the default row of the bridge table.  The default state is the topmost state listed in the visibility states dialog.  

To get your block working correctly I selected your three input points and then went to propertes and changed their base X and base Y properties to 1.  I then moved the visibility state that matches the row of all 1s to the top of the list.  See attached. 

[josie.scherrer]

I noticed you removed the bridge, How does this work without it?

Because I have a few hundred more visibility states to add, and I want to make sure I'm doing it right.

and that note brings me to my next question....

I am using autocad 2015 and everything I have read so far is that the visibility add engine doesn't work in the version.

Does that sound correct to you? 

[Libbya]

I didn't remove the bridge lookup.  It is probably just not visible for the state that was active in block editor.  If you toggle the 'visibility mode' button you'll see it.    

I have not tried to use vis-add-eng in 2015, but I do not believe it works.  Vis-add-eng is/was a nice lisp but very buggy and fairly difficult to use.  I prefer this method for any blocks that do not require an unmanageable number of visibility states.  It is MUCH easier to edit blocks in the future with this style of multi-vis.  

You could reduce your number of visiblity states a bit by using a flip action for the center weld symbols when there isn't the one opposite.    

[Anonymous]

I have a Weld Symbol that I have exactly the way I want it.  However I need to add the ability of a 2nd Visibility State for Leaders.  On occassion we dont have the luxury of our leaders  to be nice and straight, sometimes we need them to have a bend in the middle to avoid other objects.

Attached is what I have, I just need to get the leaders put into its own Visibility Menu for the option of the drafter to use per conditions.

Currently only the Fillet Weld has the arrowadded.  I can add it to the others once I get he 1 done 🙂

Can anyone help me with this,  Thanks.

[josie.scherrer]

Hey Guys,

I'm so close to completing this block! I am working through some bugs though and could use some help. Because I have ran through all the things I could think to fix.

In particular when my look up tables are set to be 

Flag on

Weld All Around on

Tail Line 2

Weld Bottom Flare bevel

Weld Top None

I can see the dots move when Im flipping through visibilty states. But its like the move on that specific instance isn't triggering the visibility state.

Maybe I've been looking at it too long.

But As far as I can see I have all of my set up values equal to eachother.

theres just a handle full of incidences like the one described above that aren't working. and none of them have similar settings. 

Other than checking the visibility state to make sure geometry is correct, and checking the move and visibility lookup tables, is there anything I can do?

Any input would be greatly appreciated!

And thank you to libbya for helping me get this thing started back in may!

[Libbya]

I'm not exactly what your issue was, but it was some sort of error with the lookup property names (right side) between the two tables.  I turned on the Bridge grip and had it show for all states and could see several states that had separate property column names despite the two names appearing to be the same.  I copied from one table to the other and all was cleared except for the last state.  That would not clear the two names until I changed the names oneach table to something completely different and then changed them back.  After clearing up the name discrepancy, the block works fine.    

[josie.scherrer]

Thank so much for bailing me out again!!!

I spent days looking at it. That was part of the problem.

THANKS FOR YOUR HELP!!!!!

Spoiler

[Anonymous]

Hee,

I've been trying to create a dynamic simulation where i can turn parts on or off without the other one changing. I've been strugging with this cause it seems like my simulation will not change. Can someone help me ? Ill include a simplified version of what im trying to accomplish. 

[ojuris]

hi!

something like this?

[Anonymous]

Exactly like that. =D how did you do that?

[ojuris]

I add point parameter instead of 2 linear parameters

and in double lookup I reordering rows to Lookup Properties rows are equal in both lookup tables

and if You don't want see custom in your selection - one value in lookup must be exactly the same as the parameter value that you attach in lookup table, in your case for example in table Lookup3 you add Distance1 and add values 1 or 2, but real length of Distance1 is 2.04, therefore you have Custom

and why you maked Distance2 chained?

I edit your block version - look attachment

[Libbya]

You simplify it a little more.  I didn't realize it when I originally posted this process, but there is no need for the 'invisible circles' or the move actions.  The input parameters don't actually need to move anything to work.

[Civil3DReminders_com]

This post is mainly for me so when I have to do this again I have a video to look at. Feel free to ignore it, I totally messed up near the beginning on the correct steps. 

https://www.youtube.com/watch?v=AWtZ9jMmLGE

[Libbya]

Nice video.  There are a couple things I would do differently, but the gist is well represented.

[Anonymous]

In examining your WindowDyn example, it appears that you have multiple visibility states--the one at the bottom for Type Lookup plus the ones at the tops of the windows  (e.g., Lookup M 2Pic-2).  I thought you could only have one visibility state.  How did you accomplish this. 

In your previous Multiple Visibility States examples, you had extensive visibility options enumerated.  But in this example, you only have 5 options, yet the top window lookup properties, you have multiple choices that are not in the 5 visibility options (e.g., Off, Top 1/4 - 2 Vert, Two Horiz).  Can you please explain how you do this?

[Libbya]

As I mentioned in the thread, I used visibility-add-eng for that block which required an earlier version of Autocad.  That block has 19 different visibility parameters added along with extensive use of lookups.  The combination makes it one of the most complicated dynamic blocks I have ever seen.  To create that block without visibility-add-eng would have required 27,000 visibility states...