Jump to content

PCGamingWiki will use a Single Sign On (SSO) system to bridge wiki and forum accounts which is ready for testing. You may login using the 'Login with PCGamingWiki' button on both the wiki and the forum, which will soon be the only option. If you have any issues please message Andytizer on Discord.

ThatOneReaper

Editing guide

Recommended Posts

Should a more PCGW like color be used when taking Windows screenshots?

 

raveEXU.png

 

I tried using the actual color in the logo and it just made everything unreadable. This isn't a great color either but it's probably better than this.

20150405190105%21Desktop_Shortcut_Exampl

Share this post


Link to post
Share on other sites

For Windows screenshots under 8/8.1, use a light blue colour (labeled "Colour 12" in the preset colour list). It retains the colour theme of the wiki, while ensuring high contrast with text.

 

It should look something like this:

 

Windows_8_Compatibility_Mode.png

 

On another note, please provide screenshots in English if possible. It limits their effectiveness with the wiki majority otherwise.

Share this post


Link to post
Share on other sites

Parts of Wikipedia tips to write better pages may apply. In particular tone imo.

 

Albeit, I understand that when 80% of sentences say "copy this", "edit that", "run those" avoiding to use first persons is quite difficult

Share this post


Link to post
Share on other sites

I think the guide is almost ready for a full release. All that is left to do (on my end anyways) is add a general section on how to properly reference in the wiki.

 

Nicereddy (or someone else equally talented) needs to help come up with a custom table of contents solution and some graphics for it (header and an icon for the front page at the bare minimum).

 

Can I get an all clear from the other editors/mods/admins?

Share this post


Link to post
Share on other sites

I'll probably base the landing page off of the Codrops CSS reference. I would personally suggest splitting the page into various different sections for each content section (e.g. Video Settings, Audio Settings, Infobox, Input Settings, System Requirements, etc.) and then offering two means of navigation:

 

* The current full page design, with each separate content section transcluded into the page so they'll always be updated simultaneously.

