V0idWa1k3r

...or just use a fake world. You know, a World instance that only exists locally, without being hooked to the rest of the world that you manipulate to your heart's desire. It also eliminates this issue I already told OP to do that in their other post. I don't see how this is relevant at all. Or, you know, since the program will likely run in the background and execute like once per hour you could just use a separate texture per visible block. You are unlikely to draw more then ~500 at a time anyway since most will not be visible. Since you are doing offscreen rendering to a texture performance is not a concern. Now, responding to the OP: You are likely going to have one image per chunk, that is the most logical way of going about it. If you are not doing a top-down view then stitching those resulting images is kinda non-trivial but possible, you just need to find a right order. Or alternatively you could export them as a list of vertices + texture and then use webGL on your website to combine them into a single world. Getting to the main problem though, the rendering of chunks. It is kinda pretty complicated in the game since the player might or might not even use VBOs and stuff, and the game evolved to make it's chunk compilers multithreaded and stuff, so you will likely have to create your own implementation of a lot of chunk compiling mechanics. Places to look at: RenderGlobal#renderBlockLayer ChunkRenderDispatcher(in general) VboRenderList Unfortunately I am not experienced enough with the game's terrain rendering so I can't really provide a coherent explanation of how the things work. I'll experiment with it a bunch later and report the results.

Well, you still have a CommonProxy, for one. https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/util/handlers/RenderRegistry.java#L20 https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/renderer/entity/RenderEntityTerraBladeProjectile.java#L26 You are not actually doing any rendering, just screwing up the matrix stack, but I assume this is still unfinished, similar to how the sword currently does nothing. https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/proxy/client/ClientRegistry.java#L19 Don't have your proxy as an event subscriber. You already have a dedicated class for that. https://github.com/Korlimann/Epic-Swords/blob/master/src/main/java/com/korlimann/epic_swords/entity/projectile/EntityTerraBladeProjectile.java#L12 Why are you calling onUpdate in the constructor? That is a very bad idea that is likely to crash the game.

Look at PathNavigateGround#isDirectPathBetweenPoints, I think that one is a direct check of whether the entity can actually navigate to the point. That said if you keep giving the entity an invalid path every time it asks for one then it will keep getting stuck. You need to check whtether the block is reachable before accepting it as a valid pathing target.

I think you have a misunderstanding of what the OP wanted to do. He wants to render the chunks onto textures in game. Then export those textures as images to stitch together in an another program. So while the entire thing is not done inside of the game most of it is and only the stitching isn't. At least that's how I am interpreting it and that's a logical way to do it. Still, pinging @AntiRix to explain more. Well, short answer - you don't. You shouldn't just pass opengl buffers between programs. I mean sure, it *could* work I suppose but it goes against the design of the whole thing. You export just enough data to reconstruct the buffer in an another app. I mean, model formats exist for a reason after all, when you export a model in blender it doesn't give you a float[] to put into a gl buffer in your code, it gives you data structures to construct into an array of vertices to convert into a list of arrays in your code. So instead of exporting the buffer you would export the chunk data as an array of block ids + meta, something like a Tuple<string, byte>[16,256,16]. Then in the other app you would use that data to reconstruct just enough to render the whole thing. Considering that this would pretty much only ever work with vanilla you don't even need to reverse-engineer minecraft's model format - just do what the game did before 1.8 - have a renderer associated with each block where most renderers would simply render a cube and others would do more unique stuff - there aren't many blocks in vanilla after all. If you want to support modded however... well, it's pretty much impossible. Render stuff in game and be done with it. That said I suppose you could export the raw gl buffer as an array of data(most likely float[]) and upload it back in your app. As long as the vertex attribs are consistent between the two programs you might just make it work. The obvious issue is that they likely wouldn't be because mods might interfere, and the pipeline is complex enough as it is.

Most I can find is this comment in the devtweaker's source If that doesn't work you could open an issue on their github. Also pinging @Cadiboo since they managed to get it working.

https://github.com/OpenCubicChunks/OptiFineDevTweaker Build it yourself.

...I don't think I understand your point here? They really don't. They are trying to render a chunk onto a texture they can later stitch together. In game. No external programs involved. Look at their description: But that's not the point, really. I still have no idea what question are you actually asking(or rather what it is that you want to know). So again Or at least what it is you want to know. I am happy to answer to the best of my abilities but you need to ask the question first

@AntiRix is trying to render chunks onto a texture, not save a buffer to a file. Please can you explain what exactly are you trying to achieve?

Which part of did you not understand?

There is not much difference between SP and MP since you have a server and a connection in both cases. Do your logic on the server and send the packets to the client(if needed). I am unable to replicate this issue with the code you've provided. This will break as soon as the player changes their name. Use their profile's UUID.

