Get rid of attribute options in pio's!

[Dieter @ DWorks]

I still don't get why these still exists.

All pio should do the same related to attributes:

Just let us set a class for every type of component in the pio, and let those components take over the settings of the class.

This means:

* Better control over the attributes in your drawing.

* Easier and faster to set

* Easier and faster to develop pio's because a lot of extra code isn't needed anymore.

* Consistency over all pio's and your drawing.

* You force user to use them, Which is really good because I still see lots of poeple that doesn't use them and it's a real shame.

I gave a lesson yesterday about classes, and it really opened a lot of eyes. They said they didn't need them, untill I showed them what they can do with them and how faster it can be.

[VincentCuclair]

... ah, for me, not all PIOs in the same class have similar attribute settings, but need to be in the same class....?

[Dieter @ DWorks]

... ah, for me, not all PIOs in the same class have similar attribute settings, but need to be in the same class....?

There is a difference for the class of the pio and the classes used for their part. The parts uses classes for their attributes. The pio is in a class for grouping.

[Miguel Barrera]

* Easier and faster to develop pio's because a lot of extra code isn't needed anymore.

This one I do not get. Can you elaborate on how it will be easier and faster?

[Dieter @ DWorks]

* Easier and faster to develop pio's because a lot of extra code isn't needed anymore.

This one I do not get. Can you elaborate on how it will be easier and faster?

If you do them both: using a class and using all attributes, you'll see the difference in code that's needed.

[Miguel Barrera]

I do both and to me it is just one line of code; setting each to a class. If desired, the attributes of the parts can be changed from the classes dialog.

[Dieter @ DWorks]

I do both and to me it is just one line of code; setting each to a class. If desired, the attributes of the parts can be changed from the classes dialog.

I think I was not clear enough: There are pio's where you can't even set a class to parts and those pio's let you set each single attribute of some parts and they don't accept by class. That's the problem. I know they are working on it, but they still exist.

[Miguel Barrera]

I understand the limitations of the VW stock pio's, such as windows and doors, but you were also making reference to developing your own pio's.

I do not see such limitation or adding to much extra code when you are programming your own. You, the programmer, set the rules of how your pio will handle the objects classes and attributes.

[Dieter @ DWorks]

I understand the limitations of the VW stock pio's, such as windows and doors, but you were also making reference to developing your own pio's.

I do not see such limitation or adding to much extra code when you are programming your own. You, the programmer, set the rules of how your pio will handle the objects classes and attributes.

By 'developing' I was referencing to NV. They would have less and easier code if they went by only using classes for attribute settings. So this means there is more time to do other things with the pio's and to really finetune them.

[C. Andrew Dunning]

They would have less and easier code if they went by only using classes for attribute settings. So this means there is more time to do other things with the pio's and to really finetune them.

The problem, here (for NVW and for 3rd-party developers) is that, in this regard, we have 2 different types of users: those who don't want to mess with managing PIO sub-parts and who just want to have all of the PIO parts automatically attributed - and those who want to sub-Class everything and have attribute control over those sub-parts. We have to serve both as equally well as possible. From my experience, the challenge isn't in handling thigs one way or the another; it's the having to allow for both ways that takes a bit of effort. It isn't incredibly difficult; but can get quite tedious...

[Miguel Barrera]

I think you can still serve both users. If the pio has colors by class selected in the attributes palette, it can have precedence over the parts, which all will display the pio class colors.

If the pio color by class is not selected, by choosing any other color, then the parts can display the assigned class colors for each one.

[C. Andrew Dunning]

Miquel -

You're quite right.

Just to add to the discussion...:

Using the new 2012 Soft Goods / SoftGoods 2 tool as an example, there are more wrenches to throw in...:

- Textures are applied to all of the PIO parts. Some of those Textures are object-color-dependent; some are not. Some are constant and some are determined by certain choices made in a dialog. We had to decide which, specific, instances would allow for the over-riding of those Textures by-Class.

- Certain colors are very intentionally chosen through a dialog. As with Textures, we had to decide if/when instances would allow for the over-riding of those colors by-Class.

- Some of our users use by-Class settings for the whole PIO instance - and some use by-Class settings for the parts. Without getting into which approach is right/wrong/better/worse, we set out to accommodate either the best we could...and I think users will find that a decent balance was found...