CosmicDan

Unsure if this belongs here but *shrug* I have a few questions/confusion about mcmod.info and can't find any recent documentation on these particular things. I know that the purpose of it is to provide metadata on a particular mod entry, but specific questions are: 1) Why do we even have it when we can just specify all of these in our main class @Mod annotation? Is it just to make things easier for FML and Modders? 2) What's the significance of having two version fields? The one in the mcmod.info metadata appears as the first version string in the "Mods" menu, whereas the one in the @Mod annotation appears after it in parenthesis. I'm *guessing* the former is designed to be numerical, whereas the later is a string representation (e.g. "Release", or "Alpha", etc.) but I want to be sure. Personally I'd like to only use one, but if I leave the @Mod one empty then it leaves the () there and it just looks dodgy. EDIT: Oh and then *thirdly* we have version property in build.gradle too... but I realized that this is only what's used in the jar filename. 3) Lastly, why are "version" and "mcversion" fields in the metadata formatted as variables by default, but don't even work? These might seem like pedantic questions, but the reason I ask is because I'm working on a script that automatically manages Mod versioning and builds changelogs based on Git commit messages, and other things of the sort. Thanks.

There's no need to jump to such conclusions. Microsoft have been neglectful, even abusive; to PC gamers in the recent past, it's true. Although Phil said in June that he wants to win-back Windows gamers (don't know what this means for Linux/Mac of course but that's not the point, these systems are not exactly designed for gaming anyway). Additionally, two Microsoft re-releases on Steam - Age of Empires II HD and Rise of Nations Extended Edition both have full Steamworks integration. As a former modder and player of both these games in the distant past; I can confirm that both these titles are just as mod-able as they originally were - if not more so. Castrating all modding capability from Minecraft would not be a good move in Microsoft Studios' attempts to redeem themselves in the PC gaming industry. Also consider the underwhelming success of the latest console generation, and the re-emergence of PC gaming. There's a lot of variables here. I recognize the fear and danger for the modding scene from this acquisition, but I can't be so quick to see this as the beginning of the end - not yet anyway. Call me a foolish optimist if you like, I just don't think it's as definite or fatal as so many people are assuming. Yet. For all we know, Microsoft could port Minecraft to C# and work on a full-fledged official API and turn Minecraft into an augmented reality simulator or training tool (EDIT: for people to learn C# programming I mean). There are many ways to make money, that's just one example Minecraft is too unique a product to predict the dimise of it with generic parallels. It's far too early to tell what will happen.

Sounds very interesting. I imagine this'd include things like combustable fuels having a heat value, and machines which use them have a minimum heat level? I.e., furnace fuels.

If these were possible, it would give us a lot of power and flexibility - there are many cases I can think of where this would save a significant number of operations/iterations, and open up other areas that are impossible without coremodding. TileEntityConstructing is pretty self explainatory: I would think this'd be injected into the end of TileEntity#createAndLoadEntity. Such an event would allow mods to observe/modify TileEntity data in a less-direct manner (i.e. without a custom mod block within proximity of whichever block has the TE) and also a less-hacky manner (reflection/asm on specific tile entity classes). The main advantage of this is efficiency - a block, tick event, etc. currently has to constantly scan for TileEntities within whatever range, or globally if they're daring enough. Another advantage is simply to make the impossible possible - for example a specific game mechanic (e.g. summoning a boss) that does something to all applicable TE's (e.g. drain all the electricity from your base). This would be doable if a mod were to keep it's own central registry of TE's that it needs to interract as they are created, and just check this array/list/whatever as needed to do it's thing - but that's probably obvious. BlockCreated is a similar idea, but for blocks. Not sure if this is possible/feasible, but it'd be potentially more useful. But maybe only along with an event that is fired when metadata for a block changes (or people can do that themselves with a tick event). Only one is needed really, since it's simple to get one from the other. I would fork MinecraftForge and make a pull request for it, but I'm new to the MCP side of things. Seems that Forge has patch/diff files that it uses, and I know how to make these but I don't know of the specifics in how Forge is built or interracts with MCP. If anybody has some further reading on this, please let me know. That is unless the Forge collective don't see the point in this suggesion, which would be disappointing. Thanks!

Erp, forgot to reply. Sorry for the bump guys. Ah, didn't realize it was that simple - thanks for taking the time to read Well, the original question is well and truly solved. We'll have Forge for 1.8.x by the end of the year and I'll update to it as soon as it hits, so ISimpleBlockRenderingHandler will be obsolete anyway. TE Renderer it is, until we get to try out the fancy new block renderer stuff Thanks everyone!

Great to read, thanks for an official word on the matter. I did read your reply to someone asking about Forge for 1.8.0 - for some reason I can't find the thread now (ninja moderated?). In it you said we could expect a release mid-September. Are you sure? Even for an initial alpha, that is *crazy* fast. You may have also implied that you yourself work with the MCP team in a lot of the primary deobfuscation, if this is true I had no idea you were directly involved there. I don't know what this beef - or the "recent events in Bukkit community" - is about, but it sounds like the usual stuff and I can imagine. I may only be a new modder but I've already publicly stated that, if I get to the point where people want to donate - that I would split it 50/50 between MCP and Forge if I could - you guys work very hard to do something that people like me just do for fun, it's the least we should do. Well, some don't have anything to give I guess, so in that case the least we can do is not harass developers to update... ...anywho, thanks again for the news. Enjoy yourself!

