yoshiquest

Well, figured out what happened. Apparently, either by renaming things through my IDE, or resaving it when the raw code got opened by accident in my IDE, two of my textures got corrupted. After replacing the corrupted textures with fresh versions, the code ran perfectly. Just thought I'd let you know I solved it.

Nope, no onStitch event. If by changing/removing any textures you mean changing the vanilla textures, I didn't. If you meant the ones I use, I did change the names a bit, though I made sure everything was clean before testing this, so it's not a name mismatch...

This is a very strange crash. No mention of my mod is made in it. Happened after I refactored my code a bunch, so could be a name issue or something. Here it is: I'd provide you with sample code if I had any idea where this is coming from. Which I don't, so if you need to look at a specific part of my code then just ask.

The problem is that the server doesn't know the animation state (it knows the id of the last animation but doesn't know anything about the animation itself -- these are contained in client-side only classes), and keeping it up to date would require every client to send a packet with information on every entity every tick. That would kinda spam the network, which is what I'm hoping to avoid. If this is a looping animation or something, then maybe you could use the current time as the current state? Because if it loops, and has, say, 5 states, then something like 0==time%5 would always get the first state, 1==time%5 would get the second, etc. Maybe you could try something with that? Then again, my animation system works in an entirely different manner from yours, so I have no idea if this will work. Thought I'd suggest it though.

Ok, I finally figured it out, and it was stupidity on my part. In the first post I did say that I had overriden isOpaqueCube, right? Well, as it turns out, the thing that determines opacity is when the Block class's constructer is invoked, by calling isOpaqueCube and setting lightOpacity to 255 if true or 0 if false. So apparantly, with the way I implemented clojure java inter-op things, the constructor was called FIRST, BEFORE the new overrides were created. Because of that, even though the methods were overriden, and isOpaqueCube did return false, this happened after the constructor was called, and lightOpacity was already set to 255. So yeah, I solved it. That was kinda stupid though.

Ok, I think I found something. Looking at some of minecraft's rendering methods, they seem to use getLightBrightnessForSkyBlocks(). Originally, I was calling it with the wrong coordinates. However, even after I fixed this bug and the proper coordinates print out, getLightBrightnessForSkyBlocks() still constantly returns 0 every time. Any ideas? EDIT: I've tested it with multiple values. The X, Y, and Z values seem to be correct, or at least it is the same as the coordinates in the f3 screen. The 4th argument seems to be the block light in this instance. If artificially set higher, the texture suddenly becomes normal due to actually receiving light. However, getLightValue at that location also returns 0. Maybe my coordinates or actually off, or something is wrong with the client world?

I'm using 1.7.10, not 1.8, so getCombinedLight and BlockPos aren't defined. What's the equivalent call in 1.7.10?

Ok, since it's been a day and no one has replied to this yet, I thought I'd translate my renderTileEntityAt method into java real quick. Note that this is more or less pseudocode, it's not actually written this way (aka I won't include the type stuff): And that's it. Now someone please help me figure this out, I have no idea what the heck is wrong.

Ok, I'm stumped now. For some odd reason, the lighting doesn't seem to apply property to my model, making the bright yellow color I'm using to test it a dark, puke-yellow color. Before you ask, yes I made sure that isOpaqueCube returns false, and I also tried using the Tessellator to fix it with no results. Here's the code for those that can actually read Clojure code (or willing to interpret it):

I'd like to get an idea of what people do in order to render models for my api. Unfortunately the sources out there aren't always the most accurate. Additionally, Techne Online doesn't seem to be working for me (on a mac, so can't use local version), so I can't get any models (pre-made or otherwise). As such, I'd like to get some examples of code for this subject. Both the code that Techne generates, and the way the code is implemented. I would also like to see the json version of the Techne file (it should be available in the export tab online now I think), so that I can see how I would implement a custom system to render that. So please post some examples here, or a link to some good examples I can use for test samples in my code.

When I was talking about generalizing things, I was mainly speaking about vertex rendering. So I took a closer look at the files Techne generates, as well as the respective Model classes, and I think I can get what I need there. From what I've seen, the model "pieces" are each composed of a single ModelRenderer. These pieces generally have a number of specific properties that get repeated with each one. In other words, generating these "pieces" should be rather easy. The same goes for the ModelBase, as implementing a default render method that just calls the underlying render methods should be easy as well. Notice that right there I just said "default". I plan to, in order to add support for animation, allow the user to define their own render method, which they can use to properly modify each piece before it gets rendered (in order to support animation and the like). As for the actual implementation, it should also be easy, since it's really just some opened and closed open-gl calls from what I can tell, and the model seems to handle the rest. Not sure if this is what I'll go with in the end though. I'm also considering a system for animation where multiple "parts" are created, and it just cycles between them. I'm not entirely sure how well this could work though, or if I'm missing anything.