* Separate pages with a "< Prev"/"Next >" design (I can handle the logistics of that if you'd like)

 

I suggest this primarily because the page is pretty large at the moment, and if someone wants to just see the guide for Video settings, they have to wait for everything to load and then find the section. With a central page like the CSS reference linked above, editors only need to load one small page with a list of the different sections (each linking to their respective guide pages) as well as a link at the top to the "Full Editing Guide" which would essentially just be the current editing guide as it is now.

 

Hopefully that would appease everyone?

Share this post


Link to post
Share on other sites

I'll probably base the landing page off of the Codrops CSS reference. I would personally suggest splitting the page into various different sections for each content section (e.g. Video Settings, Audio Settings, Infobox, Input Settings, System Requirements, etc.) and then offering two means of navigation:

 

* The current full page design, with each separate content section transcluded into the page so they'll always be updated simultaneously.

* Separate pages with a "< Prev"/"Next >" design (I can handle the logistics of that if you'd like)

 

I suggest this primarily because the page is pretty large at the moment, and if someone wants to just see the guide for Video settings, they have to wait for everything to load and then find the section. With a central page like the CSS reference linked above, editors only need to load one small page with a list of the different sections (each linking to their respective guide pages) as well as a link at the top to the "Full Editing Guide" which would essentially just be the current editing guide as it is now.

 

Hopefully that would appease everyone?

The Codrops style is a good place to start off with.

 

Everything else you stated are all great ideas. I'm all for this approach.

 

If we really want to be fancy, we can have headers (and Table of Contents icons) for each section of the guide. But it's ultimately your decision.

Share this post


Link to post
Share on other sites

Please use can not instead. Cannot is more casual, although still acceptable.

"Can not", while the most formal, looks silly in most cases. We're formal up to a point.

 

Use "cannot". All other variations are to be disregarded.

Share this post


Link to post
Share on other sites

I was wondering, now that the Fixboxes will no longer look like absolute ass, which one of these is more optimal?

KkAOud7.png

Something like "replace intro files" in the header

And actual instruction below

Share this post


Link to post
Share on other sites

Something like "replace intro files" in the header

And actual instruction below

You only liked using the second option for fixes and stuff? It's not a bad format, I just didn't use it too often on the current wiki as the fixboxes looked really ugly.

 

I will mostly use that format for very short paragraphs.

Share this post


Link to post
Share on other sites

I will mostly use that format for very short paragraphs.

Very short paragraphs sentences.

Or better a single sentence which consequently means one verb, thus one action.

 

Therefore "Use XXX parameter" is still fine imo, but not download the archive AND extract its contents somewhere.

Also, a hyperlink plus that awfully long path with another different markup is pretty heavy to read, at least for me.

Share this post


Link to post
Share on other sites

Just encountered an issue not covered in the guide. I was adding an availability row for a game's official store, and the link contained equals signs in it, causing that row to be all messed up. After consulting with soeb on the IRC, I discovered the formatting should go like this:

{{Availability/row|1=Official |2=http://www.official/store/url?action=product&id=555 |3=DRM |4=Notes |5=Key }}

As the guide doesn't have this vital bit of information, it should be updated to include it; if it affects other availability row types as well, it should be noted for those rows as well.

Share this post


Link to post
Share on other sites

Just encountered an issue not covered in the guide. I was adding an availability row for a game's official store, and the link contained equals signs in it, causing that row to be all messed up. After consulting with soeb on the IRC, I discovered the formatting should go like this:

{{Availability/row|1=Official |2=http://www.official/store/url?action=product&id=555 |3=DRM |4=Notes |5=Key }}

As the guide doesn't have this vital bit of information, it should be updated to include it; if it affects other availability row types as well, it should be noted for those rows as well.

Thanks for bringing this up. I've added in the alternate syntax details.

Share this post


Link to post
Share on other sites

Just noticed the WIP editing guide lacks any information on the disambig template nor when to use the two forms of the template. Definitely something to add in as it's not mentioned in the old guide and isn't on the editing GUI.

Share this post


Link to post
Share on other sites

Just noticed the WIP editing guide lacks any information on the disambig template nor when to use the two forms of the template. Definitely something to add in as it's not mentioned in the old guide and isn't on the editing GUI.

Speaking of which, Formula 1 and NASCAR games are a very tough case for that template. You have something like 3 or 4 series each about those.

Share this post


Link to post
Share on other sites

Just noticed the WIP editing guide lacks any information on the disambig template nor when to use the two forms of the template. Definitely something to add in as it's not mentioned in the old guide and isn't on the editing GUI.

Thanks for pointing this out. I've added in a basic overview of the tag in the Guide (not much to write on it honestly).

Share this post


Link to post
Share on other sites

Editing

This ensures that in the case of a browser crash, work is not lost.  As I said, I know at least Firefox is quite good at preserving your work even after crashes. Mentioning other good browsers wouldn't be bad
 

References
There's something odd in that statement about forums/blogs sources. It seems so strict. I mean.. even game developers sometimes post in forums, and it's not like you couldn't find good explanations even on reddit.
Though I see what you meant, and I hate stupid claims of magic fixes too.
Could a logical reasoning be the key?
 

Screenshots
If a menu cannot be completely captured in one screenshot and stitching them together is not an option, upload the screenshots of the menu as a "series" You can even do something like this tbh
 

The Fixbox
Before editing, make a backup of the FSW.dll file in case the modifications go wrong. As I said some pages ago: understanding this should be between the basic provisions.

And mentioning this for all the fixes would really overshadow those few cases (which frankly I can't recall) where this is not just about editing a stupid ini file.
Launch the game. Really?
If a fix requires a particular class of program (ex. hex editors), choose a program, provide a download link for it.... I'd rather have a page for said program category rather than having to mention this hundreds of times
And couldn't we just merge "go to <path>" and "open <file>" instructions in something like "open <path></file>" ?
 
What the wiki does not cover
Pornographic games exception smell somewhat brew with good old American dissonance towards nudity and sex.
I mean, use a cat as silencer and nobody bats an eye, put two people on a bed and everybody loses their mind.
Additionally, it's not like we ever cared whether the game was about fighting demons on Mars or zombies in a garden.

Availability template
Games using a digital distribution service (ex. Steam) will have that service act as the DRM Ehrm.. not actually. This is something editor has to find out.

 

Video settings teamplate
Widescreen resolution  It should be said that stretched resolutions do not count
Games with 4K support automatically have widescreen resolution support. Not actually. Technically 4K resolutions don't imply an aspect ratio. Just at least 4000 horizontal pixels.

Possibly I believe you could have games supporting an hypothetic 4000x3000 screen (only 2.5 times 1600x1200), but still not support 16:9
Windowed as last resort ALT+ENTER might be tried

 

Input settings template
Even though technically "Mouse acceleration" is a feature (you have it! be happy!) I believe there should always be a method to disable it. 

A standard example that explains how to properly do so wouldn't hurt.

 

Controller support could be linked to this. And in the it resulted false, shouldn't we always point to "Controller with keyboard-only games" page?

I don't understand Xinput preference for full controller support then

Audio settings template
It's should be mentioned that some games have different behaviors for "Mute on focus lost" when window is minimized rather than just unfocused (when windowed)

 

 

Last but not least.. hadn't we better to put template explanations in Template:name or Template:name/Documentation pages?

Share this post


Link to post
Share on other sites

Editing: Regardless of if a browser has good crash recovery or not, it wouldn't serve any purpose to mention it. Some people will end up relying upon that functionality too heavily, rather than backup changes properly.

 

References: I've added an exception for posts made by development team members or representatives if that helps.

 

Fixboxes:

  • It's always a good idea to mention backing up critical game files before they get modified. Even the best of computer users forget from time to time. I only mention the warning in fixes if the file is a DLL, EXE, or multi-line CFG/INI modification.
  • Yes, we need to add launching the game as a step. A fix covers everything right up to the start of the game.
  • If you want to create a page with a list of recommended programs to use, feel free. I wouldn't have the time to write such a thing up.
  • I keep going to a specific file path and opening a file separate for a reason. The first step ("go to <path>") establishes the context of all future steps in the fix in a clean manner. I might need to do more than just modify a file afterwards. Merging the two will make the steps look "sloppy".​

What the wiki does not cover: Putting in pornographic games on the list is due to good business sense and decency, not "good old American dissonance towards nudity and sex". No console manufacturer or major retail store carries AO-rated games (most porn games fall under this rating) because they are very bad for their image. The same logic goes here.

 

Regardless, porn games are seedy by nature and would cheapen the wiki if we started to allow them. They ultimately have no place here.

 

Finally, I've already stated that the definitions are subjective in nature. Questionable games can be run by the mods/admins if there is confusion.

 

Availability: I'm not dealing with that argument again. Like you said, the editor will need to make that determination.

 

Video settings:

  • The Widescreen and Windowed notes have been added.
  • 4K: That is such a bizarre edge case, even if it is hypothetical. I have yet to encounter a 4K-ready game that does not support widescreen. It stays as is.

Input settings:

  • Trying to come up with methods to disable acceleration for every game is nigh impossible. Not every game have an INI file that can be modified.
  • I've linked the toolkit in the table.
  • If controller support is false, we leave it as is. Adding the notice to every page would look messy. Anyways, the Glossary page already handles that.
  • The XInput preference is because most major controllers and modern games are designed with XInput in mind. I don't want editors to try testing for full controller support with non-standard controllers.

Audio settings: I've added the note.

 

Template documentation: That's not my responsibility. You're better off asking Soeb or Garrett.

 

Anyways, I believe the guide is finished and ready for a full release. I have to start porting it over to the redesigned site at some point this week.

Share this post


Link to post
Share on other sites

Availability: I'm not dealing with that argument again. Like you said, the editor will need to make that determination.

The argument has been over since Witcher 3. What is currently on the page is incorrect, and encourages edit wars. Editors need to cite sources or test for execution DRM if they are going to slap something on an article. Thanks!

 

EDIT: Made less lazy and terse XD.

Share this post


Link to post
Share on other sites

Anyways, I believe the guide is finished and ready for a full release. I have to start porting it over to the redesigned site at some point this week.

 

Redesigned site? What redesigned site? :P

Share this post


Link to post
Share on other sites

Fixboxes:

  • Yes, we need to add launching the game as a step. A fix covers everything right up to the start of the game.
I never added that seeing as it didn't seem like a very logical thing to write, unless the player really has to launch the game to generate some files or stuff.

 

I just find the idea of someone forgetting to play their own game oddly amusing.

Share this post


Link to post
Share on other sites

References: I've added an exception for posts made by development team members or representatives if that helps.

Well... it wasn't just that actually. I was just making an example.

There are lots of really prepared "normal people" out there. First things that come to my mind are this and this

There are many shades between "only trustable authors" and "oh, rebooting the computer worked? Let's write that"

 

Imo, the point should be about being able to explain what's going on and why the workaround works

 

Oh, and it wouldn't be bad if naming references could be taken into account by the guide

 

Fixboxes:

  • It's always a good idea to mention backing up critical game files before they get modified. Even the best of computer users forget from time to time. I only mention the warning in fixes if the file is a DLL, EXE, or multi-line CFG/INI modification.
  • Yes, we need to add launching the game as a step. A fix covers everything right up to the start of the game.
  • If you want to create a page with a list of recommended programs to use, feel free. I wouldn't have the time to write such a thing up.
  • I keep going to a specific file path and opening a file separate for a reason. The first step ("go to <path>") establishes the context of all future steps in the fix in a clean manner. I might need to do more than just modify a file afterwards. Merging the two will make the steps look "sloppy".​

1) Mhh.. Well I guess critical is the right word, you have a point. CFGs and INIs though seem everything but that.

2) Right up to the start of the game, sure (and that's why I guess we should mention, save changes!). But launching said game seems crazily obvious considering you have just fixed a problem and you are supposed to have green light to do your business

3) Neither I :S.... Hey, what about a TODO page for the wiki?

4) Very nice point. Though, I believe there are cases where defining the context is quite redundant.

Also, shouldn't we say "go to configuration files path", to not be too much Windows-centric?

 

​What the wiki does not cover: Putting in pornographic games on the list is due to good business sense and decency, not "good old American dissonance towards nudity and sex". No console manufacturer or major retail store carries AO-rated games (most porn games fall under this rating) because they are very bad for their image. The same logic goes here.

 

Regardless, porn games are seedy by nature and would cheapen the wiki if we started to allow them. They ultimately have no place here.

 

Finally, I've already stated that the definitions are subjective in nature. Questionable games can be run by the mods/admins if there is confusion.

There are also AO-rated games only for violence. But those don't cause such outrage.

That's actually the dissonance I'm talking about.

 

Availability: I'm not dealing with that argument again. Like you said, the editor will need to make that determination.

Granted.

My point was about telling the editor he should indeed check this thing (even with other clients of course)

 

  • 4K: That is such a bizarre edge case, even if it is hypothetical. I have yet to encounter a 4K-ready game that does not support widescreen. It stays as is.

 

Yes, that's really hypothetical (even because I still have to see setups with 3000 vertical pixels.. )

Still, I was just pointing out that the syllogism between 4K and widescreen is incorrect.

 

Input settings:
  • Trying to come up with methods to disable acceleration for every game is nigh impossible. Not every game have an INI file that can be modified.
  • If controller support is false, we leave it as is. Adding the notice to every page would look messy. Anyways, the Glossary page already handles that.

1) Yes, it's impossible. But shouldn't the point of the editing guide be explaining how to handle every case?

Because, I must be sincere, I still have to understand this myself.

2) Yes, but you should always think to the most moronic reader possible.

And.. I really don't think a lot of people arrives to think they may have other options.

Share this post


Link to post
Share on other sites

After nearly a full year working on it, the PCGamingWiki Editing guide is now officially done!

 

It is currently in the process of being ported over to the redesigned site. No further changes to the guide will be made until after the relaunch (excluding spelling/grammar edits).

 

I want to thank everyone that helped contribute to the project. Your input was of great help for me and all future editors that will use the guide.

Share this post


Link to post
Share on other sites

We should think which logical meaning we want to give to

{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
}}
{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
}}

