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.

What I'm trying to achieve is to make, or rather, alter a system that allows only certain blocks to be mined by hand if they're whitelisted or don't have a most-efficient tool type, otherwise it makes trying to harvest them with the wrong tool incredibly slow and not drop anything, even if it would in Vanilla. The check being in these three places is something from the source mod I'm working off of, No Tree Punching by alcatrazEscapee. The entire HarvestCheck area is a kind of double-check he implemented to stop certain blocks from his mod from not giving their drops like they should, even when whitelisted. since his check is there and in these other two places, I need to put my check there too, to see if they're whitelisted. My check is different because I have a seperate whitelist that includes properties, so that I can whitelist one variant of a block but not the other, something that is not possible in the original code. If the isWhitelisted from his original whitelist or my isDataWhitelisted is found to be true in HarvestCheck, it does event.setCanHarvest(true) for the block being mined. In the BreakSpeed section, it stops the speed from slowing down if either is true. In the HarvestBlockDrops section, it allows them to give their drops if either is true. In his own words, paraphrased, he said specifically that the HarvestCheck was there to make sure that even blocks that say they need a specific tool to mine properly can be mined at normal speed by hand and get their drops if whitelisted, like the loose rocks from his mod. Without the HarvestCheck, they would be considered unbreakable by hand, even if whitelisted, thereby causing those to not drop. And I'd rather like to keep that functionality in my variant of the mod if possible, although I suppose it isn't strictly necessary, as I've removed the built-in new blocks to keep the focus to the specific functionality of block-breaking restrictions.

I know they have IBlockState, as I got the IBlockstate through event.getTargetBlock() and event.getState(), but apparently that didn't work for my purposes. I call isDataWhitelisted() in each; they're all subscribed to seperately, so I need to get both World and BlockPos from each individually. PlayerEvent.BreakSpeed has a way to get BlockPos but not World. (event.getPos()) BlockEvent.HarvestDropsEvent has both. (event.getPos() event.getWorld()) PlayerEvent.HarvestCheck has neither, however. HarvestCheck comes first, then BreakSpeed, then HarvestDropsEvent, if I recall. Which means I can't get the values from HarvestDropEvent before the other two run. The IBlockState provided from each through event.getTargetBlock() or event.getState() didn't work for me, as it doesn't seem to contain that specific block's properties, instead just having what I assume are the defaults for those properties, so for example, if the block I'm harvesting has snowy: true, the IBlockState gotten from each of those seems to have snowy: false because that's just the default. So I think I need the ActualBlockState but getting that is proving to be difficult given what I have to work with, unless I want to severely overcomplicate things even more than I already have. However, it's 3 AM and I need to sleep, so I'm going to leave it here for tonight. Thank you for the help, I'm closer than ever to getting this working, despite my sub-par Java knowledge and essentially blank Forge and Minecraft code knowledge.

BlockEvent.HarvestDropsEvent, PlayerEvent.BreakSpeed, and PlayerEvent.HarvestCheck.

Yeah, so when I pass the blockState from other functions, it always turns out false no matter what I do. An output of false is still better than an output of Optional.absent(), but it's still not true, even when trying to mine a block that does have the property snowy: true I need to get the ActualBlockState but to do that I need to get the World and the BlockPos. With what I have available to me here, how would I do that?

