Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/23/20 in all areas

  1. Block drops are done using loot tables, vanilla sources are a good reference, and the Minecraft wiki has a breakdown of the loot table json. Unfortunately the forge docs are out of date, I use Google and the forums search to get info on stuff I tinker with. Lots of vanilla sources and forums reading!
    2 points
  2. User was banned for piracy Buy the game
    1 point
  3. Stacks in rendering is something like: Each matrix in stack holds a series of transformations (position, rotation, scale). When you render something, it undergoes the transformation of all recorded transformation in the stack. When you pop a matrix (let's call it matrix A), it removes all the transformations after the pushing of matrix A. For example (pseudocode): pushMatrix(); translate(3, 0, 2); // move 3 units on x axis, and 2 units on z axis renderModelA(); pushMatrix(); rotate(180, 1, 0, 0); // rotate 180 around the x axis renderModelB(); popMatrix(); scale(2, 2, 2); // scale 2 on all axis renderModelC(); popMatrix(); Model A would be rendered with translation of 3, 0, 2. Model B would be rendered rotated 180 around x axis and translated 3, 0, 2. Model C would be rendered 2x the size and translated 3, 0, 2. Since the matrix involving the rotation is already popped at the time Model C is rendered, the rotation does not apply to Model C.
    1 point
  4. Model controls the entity's appearance; it doesn't control the collision box (which is used in code that handles physics). An entity can have a huge model and a small collision box at the same time. MatrixStack is used to record the transformation of rendering via a stack. It is similar to the stack manipulation of GlStateManager in earlier versions. An example of updating from GlStateManager to MatrixStack is this. As for the obfuscated names, you should update your Forge to latest. The mapping has been updated in the later versions (I was using 31.1.0 and experienced the same thing).
    1 point
  5. Instead of doing checks via their registry name, maybe you can try using their registered biome instance, should avoid the problem of mismatch string in the future.
    1 point
  6. Yes I understand your question and I can see 20k JSONs being overkill but if you see the vanilla code, that's pretty much the approach taken. For example, the clock item changes texture depending on the time of day in a gradual manner. The way vanilla goes about this can be seen in my attached image. Did you see it? yeah... it might seem like overkill (and it actually doesn't stop at 40, it goes up to 63) but that's how it's done. Datagens will reduce your workload a bunch and all you need to do then it preferably order your JSONs in folders in order to organize them. Good luck! I know this answer wasn't helpful but at least I hope its inspiring or idk haha.
    1 point
  7. McJty has an example of a simple chunk provider: https://wiki.mcjty.eu/modding/index.php?title=Tut14_Ep12 You could also look at the vanilla chunk generator that generates the flat world.
    1 point
  8. 1. Don't create base classes. 2. Don't static initialize registry objects (your item in this case).
    1 point
  9. I have been digging through forge, and have not seen how vanilla generates ores yet. I did see the ChunkEvent, which looks promising. Mind pointing me what directories to look in for vanilla world generation? Not too familiar with the code base yet. For anyone in the future, check `DefaultBiomeFeatures` for implementation for structure, entities, ores, blocks, etc
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.