User talk:D0SBoots

Just so you know, it takes the server image cache 10-15 minutes to resolve new versions. Please wait to reupload, and make sure you clear your browser cache (ctrl+F5). -- Wynthyst 👁 Image
talk 05:16, 22 February 2011 (UTC)

Yeah, I know. I legitimately messed up and uploaded the wrong version (2 different wrong versions actually), I wasn't re-uploading the same image because it was still cached. :) D0sboots 05:20, 22 February 2011 (UTC)

I notice that you're “fixing” the TNT resistance values in infoboxes. Please note that the existing values are not the same as the data from the table in Explosion. The values in the block infoboxes are measured in the thickness of blocks of that type that will be completely destroyed by an adjacent explosion (thus higher values are weaker), whereas the Explosion page lists the internal values used for the explosion calculation.

I take no position on which value should be displayed, but I just wanted to let you know that the existing ones aren't just plain wrong. —KPReid 19:11, 9 March 2011 (UTC)

Ah, thanks for the clarification. I finished my big wave of "fixes" a while ago, but one of the admins could revert them all with a bot without too much trouble. Many of the values were the internal value, so it wasn't consistent either way. I think having it be the internal value is more consistent, more precise, and (most importantly) actually explained, where the old value wasn't documented anywhere (that I saw). D0sboots 19:32, 9 March 2011 (UTC)

Also, if that's the block's resistance, why is the units in blocks? Like a block resistance of 15 blocks? Wouldn't it just be a resistance of 15? --JonTheMon 19:48, 9 March 2011 (UTC)

Yes, that confused me too but I went with blocks for consistency. Now that I know what that was about, a unitless quantity would have been/be better. D0sboots 21:35, 9 March 2011 (UTC)

OK, I've changed how this works so it all goes to a big data table. At least now there's a manageable way to update this stuff, no need to hit every block page one by one. (Doing that twice was two times too many!) D0sboots 06:57, 13 March 2011 (UTC)

Why are you making the infoboxes on those blocks includable? ? --JonTheMon 20:45, 13 March 2011 (UTC)

See Minecraft_Wiki_talk:Community_portal#Consolidating_block_information_in_one_place. Doing it this way has a lot of nice properties. D0sboots 20:49, 13 March 2011 (UTC)

Also, I'll be adding documentation about how this works and why it's a good idea to Template:Block. But it's hard to explain without a good example, and I can't construct the example until I've converted the infoboxes over. D0sboots 20:54, 13 March 2011 (UTC)

I'm familiar with the process. Guildwiki does their skills in a similar fashion. --JonTheMon 20:56, 13 March 2011 (UTC)

There should have been at least some modicum of community discussion about these changes on the infobox talk page prior to you simply implementing them. You are making it that much more difficult for the average user to edit this wiki which is the exact opposite of what we should be striving for. You really need to get community consensus prior to making these kinds of bulk changes. -- Wynthyst 👁 Image
talk 21:06, 13 March 2011 (UTC)

You're right, that would have been a better place to seek discussion than Minecraft_Wiki_talk:Community_portal, probably. My current round of edits is an attempt to make it easier for the average user - my last change moved the tntres property into a data template of its own, and I'm basically reverting that here. I'm also adding in a hardness value, which doesn't ever need to be shown in the infobox if the consensus is against it. And I'm also surrounding the template with <onlyinculde></onlyinclude>, which shouldn't affect the average person who just wants to correct some misinformation listed in the infobox. However, if you think that's too aggressive I'll halt this where it's at and wait for consensus at Template:Block. D0sboots 21:16, 13 March 2011 (UTC)

I just see a mass of activity around a template that is one of the most widely used on this wiki. You are not the first to do it either, and I'm starting to get a bit frazzled about the entire lack of discussion that goes on behind 95% of these changes. I'm used to a more talkative community I guess. I just want to shake it into people's heads that this is a community based wiki and that things really need to be discussed before changes that are going to affect a large number of pages are just made. I'm a bit brain dead atm from working through a couple of issues on another site so I was having a hard time following what you were doing. I just want to make sure that if you disappear tomorrow, it's easy for the rest of the community to maintain the changes you have made. Please be sure to provide clear documentation on the various templates so I'm not having to decipher code a year from now :P -- Wynthyst 👁 Image
talk 21:28, 13 March 2011 (UTC)

