Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bbbbbbbbba

Pages: [1] 2 3
1
Hmm... I think just your presence would help us a lot. Maybe just hang out in our discord, explaining things you are familiar with if someone asks. Maybe look up the relevant glitches here when you are working on a route, noting if there is something missing, incorrect, or difficult to read. (If you don't want to fix something yourself, you can just inform us. I'm sure if you bug us enough, some of us would do it. ;D)

I am not really familiar with the speedrunning community, so I'm not sure about my suggestions. (I've tried to join the Pokémon speedrunning discord, but I left when the server asked me which game I ran. Obviously I didn't run any, and I took that as an evidence of the speedrunning community being unfriendly towards non-runners. I was probably thinking too much...)
2
Generation I Glitch Discussion / Re: The aftereffects of Glitch Trainer 0xFD
« on: September 14, 2019, 03:10:59 am »
I think I've found out the culprit. After a battle, the game copies the enemy trainer's name in a weird way (disassembly). According to this table, the 0xFD trainer's name should come from $9481, which is in the VRAM. Since this copy is until a 0x50 terminator, mass corruption happens.

Edit: I think I've found out why the game does this, too. In the Japanese version, some trainer names actually have an abbreviated version that is used as dialog tags (video). Presumably the entries in TrainerNamePointers that aren't wTrainerName were originally those abbreviations in the Japanese version.
3
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this:
Code: [Select]
; string: species name
; height in feet, inches
; weight in pounds
; text entry

RhydonDexEntry:
db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data.

Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional.

Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible.

For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 ...". I guess old crashes don't die that easily.

Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is... here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine!

Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.



It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway... why don't you set a breakpoint at 10:435E and see for yourself?
4
On the categorization problem, I think maybe the best solution is still to revive the "natural glitch" category. The thing is, in theory any glitch could be reached by only following "consequence" links starting from natural glitches (except cheating/ACE only glitches, which can have their own category). For giving newcomers a tour of the site, they are as good a category as any. And they have a rather well-defined boundary, which, in my opinion, is important for a categorization system to work, especially if we don't want it to be maintained by a single person.

One problem with natural glitches I see is that there are still too many of them, especially for Generation I (see list of natural glitches in Generation I). It might still be necessary to have a notion of "major glitches" based on their perceived usefulness/destructiveness. I currently don't have a satisfactory idea, but I hope we can come up with a definition that, while probably not completely clear-cut, is at least objective and logical, so that people can argue for a page's inclusion or exclusion.

If the "major glitch" category turns out to be too broad in the other direction (ACE programs tend to be useful, after all), we can always focus just on natural major glitches (of course, necessary precursors of major glitches would all be major glitches). I don't want to argue that something like item underflow is not major, but they don't need to be exposed through a "public-facing" category.

About the definition of "major glitches", we can open another thread if people feel it's worth it.



Another idea: Maybe we can have a "glitch infobox" template, similar to our Template:ItemInfoGenI or Bulbapedia's Template:Pokémon Infobox, and put there some basic information like affected version(s), variations, consequences, precursors (for non-natural glitches), etc. It can serve the dual purpose of helping people decide if they are interested enough to read the text, and facilitating navigation. It can also contain a good screenshot (gif if necessary) that showcases the glitch, which would be nice too.
5
Actually, I'm thinking that "meta-map script activation" should be a general name for a class of exploits, just like "arbitrary code execution". The specific exploit --- using trainer escape to get to meta-map script ID 4 --- should have a more specific name. Where is the mastermind behind "Glitzer Popping"? :P



I am also seeing how it might be difficult to differentiate between variations and consequences, as this specific case of meta-map script activation may be regarded as either a variation or a consequence of text box ID matching. I would tend to say it is a variation, because after seeing the glitched Trainer text box, the player does not need to do anything else special to achieve invalid meta-map script activation.

I think a clear-cut case of variations would be the 2x2 block encounter glitches. The left-facing shore tile glitch is one of its variations, and all of the applications mentioned on the left-facing shore tile glitch page are sub-variations. To trigger them all, the player ultimately does the same thing, although with different setups.