No, not as far as I am aware. You could check every X ticks I suppose but you might then miss something. Do you have issues with checking every tick? Performance should not be a concern since you are not doing much, just comparing ints.

Please define moved. Do you mean changes slots? In the player's inventory only or in any container? If you want any container then the best you can do is subscribe to a tick event, iterate all players, look at their open containers(will be the inventory if the player isn't looking at the GUI at the moment), iterate the stacks in that container and check their slot index against the one on the previous tick. If it changed the item was moved. Keep in mind that it is pretty much impossible to detect slot changes of the item if it happens without the player present, such as a hopper inserting/extracting an item. ItemTossEvent Check the current slot of your item each tick, compare it to the slot on the previous tick. If the slot changed and was the held one then it's not being held anymore.

You can use LivingSpawnEvent.CheckSpawn to detect the spawning itself, then either iterate all TEs in neighbouring chunks to check for your special TE that prevents the spawning(may be slow and won't work if the chunk is unloaded, the TE in this case doesn't need to be a ticking one) or you can attach a capability to the world that would store an array of positions of your blocks that prevent spawning that you update every time one of your blocks is placed/broken and then you can check against that array. In any case setting the resulf of the event to DENY will prevent spawning. You will still need to check that the mob that spawns is hostile.

What version of the game are you modding for? The issue itself looks like a desync issue where the client thinks that it filled the bottle but the server disagrees. Make sure you are only "filling" the bottle on the server.

You could listen to forge's PlaySoundEvent, check if the sound being played is the main menu music and set it to null if it is.

This issue is happening in your code, because one of your checks is failing. Since you have provided zero code I can't help you further. Please at the very least provide the sources for the mhfc.net.common.eventhandler.MHFCTickHandler mhfc.net.common.util.services.Services(full sources of the file, including nested classes)

There is EVERYTHING wrong with both of them both design-wise and implementation wise. A string is an array of characters but I don't see you storing your strings as byte arrays. By your logic - it works so there is no harm in it, right? Even if it works it makes no sense logically - you are not going to use ByteBuffers for your numbers and you are thus not going to use a CommonProxy, the string is not annotated as Iterable<Byte> and your items should not be annotated with IHasModel. It also confuses people all around the world who look at your code - there is no Common side, so why is there a common proxy then? And some of them start using common proxy to execute code they consider common which is plain wrong and has lead to numerous issues, some of which I have helped people with on these very forums, so it IS HARMFUL! Don't just shrug it off because it works. If something works it doesn't mean it's right. If you know what you are doing then by themselves these classes don't do harm. It's a whole other story if you don't though. And a lot of people don't. You are still registering them individually though. Just this time your code is in your Item class instead of your event class. It is also in your proxy. You are actually legitemately writing 300% MORE code by using IHasModel. It also makes no sense design-wise since all items need models. A string isn't IHasCharacters for a reason. Again, this HAS caused issues some of which I had to help people with so it IS ACTIVELY HARMFUL. And in any case you can iterate your items just fine since they already share a common ancestor - Item! So the argument of "but I can iterate them now" is also invalid. It can't though. Proxies by definition contain code that will crash the game if ran on the wrong side. You can't share code between server and the client like this, it happens anywhere else but your proxy. Again, there were numerous issues caused by people trying to do exactly that. Again, if something works doesn't mean it's right and you can't say "code preference" either. You can use strings to store any information but you are not doing that and it's not just "code preference" even though it works. Yes you do, actually. There are multiple reasons to use object holders, the main of which is the fact that stuff in registries CAN BE OVERRIDDEN! If you don't use object holders you now have a useless thing that is not used in the game at all. No, they really don't. The main reason is that they offer no control over when the stuff initializes, so one wrong mention of a class that contains them and now you have nulls everywhere because they reference things that have not been instantinated yet. Actually around 20-30% of issues I have seen on this forum related to blocks/items have been caused by people using static initializers! It is actively harmfull! Additionally if that wasn't enough on it's own it breaks the whole "registries can override stuff" concept and it prevents reloadable registries. Worse, similar to bytecode editing it can and WILL break unpredictably when you least expect it regardless of "complexity". It already had for multiple people who then went to this forum. So please, don't encourage cargo-cult programming and spread misinformation. There is a reason we tell everyone not to use these things beyound simple design issues. There are guidelines to using forge for a reason. Even if you yourself know how everything works you are actively confusing people who don't and are creating more issues in the process. Imagine if opengl had no guidelines and people started doing stuff like IHasVertex for their buffers, or CommonShader that holds the "common shared" shader code, or god forbid used static initializers to instantinate VBOs and other stuff *shrugs*.

