Descriptive names for style classes

[Christiaan]

This would probably be at the top of my annoyances list.

We'd like to be able to use descriptive class names for components of plugin objects, instead of being forced to use "Style-#"

Not only are these numbered styles difficult to use but their existence imposes one of three situations, none of of which are ideal:

1) User refrains from using plugin objects

2) User utilises numbered styles exclusively (i.e. not just for plugin objects)

3) User utilises one style class system for plugin objects and another descriptive style class system for all other objects.

[Christiaan]

And maybe call them "Materials" in the process (or maybe there are some instances when such terminology wouldn't apply?).

[mike m oz]

Or more to the point once you have used several plug-ins with the 'Style-x' pop-up how do you keep track of which ones you have used for what.

Just in terms of user friendliness alone this is an issue which needs to be addressed.

[P Retondo]

Ditto!!!

[bclydeb]

I'd like to hop in on this one too. I am annoyed to have to "work around" by making Style lists for each project on ledger paper. (The kind we used to do bookkeeping with.) Then copying them for each project team member so consistency is achieved. It does do one thing - we tend to brainstorm the style textures and colors to use at the beginning of a project with the obvious advantage that no one accidentally messes up the project Styles.

Named Style assignment would prevent confusion. Period.

Also - an expanded ability to add to the style list and have it show where styles are assigned in the various VW parametrics and features. I too often run out of Styles to assign colors & textures to on a project.

Maybe style naming could do some preassigning for us. Say we start the style name with "Wall-" then add "Clapboard 8-" for the desired texture type and then we could end with "White" and VW would automatically make that texture available under the styles/texture assignments for walls only.

Similarly window and door parts etc. Drop down lists get shorter to wade through and we add another complication to using VW!

[mike m oz]

Please fix this for the next version.

I am sick to death of having to deal with this user unfriendly lazy programming protocol.

Having to write down on a piece of paper what Style-x I have used for what on a project is a royal pain in the arse. Even when I do this I invariably still have problems remembering what I have used for what. Making sure I don't run out of options is a problem as well.

It can't be that difficult to fix once and for all. The payoff in not having to deal with it again, or listen to our complaints about it, surely would make it worthwhile.

[islandmon]

The very logic behind this programmers solution is highly suspect ...

WGR does not recognize that one instance of "Class Style-1" in file #1 may have different attributes than "Class Style-1" in file #2 ...

"Do you wish to replace all instances of this BS with the other BS or do you desire to just forget about using WGR until you get your act together... have a nice day asshole ; ) "

Where did I put that 5 year old Class Styles list from v10 ... ???

[Petri]

I think we all agree that the system stinks. Once upon a time it may have worked to some people with limited requirements.

While the pop-up lists are technically editable (I've posted instructions at least 20 times), with bloatware plug-ins such as Window or Door, with 200 cryptically named parameters - well, it really stinks. (Like fish & house guests do after four days, according to a Russian proverb.)

There is a conceptually manageable and technologically reasonable solution to this, but the way plug-ins were conceived, it can't be applied at present. I've got it all figured out, but since I'm not from India, I don't think NNA is interested in hearing it.