and

{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
{{Fixbox/fix|Description|ref=}}
}}

Something like telling the reader he has more than a single way to fix the issue (1 symptom - 1 problem - more available fixes) or telling him he may try to see if some tips work (1 symptom - more problems - more possible fixes)

Share this post


Link to post
Share on other sites

We should think which logical meaning we want to give to

{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
}}
{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
}}

and

{{Fixbox|1=
{{Fixbox/fix|Description|ref=}}
{{Fixbox/fix|Description|ref=}}
}}

Something like telling the reader he has more than a single way to fix the issue (1 symptom - 1 problem - more available fixes) or telling him he may try to see if some tips work (1 symptom - more problems - more possible fixes)

That's achieved by using multiple fixboxes. (Speaking of which, thanks for reminding me about that page - that giant, unneeded OR was annoying.)

 

More on-point, multiple fixboxes are used for separate solutions to the same problem, with the problem defined by the section header and elaborated on via info point before the fixes. If a fix has multiple, related fixes, they should go into the same fixbox (see my changes for an understanding of what I mean.)

 

Also, and most importantly, you do realize this change won't get done until the new PCGamingWiki skin changes are migrated over to the main site?....

Share this post


Link to post
Share on other sites

That's achieved by using multiple fixboxes. (Speaking of which, thanks for reminding me about that page - that giant, unneeded OR was annoying.)

