V0idWa1k3r

Well, you are completely free to override the values that enum holds though... you know, via reflection. Apart from that while I don't truly understand what you are trying to do I can see that this method Is only called to change the value of World#skylightSubtracted. And if that's a field then you can modify it in a tick event after the world has ticked(hint - use the phase to check that it is run after the rest of vanilla's code). You know, modify using reflection that is.

There was also the 1.2.x -> 1.3 transition when Mojang "merged" the client and the server code. There was no "common" code in 1.2.x, period. If you wanted your mod to work for multiplayer you had to write a separate version. I think there even was a separate API for multiplayer mods - Risugami's ModLoaderMP(although it might have became obsolete earlier)

Well first of all your mcmod.info is broken Next, your obj models are broken faces in .obj models must have either 3 or 4 vertices per face, not more. You have more. Don't ever use static initializers. Instantinate your stuff directly in the appropriate registry event. Also ItemBase is an antipattern, there is already an ItemBase, it's called Item. IHasModel is stupid. All items need models, no exception and nothing about model registration needs access to private/protected data from the Item. Register your models in the ModelRegistryEvent directly. CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file or anywhere else but the proxy. This makes even less sense. A CommonProxy can't be your server proxy. Server proxy either provides methods that will crash the client when invoked or noop implementation for client-only methods. If a Commonproxy were to do that it would crash the client. As for the issue - look at the javadocs of @EventBusSubscriber You need to provide the modid property value to your annotation. Also don't upload your code like that. Use github or something similar. Oh, also that is not how you use an API. Don't ever distribute any api in your mod but your own. Use the API as a library with your IDE or gradle.

Any reason you are doing this? Biomes are singletons, you can compare them by instances, there is no need to compare the classes. int x = (chunkX * 16) + random.nextInt(15); int z = (chunkZ * 16) + random.nextInt(15); This may cause runaway chunk generation, read and understand. As for your actual issue: The name for the template you are loading is static, thus is the same for all instances of WorldGenStructure - so as a result all your structures generate with the same template.

You are mixing vanilla blockstate format with forge's. Use either one but not both. BlockBase is an antipattern. There is already a BlockBase, it's called Block. Well, why should it? You've specified the property fine, (de)serializing it fine, sure. But you are not doing anything with it. You are not setting it anywhere, nor handling it in Block#getStateForPlacement or anywhere else. Unless you are using vanilla's setBlock to set the property it will always be facing north. As for your log:

I think that entity attributes are synced between the server and the client automatically(see NetHandlerPlayClient#handleEntityProperties). The snipped above would be executed on both sides. You can trace the call hierarchy of any method using your IDE to see where it is called from. For example EntityJoinWorldEvent here is fired in World#spawnEntity. And World#spawnEntity is called from both WorldServer and WorldClient. So what I am trying to say is - use your IDE to answer questions like this. Either trace the call hierarchy or just place a breakpoint and see which side it is triggered on. If anything is marked as @SideOnly at any point - that is a strong indicator to keep things side specific. Apart from that all logic should run on the server, the client should do as little as possible. The client's job is to render things and accept input. Mostly everything else should be handled on the server.

Don't compare strings like that. Use equals. I am unable to replicate the crash in test environment. And the code provided on github shouldn't crash. I see that you've changed it recently. Is the issue still relevant? As a side note - don't set the loot in the chest manually, use loottables.

Considering that it is another mod most you can do is report the crash report to the mod author. You could also change the player's dimension though MCEdit. Or alternatively you can use any NBT editor and edit the player's NBT data: Open the world.dat file with any NBT editor of your choice. Navigate to Data -> Player -> Dimension Change it to the dimension you need, like 0 for overworld. Navigate to Data -> Player -> Pos Change the values in that array to match the values of Data -> SpawnX/Y/Z to transfer the player to the spawn. Save the file. For multiplayer do the same, but instead of opening world.dat open playerdata/%UUID_OF_YOUR_PLAYER%. You can lookup the player's UUID online.

Why? If the "most terrible thing" occured then you should crash the game. Actually you should crash the game in most cirumstances. What's your reason for avoiding crashes? Apart from some edge-cases with IO/Network by writing code that works and has checks to prevent crashes. Like if you are afraid that a value is null then you check that it isn't null before proceeding, etc.

From what I can tell annotation-based configs are created and injected when the mod is constructed. So even as early as pre-init should be fine. I've just debugged it and can confirm that the configuration indeed exists at preinit.

You can get a Configuration for your mod by using ConfigManager.getConfiguration. If you haven't specified the name in your @Config annotation then it will be equal to your modid. That configuration will contain all categories/properties you've specified in your annotation-based config and you can do whatever you want with it just as you would with a normal Configuration.

Object#toString will return a fully qualified class name appended by @ and the object's hashcode in hex. Item doesn't override that method so you get this. In any case don't use metadata for buckets, use capabilities to store the fluid. As for the model - forge uses a custom model for it's buckets - ModelDynBucket. It is needed because any mod can add any fluid it wants and the forge bucket must be able to contain it and display the propper fluid textures. You can utilize forge's bucket model in json - the parent model becomes forge:forgebucket, and the textures it expects are: base: The bucket's empty texture fluid: The dummy fluid texture. I think this is basically the mask for the fluid's actual texture to apply to, and anything outside of the mask is discarded. You can use the dummy fluid texture provided by forge - forge:items/bucket_fluid if your bucket is of the same shape as vanilla's, otherwise you need to create it yourself. cover: The bucket's texture that has fluid in it, but the fluid's pixels are transparent. If you are using forge's blockstates you can also pass some custom data: fluid: the name of the fluid to put in the bucket when baking. If this is not specified water is used as a default fluid. flipGas: whether or not to flip your texture upside-down when the fluid is a gas. applyTint: whether to tint the fluid's textures based on the fluid's colour. Actually you can read the javadoc yourself - ModelDynBucket#process. If you need an example of using the dynamic bucket model with custom buckets - here is one. Note that the example uses forge's blockstates to define the bucket's model, not a model json. And yeah, these parameter names make no sense. I can kinda see naming strings as str_something, although that is actually what's called a Hungarian notation(kinda, but close enough for me to classify this as one) and has absolutely no place in modern programming whatsoever(and I think you are the first person I've ever seen to apply it to java code, congratulations), but why is Item also named like that? Or an int? This makes zero sense.

Well, updateScreen happens once each tick, drawScreen happens each frame. There are 20 ticks a second and any number of frames per second. Depends on how you do it. If you have the position value changed each tick, but calculate the interpolation based on partialTicks each frame then yes, it will be perfectly smooth. Otherwise no, it will have issues with too low or too high frame rates.

You are thinking about it the wrong way. Have a counter field that gets decremented in the tick event. When it reaches zero type your key and set it to the delay you want.

You can't just return 1 when the method wants you to return a T where T is an instance of your capability. This is basic java. You need to return a wrapper around your capability that only allows access to certain slots.

That's what I meant by "or something". I don't think it really matters, LootTables are not a IForgeRegistryEntry and are managed separately. Currently it doesn't matter when they are added to the set. If you want - yes, you can absolutely register them in pre/init. If they ever become a IForgeRegistryEntry though I will be telling people to use the appropriate registry event :P.

Just put them in the run/mods folder if you just need them for testing. If you actually want mod integration then you need to add them as libraries through your build.gradle file or put them in the libs folder and add them as a library in your IDE.

This is the cause of your issue. When loot tables are reloaded then all loot tables from the LootTableList are iterated using foreach. This method adds a loot table to the list. Obviously, you can't modify a collection while it is being iterated using foreach, hence the CME. Do this method soewhere else, like in a static initializer or something.

Are you sure? What's this line then?

Well you could type into the console with a robot, sure, I guess. There is no console on an integrated server though, only the dedicated. Chat messages are typed on a client, then sent to a server. I meant the logical server.

Use it as a library. You can use a proxy-like system where you have 2 classes that share a common interface that provides the contracts for the methods. If mod A is loaded then you instantinate the AProxy class that references mod's A code. If it isn't then you load NoAProxy that provides noop implementations. You can use reflection to instantinate the proxy, this way it is guaranteed that your proxy class will not load unless mod A is present.

Well, yes, if the fields are static then they are not instance-based and thus you can't simply create another instance and be content. You need a different approach. I kinda see your point but this is ultimately more work than the one config idea. Keeping two configs means that you now need to write the ugly: int hardness = player.isConnectedToAServer() ? ServerConfig.hardness : ClientConfig.hardness; everywhere(pseudo-code obviously).

The robot class in java exists to simulate mouse/keyboard input. The server doesn't care. It doesn't even listen to any input.

Particle textures are determined at BlockModelShapes#getTexture. If you inspect the method you will find out that it has hardcoded special cases for any vanilla block that has a TESR. Thus the only approach for you is to have a IBakedModel associated with your block. You don't actually need to have any quads in the model as long as you return the correct texture in IBakedModel#getParticleTexture and your block doesn't return INVISIBLE in Block#getRenderType(unfortunately returning invisible makes the particles have no texture) you will be fine. And yes, your model may specify a particle texture without specifying any quads and that is acheivable through json alone.

You must have done something wrong. I just used this utility and was infact able to make a remapped OF jar that works absolutely correctly. Show your command line input for running the deobfuscator, please.