Main Menu
Main Page
Forums
New pages
Recent changes
Random page
Help

Glitches
Arbitrary code execution
Pokémon cloning
Pomeg glitch and Glitzer Popping
Tweaking and voiding
Glitches by generation
Glitch categories

References/Resources
Databases
Disassembly projects
The Big HEX List
Pokémon cheat codes
Pokémon glitch terminology
Useful tools
More

Affiliates
Legendary Star Blob 2 (Hakuda) (日本語/Japanese)
Pokémon Speedruns wiki (English)
PRAMA Initiative (Français/French)
MissingNo. Glitch City (Italiano/Italian)
Become an affiliate!

Technical
Site source code

Search Wiki

 

Search Forums

 

Recent Posts

Pages: 1 ... 8 9 [10]
91
Forum Discussion / Uploading problems.
« Last post by James-the-Charizard on September 05, 2019, 01:10:17 pm »
For some reason I’ve meant to make a post about an odd Pokédex result, but the image I have won’t post while attached... (I checked, it’s near 3.1 MB, short of the 8,000 KB limit.)
92
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« Last post by Evie the Mother Hen ☽ ❤ on September 05, 2019, 07:13:21 am »
Also Pokémon Curry Version announced. Does this mean, Telefang characters confirmed!? :)


93
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« Last post by Parzival on September 04, 2019, 08:37:38 pm »
did they really just

release Team Rocket fighter skins

then IMMEDIATELY fucking steamroll it with FUCKING SANS
94
General Discussion / Re: The Glitchy Thread of Topiclessness (#3)
« Last post by Parzival on September 04, 2019, 06:26:04 pm »
Generated and published a PGP key for myself.

However:

GPG's bad at it...?

I set it to expire in a year, and it wasn't detected as such on any keyserver, some keyservers didn't see an email address embedded in it, and it ended up being 3Kbit and not 4Kbit like I asked it to generate.
95
Wiki Discussion / Re: Organization discussion thread (everyone please weigh in)
« Last post by Ryccardo on September 04, 2019, 03:19:00 pm »
The way I see it, collapsible sections serve the same function as a table of content. [...] TVTropes [...] [notes]
Oh right, it's been so many years since I visited their website (vastly preferred the unofficial Android client "Lampshade", now broken) that I forgot they have an "open all" button - I'd be more than fine with that (or a preference to just disable them); and the "inline long comment" use also seems reasonable!

96
Wiki Discussion / Re: Organization discussion thread (everyone please weigh in)
« Last post by bbbbbbbbba on September 04, 2019, 01:33:33 pm »
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!
97
Wiki Discussion / Re: Organization discussion thread (everyone please weigh in)
« Last post by Ryccardo on September 04, 2019, 07:24:54 am »
Too long of a post delving into different points!! :P
Anyway:

Fully agree that the current (vertically centered) bullet points are an eyesore as is the trashy strolling - and while we're talking about theme edits, yes a bigger visual difference between heading levels woild be better both in general and for my next point;



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);



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 :) )

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?



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")

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 :)
98
Wiki Discussion / Re: Organization discussion thread (everyone please weigh in)
« Last post by bbbbbbbbba on September 03, 2019, 05:26:57 pm »
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?
99
Quote from: luckytyphlosion
that's a lot of memory you'd have to overflow to corrupt cd38
you can probably do better by just corrupting map height/width and reloading the map
Does that help clarify anything?

As for me I need a lot more practice with this glitch before I could think of any input.

It does (and I found later easy walk through walls is viable https://glitchcity.info/wiki/Map_size_walk_through_walls ). Seems then for CC47 we just need to find the right height/width values/map that would give an ACE CC57 value without freezing the game (they exist but don't know good specific ones yet).

In other words

1. Go somewhere
2. Change item 38 and its quantity
3. Save and reset
4. ???
5. Profit

Changing item 41 and item 41 quantity (D36E/D36F) is another way of causing continuous arbitrary code execution instantly like changing it to 22 D3 to run ACE at item 3, but CC57 ACE is kept even after changing maps so is useful and a little closer to OAM DMA ACE. The Start menu and text boxes may be disabled, however perhaps the ACE could run a code to fix them.
100
Wiki Discussion / Re: Organization discussion thread (everyone please weigh in)
« Last post by Parzival on September 03, 2019, 09:26:21 am »
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.).

Kinda like the one at the bottom of this page, maybe?
Pages: 1 ... 8 9 [10]