User talk:LpSamuelm

Welcome

Welcome to Bulbapedia, LpSamuelm! Here are a few links to help you get started:

Manual of Style The Manual of Style, or MoS, outlines the format of all pages on Bulbapedia. Need a hand? Our friendly team of staff are here to help! Talk to them if you have any questions or problems with Bulbapedia.

Signatures On talk pages, please sign your comments with four tildes (~~~~), or by using the "Your signature with a timestamp" () button at the top of the edit window. Userspace Policy On Bulbapedia, the ability to edit personal userpages is a privilege. Per our userpage policy, this must be earned by first making constructive edits to the mainspace. Once you can, remember to keep userspace edits (edits to User:LpSamuelm) to a minimum. For a complete list of policies and editing advice, please see the Welcome Portal.  Thank you, and have a good time editing here!   «ιɴsσмɴιαc» 10:57, 6 June 2010 (UTC)

Monospace/Gen II save data

Do you actually have some "real" reason the tables under checksum shouldn't have the whole cells in monospace? Is there a actually some significant problem with "to" being in the same font? It's the easiest solution; it looks fine. I get that your intention is to put the font on the hex values, but I don't know any reason why it's so terrible that "to" be in the same font. In other cases, I'd be happy to leave "to" out; and that's possible here, but doing it is just more trouble than it's worth (AFAIK). Tiddlywinks (talk) 21:07, 19 April 2016 (UTC)

Well, the reason they're in monospace at all is to set the hex values apart. tags are for just that - setting apart code. Having the entire sentence (which "[x] to [y]" is) in monospace makes it seem like it was taken straight from a .txt. Honestly I would've kept the tags even in the code-only cells in order to keep the formatting uniform, but it doesn't really matter as much there. So basically, to separate text content and code content.

Another formatting that would work, I suppose, would be to split the table up into a table with a "from" column and a "to" column - that'd be fine too, as the code and text would be separated in style in that case too. LpSamuelm (talk) 21:19, 19 April 2016 (UTC)

In lots of text, it's certainly worth setting apart the hex values. But in those tables, it's not (at all) hard to identify the relevant values, even with "to" in the same font. Can I ask you to just do something so that the code tags aren't used in the table? Either setting the whole row monospace again, or making from/to columns, or something. (Honestly, I tried from/to columns before and didn't like it. But...) I'll leave it to you, but those code tag formats are just too out of place in a table.

(P.S. If you removed the welcome template on purpose: please don't.) Tiddlywinks (talk) 21:26, 19 April 2016 (UTC)

I really liked code tags in the table, at least. Felt consistent, and was pretty enough. But sure, if it makes you happy it can't be that bad. LpSamuelm (talk) 21:32, 19 April 2016 (UTC)

Japanese holdovers

There's one thing I'm particularly confused about in your recent edit to Character encoding in Generation III. It's the bolded part below.

Characters on a dark gray background are, in all versions, unused holdovers from the Japanese encoding. They are displayed differently across versions.

It seems to contradict the "in all versions" part. Or are you talking about some sort of trivial differences somehow?

Tiddlywinks (talk) 18:54, 15 April 2017 (UTC)

Ah, no, both statements are true. They are unused in all versions, but display as spaces in FireRed, LeafGreen, and Emerald. Perhaps I should change that to something along the lines of:

Characters on a dark gray background are unused in all versions. In Ruby and Sapphire, they are holdovers from the Japanese character set, while in Emerald, FireRed, and LeafGreen they (with the exception of 0xAF) simply contain spaces.

How about that? I'd have to do some editing in the beginning of the "Revisional differences", but the added clarity might be worth it. LpSamuelm (talk) 19:34, 15 April 2017 (UTC)

I'm doing some moderate changes already anyway. I'll make sure it's accounted for. Tiddlywinks (talk) 20:26, 15 April 2017 (UTC)

I figured you would! I'll swing past once you're done and make sure you didn't change anything for the worse. LpSamuelm (talk) 22:27, 15 April 2017 (UTC)

Images

As a rule, can you please not use images from external sites in the future? Tiddlywinks (talk) 21:38, 15 April 2017 (UTC)

Of course! I wanted to upload the characters myself, but as it turns out I (despite being auto-confirmed since long ago on the wiki) can't upload images. I asked an administrator, but I figured these would be fine temporarily. If you look at the HTML comments right by those images, you'll see I'm fully aware they should be replaced. LpSamuelm (talk) 22:22, 15 April 2017 (UTC)

Just in case, I'll emphasize that they shouldn't really be used even as a stopgap. Thanks. Tiddlywinks (talk) 22:53, 15 April 2017 (UTC)

Odd characters

Just to check, I don't suppose you'd know if the Italian _M (0x59) from the RS encoding is used in text anywhere? Or where the Pco (0x64) in French Emerald is used? I'm glad you figured out those ordinal characters before that I originally used images for, and I'd love if we knew about these as well, possibly for noting somehow. Tiddlywinks (talk) 21:38, 15 April 2017 (UTC)

And, vaguely related, but did you merely make a mistake when marking 0x60-0x63 as differing by region, or did you just forget to include them in the section below? Tiddlywinks (talk) 22:09, 15 April 2017 (UTC)

No mistake there specifically - I did however do a copy-paste goof, marking the Italian Pokéblock text as 0x7D-0x83 when it is in fact 0x5E-0x63. I'll fix that one once you're done with... whatever you're doing. LpSamuelm (talk) 22:22, 15 April 2017 (UTC)

The _M I have no idea about, and haven't looked for. Since it was removed from all subsequent versions, I assume it wasn't very important. "PCO" isn't a common abbreviation in French, so it'd probably be something Pokémon-specific. I thought it perhaps stood for "Pokémon Contest", but I looked for it and found nothing. Not in contests, not on summary screens, not the PC, not the Pokédex, not your Trainer Card, not the options menu, not berry mixing... Seeing as it was added in Emerald, it might be about the Sevii islands, although I highly doubt it.

The ordinal suffixes are at the very least used on the contest high score boards (in the contest halls), but they're probably used elsewhere, too - it's fairly probable that they'd be used in normal dialogue, too. You probably weren't wondering where those are used, but hey, there it is. LpSamuelm (talk) 22:22, 15 April 2017 (UTC)

Found it! Pco stands for "points de combat", and is used in the Battle Frontier exchange desk. For example, a Blastoise doll (or should I say a Poupee Tortank?) is listed as costing 256Pco. LpSamuelm (talk) 22:45, 15 April 2017 (UTC)

I think I get what you mean about the Italian Pokeblock text, so I fixed it too. I'll be ready to save once I've just uploaded and replaced the external images.

The Italian remains a mystery for now then. Thanks!

(On a side note, I'll guess that the in-and-out indentation you had above was meant to each be one advanced beyond the comment it was replying to. Around Bulbapedia, though, we generally prefer that all reply indents be strictly advancing (or reset if it gets very far). If you want to use the same indent after something of your own you recently wrote, though, that's probably fine usually.) Tiddlywinks (talk) 22:53, 15 April 2017 (UTC)

For what it's worth, it might stand for "Melle", the Italian word for "block". It might also not at all, though.

Oh, and please don't edit my indents citing some unwritten rule, as it's entirely subjective. Cite the manual of style if anything (or get your unwritten rule formally written down) - it contains nothing about "strictly advancing" indents. LpSamuelm (talk) 23:02, 15 April 2017 (UTC)