Would this work for things other than, say, rendering a block side and stuff (because from what I can tell, you're just rendering a single face instead of all six faces, though I could be misinterpreting something)? The main reason I'm making this is NOT for personal use, but for a library adding support for Clojure code to it. As such, I need to make sure that whatever system I use can be used for multiple things (blocks, items, tile entities, actual entities, etc). Of course, all of those things probably won't be in the same function, but having a single system that can handle the actual rendering (vertices, etc) is what I need. Also, the system shown in my earlier post actually did work rather well when I didn't specify a texture, it's just that now it isn't working when I add a texture. The reason I mentioned Techne earlier wasn't because I was thinking your code was implementing Techne. Rather, I need to make sure that the system I end up using is general enough that I'll be able to actually render Techne models (using a .java file is not an option for obvious reasons since this is a different language). In the end I want to be able to read in a Techne model (as a .json), and then use my code generators to generate what is needed underneath.

Yeah, um, this is the first I've ever heard of this way of rendering every single other tutorial I checked used addVertex in some way. I think I understand it a little bit, but I'm not sure if I'm going to be able to use this technique anyways, since I'm trying to add custom rendering to forge-clj. And from what I read, this doesn't support techne models, something I'm going to have to make room for anyways. I think it might have something to do with the icons though. Maybe I should try using the icon instead of the u and v coordinates?

Unfortunately, well, here I guess: Yup, it's Clojure code, so I don't think you'll understand it. Here it is anyways, just in case you somehow do understand it. But yeah, normally I would have posted the code if it weren't for that fact.

Ok, for some odd reason my textures aren't loading on my tile entity custom renderer. It's just a black square that gets placed. The texture I'm using is 16x16, so that might be the issue (I'm not sure how these textures are formatted)? I am using vertex with uv, the texture is being bound with the bindTexture method, and minecraft doesn't say that the texture is missing.

I think the specifications here are what you're looking for. In other words, in json you have "objects" (they act more like hashmaps, but still). They are enclosed in curly brackets ({}). Each pair consists of a string (a key/field name), and a value (string representation of your data), with a colon ( inbetween them. Commas are sometimes used to separate the key-value pairs. Arrays also exist, and are enclosed in brackets ([]). They contain a list of values, separated by commas.

I'm currently working on a wrapper for the Clojure programming language (viewable here), letting you code in that instead of java. As such, making the user use a .java file in this context is kind of.... counter-intuitive. If I need to, and the format for the json files is correct (techne does seem to have this option btw), then I can simply create a code generator for the json files (which is what most of this library is anyways). Why do you say it's only usable in 1.8 though?

I've seen plenty of tutorials about adding it via the exported .java file. However, for my project I'd rather not use that. Is there a way to use the raw techne model file instead? Or if not, then what does the json generated look like, and would that be a viable way of implementing it?

Updated to Version 0.3.0. This adds 3 different systems: packets, event handlers, and extended entity properties. It also changes the existing tile entity implementation to more closely match the new extended entity properties system. Next up: Either custom renders or GUIs. Maybe both. I think I'll do custom renders first though.

Ok, I'm using an external plugin for forge gradle called clojuresque in order to compile clojure code. This actually works rather well but... every time I run this thing the console always spams this: And my build.gradle file looks like this: Even if I remove the clojure.warnOnReflection = true line, and clojure.aotCompile = true line, it still spams this message, and it's getting annoying, and might be confusing to other modders using the library made with this. So what I'm asking is mainly if there's a way to just suppress the deprecation warnings on this thing. If I had to guess, the issue is probably in the plugin itself (it's been abandoned for ~2 years, but still works). I can do without a solution, but it'd be nice if there's a way to prevent it.

Ok, thanks for this, that was useful. As for why, maybe I am reinventing the wheel here, but it mostly comes down to Clojure coding and how people typically structure their Clojure code, or at least from what I've seen. It's to make it more "Clojure friendly", really. Actually wait, where do I put the argument? I thought it was a console argument, but it doesn't seem to like that.

Ok, nvm, I think I actually found something that worked (I tried using the player object itself as the map key, and it seems to be working). Unfortunately, Forge seems to generate a random player name every time I use ./gradlew runclient, so I can't properly test everything. Is there a way to make it so that forge doesn't change the player name every time? As for your question, the answer basically sums down to "it's a more Clojure-y way to do it". I'd elaborate further, but it's 1:00 AM here and explaining things take too long.

Unfortunately that won't work with the way I'm structuring things. I'm using a different way of storing fields (in order to make the code cleaner and minimize field mutation). When the entity is constructed and the properties are registered, it gets the UUID in order to differentiate between instances within a hash-map. Due to this, a single instance has no fields, but just contains the required implementations in order to store these things in a global state. For example, player1 has a uuid in the hash-map bound to a map containing a test value of 0, while player2 has a different uuid in the same hash-map with a test value of 1. Keeps the instances separate, but in one place. I did this successfully with tile entities, where instead of a uuid, I just used the x, y, and z values as the map key. So yeah, because of that what you said won't really work. Thanks though.

EntityEvent.EntityConstructing is fired from the Entity constructor, which is called before the EntityPlayer constructor sets the Entity#entityUniqueID field to the player's UUID . Yeah, I need the UUID for my Extended Properties. Is there an event I can safely call later or something?

Why is it that the same player has a different UUID in the EntityConstructing Event than when they are passed in via onItemRightClick?