Roger dodger. I'm going to stop edits for the moment to work on documentation. I think I'll also add a big bold note to Template:Block/doc saying that "you really should discuss before making any substantial changes to this template" - it'll help remind me if no one else. :) D0sboots 21:34, 13 March 2011 (UTC)

Perhaps at this point it would make more sense to start splitting out infoboxes to their own templates, as is done with element infoboxes on Wikipedia? That would eliminate the whole <onlyinclude/> business from articles, and would get a lot of seldom-edited code out of articles as well. On the other hand, you could gun for SMW to be installed here... Either way, I think it would require community consensus. 「ダイノガイ千？！」^{? · ☎ Dinoguy1000} 01:07, 14 March 2011 (UTC)

I'm really trying to keep the data right there on the page, so that it's easy to understand where it is and how to edit it. However, if folks think having separate templates is a good idea, it would only take a few small changes to make what I've proposed work with that, instead. D0sboots 01:12, 14 March 2011 (UTC)

You stated that fireballs can start fire in your edit. But this is contrary to my recent in-game observation and code analysis with MCP 3.1 (Beta 1.5_01). Can you verify your statement? Xfs 05:46, 12 May 2011 (UTC)

That wasn't what I meant from that edit. What I actually did was delete a small paragraph that included the assertion, "Fireballs can't start fire," but I never personally asserted that they *can*. My intention there was strictly editorial - the paragraph was awkward, and didn't seem to be adding any relevant information. I've never seen a Ghast fireball start a fire either, so my suggestion would be to add that information to the "Ability to generate fire" bullet, instead of near the bottom. Perhaps something like, "Fireball explosions can theoretically start fire, but other code makes this impossible. In practice, no explosions cause fire." D0sboots 14:12, 12 May 2011 (UTC)

Your point is reasonable. The original wording would confuse readers with technical details. I'll change it into more readable form. Xfs 14:52, 12 May 2011 (UTC)

Well darn, I wish I'd seen that before; it would have saved me a lot of work.

I see your work on transparency. Let me tell you why you didn't see it.

I found opacity/transparency interesting, did some research, and started writing the opacity article. But it was speed deleted within minutes by an admin seemingly for no clear reasons. The same thing almost happened to explosion.

My suggestion is that you have to be careful when you're writing something not believed or understood by the deletionist admins here. Xfs 20:56, 29 May 2011 (UTC)

I did actually discover the saga of your previous attempt to write Opacity once the delete request came in and I started doing some meta-research. That's why I quickly beefed it up with pictures, added a general overview, and updated it to be more current than your stuff at Blocks#Opacity. Once that was done, it seemed pretty obvious that it wasn't a stub and really stood on its own as a subject.

I don't envy the admins their job; this wiki is a big spam magnet, not in the "buy V1AGRA" sense so much as "let me add a vanity page for this minecraft fanfic I wrote." After a while I can see how you could come to assume that all the top-level subjects were already created and all future editing confined to existing pages. My only advice is, if you discover a new concept, (especially one that seems common-sense, but is actually quite technical,) then write it up offline first, and make sure it really stands on its own before you post it. D0sboots 22:57, 29 May 2011 (UTC)

Are signs non-solid? If you still read MCP code, there is a function getIsSolid() overloaded at several places which you may want to look into. Your could have different taxonomy from mine so I didn't edit the article but just remind you of this. I found this problem when discussing how solidity affects pathfinding. Xfs 12:02, 5 June 2011 (UTC)

I categorized those based on "common-sense" definitions, not anything technical. Signposts are non-solid in the sense that they don't affect physics, but I'm sure pathfinding uses a slightly different definition of "solid," just like everything else in Minecraft. :)

BTW, how do you know the function is named getIsSolid()? My research has been based off the decompiled minecraft jars, and all the function names there are minified down to a(), b(), etc. D0sboots 17:59, 5 June 2011 (UTC)

MCP is doing some deobfuscation work and has greatly improved readability. From what I've seen, signs are made of wood (material), and wood is solid so signs are solid. But signs have different collision model than normal blocks, and this is why entities can fall through signs. Xfs 21:22, 5 June 2011 (UTC)

Hehe, sounds a lot like what I was doing. :) I independently discovered the "materials" too, although the methods on them have a lot of redundancy so I don't think I came to a solid decision on what they should all be named. If you ever write up a technical article on "Solidity" or "Materials" feel free to change the wording I used in Opacity, or move Sign to a different category. D0sboots 15:07, 7 June 2011 (UTC)