If we draw a box diagrams of glitches, then variations would be boxes within a box, and consequences would be indicated by arrows pointing from one box to others.
6
Fair ;D Honestly I'm not sure. First dividing by something like "technical information, procedures, and results" would help everyone to find what they need most in one place, but it also seems like it would put too much content out of context. If you think first dividing by sub-glitches would be better, then let's try that first.

Actually, I think it would be also important to clarify the relations of the "sub-glitches", seeing as they are neither all parallel or all sequential. Maybe "sub-glitch" is not a good word to use, and they should be divided into varations (different ways to do the same thing) and consequences (non-natural glitches enabled by the "main glitch"). The thing is, the whole "special stat encounter" part is a consequence of the actual trainer escape (I actually feel that the section name "initial steps of the glitch" might be difficult to process), but they are so closely related that it makes no sense to separate them into two pages. Also, part of the "special stat encounter" is actually "escaping the trainer-escape state" ;) I don't know if that part deserves its own section too.
7
I'll use the Trainer escape glitch page as an example for a handful of things again. For a glitch scientist, there are technical explanation sections. They don't take up much of the page, but they can easily be clicked to and there's not a whole lot to say on that front anyway. The glitch artist is plenty satisfied for obvious reasons. The glitch technologist can click directly to any section labeled "method" or "procedure". A possible solution in the case of this page, if the clash is significantly perceived, would be to reorder the sections. (There are other issues with it--for instance, the phrase "for some reason" should never appear for any reason--but those are sidenotes for now.)

There is another piece of technical explanation that cannot be seen from the table of contents. In the "Special stat encounter" section, anything related to $CD60 and $D730 are technical explanations. They are intermingled with descriptions of methods, possibly making the tasks of both the scientist and the technologist harder.

The section "Textbox ID matching" also contains some technical explanation, and it really needs to be expanded a little, but I feel that it would just get in the way of non-scientists. Same for "Encountering Trainers" and "Trade NPC Pokémon and resulting Pokémon". Similar for "Getting Pokémon at level 100 with this trick", "Going up and down the stairs infinitely", "Removing Snorlax", "Glitch meta-map script activation", although those all have their own pages --- then again, one cannot see this from the table of contents.

The technologist is probably also confused because there are a bunch of procedures, like three that claims to be "initial steps of the glitch", one with screenshots that goes from the start to the end (although it seems to assume that its readers already know how to do the actual Trainer-Fly input, as this most important part only gets one screenshot, after the whole thing is done), another that refers to both "initial steps of the glitch" and "Special stat encounter" ("wait, there are a bunch of methods there?"), and so on.



Edit: I guess in any case, reordering the sections will surely improve the page's navigability, and also give us a better insight whether collapsibles would help further. This page is special in that it kind of already have "scientist's procedures" (the descriptions in "initial steps" and "special stat encounter" are pretty general) and "technologist's procedures" (like "Mew trick" and "Level 100 Pokémon before Brock"). The question is how to organize those contents to make them easy to find for their respective target audience.

I am surprised that you seem to think this page is an example of good organization. It does have a lot of good information like I mentioned above, but I've always felt that it is an organizational mess.
8
EDIT: On a quick editing spree at the moment, but don't take that as an indicator of me being ready to process things in depth. :P

I have been also been doing many wiki edits, but don't take that as an indicator of me having enough energy to keep this discussion alive. I know what I should do is to clean up the Trainer escape glitch page to have an example on how to use collapsibles, but that in itself is a huge task...
9
Incidentally, I'll mention that one consequence of different people enjoying different parts of a page is that the "don't link a term more than once" policy is not necessarily appropriate. We can refer to Bulbapedia's manual of style:

