Talk:Prop data

QC: $keyvalues prop_data vs $surfaceprop

I'm a bit confused about when to use $surfaceprop QC command rather than the $keyvalue{prop_data ... QC command.

My propdata.txt includes the warning " // DON'T USE THIS FOR A PROP. USE THE NON.BASE ONES. " for each and every base class ...

Please could someone explain ?--Beeswax 08:11, 30 Mar 2008 (PDT)

Hmm, that's a good question. While both of them theoretically determine physics simulation, I think you'll find that prop_data provides models with additional and overriding information. Why not experiment? --TomEdwards 02:50, 31 Mar 2008 (PDT)

I figured it out by reading the propdata.txt when I wasn't so tired ;) The warning DON'T USE THIS FOR A PROP. USE THE NON.BASE ONES. applies only to the base base class.BASE, eg Metal, as opp the NON.BASE ones such Metal.Small, Metal.Large, etc. --Beeswax 08:56, 1 Apr 2008 (PDT)

As far as I can see, prop_data is used almost exclusively for prop_physics models' special attributes, whereas $surfaceprop is used for anything and everything. As far as I can see, prop_data will not override $surfaceprop or vice versa because the don't seem to define the object properties.--Beeswax 08:56, 1 Apr 2008 (PDT)

Article Structure & layout

Please do not edit or delete what you do not understand. Use the discussion page instead. --Beeswax 08:56, 1 Apr 2008 (PDT)

1. Please Do not DELETE statements made by other VDC wiki users. The function of a wiki is to collate information from multiple users. By all means clarify the wording or integrate it into a better context, but don't just delete it because it does not interest you. Someone had reason enough to bother putting it there in the first place. (Beeswax)

2. If you are absolutely certain something is incorrect either raise the issue on the discussion page (using a reference link to your point from the appropriate part of the main article) or correct the article and draw attention to it in the edit summary or discussion page - and be prepared to justify your decision. If you have doubts or reservations about the accuracy of a statement by another user - voice then on the discussion page.(Beeswax)

QC syntax examples

1. Precise titles, like QC syntax example, are more useful than bland titles like Simple Example.(Beeswax)
2. Key value syntax: By including "quotes" around value strings (even when not strictly necessary for correct code-interpretation) readers can easily see what is a Key and what is a Value. (Beeswax)

   Using quote marks in articles achieves that, but also encourages readers to type them in their own code - which as you realise is usually unnecessary, and as I expect you probably release always irritating. ;-) I prefer to use presentation for distinction: either bold key normal value, or using tab characters to align everything into columns. Preferably both. --TomEdwards 10:55, 1 Apr 2008 (PDT)

3. //Comments: Code examples should generally be kept clear of //comments which distract from the active code.(Beeswax)

   I think we can trust readers to differentiate between the code and comment, especially if the comment is italicised. When and if any issues of distraction are overcome, inline comments explaining each line of code in turn and in the same visual space are undeniably superior teaching tools to a chunk of text beneath. --TomEdwards 10:55, 1 Apr 2008 (PDT)