User talk:WolfieMario

Inquiry on Villagers
I was directed here by Orthotope, and there isn't much more I can say outside of what I asked of him:


 * "The wiki says the Riches variable on Villagers is currently unused. However, in 12w26a, I suspect it is used. I traded with a villager several times, then right click traded. The Uses variable says it totaled 127 uses. At first, he was not adding new trades. After doing so may trades, he added new ones and didn't remove the original. Could you see if Riches is used now, please?"

Partially off topic, but I made a Villager Mob Spawner in 12w26a that does this: http://i.imgur.com/98Rgs.png Thought that might interest you. --MegaScience 01:06, 30 June 2012 (UTC)
 * The call hierarchy indicates that the Riches variable is never called, except when reading and writing NBT data, and when increasing it, all of which happens in the Villager class. In fact, the variable can't even be accessed outside the class, unless other classes can load a Villager's NBT data, and the Villager class is also the only class to contain a reference to "Riches", so that's not possible either.


 * In short, no, the Riches variable is still unused.


 * As far as the uses variable, it's only referenced 4 times within the Offer class, where it reads and writes NBT data, increments the value, and provides other classes the ability to read the variable. The call hierarchy of the method providing access to it indicates that the Villager class is the only one to actually do so, and it does that when it checks whether an offer's been used enough times to be removed.


 * So the uses variable has no special/previously-unknown purpose, or any interaction whatsoever with Riches. Also, since uses is an int, it can have a maximum of 2147483647, meaning that 127 isn't a special number for uses, either. If uses were a byte, then yes, 127 would actually happen to be its max.


 * Assuming you were trading the rightmost slot until uses hit 127, there's no surprise: the rightmost offer is never removed. Now that it is no longer the rightmost, if you try trading that offer again, it will be removed because you've reminded the game that it's (over)due for removal.


 * Also, the custom trader spawner thing is interesting; I'm glad Mojang has made this possible. I actually saw sethbling's video demonstrating MCEdit filters he made which can streamline the process of making things like that. Who knows, maybe someday Mojang will let us slap a mob's NBT data onto a spawn egg, allowing a dispenser to, say, dispense a special trader in the event that the original killed - though Resistance IV dramatically reduces the odds of that ever happening anyhow :p --WolfieMario 03:08, 30 June 2012 (UTC)


 * I did leave the villager for a moment and reopen the trade. I only found the number significant for being far over 15. But... okay


 * I was actually using NBTEdit on Mob Spawner Schematics to make my Mob Spawners for MCEdit. Before this, I hadn't even used MCEdit before, so it was a littlee confusing. I was only working off the information Dinnerbone gave, didn't think you could apply positions and such. Should have guessed it.


 * Actually, that brings up one more question: Would you happen to know (or know how to find) why spawning Iron Golems from a Mob Spawner crashes the game when one spawns? The world runs fine if you reload it, just spawning them crashes the game. Seems odd to me. --MegaScience 08:07, 30 June 2012 (UTC)


 * I'm not sure; this is just a guess, but it may be related to how Iron Golem spawn eggs do not work. Do similar crashes occur for Snow Golems, or Primed TNT, or other things spawn eggs can't spawn? Also, it may be related to the fact that Iron Golems likely don't have any spawning conditions: since the spawner checks if the conditions are right for a mob to spawn (e.g. grass, light level), it may cause an exception when doing that check on anything that doesn't have a natural spawning condition. I don't feel like checking the code right now, but it's likely either one of those; I'd personally hedge my bets on the latter. --WolfieMario 15:22, 30 June 2012 (UTC)


 * Iron Golem spawners work fine for me in 1.2.5, so this may be a new bug. Mob spawners use the getCanSpawnHere method, which Iron Golems don't override (again, in 1.2.5), so it uses EntityCreature.getCanSpawnHere. Spawn eggs are much simpler, and just have a list (EntityList.entityEggs) of which mobs they're allowed to spawn. -- Orthotope 16:46, 30 June 2012 (UTC)


 * I tried placing the Iron Golem spawners in a village I accidentally overpopulated from my NPC Villager spawner in daylight with enough room, but the game still crashes when they spawn. When I do reload the world, they are spawned as they should have been and walking freely. I could EASILY be missing it, but I feel like Iron Golems aren't spawning naturally at all. With my overpopulation of that village, there should have been 1-2, but I can't find any. This might actually be a bug, then.


 * I actually did try spawning Primed TNT from Monster Spawners, but that crashed the game immediately on loading the world instead of on spawn. I just tried Snow Golems, and they crash the game the same way as Iron Golems. --MegaScience 18:09, 30 June 2012 (UTC)


 * Okay, I believe I found the problem. I used the filters from the video you linked on a Snow Golem, expecting to crash, but I didn't. I checked the schematic of the spawner I made, and it included all spawn information you'd normally have. I'm assuming that unlike other mobs, these do not spawn was all their data, so if it isn't included on the Mob Spawner, then you crash. It is extremely annoying you must set everything (or a few usually unrequired parameters) for them to spawn, and from what Orthotope said it wasn't previously required. Maybe an oversight when converting the game for 1.3? It'd be a bug of sorts if these mobs can't function with Mob Spawners without basic data they should spawn with to begin. --MegaScience 18:31, 30 June 2012 (UTC)