Quote
Also, only link to an article once within a given portion of text; if you say "Ash" more than once in a paragraph, only link it the first time. Instances further apart may be linked to more than once, it is up to you how far apart to place repeated links. For consistency, if most elements of a list are links, then link to an article as many times as needed in that list.
10
Not a big fan of hard-stuffing "core" content into click-to-expand blocks (but I find reasonable the Wikipedia/Bulbapedia system of folding each ==h2 heading== section into its own collapsible element on mobile themes);
Ideally the content folded away would not be "core" (although I'm not sure what you actually mean with this term), but just some details that are considered important by at least one type of glitcher.

The way I see it, collapsible sections serve the same function as a table of content. It can be a fine system if there is a way to design the sections so that everyone can find what they need by section headings. I think that might be difficult (see below).

Incidentally, there is another kind of collapsible element: the "note"s of TVTropes that expand in-line (example; search for "note"). They may be more convenient depending on the exact circumstances, so it would be nice if we can implement those, too.

I don't see how the "different personalities" in your example would be conflicting - surely there can be sections for a beginner-friendly explaination, one for a technical one*, an "academical" use, and examples of results/applications - plus of course* notes on the discovery, historical use, etc?
(The ones marked * are my personal interests, by the way :) )
The problem, as I see it, is that each personality wants an entire narrative, not just a section. For example, not only do we need a "beginner-friendly explanation", we also need a "beginner-friendly procedure" (that is not described in technical terms) to go for it. Burying all those sections in a lot of technical stuff is not beginner-friendly. It may be better if we keep those sections consecutive, but at that point, we might as well have several different pages.

Splitting every glitch page into several different pages is actually something I've seriously considered. Like how Wikipedia has "Introduction to ..." pages, or how TVTropes has "Funny", "Heartwarming", "NightmareFuel", "TearJerker" subpages for works, this might be a viable approach to solve the problem of too much information (also known as TMI). Ultimately I didn't propose it because it seems like even more work than collapsibles across the board.

An example could be an hypothetical edit of the old man glitch to remove duplication of the information found at "Left-facing shore tile glitch", splitting off the "traditional Missingno glitch" to a separate article (with historical notes, but referring to the two glitches it combines for further information), while providing a link to this new page as application examples?
That is not just a hypothetical (potential) edit! Now that you brought it up, the page seems super messed up. This seems more like a case of stuffing all "beginner-friendly" related information into one page, even though they don't really belong, because how is a beginner supposed to know which link to click?

Kudos for bringing up a concrete example, though. I have avoided examples because I think the potential use cases of collapsibles would be many, and I don't think I can list them all, but a concrete example can surely help evaluating the proposal better. Maybe I will try it on Trainer escape glitch and see how it goes.

(And maybe you can also bring up or create an example of a page where all the "sections for a beginner-friendly explanation, one for a technical one*, an 'academical' use, and examples of results/applications - plus of course* notes on the discovery, historical use" coexists in harmony. I cannot think of such an example, but that doesn't mean they don't exist.)

As for hexadecimal style, could it be possible to have some markup/template around a number that the server would process into an user-selectable style, like with dates? (My personal choice would be "nothing at all if it's obvious from context, like having letters in it or being in an appropriate table column, anything goes if it needs to be called out")

I believe that should be possible (not a MediaWiki person though), but that might be slightly more work than fixing everything according to a single guideline, and would be more confusing to new contributors, too.

The "obvious from context" point can be a little subtle (what is 8F? :P), but I agree that in certain environments, like table columns and maybe long byte strings, a marker is not necessary.

Quote
Although I am faced with a technical problem right now: It seems that the items on the Glossary page are not anchored (i.e. a "[[#count byte|count byte]]" would not jump to the corresponding item), and I would have to do it manually like this or this. Is there a better way, or is there an advantage in using explicit anchors for every term that I'm not seeing?
I don't have an answer about the cause, but I think the automatic heading-to-anchor system of mediawiki is problematic - it unsurprisingly breaks down when a title is edited, it fails when a title is repeated multiple times (as seen in our "text errors" page), ... so I'd say that you can't go wrong by doing it manually :)
You can go wrong by, for example, spelling the anchor incorrectly! Or worse, overwriting another anchor because you copied the entire thing and forgot to change the anchor. When a title is edited, you always have the option of keeping the old anchor (by explicitly adding one if the default is implicit), but in my opinion that is not a good state to be in anyway. My suggestion would be only to link to titles that are unlikely to change, which terms in the glossary are.

Maybe from a practical viewpoint, explicit anchors cause less headache in the long run (discounting the fact that having to type every term twice is already a headache). But I hate code duplication with passion!
11
Kinda like the one at the bottom of this page, maybe?
Yes, that's exactly what I mean.

