williewillus

Hello all. I'm trying to finish the ProjectE homing arrows. They currently have a crap linear "point directly at target and go there", but I want something that's pretty and arcs towards the target. I'm fuzzy on how projectiles in Minecraft work, but I'm gonna try to bump the rotationPitch and rotationYaw so the arrow faces correctly. I've read some pages online, but currently have no idea where to go. What I have so far: [*]Get the arrow's position vector [*]Get the target's position vector [*]Subtract the two vectors to gain the one that points directly from the arrow to the target I need to find a way to rotate the arrow vector onto this vector (someone says cross product and axis-angle rotation), but the problem is.... how do I apply this back to Minecraft? Need to find how to bump the rotation and pitch, and how to reset the arrow's velocity vector. At a loss here, and some explanations and sample (pseudo)code would be nice My trigonometry and vector calculus are extremely weak, so please explain your reasoning if you give me sample code.

Hey guys, Whenever we want to have textures that aren't linked to a specific item or block, we use the texture stitch event to manually add entries to the texture atlas. Then, we're able to use the TextureAtlasSprite we get back to draw things in the gui, etc. What I'm looking for is something equivalent, but for models. Let's say I have a model "arbitrary.json". Right now it's simply a "builtin/generated" model with a texture specified. (That texture is registered during stitching). Some time during my entity's LayerRenderers, I want to take this model, load and bake it, and render it on the entity in the "flat 3D" style of held items. This could be done in 1.7 with ItemRenderer.renderIconIn2D, and I know it can be done in 1.8, but I'm not sure what to call to register and get this model arbitrarily and to render it on the entity. Keeping in mind that this model is NOT linked to an item and shouldn't be. Tl;dr stitching and rendering arbitrary icons, but for models. How?

If I recall correctly, vanilla 1.8 has a entity NBT tag "NoAI" that disables all AI and physics on the entity that it is applied on.

I am a very strong proponent of everyone updating and moving to 1.8 and the newer, faster ways of doing things. However, I think that part of the reason why migration and adoption is so slow is because there is little to no documentation for any of Forge's additions to the model system, and we as modders are simply not aware of the things that we can (still) do with Forge's provisions in 1.8. (For example, I did not know something like Botania's animated lexica opening animation was possible with 1.8's static models, but apparently it is!) I'm talking about everything from flexible models, perspective aware models, to ModelStates, smart models, animations in b3d and obj, the model baking pipeline (how do you even use it?), transforms, the custom state file format, etc. Documentation is nearly nonexistent and the classes are not documented very clearly - I've tried trudging through the code and for people who aren't very versed in computer graphics, it's not immediately clear how everything fits together ("what's a TRSR? why is there scary linear algebra everywhere? I want my ISBRH's back! *sob*"). The examples on the forge debug folder are simply debug tests, and do not cover most common use cases either. My request is that we get together and write some sort of "complete guide" to the 1.8 rendering system. This could range from simple descriptions of the classes and what to use when, to the full runtime code path of what happens when (mainly focusing on Forge stuff and where Forge hooks in, etc.). We could do it here and I'll add it to the main post as information comes along. As it gets fleshed out, we can move to the readthedocs repo Thoughts? The full block model rendering system: The full item model rendering system: Useful features added by Forge:

...what? This is using JSONs here. I'm not touching the tessellator or GL at all. AND I said not to worry about the sticks, I'm concerned with the big log in the middle here. Please read more carefully -.-

I am trying to remake what was a TESRed block into a model system block. Information: 1. Using Forge blockstates json: https://github.com/williewillus/AdventureBackpack3/blob/master/src/main/resources/assets/adventurebackpack3/blockstates/campfire.json. 2. Both the campfire base model (pebbles) and the log submodel are standard-issue block models created in MrCrayfish's model creator. 3. What I want: The campfire base model, with a log as a submodel that is slightly tilted upwards (20 degrees). Reference from 1.7 TESR: http://gyazo.com/260e049dbb252d89fffc82536621c00e. 4. What I get: The texture itself becomes fucked or the rotation is completely borking: http://gyazo.com/08753bac6c1bb9d4dda64da4b7c80aec. The sticks from the 1.7 screenshot are not present because I haven't done them yet 5. Interesting things: In the Blockstate V1 spec by Fry (https://gist.github.com/RainWarrior/0618131f51b8d37b80a6), Zaggy commented that transform{} modifications are not about the center of the block. If that is so, what point are they about? How do I change it so that it works? Should I just ditch this and go for b3d? (If so, any examples of how to use Blender?) 6. Interesting things: If I specify the rotation angle as a multiple of 90 it works completely fine. Anything else, even 91, borks completely. In the spec above it says that these rotations are unrestricted, so this is confusing... Thanks for the help

Also note that any ChatComponentTranslation 's sent from server to client will use the client's locale.

Override Item.onCreated for the latter. It is called when an item is pulled out of the crafting or furnace result slot. You get the Itemstack to modify to your liking

It's obscured/separated from the mod workspace now, I just use an MCP decompilation, forge docs, and other mods as references.

That was it, I derped hard there Thank you!

It's just telling me that onUpdate()'s descriptor is ()V My gut says that the ints it can't find refer to the invocation of getBlock() that I added, which means that I may have retrieved them from the fields the incorrect way. Can someone more experienced verify?

Hiya, I'm starting to feel my way around ASM and bytecode manipulation, and decided to create a fix for one my most annoying bugs of all time, https://bugs.mojang.com/browse/MC-29475. I know what base edit I need to do, I need to change Line ~382 of EntityArrow, in its onUpdate() method, from this.field_145790_g = var16; to this.field_145790_g = this.worldObj.getBlock(this.field_145791_d, this.field_145791_e, this.field_145791_f); In a MCP environment, this fixes the bug completely with no side effects observed. Here is my effort so far using ASM coremodding: https://github.com/williewillus/ArrowFix I know for sure that my instructions are injected into the correct place in the method successfully; the game starts and runs. However, the game crashes when I fire an arrow, with this error: http://pastebin.com/5sZFV44f Which tells me that I may have formatted my instruction injections wrongly or used the incorrect instruction altogether. Any pointers on where I went wrong, how I can improve?

Thank you!

I moved manifest.mf to src/main/resources/MANIFEST.MF. On build the proper manifest is included in the root directory of the jarfile, however a new META-INF is generated with a "blank" manifest inside. Same thing occurs if I move it to src/main/resources/META-INF/MANIFEST.MF, except that the proper manifest does not show up at all in the jarfile (Gradle overwrites it with the blank??) Neither of these allow for FML to load the mod.

Hey guys! I finished reorganizing my mod workspace similarly to how bspkrs arranges his, and updating my bugfix mini-coremod to 1.7.2 It works completely in my workspace. However, when I do gradle build , the resultant jarfile has its META-INF/MANIFEST-MF replaced with a single line: "Manifest-Version: 1.0" The line where I specify my FMLCorePlugin is missing. If I manually readd this line to the manifest in the jar, the mod works as intended, but that's not really in the spirit of gradle's automation, eh? What is happening and how do I correct it? Source: https://github.com/williewillus/XPFix/