jabelar

In addition to what Ernio said. To intercept the normal inventory you'd probably need to handle the GuiOpenEvent and open your GUI and cancel the default one. Also, you have to consider the behavior whenever you run over stuff on the ground, or any other time stuff is automatically moved to the inventory. You'll have to handle all those cases (also probably with events) to move them into your special inventory.

I also have a tutorial on blocks with GUIs that work over time (i.e. Furnace) here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-containers.html

To clear up some confusion on this. If you're trying to spawn vanilla particles, you DO "initiate" the spawn on the server. This works even though EntityFX is client side only class because the spawn particle method doesn't actually use the EntityFX class (which is not available to the server) but instead has a mapping to a string particle name. When you do this, the server will take care of notifying all clients, each of which will create the actual instance of the EntityFX class. So I would still sort of call this "spawn on the server" since you initiate it on server side. If you're trying to spawn custom particles, you should still initiate on the server, but you have to implement the packets yourself to tell each client to instantiate the EntityFX. The point of saying "spawn particles on the server" is that you want your code to initiate the process on server side only, and then the server should take care (either using built-in sync for vanilla particles, or using custom packets for custom particles) of syncing the clients.

Okay, cool. You had so much information about all sorts of artifacts it wasn't clear to me which one might be a problem. I'll check it out.

Hmmm, that is a tricky situation. One approach might be to use an item stack NBT on a stack of a vanilla item. I am not sure but suspect that the client would tolerate getting NBT data that it doesn't care about. The hard part then is that the item will actually be the vanilla item (with NBT) on the server, so you'll have to intercept a bunch of events for interaction with the item, etc. where you would check the NBT to see if it is your special item. For clients that actually have the mod installed, then you'd have to intercept the rendering of the item to show it properly.

Invisible blocks are just blocks. But if you want to test it, go find my Unique Artifacts mod. Yes, but I can't think of any mods that create visible blocks on the player's head. Does yours do that? I'll check it out.

Yeah, there is a lot of scenarios to check. But the logic is really clean so the scenarios you mention aren't relevant. What I'm doing is detecting when the player holds a regular torch and then placing invisible light emitting blocks accordingly. But I only place it if there is air in the location. So if you're under water it works (meaning that the light goes out) and then comes on again when you resurface (for realism I suppose I could make an "extinquished torch" as well, but I'm just proving the concept). Since the block doesn't have any collision box sand and such seems to work normally. Also, because it is just working when holding a normal torch if you drop it, it is just dropping a regular torch. The blocks will "kill" themselves over time so if the player dies or something it shouldn't cause issue. I'm not saying that the approach is new, however, it was much easier to implement than I expected and not laggy at all (most people including myself thought it would be). Also it doesn't mess with G11 or anything so is really a beginner level mod. Other mods with similar effect like Dynamic Lighting has a lot of compatibility issues. In terms of mod compatibility I suspect that only another mod that places invisible blocks in same place would have conflict.

Hey, sorry for dredging up a topic that is two weeks old. However, now that I had day off I had time to try to figure out how to make a handheld torch. It was actually really easy and doesn't seem to lag. Here is a vid of it working: What do you think? The technique I used was to place an invisible torch at the head level of the player. It is a block, so I had to do things to ensure you could still interact with other blocks (that is why I do a bit of digging at the end of the video), and also needed to handle case when you're going through doors (since there is a point where the torch would interfere with the top block of the door) and other 2-block high situations like running through grass. Overall though I was pleased with the result and it really wasn't hard to do. I'll write up a tutorial soon.

So I should use world.isRemote on the spawn method instead and I'll be able to use Minecraft.getMinecraft()? This is a common misconception. The @SideOnly classes (and methods) are not available to Java at all if you're only running the other side. However, Minecraft is a bit "lazy" when running single player because it runs both sides in same Java executable, so references to the wrong @SideOnly classes might actually work (because the Java has loaded the classes for both sides). But it will definitely crash when you run server only. For code that is loaded on both sides, there is a lot of data syncing going on so sometimes you want to only do something on one side and let Minecraft sync the other side. That is when you use the isRemote field. For example, when generating structures you should only place the block on the server side. So you would check for !world.isRemote before placing the block. Anyway, placing blocks at ground level or below should not be slow. If you generate high in the sky, lighting will cause you trouble though and really slow things down -- I actually came up with a way to disable the lighting updates while placing multiple blocks that fixes that (literally changed from 20 seconds down to 2 seconds).

To be clear, we're talking about the application arguments in your Eclipse Run Configuration that you're using to launch in dev environment. As mentioned, you can add the --username=<your_user_name> and --password=<your_password> arguments.

