Laike_Endaril

You mentioned the cache, but did you also try deleting the build folder? If not, try deleting it (running the "clean" task does this). Other than that, what diesieben said, since there are too many different things that could go wrong to guess...maybe the UV is off, maybe the render isn't being called at all for some reason, etc.

No problem. And yeah, if it's moving faster than most vanilla stuff you might still notice some rubberbanding. Hopefully it's not too bad though, because trying to fix it in an accurate way is a pain if you're already at max update frequency (1).

They were absolutely right, but the entity tracker does this automatically, which is why if you also do it, and end up with different values, you will absolutely see rubberbanding, and if that happens then it will be worse at higher update frequencies (eg. when setting it to 1). Basically you should either be using the built-in entity tracker synchronization, or you should use your own custom synchronization, but not both. I'd suggest trying the built-in one first because if it works, it's a lot less programming.

You may already know this, but an update frequency of 20 means once per second. The variable is not actually the frequency; it is actually the delay (opposite of frequency). Ie. it's not 20 updates per tick, it's one update per 20 ticks. If you haven't tried setting it to 1, go ahead and try it just to see if it resolves the issue or not. It will give a better idea of where the issue may lie. Iirc, either ridden entities or riding entities (or maybe both? I can't remember) update every tick (update frequency of 1)...but I could be remembering that wrong. I know animals use an update frequency of 3, and they're all over the place, so quite honestly having your vehicles update every tick may not be an issue. This somewhat depends on how many vehicles you expect to be loaded at once I guess, but that falls more into the server admin category imo. I was going to mention the possibility of rubberbanding if you don't use the built-in motion variables, but it looks like you're doing so. Still might want to verify them though, just in case they're eg. being transferred *before* you update them each tick or something. Oh, and if your tracker entry does not have "sendVelocityUpdates" set to true, you may want to try setting that to true as well. Also, if you're doing any position/velocity computation client-side, it may actually be causing conflicts with the normal position/velocity tracking. First I'd try removing all custom client-side position/velocity and use and update frequency of 1 with velocity updates enabled. If it works nicely, you can try disabling velocity updates or increasing the delay between updates a bit and see what happens. If it doesn't work...well then something more complicated is probably going wrong.

This is false itemTag is the thing which is null, which means compound.getTag("item") returned null

Well, only thing I can say for sure is that something is null in TileEntityAltar line 108 Caused by: java.lang.NullPointerException at thetrueskeptic.ebtks.tileentity.TileEntityAltar.loadFromNbt(TileEntityAltar.java:108) ~[TileEntityAltar.class:?]

Yep, after doing a short experiment with render distance in the nether, I noticed the observed "sky color" is far darker at *short* view distances. Really short view distances are dominated by the fog color, so the nether has a dark fog color, and when you increase the view distance, the fog color has less effect, so in the nether, the "sky" becomes brighter with longer view distances (up to a point) In your case it may well be the opposite. Ie. your fog color is probably brighter than your skybox color, and your fog color is probably the color you're trying to achieve, I'm guessing. You may want to try setting the skybox color brighter. Edit: You know what, I might have the skybox color and fog color backwards...in any case, try messing with both and observe the results

Well as a starting point, I'd make sure you're not testing with any other mods involved (if possible), especially any shaders, optifine, or anything else that is likely to do anything graphics-related. That aside, the only things I can think of are the skybox color/texture, the sun/moon textures, and the fog color. I haven't messed with any of these and don't know where they're being handled. There might also be other factors I'm not aware of.

If you want to do it from server-side only, you'll have to see if you can find a packet that harmlessly triggers a client-side inventory sync. I haven't looked into that, so I won't be much help.

Well, for timing, if the registry event is used, setting priority to lowest should *usually* catch all fluids...but if some other mod adds a fluid using lowest priority and comes after your mod alphabetically then that could be an issue. Even with post init and lowest priority, I wouldn't be surprised if some things ended up getting added after it (depending on the name), as some mods add fluids dynamically based on ores loaded. I think tinkers construct might do this, but I'm not sure (also not sure what timing it's using if so). The ForgeRegistries#register() method has a callback that might be useful for catching things as they are registered, but I haven't dug deep enough to see what it's actually being used for, so I don't know if trying to hook into that will screw something up or not. Maybe there's a better way? I haven't tried intercepting registry entries as they're added before.

I see a 2781 in there as well. I'd suggest trying the most recent forge version for 1.12.2 (or looking through your entire log to see what the highest minimum required version is; I'm not doing that)