I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.
Can you elaborate on what you mean by a "dashboard"?

Tree Folder Structure
Oh. I think whether this works will depend on the solution to the categorization problem; for example, I suspect it might not work well with a multi-aspect categorization system.

I probably should first give my own input on the categorization system, then. I realize that my proposal last time is probably too complex to implement. So this is my attempt to capture the "scientist" perspective in a simple and clear way:
  • Pages with explanations.
    • Pages with incomplete explanations.
  • Pages that need an explanation (AKA: explanation_request).
  • Pages that don't need an explanation. (Those can be just left out of this classification system; I just want to emphasize that those page exists, in no small volume, and that is a healthy thing because glitchology is not just for scientists.)

Incidentally, I am thinking about adding a glossary page, for some recurring concepts that may not be intuitive for the average player, like "0-based", "jump table", "save clear", etc. Those concepts are exactly what would be "not interesting enough" for an individual page, but would benefit from having a brief description to link to, instead of having to either be explained in-line or left unexplained.

Edit: I got the glossary page started. Everyone is welcome to edit that page (as is any other page under my user page, which I clarified on my user page just now). Although I am faced with a technical problem right now: It seems that the items on the Glossary page are not anchored (i.e. a "[[#count byte|count byte]]" would not jump to the corresponding item), and I would have to do it manually like this or this. Is there a better way, or is there an advantage in using explicit anchors for every term that I'm not seeing?
12
I also think having a dashboard with colapsable folders sounds like a very nice idea, it would be good so a person has a good concept which category a page is part of and what other pages are on the same level.
Can you elaborate on what you mean by a "dashboard"? Do you mean just like what is going on with the "major glitches" template (go to a page using that template to see it in action)? That could be nice if it is used on every page, but as of now, I think it may have too low a visibility.

(Honestly speaking, the "major glitches" template is currently a little of a mess, with some pages it links to (in the "'Core' glitch" column) not linking to it, but that's mainly because of an inherent problem with the category "major glitch": While many ways of categorizing a glitch is subjective, the definition of "major glitch" turns the subjectivity up to eleven. It can even be self-fulfilling because of the "well-known" clause.)

Actually, I have considered adding (multiple) navigation bars to every page, just like what is going on at the bottom of any random TVTropes page. Of course the order would have to be arbitrary (e.g. alphabetical order), but the point is just to give the reader a "tour" through pages in the same category. It would be more eye-catching than the collapsed "major glitches" template because it would have two page names to pique interest.

Collapsible folders sound good!

I haven't read all of this properly yet sorry, but regarding the scope of the wiki, I relate with that how we cover not just glitches, but also data, terms, unused content, recently a little speedrunning content. If it was focused on just glitches/data with terms etc. in like an appendix page then I suppose that would organise the wiki better as most pages would be examples of glitches with a method or the database pages. At the same time (though no one has said it), it feels a shame to let them go, and it's a double-edged sword as you said.

The style has a lot of inconsistency yeah. A lot of it is my fault. Sometimes while perfection is overrated, it would be good to have a style convention not just for the Dex articles, so that most instances of hex: hex 0x $ etc. are kept under one notation.

I agree with cutting down on very similar pages and merging them (ItemDexES/RB:094 and ItemDex/RB:094), though otherwise disagree personally with "interesting" as it's subjective and there are various small but unique glitches (e.g. https://glitchcity.info/wiki/Ragon_Pok%C3%A9dex_entry ). However, these could be merged somewhere as well (like Bulbapedia's 'list of glitches in Generation I', we have list of natural glitches, and Ragon could be under a list in a different article list for non-natural glitches (I'm unsure though, I don't know how we would organise everything together?))  and we could set some criteria of which glitches get their own article) and we've had a pattern of keeping articles for very small glitches without any (known) additional uses (e.g. https://glitchcity.info/wiki/Stand_on_a_tree ), while Bulbapedia would just include them on a list of glitches page. However, some of Bulbapedia's list of glitches pages are quite long as well.


Actually, I suppose MediaWiki has multiple ways to separate "primary" content and "secondary" content, such as subpages and namespaces. I haven't studied those mechanisms in detail, but I think it's likely that there exists a good way to move the "secondary" contents out of the way without actually letting them go. (Although it might be necessary to let them fall behind for a while, when we first sort out the organization for our "Project Glitch").

