|
|
| (25 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| | __NOTOC__ |
| | {{toc-right|startcollapsed=1}} |
| | {{Background |
| | | file = Idyllic.jpg |
| | | opacity = 0.15 |
| | | gradient-height = 250px |
| | }} |
| | {{clr}} |
| | '''I've decided to leave VDC behind.<br>In my eyes it's too far gone down the uncontrollable template hell spiral, making reading and editing it harder and harder.<br>It's becoming a black box of too-hard-to-follow spaghetti code, and the clean-up attempt started about a year and a half ago, turned into something different.<br>Thank you, those who have made constructive edits over the years, and good luck to future editors.''' |
| | <!-- <div style="float:right"><span style="align:right">{{quote|''Thousands of them. Thousands of mad frogs!''<br>-- Outer limits}}</span></div> --> |
| | <br> |
| | <br> |
| | <br> |
| | <br> |
| | <br> |
| | <br> |
| | |
| Source Engine developer. | | Source Engine developer. |
|
| |
|
| Line 9: |
Line 26: |
| I release [https://gamebanana.com/members/submissions/sublog/2012192 Gamebanana addons] from time to time, they range from model edits to prefab mapping and even some mappacks. | | I release [https://gamebanana.com/members/submissions/sublog/2012192 Gamebanana addons] from time to time, they range from model edits to prefab mapping and even some mappacks. |
|
| |
|
| == Documenting VDC Redesign Flaws == | | == Memo to self: future [[Valve Developer Community:Proposals|Proposals]] == |
| Here I'll attempt to describe what it is exactly that causes friction in my user/editor experience in the new redesign (the 'templatism'), and some ideas of how to fix it.
| | * Clean-up and reevaluation of {{tl2|Source games}} (see the specific pages inside the Warning box) |
| | | * Massive reworking/split of [[Porting GoldSrc content (maps, models, etc.) to Source]] - may be *the* messiest VDC article I've seen so far |
| '''''If you have something to add or think I missed some facet of it, do tell! We may hope to document it and then clearly point out it to anyone who asks why we don't like it.'''''
| | * Reworking of [[GoldSrc]] - in particular its templates {{tl2|Branches and Forks}} and {{tl2|gldsrc games}}, and Bugs and limitations section |
| | | * New template {{code|<nowiki>{{Infobox entity}}</nowiki>}}; same idea as {{tl2|Infobox game}} and {{tl2|Infobox engine}}. For entity pages to list relevant information without redundancy: |
| === The structure ===
| | ** Picture |
| ==== "Multipage" ====
| | ** Classname |
| The use of 'Multipage' makes editing awkward. Trying to edit [[Func_viscluster|a page]] usually puts you in front of a tiny stub of a module, because the real page you meant to edit is a separate sub-version of the page, under a language suffix. I get that this was done to make translation easier. But translating the old way isn't hard to begin with. You can make a separate page with /language at the end, fill in it, link to it, done. It worked.
| | ** Relationship class? |
| | | ** Type? (NPC, weapon, etc) |
| ===== Referenced/nested templates, strings, etc =====
| | ** Model paths |
| Even without multipage concerns, the way most pages have been restructured leaves a lot outside immediate editing. Tabs, panels, disclaimers, forms have been overly packaged into some outside modules that are referenced instead of being described right in the article. Pages become like these grey boxes where on the surface (to a reader) they look like regular content, but trying to edit them puts you amidst coded chaos.
| | ** Texture paths, for Source? |
| | | ** Convar box (list the most relevant convars and what they do) |
| It's like someone wanted to make them all "do once and forget" style. This clashes with the idea of actively documenting and updating information. It is difficult to keep track of template modules and decipher them when you just wanted to insert a damn bit of information. It made me give up numerous times.
| | ** Potentially put the {{tl2|CD}} into the bottom field so it can spread downward at the end? |
| | | ** {{tl2|Infotable}} exists; however it often states redundant information, sometimes contradicts the page, and it's not in the "family" of "Infobox <thing>". |
| *'''Way to solve''': go old-school, really. De-templatise pages. Write about subjects in plain paragraphs using standard wiki tools. Write new pages without them, rewrite existing pages transcribing their text in plainer form. | |
| === The styles ===
| |
| ==== Colours ====
| |
| ===== Colour-coding=====
| |
| Most obvious and easiest to complain about. Templates with tools/games categories look like clown makeup. The colour-coding: it doesn't make it any more useful. It doesn't help keep track of a subject because it's been assigned an arbitrary colour.
| |
| | |
| *'''Way to solve''': very simple. Don't do it. Links all go same colour.
| |
| | |
| ===== Coloured tips/notes/panels =====
| |
| A more complex manner. On one hand I can totally live without them, or the dropshadows, or the rounded corners. On the other, they do make things like [[Template:bug|bugs]] pop out more. I would suggest being more reserved about them, not getting rid of them, but using them when it really makes a difference. A [[Template:workaround|workaround]] or [[Template:todo|todo]] panel already has coloured text (and sometimes icon), it doesn't need a gradient.
| |
| | |
| *'''Way to solve''': be reserved in colour application, make panels more compressed.
| |
| ==== Icons ====
| |
| ===== For software =====
| |
| The ones cluttering category templates. It's too much. They're not needed. They waste bandwidth. They waste screen space. They are distracting. They don't follow some one guideline. Can I say something positive about them? Well, some are nostalgic. But too few.
| |
| | |
| With icons:
| |
| {{sdktools|cat=0|0}}
| |
| | |
| Without icons:
| |
| {{Navbox
| |
| | name = Sdktools
| |
| | title = {{src}} [[:Category:Third Party Tools|<span style="color:lightgrey">{{Sdktools/strings|Header 2}}</span>]] {{Table tools|sdktools}}
| |
| | navbar = off
| |
| | |
| | titlestyle = border-radius: 8px 8px 0 0; white-space: nowrap; font-size: 100%; background-color: {{src|col}}3a; padding: 2px; color: #fff;
| |
| | bodystyle = background-color: #202020; clear: both; border: 2px solid #525252; border-radius: 12px; margin: 1em auto 0em;
| |
| | groupstyle = background-color: #3A3A3A; padding: 2px 10px; width: 1%; white-space: nowrap; font-weight: bold; text-align: right;
| |
| | liststyle = border-left: none;
| |
| | |
| | group1 = {{Sdktools/strings|Mod tools}}
| |
| | list1 = {{duckt|1}} • {{Vide|1}} • {{Xblahmt|1}}
| |
| | list1style = background-color: #252525;
| |
| | |
| | group2 = {{Sdktools/strings|Map editors}}
| |
| | list2 = {{Hammerpp|1}} • {{strata hammer|1}} • {{slamminsrc|1|nt=4}} • {{qtpyhammer|1}} • [[Lambda Level Editor|Lambda]]
| |
| | |
| | group3 = {{Sdktools/strings|Map compilers}}
| |
| | list3 = {{CBSP|1}} • {{CRAD|1}} • {{CVIS|1}} • {{vbsph|1}} • {{slamminsrc|1|nt=0}}
| |
| | list3style = background-color: #252525;
| |
| | |
| | group4 = {{Sdktools/strings|Map compiler frontends}}
| |
| | list4 = {{Vbct|1}} • {{Batchcompiler|1}} • {{Compilepal|1}} • {{Htct|1}}
| |
| | |
| | group5 = {{Sdktools/strings|Map converters}}
| |
| | list5 = {{005|1}} • {{Bspsource|1}} • {{mapfool|1}} • {{vmex|1}}
| |
| | list5style = background-color: #252525;
| |
| | |
| | group6 = {{Sdktools/strings|Map tools}}
| |
| | list6 = {{autobspp|1}} • {{bspentspy|1}} • {{crafty|1}} • '''[[Convexer]]''' • {{ented|1}} • {{entspy|1}} • {{jerc|1}} • {{mapanalist|1}} • {{obfuscator|1}} • {{materialenu|1}} • {{pakrat|1}} • [[Source Compile Analyzer]] • {{tar|1}} • {{Tsha|1}} • {{vgroup|1}} • {{vmfupdater|1}} • {{winbspzip|1}} • {{lumpStich|1}} • {{vPKEdit|1}}
| |
| | |
| | group7 = {{Sdktools/strings|Model compilers}}
| |
| | list7 = {{Crowbar|1}} • {{guistudiomdl|1}} • '''[[NekoMDL]]'''
| |
| | list7style = background-color: #252525;
| |
| | |
| | group8 = {{Sdktools/strings|Model converters}}
| |
| | list8 = {{Crowbar|1}} • [[FireSoft Half-Life MDL Converter]] • [[FireSoft MS3D to SMD converter]] • {{mdldecomp|1}} • {{propper|1}} • {{studiocompiler|1}} • {{vmf2smd|1}}
| |
| | |
| | group9 = {{Sdktools/strings|Model tools}}
| |
| | list9 = {{coat3d|1}} • {{3dmax|1}} • {{Blender|1}} • {{cinema4d|1}} • {{fragm|1}} • {{gmax|1}} • {{Hlmvpp|1}} • {{khed|1}} • {{lightwave|1}} • {{maya|1}} • {{m3d|1}} • {{modo|1}} • {{bsourceops|1}} • {{vsif2vcd|1}} • {{softimgmod|1}} • {{zbrush|1}}
| |
| | list9style = background-color: #252525;
| |
| | |
| | group10 = {{Sdktools/strings|Displacement tools}}
| |
| | list10 = {{dispgen|1}} • {{terragen|1}} • {{twister|1}} • {{worldmac|1}}
| |
| | |
| | group11 = {{Sdktools/strings|Particle converters}}
| |
| | list11 = {{sparc|1}}
| |
| | list11style = background-color: #252525;
| |
| | |
| | group12 = {{Sdktools/strings|Texture converters}}
| |
| | list12 = [[360g]] • [[FixVTF]] • {{no_vtf|3.1}} • {{pbr2source|1}} • [[TGAtoDUDV]] • [[VTF Creator]] • [[VTEX (Source 2)]] • {{vtfver|1}}
| |
| | |
| | group13 = {{Sdktools/strings|Texture tools}}
| |
| | list13 = {{photoshop|1}} • {{gimp|1}} • {{paintdotnet|1}} • {{hl2tex|1}} • {{Materialize|1}} • {{signmaker|1}} • {{wskywriter|1}} • {{srcskineditor|1}} • {{terraingen|1}} • {{vmteditor|1}} • {{vtfcmd|1}} • [[VTF Explorer]] • {{Vtfedit|1}} → {{Vtfeditrld|1}} • {{vtfshell|1}} • [[VTFTool]]
| |
| | list13style = background-color: #252525;
| |
| | |
| | group14 = {{Sdktools/strings|Sound tools}}
| |
| | list14 = [[L4D2 Sound Mod Creator]]
| |
| | |
| | group15 = {{Sdktools/strings|VPK tools}}
| |
| | list15 = {{Crowbar|1}} • {{Gcfscape|1}} • {{gvpkext|1}} • {{VRF|1}} • {{vPKEdit|1}}
| |
| | list15style = background-color: #252525;
| |
| | |
| | group16 = {{Sdktools/strings|Libs}}
| |
| | list16 = [[AVIKit]] • {{hllib|1}} • {{veclib|1}} • {{vtflib|1}} • {{vPKEdit|1}}
| |
| | |
| | group17 = {{Sdktools/strings|Plugins}}
| |
| | list17 = {{3dmaxexport|1}} • {{3dmaxvtf|1}} • {{Blendersrctools|1}} • {{blendervertexlit|1}} • {{mesa|1}} • {{nppvlp|2|nt=0}} • {{pvp|2|nt=0}} • {{sourceio|1}} • {{srcengcolltools|1}} • {{sourcemod|1}} • {{wallwormmtools|1}}
| |
| | list17style = background-color: #252525;
| |
| | |
| | group18 = {{Sdktools/strings|Other}}
| |
| <!-- The very last group of a navbox will need this border radius for the bottom-left corner -->
| |
| | group18style = border-radius: 0 0 0 8px;
| |
| | list18 = {{CCExporter|1}} • {{bee2|1}} • [[CtxConverter]] • {{ccg|1}} • {{Sourceiconset|1}} • [[Source SDK Windows Gadget]] • {{steamcmdui|1}} • {{vguiloct|1}} • [[VirtualDub]]
| |
| }}
| |
| *'''Way to solve''': very simple. Don't do it. | |
| | |
| ===== For page elements (?) =====
| |
| These aren't too frequently encountered, I suspect only one or few editors use them. I am talking about [[VTF (Valve Texture Format)#Files|things like folder icons]] when describing paths, shader icons when inserting a template about shaders, various file type icons, icons that relate to software categories...
| |
| | |
| They reek of cosmetic desperation. Like we don't have anything to add, so we'll sprinkle these around. They don't do anything. They don't guide, they don't effectively codify information on top of what's already implied in the text, they stand out for sake of standing out.
| |
| | |
| *'''Way to solve''': harsh truth, but just get rid of them. Be simple, be efficient. | |
| ==== Fluff ====
| |
| Things [[TeamSpen's Hammer Addons|like]] background [[Materialize|images]]. They simply only do fluff. They don't add to the subject, they hardly are necessary to inform where the user are, if they can't read the title, they are just pngs wasting bandwidth and distracting because pages don't uniformly use them.
| |
| | |
| *'''Way to solve''': do not use, discourage the practice. | |
| === The inclusionism; over-documenting ===
| |
| In addition to the categories being made distracting, they are also very packed nowadays. This comes in several varieties:
| |
| ==== Including third party/proprietary/industry software together with Tools. ====
| |
| I am talking about, for example, including [[Adobe Photoshop]], [[3ds Max]], [[Zbrush|Zbrush]], [[Paint.NET]] in the Third Party tools template. Note how the Ps and Paint.Net have the ugliest infoboxes, ZBrush is a stub, and 3ds Max is the one most direct and functional page.
| |
| | |
| Of course we modders constantly use some or even all of these tools. But they're complete packages which are of course meant for broadest spectrum of things.
| |
| | |
| They shouldn't be taking up category space and mixed in with much smaller, focused, fan-made software. The template in question even already includes items like 3DS Max plugins, VTF plugin for Photoshop - so it's a moot point to include the general information on Photoshop and 3ds Max.
| |
| | |
| To summarise: Third Party tools should be about ''tools that were created for the purposes of modding''. Industry tools that exist outside this scope should not be included.
| |
| | |
| *'''Way to solve''': Because overview information can still be valuable, their general articles can be linked inside those plugin and tutorial articles. On the other hand the general article on Photoshop (3ds max, Blender, etc) can be replaced with a category collecting these specialised pages. (template-less, no need to insert it or make it into a category; it would be linked to in relevant articles and visible in categories listing). | |
| | |
| ==== Including every little tool under the sun on par with well-known, well-documented ones ====
| |
| Every utility someone made on Github can be great but it doesn't mean it should instantly be given template strings and icons. Going through some of them often reveals stub articles or even tools without features. Even if it's not the case, some of these are so highly specific it feels odd to direct users to them through templates? Isn't it more natural to direct them there through pages, through tutorials on working with things? Just a label in a group doesn't explain much.
| |
| {{sdktools|cat=0|0}} | |
| *'''Way to solve''': pose some requirements for what's noteworthy, what's truly useful. Work not from the point of inclusionism, but from the point of being provably deserving of template space. Also, they can be put together in an article like "Other [role] tools" and talked about in their own sections.
| |
| | |
| ==== Including mods and third party games on par with engine branches. ====
| |
| Inclusionism and exposure is great... but to a degree. When searching through categories and templates, it obfuscates the process to see all the niche, barely documented, frankly barely worth mentioning 'branches'. This is also the case [[Gearcraft|with some tools]], which were [[Svencraft|specifically made]] for [[Bspguy|those]] branches.
| |
| | |
| Including mods in the games template is questionable. Just because a mod came out in Steam, and an editor likes it, doesn't necessarily mean it's noteworthy enough for this wiki. Something like Garrys Mod, with its ecosystem and infrastructure of tools and tutorials, without question, should count as a branch. But [[Weapon_smg1#Placement guide|should Entropy Zero]]? If it should, why Obsidian Conflict shouldn't? But I would be making a case against either to be in template categories that are already so full of bigger games.
| |
| | |
| A special case of it is including ''non-Valve, non-Valve-engines'' games like [[Quake]], because they share the lineage. It doesn't matter! There's no point in including or referencing Quake other than in Goldsrc's page about its history! There's no point in referencing Unreal Engine either! It's a different celestial body on its own orbit!
| |
| | |
| To summarise: most people come to look up information on a specific game and there's not that many big ones to choose from. Only the big, clearly noteworthy branches should be listed. They also must be ''playable'' branches or projects, with some releases.
| |
| | |
| *'''Way to solve''': same as with 'every little tool' above. Work not from inclusionism but being worthy of inclusion.
| |