is there any way to easily get the BlockPos and World for getActualState? The this.mc.objectMouseOver and this.mc.world don't exactly work in this case. All I really have to work with here is "Block block" or an IBlockState blockState (that was not from getActualState) I'll just post what I'm actually working with currently and try to explain what it is I'm trying to achieve... It's a check when the player is breaking or has just broken a block (it's used in both places). It checks to see if a block and its properties, all stored as strings, match those in the config. The actual block is stored as a ResourceLocation in order to do those comparisons for the domain and path. The properties, meanwhile, are stored as Strings in a List which is also within a List. So it would be like this, using my snowy grass example: List BreakableDataWhitelist contains: ResourceLocation minecraft:grass List BreakableProperties contains: (here to align its index with the BreakableDataWhitelist blocks for easy pairing of block and its properties) List (nested inside) which contains: (one of these is added to BreakableProperties list for each property specified in the config) List (nested again) which contains: (they key/value pairings as specified in the config) {"snowy", "grass"} So, if the block itself matches one of the ones in the whitelist (status=true), it then goes to check that its properties also match. (forgive the logs, those were from my tests to figure out why it wasn't working) It does this by getting the property keys from the block's default state, and iterating through them. It then compares each individual Property with the listed ones, checking that the Key and the Value both match what is given in the config. Since the config keys and values are strings, it compares the Property Name to the string, and converts the Property Value to a string. This is the part I need to get working. If both match, a counter is increased (numMatches++), then after it has iterated through them all, it compares it to the number of properties in the whitelist entry for that block. (which I notice I've done wrong, I should be checking the size of the List inside BreakableProperties, not BreakableProperties itself. Oops. I'll fix that in a few minutes.) If the number matches, that means that all the properties matched up, and since it's already been determined that the block matches up, it returns true, the block is whitelisted. Of course if it doesn't work then it returns false. So the part in specific I need to get to work is: I've confirmed that getting the property name works fine. But preferably without rewriting huge chunks of this to use the ActualBlockState (which since it's an IBlockState instead of a BlockStateContainer, doesn't allow the use of getProperty(String) which would mess up the part that IS working) However, I could use that for the first part and ActualBlockState for the second part, and get the Property another way. But to do that, I need to get the World and the BlockPos, and I can't seem to find a way to get either, much less both, using the information I have at my disposal. I considered passing them as arguments in isDataWhiteListed() but that isn't working because the events in the places that it's called also don't have methods to get the BlockPos and World. They can pass a BlockState through event.getTargetBlock() and event.getState() respectively, but I'm not sure if those BlockStates have all the information I need in the first place. I'll try that for now and see if I can get it to work, but if there's a better, cleaner, less convoluted way to do this I would love someone to point it out, because I can't imagine this happening... probably every tick that a block is being harvested for?... per player, is very good for server performance. Sorry if I'm missing plainly obvious things, this is literally my first foray into Minecraft modding and I've never been well-versed in Java because I always found it to be one of the most intimidating programming languages. private boolean isDataWhitelisted(ResourceLocation blockName, Block block) { boolean status; boolean matched; int index = 0; for (ResourceLocation r : BreakableDataWhitelist) { status = false; matched = false; if (r.equals(blockName)) status = true; if (r.getResourceDomain().equals("*") && r.getResourcePath().equals(blockName.getResourcePath())) status = true; if (r.getResourcePath().equals("*") && r.getResourceDomain().equals(blockName.getResourceDomain())) status = true; if (r.toString().equals("*:*")) status = true; Main.log.info("iDWl Status: " + status); if (status == true) { int numMatches = 0; Collection<IProperty<?>> blockProps = block.getDefaultState().getPropertyKeys(); for (IProperty prop : blockProps) { for (List<String> kvp : BreakableProperties) { Main.log.info("iDWl Nam: " + prop.getName()); Main.log.info("iDWl Val: " + block.getBlockState().getProperty(prop.getName()).parseValue(prop.getName()).toString()); if (prop.getName() == kvp.get(0) && block.getBlockState().getProperty(prop.getName()).parseValue(prop.getName()).toString() == kvp.get(1)) numMatches++; } } Main.log.info(numMatches + " matches out of " + BreakableProperties.size()); if (numMatches == BreakableProperties.size()) matched = true; } index++; if (status == true && matched == true) return true; } return false; } }

I redacted it because it was terribly implemented and I redid the whole thing from the ground up. Hence why I said please ignore this post. I don't want help on this issue anymore because I've completely scrubbed it from my code. If I could delete the topic I would but there doesn't appear to be an option to do so.

For simpleness' sake, let's say I have something like this: @SubscribeEvent public void breakSpeedSwap(PlayerEvent.BreakSpeed event) { Block block = event.getState().getBlock(); String prop = "snowy"; if ([just pretend it's checking to see if the block is minecraft:grass for this example]) Main.log("isSnowy: " + block.getBlockState().getProperty(prop).parseValue(prop.getName()).toString()); } what I want is the value of "minecraft:grass[snowy=???]" and i want that value in String form, so it can be output or used in String comparisons or whatever. so for a normal everyday grass block, i would want the output to be: however even with the toString it instead outputs: for both snowy and non-snowy grass blocks. So I'm just wondering, how can I properly turn the value of the Optional returned by parseValue into a String? Am I using the wrong BlockState for this? There's like 10 different ways to get the BlockState from a block and it's kind of overwhelming. I was originally going to use getDefaultBlockState() but I feel like that would just return, well, the default BlockState with the default values, so it would always be snowy=false? Or am I interpreting what Default means in this case wrong?

Except it wouldn't accept Strings. I tried. Just please nevermind, I'm going to redo this whole mess from the ground up to find a less completely insane way to do it.

While I appreciate the fast response, this isn't actually what I wanted help with. Slow block breaking is the intent of the mod, unless a block is whitelisted in the config or other conditions are met. The issue is that I want to be able to whitelist specific variants of blocks like snowy grass as an example. so minecraft:grass with the property snowy: true say I want to whitelist that for whatever reason so you can break snowy grass at normal speed but other variants you can't. so in the config I have something amounting to: String[] BreakableDataWhitelist = {"minecraft:grass{snowy=true}"} I break that down into the block and key/value property pairs in lists so I can easily get just the key or just the value. So it ends up something amounting to: BreakableDataWhitelist[0] = "minecraft:grass" BreakableData[0] = { properties = {"snowy","true"} } and so I need to get the block being targeted for mining. i get that, I pass it to isDataWhitelisted, and I need to get its properties. so I do that, then I go to compare the key/value property pair in the properties list to the actual block's properties so "if blockState (the block).getProperties().containsKey(properties[0])" "if blockState.getProperties().containsValue(properties[1])" but that doesn't work because properties[0] and properties[1] are Strings, and containsKey and containsValue need Objects as arguments, not Strings. so I need a way to convert the String in the config file to Objects of the type [string's contents] so i need to convert String "snowy" into Object snowy so that containsKey() can actually accept it and check if the block's properties contains the key "snowy" and String "true" into Object true so that containsValue() can actually accept it and check if the block's properties contains the value "true". And I'm aware that brings up the issue of there being multiple "true" values in the block's properties but one issue at a time.

[Redacted] Please ignore this post. I'm pretty sure what I was asking for is impossible, and I'll need to completely redo how I was implementing it.