Yeah, I was thinking that maybe you could just save all height values. It still seems a bit wasteful though since you only really care about spots where you dig. But like you said, it isn't really that much data for a modern computer to record all original height values when chunk is generated.

Yes, I was going to suggest something similar (count accesses to a unique page rather than edit files). In terms of github, you said you want to edit files based on the mod's usage but also say you don't want to do a commit. Isn't that pretty much the same thing? I don't know how you'd get git to consider a new file in a repository without committing it. I'm still not sure how you could prevent redistribution, but I guess you're just trying to detect redistribution?

There is actually a heightValue (the method for retrieving it has different names in different versions of Forge, but something like World#getHeightValue() method) for each X, Z position. So my suggestion is this: 1) Create an empty map to hold the original height values according to the world X, Z position. 2) Handle one of the related events, probably the PlayerInteractEvent, or maybe BlockEvent.BreakEvent or the BreakSpeed event as that might be able to cancel the breaking as well. 2) If you're trying to dig with your tool, check if there is already a heighValue in the map you created in Step #1. If yes, then cancel any digging more than 3 blocks down or whatever. If no, then add the height value to the map and allow digging (since this means it is first time you dug in this location). I think that would work. The one thing I'm not certain about is whether trees are included in the height value. I think they are not, but not sure. If they are included in the height value then what you would do is same steps but you would check for leaves and logs downwards from the height value until you hit ground and then put that in your map as the top block.

There are actually three different versions of quantityDropped that take different parameters. One of them is: public int quantityDropped(IBlockState state, int fortune, Random random)

I've got a tutorial on making a version checker here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-making-mod.html Basically during loading it checks a string versus a web page and sets a field to indicate whether it is latest version. If not, after the game starts it will display a chat message to the player.

I'd also suggest that even the goal of compiling multiple projects at once with shared gradle file might be mis-advised. Because the Forge library gets updated frequently, as do SRG name mappings, once you have several legacy projects you'd have the problem of having to update all of them before compiling any of them. Sure you have to do a separate build per project, but that is only a 10 second activity to type in the command and another 10 seconds to drag the resulting JAR someplace. In my experience, I only actually build the mod infrequently -- maybe every couple of weeks. Maybe you don't know that you don't have to build the mod explicitly to test your mod during development; instead you just need to make a Run Configuration in Eclipse and run it directly from Eclipse.

I agree that the light updating can cause a lot of processing slowdown, even when simply placing a regular block if that block is high in the sky. I have a mod where you can spawn a castle in the sky and it was extremely slow. After playing with placing it at different heights and then also playing with disabling the light updates I found that it was the lighting update causing serious lag. My work around in that case was to disable updates except for every occasional block placed (since I knew I was going to spawn a bunch). Anyway, my point is that you would have to handle the automatic updates that happen after a block changes, in addition to just the movement of the torch. And also I confirm that unfortunately the simple way to do the moving torch (i.e. placing invisible light-emitting block as you move) will probably cause lag. However, if you don't mind it being a bit inconsistent, you might get away with doing it occasionally. Like if you time how long it takes to update you can just update every so many ticks. If a person is moving quickly it might create a flickery effect but that might be okay for a torch, and once they stop it would catch up fairly quickly.

Ahem. Weird, I thought I read through whole thread. Sorry! Of course it is easy to sound smart when I copy what you said!

I usually do this sort of thing using the block's addCollisionBoxesToList() method. The addCollisionBoxesToList() method is generated dynamically, is public, and can be overridden to provide and collision box you want! Since this is called by path-finding, you can have different collision boxes depending on the entity type or other entity-related variables.

Actually, in the error message the prototype for the first method has seven ints, whereas the second one has only six ints. I think maybe you're missing an int parameter.

What do you mean exactly? There is World#getTotalWorldTime() method which returns how many ticks (which happen at 20 per second) since the world was generated.

I don't think you should be comparing states, especially the default state because I think if the chest is rotated it probably isn't in the default state. Why don't you just compare the actual block instead? With something like if (this.worldObj.getBlockState(pos).getBlock() == Blocks.chest)

Yes, the whole point of extending Block means that anywhere you use a block you can use your class that extends Block. It is basic Java and has nothing to do with Forge.

I have a tutorial on this as it is a common problem: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-custom-entity.html Hopefully one of the tips there will solve your problem.

As you partially discovered, the width, height and also the setSize() only affect the bounding box. For scaling the model, you do that in your model file for the entity. In the render method that is called, you add a G11 scale operation. Note though that you may have to do a translation before and after the scaling, otherwise the "feet" of the entity will go into the ground. Basically what you need to do is: 1) G11 translate downwards by the distance your origin of the model is above the ground. 2) G11 scale 3) G11 translate upwards by the distance from Step #1 times the amount you scaled the model.