I've solved this in my build protection system by canceling the event on both server and client side, using the same conditions. I can do this in my system, but it may not be feasible in yours if the data needed for the check only exists server-side. Cancelling the event server-side ensures nobody can cheat their way past your protection (for the most part). Cancelling the event client-side doesn't, but if used in addition to the server-side function can make your protection "prettier" by preventing the inventory desync. If someone hacks past it, it will just prevent it server-side (again, only if you're also doing the check server-side, in an identical fashion), and give them the inventory desync, so no benefit for them aside from the very brief window of the block not existing client-side which could allow them to jump on top of it or w/e...but if they're hacking past your protection to do that, they could just as easily use simpler hacks to accomplish the same thing. Once again, I only suggest this if you can do your check identically on both server and client.

Ernio hasn't posted anything since 2017 (and I have no idea whether the mod/api was released, or what its name was if so)

There is no error message in the file you posted. I can only assume it's not the entire log file? There should be log files located inside the "logs" folder.

Good point. The only approaches I can think which would bypass that issue are... 1. Preventing the flow using actual blockstate properties, but I haven't delved into that concept yet and it's probably chock full of caveats. 2. Preventing the flow by altering the behavior of fluids directly. Getting this to work right with all modded fluids would probably be a nightmare unless you find a neat trick.

Depends on how you program it. If you filter using the block position correctly, you can have it apply only to blocks on borders. I'll probably be playing with this idea before too long since I'm rolling my own protection for something as well (and have everything working except fluids and falling blocks iirc). I haven't gotten around to playing with it yet, but you might be able to do something like this: 1. Find the block being placed 2. Find the block which is placing it 3. Check if their positions lie in 2 different chunks, and if so, take whatever actions you plan to take to prevent it My boundaries don't lie on chunk boundaries, so I can't use this method of comparison, but I'll be trying something along the same lines when I get to it. Also, there is a whole series of fluid-related events that may be useful. I haven't gone through them yet, so I can't say for sure, but for now, here's a list: ~SNIP~ Just saw you already tried these events, so nvm about the events. If you experiment with it, maybe you can post your findings...so I can use them for reference when I get around to this again XD

You can also accomplish this without TEs (TileEntities), but only if you do all your own data handling, which I most certainly do not suggest for what you're trying. TEs are the way to go as was suggested; once you figure them out, they're much simpler to deal with in most cases than manual data handling. Since this is your first time dealing with TEs (TileEntities), here's a tip: Don't extend BlockContainer to get your TE on your block, instead just extend Block, and override the methods hasTileEntity(IBlockState) and createTileEntity(). You probably get the idea from the method names, but the first should simply return true in your case, and the 2nd should return an instance of your TileEntity. This is one of the pointers given in the Common issues and recommendations, which is good to read through every once in a while; it will probably end up saving you time by preventing some potentially very time-consuming mistakes (yes, speaking from experience :P)

I haven't tried editing that part of the build file, so I'm not the best one to answer, but... buildscript { repositories { jcenter() maven { url = "http://files.minecraftforge.net/maven" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:2.3-SNAPSHOT' } } apply plugin: 'net.minecraftforge.gradle.forge' //Only edit below this line, the above code adds and enables the necessary things for Forge to be setup. ^ There's a comment there which says not to edit it. Just don't ask me the implications

I'm not really sure what this comment means, but if you have any version of java 6 installed, I'd suggest uninstalling it (as long as you don't need it for anything). I've seen many issues with the wrong version of java mysteriously being chosen, so on my own machine I only have one jdk+jre installed (64-bit 1.8).

Ah, tyvm Choonster. Setting the creative tab in the block solved the issue.

Are you on 1.12 or 1.13? On 1.12 the first task to run is setupDecompWorkspace (after importing the build.gradle). On 1.13 I think the standard setup is just importing the build.gradle? Correct me if I'm wrong; still working 1.12 myself. I have 0 exp. with Forgelin / Kotlin so I can't directly help with any java/kotlin differences.

Can you post the contents of your build.gradle file?

I'm just now finally getting around to adding blocks/items for the first time, and for some reason I cannot get the item for my block into my creative tab. The creative tab exists with the correct icon, and the item itself can be obtained with /give (and has no issues) Main suspects in my eyes are the registry handler class... ...and the item class... ...and here's a link to the repo: https://github.com/Laike-Endaril/Wardstones/tree/1.12.2/src/main/java/com/fantasticsource/wardstones

Usually you can completely replace a block by registering a new block over it. It could be worth trying to extend the original BlockBarrier class and register your new class with the same registry name as the old one. This is basically how I made a fire customization mod; by extending and replacing the vanilla fire block.

Thanks for adding in the build file; it makes importing the project much easier. After looking through your BlockClock and many related classes, I believe adding a TileEntity is the best approach for a clock. You can probably make a clock without using a TE, but it might be tricky to preserve the internal timer state when the world unloads/reloads. I suppose you might be able to get away with using a blockstate property as a timer, but I haven't tried this. Consider taking a look at the BlockDaylightDetector class. It may not be a clock in the way you're thinking, but some of its code could probably be useful here. It uses a TileEntity as well. That's about as far as my guesswork is going on this one. If you still have trouble you'll need advice from someone with more related experience than I have.