Good point. And awesome machines btw This would be good for calculating the borders too, but draw distance cut-off is a concern here. If I did it this way there'd be a "town center" block which handles all the drawing, and it would eventually have to draw borders many chunks away as a players' faction expands. I do plan to force chunks-within-borders to always remain loaded (big performance concern, I know) but how would that work for rendering? Say for example the town center is at x location, the player could have expanded their realm with some military buildings causing the borders to expand, say, 20 chunks towards the north. If a player was standing at this northern edge, 20 chunks away from the town center (i.e. outside the draw distance from the actual town center block), the borders would not be rendered - true? Or would they still be as long as the chunk that contains the town-center is kept loaded?

Well that still sounds pretty good, thanks! This still seems ideal, for what I wanted this for. What I need is to have visible "borders" in the world that belong to a player team, or "faction", and each block will simply be a flag resembling that factions' colours. These flags (and colours) were going to be items, since that seems the most versatile way to do it (these flags will also be elsewhere). True this wouldn't be good for performance in many cases, but in this case this is better than having a tile entity for every single block of the visible border! Unless there's a way to have many blocks share the one tile entity... ooo that'd be nice. Cheers!

Well there you go. As I said, pretty basic stuff - I know how to use tesellator, but trying to stop/start drawing again just crashes - I was told this is because block rendering is all done in one pass but I don't know the technicals, just that i couldn't get it to work. Apologies for the lack of an actual log or "proof" of this, but now we know I'm not crazy/noobsauce since Reika is having the same issue

Well that's pretty basic stuff, but as I said (sort of, wasn't clear sorry - was replying from phone) - when I try to start drawing I get a crash saying "already tesselating!" or whatever that error is (we've all seen it I'm sure). While in this particular case I would prefer using a Tile Entity Renderer since I am using the 2D item render thing and it's just easier for me; I am interested in it for future - assuming it's possible afterall. Question is, why can't I start a new tessellation/draw within renderWorldBlock? It was my understanding that it's not possible because it's all done at once for blocks (and this is one reason why block renderers are far more efficient than TE renderers) but according to this new information you have full multipass tessellation after all?

No, you can't do tesselator.draw in block renderer because it's all done in one pass (or whatever the term is) - it's not possible to start/stop tesselation. I figured as much (that the item sprite sheet wasn't "applying"); but I've solved it with a tile entity renderer anyway. Good enough

Makes sense why I was having such trouble and not finding anything though. Tile Entity Renderer it is then! Thanks for answering this problem.

Hello, new member but not (completely) new to modding and experienced enough in Java. I queried this issue over at the curse forum and have gotten a lot of help, but so far everybody is at a loss as to how this particular case could be solved. coolAlias suggested to consult the experts here for additional ideas I am using ISimpleBlockRenderingHandler and wish to get an IIcon instance of a given item, but can't seem to work it out right. Problems, and what I've learned so far: 1) Cannot use ItemRenderer, since Tessellator is already drawing. 2) I may need to switch from block "sprite sheet" to the item "sprite sheet", which appears to work in practice, however results in the same incorrect graphic being rendered (see screenshot). 3) I am sure I have the write idea, but am just missing a step in the UV mapping/size, or.... translation (?) or some such term I don't quite know about yet, still a bit ignorant on the rendering stuff Here is my (experimental) code so far, this is just a chunk taken from my block renderer (full class source can be seen here on GitHub for reference). Note that, yes I have assigned a hard-coded item here, but that's just for testing - it will be gotten programatically from a given Item (or ItemStack) in a TileEntity field: // none of this is necessary it seems, commenting these 4 lines out render the same thing TextureManager renderEngine = Minecraft.getMinecraft().renderEngine; ResourceLocation blockSpriteSheet = renderEngine.getResourceLocation(0); ResourceLocation itemSpriteSheet = renderEngine.getResourceLocation(1); renderEngine.bindTexture(itemSpriteSheet); //iicon = Items.beef.getIconFromDamage(0); // same result as below iicon = new ItemStack(Items.beef).getIconIndex(); u = iicon.getMinU(); v = iicon.getMinV(); U = iicon.getMaxU(); V = iicon.getMaxV(); tessellator.addVertexWithUV(1, 1, 0.53125, U, V); tessellator.addVertexWithUV(1, 2, 0.53125, U, v); tessellator.addVertexWithUV(0, 2, 0.53125, u, v); tessellator.addVertexWithUV(0, 1, 0.53125, u, V); // switch back to sprite sheet renderEngine.bindTexture(blockSpriteSheet); And here is a screenshot of the result of this code (the weird icon bunch above it, not the dodgy looking campfire): Judging by the appearance of the health potion icon, I can see I'm on the right track. But nevermind why it's wrong, why is there a brewing stand there? And what's that thing on the left, a part of the bed texture? I've spent quite a bit exploring this, in Minecraft code and other projects sources to no avail. Note that, for this particular block, I have chosen to use a tile entity renderer for these food items (makes far more sense) but I wish to avoid the use of any tile entity renderer for a different block in future (there will be a LOT of them in the world and I want to preserve performance where possible). Thank you in advance for any suggestions!