Yeah annoying... And how do you tell the reader to do things sequentially VS in parallel ?

Because manually patching savegame AND then doing the rest is not the same than running the trainer every time you start the game OR permanently patching files

 

More on-point, multiple fixboxes are used for separate solutions to the same problem, with the problem defined by the section header and elaborated on via info point before the fixes. If a fix has multiple, related fixes, they should go into the same fixbox (see my changes for an understanding of what I mean.)

The section header merely describe what I called the symptom in my previous examples (it's the upper distinction and what should attract the reader attention)

Point info may describe the problem then (I'm not sure if there's space for technical details in the game page itself btw) but it's not like you can't have more than a single distinct problem for any given "symptom" (and indeed, I guess this is why we have detached fixboxes)

Last, any given discrete problem might have more than a single specific fix, thus the need of multiple "fix lines" with instructions and all inside a fixbox.

This is the normal rationale I guess. But you see that this way I have no clear manner to give "separate" alternatives in specific points of the procedure.

 

So I introduced upstream the OR separator.

Also, I noticed that is not actually the procedure I originally written. I hope you see the point there

 

Also, and most importantly, you do realize this change won't get done until the new PCGamingWiki skin changes are migrated over to the main site?....

Do you realize this is only something that affect the logical (as in mental way to organize things) side of writing fixes?

Share this post


Link to post
Share on other sites

Do you realize this is only something that affect the logical (as in mental way to organize things) side of writing fixes?

I do. But as I see you don't realize none of this will be properly discussed or considered until the new editing guide is migrated from the dev site to the main site, I'll just wait until it is.

 

It's a good argument, Mirh - I'm not saying it isn't. It was just brought up too early.

Share this post


Link to post
Share on other sites

Just a quick thing that come to my mind.
 
Open source should be {{++}} a positive point
Free to play should just be {{ii}} info point
 
Makes sense for you?

 

EDIT: another thought: what if DRM restrictions can be chosen? And what if DRM is present at launch but last patch removed it?

Edited by Mirh
I damn hate IPboard and its annoyances

Share this post


Link to post
Share on other sites

When I started following the editing guide creating a new page and saw some inconsistencies between the sample article and editing guide, I saw some differences between the two and made a thread about it in sample article's page.

 

However, I started seeing more differences and inaccuracies between the two, so I thought a forum may be a better place to discuss it.

 

I'm going to list what caught my eye, but I'll also list the things that should be fixed in both of those places, since both of them are for view only:

  • "wikipedia" and "winehq" places are swapped in infobox; it's in different order in sample article's cheat sheet than it is in editing guide
  • "steam appid side" parameter is missing in the sample article's cheat sheet
  • square enix cloud syncying option is missing in save game cloud syncing table in sample article's cheat sheet
  • API and middleware tables are missing in the sample article's cheat sheet, seems it was already mentioned before, but not answered AFAIK. They are in the base article body though and editing guide does not say anything about the tables being optional
  • Sample article's cheat sheet for series pages uses {{SUBST:PAGENAME}} while the editing guide do not use it
  • Sample page's "genre information" links to the now-dead Style Policy page
  • links in "General information" in sample article does not match what the editing guide recommends (i.e. GOG links should be over Steam links). Editing guide does not mention nothing about the point: "If still relevant, state where bugs can be reported."
  • A small discrepancy in availability type, in example GOG.com is written as Gog.com (no uppercase)
  • The "Which is the 'best' version of the game to get?" under availability point is not present or explained in editing guide
  • I'm a bit puzzled about the patches section in essential improvements. Editing guide is really vague about it, only saying to place "Patches (both official and unofficial)", while sample article says [only?] "Include If There is a benefit in using an older patch". For example Brigade E5 is patched to latest 1.13 version on Steam, but my retail version is not. Following what the sample article says, I should not upload a link to patch 1.13? Or should I anyway? I'm confused x.x
  • Intro skip methods section is missing in sample article entirely
  • The order of utilities and modifications is swapped between sample article and editing guide (patches-utilities-mods in sample article vs patches-intro skip-mods-utilities in editing guide)
  • Configuration file(s) location table is missing in sample article body (not cheat sheet), and while we're at it, cheat sheet (and editing guide) says "Save game data location" while body simply "Save game location"
  • Some of the newly added table options are missing the appropriate "See <something>" section and matching headers. While we're at it, should we always use "See <something>" instead of just fill the notes, or only for really long explanations? Nor sample article or editing guide explains it
  • Sample article does not use the new way of treating fan translations for Spanish example
  • Creative Senz3D table features "class="generic-table-notes-cell" colspan="2"|"
  • "Other information" guidelines differ in sample article vs editing guide

P.S. There are other minor differences between the two, especially when it comes to the formatting of missing data in cheat sheet - for example sample page's cheat sheet fills steam id with "000000" while they are blank in editing guide. Those are less of an issue, as they will get replaced anyway and will not reflect the final page's look in any way.

Share this post


Link to post
Share on other sites

When I started following the editing guide creating a new page and saw some inconsistencies between the sample article and editing guide, I saw some differences between the two and made a thread about it in sample article's page.

 

However, I started seeing more differences and inaccuracies between the two, so I thought a forum may be a better place to discuss it.

 

I'm going to list what caught my eye, but I'll also list the things that should be fixed in both of those places, since both of them are for view only:

  • "wikipedia" and "winehq" places are swapped in infobox; it's in different order in sample article's cheat sheet than it is in editing guide
  • "steam appid side" parameter is missing in the sample article's cheat sheet
  • square enix cloud syncying option is missing in save game cloud syncing table in sample article's cheat sheet
  • API and middleware tables are missing in the sample article's cheat sheet, seems it was already mentioned before, but not answered AFAIK. They are in the base article body though and editing guide does not say anything about the tables being optional
  • Sample article's cheat sheet for series pages uses {{SUBST:PAGENAME}} while the editing guide do not use it
  • Sample page's "genre information" links to the now-dead Style Policy page
  • links in "General information" in sample article does not match what the editing guide recommends (i.e. GOG links should be over Steam links). Editing guide does not mention nothing about the point: "If still relevant, state where bugs can be reported."
  • A small discrepancy in availability type, in example GOG.com is written as Gog.com (no uppercase)
  • The "Which is the 'best' version of the game to get?" under availability point is not present or explained in editing guide
  • I'm a bit puzzled about the patches section in essential improvements. Editing guide is really vague about it, only saying to place "Patches (both official and unofficial)", while sample article says [only?] "Include If There is a benefit in using an older patch". For example Brigade E5 is patched to latest 1.13 version on Steam, but my retail version is not. Following what the sample article says, I should not upload a link to patch 1.13? Or should I anyway? I'm confused x.x
  • Intro skip methods section is missing in sample article entirely
  • The order of utilities and modifications is swapped between sample article and editing guide (patches-utilities-mods in sample article vs patches-intro skip-mods-utilities in editing guide)
  • Configuration file(s) location table is missing in sample article body (not cheat sheet), and while we're at it, cheat sheet (and editing guide) says "Save game data location" while body simply "Save game location"
  • Some of the newly added table options are missing the appropriate "See <something>" section and matching headers. While we're at it, should we always use "See <something>" instead of just fill the notes, or only for really long explanations? Nor sample article or editing guide explains it
  • Sample article does not use the new way of treating fan translations for Spanish example
  • Creative Senz3D table features "class="generic-table-notes-cell" colspan="2"|"
  • "Other information" guidelines differ in sample article vs editing guide

P.S. There are other minor differences between the two, especially when it comes to the formatting of missing data in cheat sheet - for example sample page's cheat sheet fills steam id with "000000" while they are blank in editing guide. Those are less of an issue, as they will get replaced anyway and will not reflect the final page's look in any way.

Thank you for taking the time to give us this feedback. When you've edited the wiki for so long, you stop noticing all these small issues, good to have a new pair of eyes on it :)

Share this post


Link to post
Share on other sites

  • Who's Online   0 Members, 0 Anonymous, 103 Guests (See full list)

    There are no registered users currently online

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Forum Statistics

    1,200
    Total Topics
    6,736
    Total Posts
×