I agree that "interesting" is very subjective. There is another criteria that is still subjective, but maybe less so: On a page level (i.e. not considering the navigation problem), do we lose anything by merging those pages? Or maybe in contrary, we gain something by presenting the contents together? I strongly believe that ItemDexES/RB:094 and ItemDex/RB:094 are the latter case (we gain something by emphasizing the fact that international versions are generally similar to each other, including in terms of memory layouts, etc.).
13
Wiki Discussion / Organization discussion thread (everyone please weigh in)
« on: September 02, 2019, 02:10:33 am »
TL;DR
The wiki needs better organization, and we need as much input as possible (especially "oldbies" who are more familiar with the site). Any form of discussion (reply, Discord, PM, wiki talk pages, etc.) is welcome. Below, I have outlined the main problem I see with the wiki (disagreement between "scientists", "artists", "technologists", and maybe "historians"), and I want your input on how we might solve this problem, or why this might not be a problem.

I have also proposed some solutions of my own, in the section titled "Proposals" (with four subsections, although now I think about it, only the first subsection is a direct answer to my own problem, and the other three are just organization ideas in general...), so if you want to see concrete proposals (instead of some abstract analysis), feel free to skip ahead.



Introduction
After a long PM thread with Sherkel, I decided to make this public in the form of a forum thread. We both agree that the wiki is currently lacking in proper organization, a discussion is needed to decide what we should do to fix that, and that discussion should involve as many people as possible. Lack of organization is a serious problem, as it frustrates users and (potential) contributors alike. A new user --- indeed, probably any single user --- is powerless to fix a systematic problem, and that is why we need a public discussion, in order to come up with something most people would agree with.

One of the reasons that deterred me from doing this earlier is that I am not very comfortable with the GCL forum. Maybe the UI is not as friendly as could be, and maybe it is just me. But I suppose I might not be the only one who don't want to post on the forum for one reason or another. If you have anything to say, I encourage you to join the discussion in whatever form you are comfortable with. Ping me on the GCL Discord (I am suggesting a new channel for wiki discussion, but until then, #glitch-general should do), private message me, edit my user talk page, or any other talk page if appropriate.

