User:Cvoxalury

Thousands of them. Thousands of mad frogs!
-- Outer limits

Source Engine developer.

Author and lead of Dark Interval and a couple other things.

My specialties include singleplayer mapping, art passing, optimisation, soundscapes.

I do programming on Source and would be happy if people find some of it useful.

I release Gamebanana addons from time to time, they range from model edits to prefab mapping and even some mappacks.

Memo to self: future Proposals

• Clean-up and reevaluation of {{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
• Reworking of GoldSrc - in particular its templates {{Branches and Forks}} and {{gldsrc games}}, and Bugs and limitations section
• New template {{Infobox entity}}; same idea as {{Infobox game}} and {{Infobox engine}}. For entity pages to list relevant information without redundancy:
  • Picture
  • Classname
  • Relationship class?
  • Type? (NPC, weapon, etc)
  • Model paths
  • Texture paths, for Source?
  • Convar box (list the most relevant convars and what they do)
  • Potentially put the {{CD}} into the bottom field so it can spread downward at the end?
  • {{Infotable}} exists; however it often states redundant information, sometimes contradicts the page, and it's not in the "family" of "Infobox <thing>".

Documenting VDC Redesign Flaws

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.

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.

The structure

"Multipage"

The use of 'Multipage' makes editing awkward. Trying to edit 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.

• SOLVED. The MultiPage had been replaced across the entire wiki and a new {{LanguageBar}} template replaces both it and the expensive {{uselang}} function. Nescius worked for days on this and finally the pages are much easier to access. Along with that, a few useful updates were done to various related modules, such as previewing string pages translations.

Referenced/nested templates, strings, etc

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.

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.

In another instance, usage of templates doesn't obfuscate editing too much, but pre-template version just looked simpler, easier. Why all the green?

*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.

• RETRACTED. I think template nesting just isn't going to go away at this point. The worst of it which was multipage, was dealt with, and the rest, I suppose, will have to just be written more thoroughly and dealt with excesses on a case by case basis.

Keyvalues and Inputs/Outputs

The KV and IO blocks on every entity page is represented by an enormous pile of templates, nested, looped in each other, and reused everywhere. While it does enforce consistency, a single mistake in one of them will propagate down all the pages that use them (earlier today as I'm typing this, I fixed loose brackets in such a generic KV block as "Studiomodel" - having them affected every single page on entities with model keyvalues).

Not only is it risky like that, and very hard to follow (I spent something like 30 minutes scanning every {{ }} pair to find the error, and didn't start on the template page, I arrived to it eventually, to the root of the problem);

It also means that every page on entities contains a lot of regurgitated repeated info that isn't really relevant to it. So many KV are shared between entities, it's pointless to talk about them most of the time. When we visit these pages, we want to quickly find specifics pertaining to the entity. Instead, it's scrolling time.

• Way to solve: maybe at least order the keyvalues from most specific to least specific. It'd take manual reordering on pages (making generic ones collapsed can help?), and it'd take more work because of the awful nested nature of it all. I'd just go back to simplest lists, but the KV template had been around for longer than this current problem.

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 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 workaround or 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 games

For the most part I think they are fine, the mainline games to be specific. They serve a purpose of specifying the subject clearly, the Source branches, etc. The third-party games can be more of a mixed bag, but that's more about inclusionism which I address further below.

To summarise, they can basically be left alone.

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.

The Third Party tools template has been edited to exclude icons, so I'm collapsing this
With icons: Without icons:

• 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 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 often look excessive. Some - in particular {{path}} - is indeed useful when putting together tutorials, make important information pop up. But I've come across excessive use too. When you make things pop out too much, you made it look like you don't trust the reader to read successfully.

• Way to solve: be moderate when using them. Recognise this isn't about being prettier.

Software template

It's the one that turns every game page (like Portal) into a Steam-looking big box, same is used for mods that aren't on Steam, which is potentially misleading. It is even used for tools which is more bonkers than with games.

It looks awful. The relevant info like categories is pushed down, or into a sub-page above the image, there's huge unnecessary elements like Metacritic score, it's a mess of colours, shapes and slowly-loading content.

I can't grasp the idea behind hiding "For developers" into a sub-page, when this wiki IS a developer's resource.

Pages for games were much more legible and easy when they were plainly laid out like on Wikipedia.

• Way to solve: go back to old style. Stop using this template entirely.
• SOLVED. Through swift and dedicated work of the fellow editors, the template's been deprecated, additional cleanup's being done, and articles are back to their normal readable view. A new infobox for games is being added, collecting the relevant information in a compact, uniform and efficient way.

Fluff

Things like background 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.

• Note: they do look fine when it's pages like chapter overviews, because after all, those do talk about artistic/style side of maps. But they should be JPEGs, and not too prominent (the background template has opacity control).
• Way to solve: do not overuse. Software pages hardly ever need them. Watch out for bandwidth use, too.

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, 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.

• 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 with some tools, which were specifically made for 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 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.