View source for User:Beeswax

<h1>Barnstars</h1>
{| style="background:transparent;"
| [[File:Barnstar-rotating.gif|left]]I award this [[Wikipedia:Wikipedia:Barnstars on Wikipedia|Barnstar]] to Beeswax for donating a ridiculous time on the VDC to make it better.--[[User:MrTwoVideoCards|Gear]] 18:32, 8 Nov 2007 (PST)
|}


== VDC projects ==

; [[:category:QC Commands|QC Commands]]  
: I basically took data from various flat list articles already on VDC, and broke it out into more manageable, categorised pages. I'm not really in a position to add or correct this info substantially, but I have tried to maintain a fairly standard page format. This seems to have been fairly well received by other VDC contributers.

; [[:Category:Source_Base_Entities|Entity FGD Sub-Categories]] 
: Using the Orangebox [[FGD]] files as a reference, I've tried to contribute to the categorisation of Entities by which Game/Mod the hail from. Using a set of template tags, I've populated the [[:Category:Source_Base_Entities]]. Templates allow for more flexible categorisation and are used to "flag" each entity page with its FGD availability. In the long run, this method makes maintenance much easier.

; [[Talk:Entity_Article_Template#Entity_Properties_Table_-_alternative_layout|Entity Properties]] 
: For Entity Properties (Keyvalues, Flags, Inputs etc) I've suggested a [[Talk:Entity_Article_Template#Entity_Properties_Table_-_alternative_layout|table layout]] which IMO is more user-friendly than the current system. It should be easier to read ie. emphasising the importance of placing Entity-specific properties higher up the page, with generic properties (eg targetname) further down the page, and using columns for keyvalues, flags, inputs, outputs so that each property-group is kept together in a table row. It should be easier to maintain because one template can be used per property group instead of the current 4 templates.

; [[Talk:Modeling_props_with_Blender#Re-categorise|Modelling Tutorial Infrastructure]] 
: I've put forward the beginnings of a plan to methodically [[Talk:Modeling_props_with_Blender#Re-categorise|re-structure the modelling tutorials]]. Essentially I suggest separating Tutorials, Tasks and Tooltips, so that a Tutorial can specify "Export SMD" as a link to a specific Task page rather than feeling obliged to explain the why's and wherefore's of SMD exporting inline. The "Export SMD" Task deals with general things you need to know about it in one place, and provides links to App-specific Tooltips (eg "Export SMD in XSI", "Export SMD in 3DS", etc.). The aim is - again - to use wiki structuring to avoid unnecessary repetition of information which is often distracting and difficult to maintain centrally.

; [[:category:Glossary|Glossary]]  
: The Glossary is very important to ensure the writer and reader understand what a specific term means in the VDC context. In software documentation most terms do have very specific meanings. I keep trying to clarify these wherever possible, with special attention to "high-level" concepts which are too often used loosely and inaccurately.

; Level-Design Resources
: I'm interested in creating better documentation for the various Models, Materials and Textures provided in Valve GCFs. I'm thinking along the lines of categorising by :
:* GCF Availability:  HL2 / Lostcoast / EP1 / EP2 / DOD / CSS / Portal / Ship / etc
:* Budget: polycount, renderpixels, etc (?)
:* Filetype: Model (mdl) / Material (vmt) / Texture (vtf)
:* Setting: (eg) Sewers / Tenements / Coastline / Streets / etc - or might be easier to simply flag which Valve maps they are used in/designed for!
:* etc
:... but it seems like an impossibly huge task ... I got as far as making a spreadsheet of HL2, Lostcoast, EP1 and EP2 Models : over 3000 reference.mdls !