Entities are a more general concept than just throwables. An item on the ground is an entity. A zombie is an entity. A player is an entity. Particles used to be an entity too. Entity is basically any instance-based dynamic object in the world that needs to exist on both the client and the server and can interact with said world and it's contents in various ways. Blocks don't fit this description because they are not "instance-based dynamic object", they are singletons that are stored in fixed positions. Items don't fit this description either because they are not "instance-based dynamic object" either, they are also singletons and can only interact with other things by containers like ItemStack(inventory) or EntityItem(world). A particle doesn't fit this description because it only exists on the client, etc. Similar to items and models all entities need a renderer even if your entity is completely invisible. This is not necessairly true. Unlike items which are baked on startup entity models are drawn in real time, no baking required - the buffers are filled each frame. Which is actually the main reason why the game's framerate dies if there are a lot of them. This means that you can push any data into the pipeline. A lightning is an antity that doesn't have a ModelBase associated with it but is rendered perfectly fine. EntityItem fetchs a model to render from respective items, which have nothing to do with ModelBase either. EntityThrowables usually render a simple quad. A ModelBase is just minecraft's way of having "complex" entity models which are composed of cubes that can move around, like a pig's model for example. But nobody requires you to have a ModelBase, you are free to do whatever you want. This is pretty much correct. Register the entity's entry in the appropriate registry event and register the renderer in your client proxy. Well, entities move using the motion varables. motion is simply a vec3 that is the entity's change of position each tick. So if the motion is [0,1,0] the entity moves one block up each tick. Not everything works with motion though, some functions may straight up use the move method without changing the motion. Motion is usually used for "physics", like sliding on ice or falling down, etc. Pretty much all minecraft modding tutorials in a nutshell. This is exactly how you get cargo cult programming people. https://mcforge.readthedocs.io/en/latest/ You can read the explanation in the official docs - https://mcforge.readthedocs.io/en/latest/concepts/sides/ Basically the game has a concept called sides. There is always a server and a client, akin to any online game. The server's job is to do all of the game's logic - move entities, change blocks, do physics, etc. After it is done it sends the changes it made to all connected clients. The client's job is to have a local copy of all the data, receive the change from the server, update the data and draw it in the world. The client also processes input - like you pressing a key on your keyboard and then it sends the press to the server so it can decide what to do with it. There is always a server, even when playing single player you are connected to a server that is running alongside the client. So thus there are two sides - the client and the server. It's not however quite that simple. The sides can have a "prefix" to them. They can either be logical or physical. What's the difference? Well, the "logical" side is simply a thread that executes the code that that specific side needs to execute. So in your singleplayer game you have 2(actually 3, not counting workers and utility but that's not the point) threads - the server and the client. These are logical sides of your game. They are called logical because they separate different logic - the logical server does the game's logic, while the logical client updates the data of the client to later render it(again, a bit more complex in reality but that's not the point), The physical side on the other hand is the physical representation of your game, the binary itself. On your PC you have a binary of the game that contains the executable code. Since your binary creates a window and displays stuff it has client-like code in it, thus it is a physical client. However on the official website you can download a so called "dedicated server" that is basically a server. It does no rendering, it is just a console window(so-called "headless" application), in fact, it doesn't even have the code in it that does the rendering, nor does it have any rendering related libraries like LWJGL - that's why the file size differs even though they both have the same game. This is the physical server. It is physical because it is based on the actual binary - your game has no code that does dedicated-server specific stuff in it(like your game simply doesn't have the capability to process the server.properties file, it simply doesn't include that code), and the dedicated server binary has no rendering code in it. That's why in your IDE you can see methods marked with @SideOnly. This means that the code only exists on the specified physical side. So you need to be carefull when invoking those methods - if your mod runs on a dedicated server and you attemt to invoke a method that only exists on the physical client - that's a problem. A crash rather. So this is where forge's proxy system comes into place. The proxy is a way to distinguish between physical sides - you specify 2 classes, one that is client-based and is free to access client-only methods, the other is the reverse - server-side only. We are talking about the physical sides here! Typically you would have a contract both classes need to follow - a collection of methods for them to have. An interface works perfectly for that. Forge will then pick and instantinate the respective class based on the physical side and inject it into the field marked with @SidedProxy. A common proxy thus makes no sense because there is no "common" physical side. That is correct. Well here is one. It is in the wrong place though since it is client-only and needs to be located in a client only class(not in your client proxy, just in a class that will only be loaded on a client like this) By doing the same thing you are already doing, just in the ModelRegistryEvent instead of in your item's code. Like this for example. I don't think there ever was a good tutorial for earlier versions either. The CommonProxy dates back to the days the proxy system was first created for example and people have used it ever since even though this makes no sense. Simply deleting static will just make the fields instantinate when an instance of a class is created which doesn't really make a difference.