The problem with being a "catch-all" site
As Sherkel has said in a PM, GCL "has always been a 'catch all' for all forms of glitchology, much as Bulbapedia is to Pokémon." I think this is an ambitious goal. This approach surely has its advantage: We don't exactly have a large user base, so we want to retain as much of it as possible. However, I believe this approach also has an apparent problem. To quote myself:
Quote from: bbbbbbbbba
The way I see it, there are at least three, maybe four, approaches to Pokémon glitching: as a science, as an art, as a technology, and maybe as a history. (In case you didn't notice, I'm firmly in the "science" camp.) Those approaches pull the site in different directions.
(To be clear, Sherkel's statement above is in response to my statement above, instead of vice versa.)

This is another reason why we want to hear as many different voices as possible!

This clash might show on multiple levels. I have analyzed this on the individual page level, specifically regarding the glitch pages (pages that document individual glitches) because I believe that is the most important component for a glitch site.
Quote from: bbbbbbbbba
I think the first thing should be to figure out what we want our "Project Glitch" pages (pages that document individual glitches) to look like. And here we can already feel the tension. Even though everyone would agree that a glitch page needs an introduction, a procedure, and a result:
  • The glitch scientist wants the procedure to be as general as possible, covering all the examples and exceptions to our best knowledge. There should usually be an explanation section --- or explanations should accompany each step of the procedure, in the case of particularly complex glitches. If the desire for generality means that the result could only be stated in technical terms, so be it.
  • The glitch artist wants to document all the cool results observed. That sometimes means documenting a lot of slightly different procedures individually. It doesn't matter if the results cannot be reproduced --- it might be preferable if they cannot be reproduced.
  • The glitch technologist wants it to be as easy as possible to use the glitch. That means concrete and detailed procedures that even a newbie can follow, preferably also optimized for simplicity (a 5-Pokémon setup should obsolete a 20-Pokémon one). Useful results are prioritized.
(My portrayal of the latter two attitudes are not necessarily accurate.)

My point is that those goals clash with each other on how to write the procedure and the result. It would be one thing, e.g., if I only wanted a separate section for explanation. But in an article describing a glitch, all the sections are related to the others. It's not like Bulbapedia Pokémon pages, where the "game data" section could be completed without even knowing what the rest of the page is going to look like.

And so this is a puzzle that needs to be solved.
Quote from: bbbbbbbbba
To put it another way, the clash is between concrete and optimized procedure / general all-encompassing procedure / all the individual procedures.
(I.e. it's not simply that technologists want procedures, scientists want explanations, and artists want results.)

Proposals
Collapsibles ("folders")
The reason I wrote about the "clash" is because I felt it. There are long stretches of contents on the wiki that I don't want to see. Conversely, when I write about technical details, I often worry that they are long stretches of contents that other users might not want to see. Those long stretches of unwanted contents disrupt the flow of reading.

Maybe the problem can be solved by hiding them away, but only one click away. A link to another page can do that, but some things don't warrant creating a separate page, and having to click links is disruptive in its own way. I think collapsibles ("folders") is a better way of doing the same.

Collapsibles are boxes you can "expand" and "collapse". Template:Major glitches is an example. Apparently, they are a MediaWiki feature, but the wiki code for them is kind of difficult to understand. To make collapsibles something everyone can use, we need to make a template for them.

After we have the template, we need to begin editing existing pages to include them. This would sets up examples on how to use them, so that new contributors might be able to finish the job, and new pages would be able to catch on. Trainer escape glitch might be a good first page to try. It is a complex glitch with many moving parts, and as a result many sections that might benefit from being collapsible.

Templates
Wiki templates are great. They make what would have been a complex mess of HTML code (or just a lot of text) easy to use, and easy to maintain, too. I believe if we use them correctly, they can make the wiki more friendly to new contributors, which is exactly what we want.

I'm not familiar with the MediaWiki framework, so I don't really know what can be templated. I do feel that it is difficult to make a table that looks good (like The Big HEX List), so if a template can help with that, that would be awesome. There might be things I am forgetting for now...

Edit: Let me just begin listing things I might want.
  • "PK" and "MN" symbols that render like how they look in-game, and copy as something relatively unambiguous (e.g. "<PK>").
  • A "glitch infobox" template.
  • The existing YouTube template should allow an optional parameter for a timestamp. Furthermore, the visibility of that template could be improved (it can be difficult to see a small strip of text centered in a page, especially when it is the only thing in a section).

But more importantly, to make templates really work, we need to advertise them. I believe the MediaWiki allows a message to be displayed on the "edit page" UI. We should put some commonly used templates there so that new contributors would know to use them. That also saves contributors the trouble of finding them from other pages. That can also include things that are not strictly templates, but people might need to copy-paste from somewhere else anyway, like the word "Pokémon". (I got the idea from another wiki site (in Chinese). And yes, the idea of using collapsibles extensively also came from that site.)

Style guide
We have a manual of style, but I feel that it can use some additions.

One problem that concerns me the most, the formatting of hexadecimals, has been brought up before (although I also want to unify the capitalization, and that thread didn't mention that "hex:E9" and "hex E9" are also used ). I disagree with the resolution:

Wow...such evenly spread votes all the way across the board. Ironically, after having starting this poll I'm leaning toward it not being important enough. A few reasons:

1. The opinions from what we can see of the userbase are so divided that a unilateral change would be disliked by most users, no matter what it ended up being.

2. There are a lot of articles on the wiki. Originally I thought it would be best to catch this and set a standard on it before the page count grew even higher, but for about 3,400 pages at the time of posting this, there'd need to be a very pressing reason. Speaking of standards...

3. The wiki doesn't have strict style standards and never has. We have the manual of style, but that's just enough to prevent it from looking like articles were thrown together by elementary schoolers in seconds. I haven't seen any violations of that thanks to the QC team, but pages are written in all manners of different writing and organizational styles. This includes aspects like notation. Information is our first priority; if we had an editor base of hundreds, we could strictly look over every page and edit even the slightest deviations from what we consider the most proper style, but that's not the case right now.

Oh well, maybe this was a bit needless. Or was it not? More input  about the wiki is always welcome, in this thread or elsewhere.

My counterpoints:

1. The poll didn't have an option "anything, as long as it is consistent". I think it is rather likely that most people who voted on any of the first four options would be more OK with any of the other three than with the status quo.

2. Well, I am already proposing across-the-board changes. And we don't actually need to go over 3,400 pages. Simply put something in the manual of guide, and edit some major pages to establish the rule, maybe mass edit Dex pages with robots --- I believe the rest will be brought in line in time.

3. We might not be able to look over every page, but we are able to look over every future edit. In this regard, our lack of wiki activity (especially new contributors) could actually be an advantage. We can put something above the edit area to the effect of: "We are serious about our style guide, but don't worry about it if you are new to the site. Our staff will review any edits and gladly fix any style problems for you!" I don't think that would be a deterrent to any new contributor.

Actually, I believe the status quo of inconsistency may be a deterrent to some new contributors. How so? Editing the wiki is mostly thankless work. I think most people do that because they believe they are creating something good. And inconsistency does not look good --- at least to the conformists it doesn't. So those inconsistencies may be enough to make them think again about contributing.

It might be argued that there are more non-conformists out there than conformists. But even then, I don't think the approach of "feel free to edit, staff will catch problems" would alienate non-conformists. It might alienate anti-conformists, but I don't believe anti-conformists would be a significant portion of the crowd. Maybe we can also mention that we are open to exceptions, as long as there is a good reason --- that can be determined on a case-by-case basis.

As a bonus, if we can make it a wiki task to fix the pages to adhere to a more strict style guide, it might well incentivize some lurkers to contribute! It isn't unthinkable that, having gotten comfortable with wiki editing, they go on to contribute in other ways, like bringing new information to the site, right?

Some other things that might be unified with a more strict style guide:
  • Capitalization of X and Y (as in coordinates).
  • Capitalization and formatting of register names. In particular, the register a needs something to distinguish it from the English word "a".
  • Really, capitalization of everything.
  • Whether to use spaces around operators (+, =, <=, etc.).
  • ... Suggestions are welcome!
Those are not exactly priorities, but I think we can begin by implementing some items where there are no strong arguments for inconsistency, and there are no strong arguments against every option. Those can be discussed in separate threads if necessary.

CSS

I've brought up one problem with the CSS before, and I have since decided that other problems are also in need of fixing. The reason I decided to bring it up here is that I feel that CSS problems cause organization headaches:
  • Bulleted lists are a useful tool for organization, but editors may be discouraged from using them because nested/multiline bulleted lists are ugly.
    • Numbered lists are even more ugly (I've never seen a number followed by a bullet anywhere else).
  • Different section headings are of the same size, making it hard to see the structure of a page from a glance.
  • The color of links are almost indistinguishable from normal text. This discourages intelligent potholes and encourages cramming all the information in one page.
Currently, I use the Stylish plugin for Chrome to give myself a better viewing experience. But I would surely prefer those changes to be incorporated to the site's CSS. I am no expert of CSS, and I don't know whether those settings would look as good on mobile, or if they would break something else (as I mentioned, I don't use the forum often), so I would appreciate it if someone with experience in CSS could help to implement it.

P.S. I've already realized one potential problem: My bulleted list fix didn't take into account the font size, making bullet points in e.g. forum quotes slightly off. If anyone knows a more correct way to do this, please let me know.

Code: [Select]
/* Bulleted lists */
li {
    background-position: left 5px;
}

/* Numbered lists */
ol > li {
    background-image: none;
    padding-left: 0;
}

/* Numbered lists on the forum */
ul[style="list-style-type: decimal;"] {
    padding-left: 1.5em;
}
ul[style="list-style-type: decimal;"] > li {
    background-image: none;
    padding-left: 0;
}

/* Bulleted lists in the "Categories" line on the bottom of wiki pages */
.catlinks li:first-child {
    padding-left: 0.6em;
}
.catlinks li {
    padding-left: 0.6em;
}

/* Link color.
Not sure if this color works for everyone, but it is more distinguishable and also doesn't look out of place to me. */
a:not(.new) {
    color: #778899;
}

/* Some links on other parts of the site shouldn't have the above applied */
.dropmenu a {
    color: #000000;
}
.catbg a {
    color: #FFFFFF;
}
.table_list .header td.catbg a {
    color: #515151;
}

/* Section headings */
h2 {
    font-size: 1.5em;
    margin-top: 0.5em;
}
h3 {
    font-size: 1.17em;
    margin-top: 0.5em;
}
h1, h4, h5, h6 {
    margin-top: 0.5em;
}

/* Code */
pre {
    font-size: 130%;
}

code {
    font-size: 130%;
}

Beyond page-level
My above proposals are mainly about how to let users easily find information they need, and contribute information they have, on an individual page. They don't address the issue of how to let users find an interesting page in the first place. Part of the problem, again, is that different users find different pages interesting.

The problem of categorization has been brought up, too. That thread died down without a real conclusion, and I guess that was at least partly my fault. At that time, I already had some vague idea of the problem:
I think the advantage of your system is that it singles out the most interesting glitches to the average player (1B and 2A); however, the most interesting glitches to the average glitcher are probably different.
I didn't have the "science/art/technology/history" idea then, though. Now that I have a better idea of the problem, I want to ask for suggestions again. Maybe more than one categorization system co-existing is the way to go.

Actually, it doesn't seem like a bad idea to explicitly mention this "division" on the front page or the sidebar, and portray it in a positive light. It would help everyone find what they need, and also reinforce the idea that we are indeed a "catch-all" site for all aspects of glitching.

Other random ideas:
  • A navigation bar on Dex pages, like the one Bulbapedia has on Pokémon pages, would be nice.
  • The "Random page" button can be split into "Random (major) glitch", "Random glitch Pokémon", etc.
  • Related to the above suggestion, I want to cut down on the number of uninteresting pages, even Dex pages. Would it be fine to, for example, make ItemDexES/RB:094 a redirect to ItemDex/RB:094? I believe they act identically except for the name, which can easily be acknowledged on the latter page. And yes, I don't see any problem with a page with multiple navigation bars either, as long as they are thin enough.

I will keep this section short, not because the problem of page visibility is not important, but only because I haven't been thinking about this part of the problem too much, and this post is getting long enough. Maybe I will expand on this section later, factoring in whatever input I get.

Conclusions
To reorganize the wiki is going to be a huge project no matter what. I am willing to help, but only if I believe it would make more people here happy than not. Again, we need as much input as possible. Please let me know whether you agree or disagree with my interpretation of the problem and my proposals, and if you have different proposals. I hope that we can get to a consensus before taking any large-scale actions, which I believe is needed now.
14
Wiki Discussion / Re: Revisiting categories and organization
« on: March 15, 2019, 04:11:34 pm »
Hmm... I just checked the Gen II RNG, and the core function seems to be exactly the same as Gen I (except that the framely RNG advancement is spelled out in VBlank rather than as a function call). But I'm sure that there are many differences because surrounding codes determine what matters, and frame windows are also an important consideration for RTA.

For this kind of situations, I think it might be best to use the article length as a criterion. The Gen I luck manipulation page is already pretty long, and tacking some Gen II content onto it would probably either make the new content invisible, or make the article too confusing as a whole. Therefore I think "Luck manipulation (Generation II)" should be a separate page; if the overlap turns out to be substantial, we can always move the overlapping part to the parent page.

To be honest, I don't consider my level of knowledge to be high either (especially with Gen II), but BGB + pret + a bit of time usually gets you there. It would be much appreciated if people in the speedrunning community would help.
15
Wiki Discussion / Re: Reducing the side bar
« on: March 01, 2019, 11:55:05 pm »
Actually, the sidebar is still too tall for my screen. May I suggest moving the "search wiki" function up a bit? Every other wiki I use have the search on the top right corner, but if you insist that we are primarily a forum rather than a wiki, then at least putting the "search wiki" somewhere with more visibility.

To be honest, I feel that "search forum" is actually unnecessary. If something is search-worthy, it probably belongs in the wiki.
Pages: [1] 2 3