IdrisQe

Oh wow, that's really cool. It's a shame it had to be closed, but hopefully the new work between you and Grondag can lead to a version of this in Forge, or at least in some form that's easily accessible by modders. I saw Grondag's mod when it was released, but I didn't really see the connection since those were custom blocks and didn't think that what was done there could be done dynamically to blocks on worldgen. If BetterFoliage could make smooth leaves with that, and NoCubes got working on 1.12, both without coremods, that would be fantastic. The possibility of having Optifine-like features such as the better grass, better snow, connected glass, etc. but customizable would be a godsend to modders. I can think of so many possibilities for that. Those very buggy screenshots shown in the PR makes me think that stuff like that could also be used to render directional block shadows, godrays, and stuff like that without shaders, even, if implemented. That would be brilliant. I hope the performance issues can get solved and that some variant of the PR gets accepted, because clientside rendering tech is becoming a bigger and bigger part of many mods, and it seems to be an area somewhat lacking in Forge.

I'm not sure if this is even possible without a coremod, but I'm looking to intercept the rendering of fluid sides, in order to stop ones from rendering that are against blocks with specific properties. Vanilla has a system of doing this, which it uses to stop water faces from rendering next to full blocks. I can't seem to find any forge hooks or classes related to fluid rendering, however. Basically, I'm attempting to make fluids not render their sides when next to non-solid blocks that have bounding boxes/collision boxes (essentially if it isn't air or some air substitute) Pretty much I want to stop the horrifically ugly air pocket rendering around non-solid block faces similar to 1.13 (though not actually putting water inside a block and all the physics changes and stuff) I know doing this would break water if it was next to a fence or something... And it would ideally be better to find a way to implement it like how Vanilla did with Glass in one update... Though I imagine that wouldn't be feasible since it was probably a direct change to the water rendering logic. It's probably impossible in modern versions, and the only implementation I found, AquaTweaks, is an outdated coremod stated to not be possible on current versions, which only worked with specifically implemented blocks. I just really don't want to have to wait for Forge and every mod I'm using to update to 1.13 in order to just not have horrible-looking non-full blocks underwater.

I'm not sure what's unproductive about suggestions. The base of the suggestion had nothing to do with coremods. The point I was making is that mod authors (any mod authors, not just coremod authors) aren't given any warning before a new reccommended build comes out, and as such, have no time to make sure their mod works correctly on that version before it becomes the defacto "standard" of the modding community for that version. It doesn't help to specify what versions you can and cannot run it on if you don't have enough time to react to even update that single line, and if you have absolutely no way of knowing what builds it will work with until the build is already out. The moment a reccommended build gets released, it's entirely possible that a user will download that, since it's the reccommended and it's above the lowest build needed listed on the mod page, and then find out the mods don't work, and complain to the mod authors. Giving even a brief period where the build is out in the open but not the RB yet would allow mod authors to prepare. If they can't make it work with that version, it would at the very least give them time to update that line, or mention in their mod page description that it doesn't work with versions above [version]. I don't know how making a build with changes the Reccommended Build literally the same day those changes are implemented amounts to giving modders enough time to update. Unless they're super fast and not at all busy with other things, and are very actively watching the Forge builds, even 24 hours wouldn't be enough time to react if there was any heads-up. Literally all my suggestion boiled down to: What: Give mod authors a heads-up when a new reccommended build is coming, stating exactly what changes it contains since the last reccommended build. How: Add some note or something on downloads page, make a tweet, whatever, that says "Build [whatever] will become the reccommended 1 week after release" or something. Why: So mod authors have a week to make sure their mods work with the reccommended build before it becomes the reccommended build (and therefore the build most users expect any mods to work on), to avoid day-1 reccommended build downloaders flooding complaints that the mod doesn't work on the reccommended expected build. And instead they focused on me using the recent coremod reccommended build fiasco as an example, complaining about coremods and how absolutely terrible they are and that no mod author should ever use them etc. etc. and shrugged off the suggestion because "it's coremods!" and replied in a tone that was somewhere between putting-down and outright condescending. When really, this would help any mod author who might have their mod affected by builds in-between the old and new reccommended builds. Instead of needing to either wait for a reccommended then hurry to fix it, or continually make sure it works on every single latest build leading up to the reccommended, they could then see "oh that is going to be the reccommended in a week i'll make sure it works with that build since that's the build most users will probably be using in a week or so". Besides. Being unproductive isn't a good reason to outright delete the thread, wiping any memory of it from existence. Look at those examples I posted at the bottom. Those are the definition of unproductive, terrible forum behaviour, yet they weren't deleted, even after quite a while, so why was I singled out so promptly for the purge?

http://www.minecraftforge.net/forum/topic/66762-about-reccommended-build-candidacy/ So, I posted this the other day. A suggestion regarding how Forge does its releases to help modders, I won't go into the details here. LexManos himself replied, and was frankly rather condescending in his response. I posted again, trying to explain better why I thought it would help in a reasonable manner, even though I was upset at how I was responded to. I also voiced that I was displeased with how I was responded to, and with the implications of some things said, but tried to remain as civil as possible about it. Upon coming back to the forums today, I found, instead of a response to my response, perhaps with the thread being closed after a difinitive "no" or something, that my thread had been outright deleted with no explanation. I'll be blunt here: This is not good forum management. If my behaviour was in some way unnacceptable (and I would say honestly it was at worst equally unnacceptable to how I was responded to) then I should have just gotten warning points and the thread closed. Instead I find it's just gone without explanation, without getting to see if anyone responded, or anything. I don't understand why my thread, where I was trying to post a civil, well-intentioned suggestion, was deleted, when threads and posts that are obvious flaming jerks are left untouched. Like these for example: http://www.minecraftforge.net/forum/topic/65936-forge-server-error/ http://www.minecraftforge.net/forum/topic/66418-to-lenmanos-your-wrong-idc/ All I want is an explanation, because honestly, I'm hurt at how this was handled.

Wait, does 1.13 require Java 9? That will be a headache for anyone wanting multiple instances... Since you'd need Java 8 for a 1.12.2 instance or below, and Java 9 for 1.13+... And Java automatically uninstalls other versions when you install a new one now. Oh boy.

Uh... Okay admittedly now I'm a bit confused. I take it you mean if I use the system that the mod I linked uses? It doesn't really matter either way though. As I said, I'm probably not going to go through with this anytime soon, since I don't have the skill required yet.

Unpopular opinion but honestly, I would just keep it as-is. Better to inconvienience users very slightly into downloading an updated Java every few months (which takes like... 15 minutes) than letting them unwittingly use the broken, dangerously unsecure old version Minecraft ships with. If anything, Forge should complain when the Java version is too old. Security and functionality trumps very, very minor user inconvienience. At least in my eyes.

Hmm... Isn't there a way to specify what things can be put in a slot? Like how armor slots only accept armor of the matching type. I can't imagine they constantly check and reverse changes. So if I just set the slot to not fit any type of item, wouldn't that work? Maybe with occasional checks to make sure items haven't bugged out and gotten into the slot, and if they have, then just drop them automatically. Mmm... To be honest I'm probably biting off way more than I can chew given my lack of experience with Java. I might just save this project for another time, once I've gotten a better hold on the fundamentals.

Ingame, I just want the hand to be rendered like if you had an empty slot selected. What I intend, pretty much, is that a user can press a key to empty their hands even if they have a full hotbar, without removing any item from the hotbar. The slot isn't visible or anything, and cannot pick up items, it just functions like a completely empty hotbar slot. Scrolling or pressing a hotbar key or repressing the keybind would let you go back to the item you were holding beforehand. A mod already does that. https://minecraft.curseforge.com/projects/empty-hand The thing is, the way that's implemented, once you empty your hands, the items are stored away and your hotbar slot instead becomes empty, allowing anything to fill it back up. In that case, you then need to store those items somewhere, and manually, since pressing the keybind will just swap the already-stored items for the ones now occupying that slot. May seem just like a minor inconvienience, but it can be a real nuisance if you're playing with something like The Monk Mod which encourages you to keep your hands free, since items go into your hotbar before entering your inventory, your hotbar will constantly fill up with stuff. The mod linked above renders the items off to the side still, and explains how it functions when you first use it to get around the "disappearing" problem. But yeah, the latter part is exactly what I want to avoid.

I just kinda mean a permanently-empty slot that can be switched to with a hotkey. Doesn't even need to appear, I just want the ability to have an empty hand even with a full hotbar. So basically, anything that requires interaction with an empty hand would work because there's nothing in the slot, but the slot can't pick up any items either. I guess getActiveItemStack would always return... either null or air, I'm not sure which it returns on an empty slot. and I don't think I'd need getActiveHand to returm the slot, since the slot can't be interacted with. All I want is the no-item-held functionality that an empty hotbar slot would have.

I started work on a mod, I want to make an extra "empty hand" slot which can be switched to with a hotkey. Before I put in the legwork to actually make the slot and get it working, I'd first like to know if it's even possible to manually set the player's selected slot to one other than the hotbar slots... I mean, I know it's possible with a coremod that changes every reference to the hotbar to be a higher number, but I mean without messing with Vanilla code too much. I don't need it to be able to hold items, in fact I want the opposite. Just a slot that's perpetually empty which you can switch to and from with a key press. No special scrollwheel selection functionality or anything, no special rendering (aside from the empty hand but considering the slot is empty that should happen automatically). But to do that, I need to be able to set the player's selected slot to something else. All the information I can find on the subject on these forums, or anywhere, was vague and for waaay earlier versions, so I'd like a clear yes or no (preferably with some reasoning if no, or at least some hints on how I would go about it if yes) I suppose I don't necessarily need to set the selected slot to something else if there's a way to trick the game into thinking the player isn't holding anything? But that sounds somehow actually less compatible and like it would be even more of a pain to code, and isn't the topic of this post. (Although if there's a way to do that I'd be fine with hearing that too)

That's fine, don't worry! My code is a mess and my explanations are frankly awful so I can understand confusion. Also I tested and it works fine with hammers. So that's nice.

I... am? Well, I use GetActualBlockState(world,pos) but same idea. I don't understand why I need to cache them if I get the blockstate of each block that breaks individually, which I currently do. I do cache a single blockstate currently; that of whichever block is getting broken at the moment... which should be the only one I need. I first get it when BreakSpeed starts, then I get it again in BlockEvent.BreakEvent which fires just before the harvestevents, so it should be the correct value for any block broken, unless there are breaking methods which skip BreakEvent maybe and go straight to HarvestEvent but... that seems more like it would be a problem on the end of whatever implemented that, since I'm pretty certain they're meant to go together.

Don't worry, I'm not checking for that anymore. I found a better way of doing it that means I only need to get the blockstate once, and I can get it from BreakSpeed instead. As a catch for cases that don't trigger BreakSpeed (i don't think it happens in creative, for example) I also added an update to the blockstate on ... BreakBlock? HarvestBlock? ... the one that fires just BEFORE a block is broken. I'm bad with all these names. And the way I'm implementing this should be compatible with veinminer as it typically only mines the same type of block as the one you actually harvest. (And if it isn't, not a big deal, since Veinminer is kinda antithetical to my intended purpose of this mod and I honestly don't know why someone would use both together.) As for hammers, that's a bit more of a difficult issue but i think the ring of blocks around the original don't quite follow the same breaking logic? I think since I get the target blockstate during the pre-break event... thing... (again, I can't remember its name) it should perform the check again for each block...? I don't know how hammers work in their code, and each hammer's code probably varies wildly, so compatability will probably always be an issue. That said, I will have to check that because the modpack I made this for has hammers, and ones which are known to be a bit iffy about which blocks they can mine... This... Aaaalso shouldn't be an issue...? I'm no expert, and I'm certainly not comfortable enough with modding yet to say it definitely wouldn't be, but given what I'm doing, and given that I get the player doing the block breaking each time, I imagine it would work seperately. Pretty sure a new instance of BreakSpeedEvent and HarvestEvent and all those are called each time a block is mined. If it didn't, then in Vanilla you would have it where two players can't break different blocks at the same time without issue. At least... I think? Knowing what little I know of Minecraft's code anything could be possible. Either way, I intend to use this in a small server modpack. If issues like that arise, I'm sure they'll be noticed, and I can then figure out how to deal with them. I'd rather not tinker with my code more at the moment as I have every feature I want in it implemented the way I want it and it's the most stable it's been yet, so I think I'll sit on this version for now, unless a problem does definitively come up. On a related note, however. Am I right in assuming that on a server, all block-breaking handling and stuff like that is handled by the server and only the server? So like, if a player joins a server and has a mismatching breakable block whitelist, it won't cause desync because the client's config is ignored in favour of the server's? That's something I've been a bit worried about, especially after I made it so you can change and refresh the whitelist while ingame without restarting minecraft or relogging into the world.

Just to note it here, no further help is required on this issue! I got it working perfectly! I used raytracing and stuff in HarvestCheck to get the BlockPos, which seemed to work. The issue then was that the block still wouldn't drop because the actual state stops being snowy after the block is broken, which is when HarvestBlockDrops fires. So how did I fix that? I was wrong, HarvestCheck comes after BreakSpeed, which means I can get the ActualBlockState in BreakSpeed, save it outside the BreakSpeed event call so that the others can use that, which actually solves that problem in addition to greatly simplifying the code! Since I only get the ActualBlockState while the block is still in the correct form, even after it breaks, it still passes as snowy so it matches the whitelist! It works exactly as intended now! Thank you all for the help! I know I was a bit difficult about this, and sorry for that. I'm still pretty much a Java and Minecraft/Forge code newbie.