Plants check whether they can stay or not when their neighbour changes, not when the block receives the update tick. Actually a lot of blocks work like that - crops, torches, end rods, flowers, fire, snow layers, cactus, chorus plants, tallgrass, mushrooms, sugar cane, vines, ladders, pots... I could go on but you hopefully get my point. All these blocks don't update(most of them don't even allow the world to "tick" them) but rather detect neighbours changing and re-evaluate themselves. See any of those block's classes to see how they do that. I would recommend BlockLadder since it is probably the least complex of them all. If that doesn't work for you then you might need to use forge's WorldTickEvent to manually run whatever logic you need. There is really no way to make the block "tick" every X ticks without either using a TE(which you want to avoid) or scheduling block updates(which is just as slow as TEs are pretty much but has additional issues that can easily crash your world, especially if there are a lot of them scheduled, I've personally experienced the "ticknexttick list out of sync" issue as an example)

Well first of all you should probably read the comments of the code and understand them. // IMPORTANT! Only spawn new entities on the server. If the world is not remote, // that means you are on the server: if (!entityLiving.world.isRemote) { entityLiving.world.spawnEntity(new EntityTerraBladeBeam(entityLiving.world)); } else entityLiving.world.spawnEntity(new EntityTerraBladeBeam(entityLiving.world)); I mean you have them right there, above your code and still go against what they tell you to do. As for the issue - you are not setting the position of the entity you are spawning so it spawns at [0,0,0]. You can see an example of an item creating a projectile at ItemBow for example. What explanation would you like exactly? I am happy to provide, but you need to ask your questions first. Entities are kinda complex. Now, as for the other unrelated issues of your code that probably arose from the fact that you've used a crappy tutorial: CommonProxy makes no sense. Proxies exist to separate sided-only code that only exists on a specific physical side. If your code is common it goes anywhere else but your proxy. This makes even less sense. A server proxy either provides methods that would crash the client if executed on it or noop implementations for client-only stuff. Your common proxy can't be your server proxy because if it would it would crash the client. es is a terrible modid. You have 64 characters for a reason. The name property is supposed to be a user-friendly name of your mod. IHasModel is stupid. All items need models, no exceptions, and nothing about model registration requires access to private/protected data of the item. Register your models in the ModelRegistryEvent directly. This is kinda nitpicky but why is your entity renderer in your proxy package of all places? ItemBase is an antipattern. There is already an ItemBase, it's called Item. Don't ever use static initializers. Instantinate your stuff in the appropriate registry event. If you need a reference to the thing later use ObjectHolders. Same applies to your entity entry btw. This is probably the most, um, interesting way to use IHasModel. Especially considering that the renderer must be registered in preinit, not in a ModelRegistry event. Also the implementation @Override public void registerModels() { Main.proxy.registerItemRenderer(this, 0, "inventory"); } Entity is not an item. It makes negative sense to call a "registerItemRenderer" for an Entity. Actually now when I look at your methods this doesn't even compile. Are you using an IDE? I also don't think your entity is going to work too well since you've basically copied EntityFireball's code, but are also extending it and invoking the base implementations here and there. Chances are it is doing a bunch of redundant work and also it's movement is all sorts of screwed up since it is performed twice per tick.

@Cadiboo was able to do it recently, see this thread

If the OP renders the things chunk-by-chunk and then simply joins the render output together then it won't be. However the shadows will not work correctly, this needs a two pass drawing with drawing the shadows in the second pass. You will need a custom shader then. Minecraft doesn't have lightsources that cast shadows. Since minecraft uses outdated opengl (1.x) for stuff the camera isn't just a collection of uniforms passed to a shader but instead GL api calls that set up the projection matrix. You can see the game setting up it's projection in EntityRenderer#setupCameraTransform. Specifically it uses the Project class to manipulate the matrix. You might be able to do something similar. Or just change the matrix with basic opengl calls, that should work too. Also relevant: Topic where I described how to render to a framebuffer:

JEI has a wiki describing how to create plugins for it on it's github page.

Please define "specific type". Do you mean how to test whether the ore dictionary contains itemstacks for a specific name? Use OreDictionary.getOres. Use the overload that also takes a bool. The list will be empty if the given name was not associated with any itemstacks in the oredict. You don't. You construct a new itemstack with the new item and use the new one.

You are returning the wrong arms in ModelDeath#getArmForSide. You return either LeftArm2 or RightArm2 and those are never rotated. Their parents may be, but they aren't. ModelRenderer#postRender changes the matrix according to it's rotation, not the rotation of it's parents.