Leaderboard

No. neighbourChanged happens when any additional block is changed regardless of whether it was changed by a player or something else, like a piston. You will pretty much have to use PlaceEvent as far as I am aware. What exactly is your code going to do? Checking a few blocks around the placed one and invoking a method within them if the condition is correct is a very fast operation. Performance should not be a concern here, and in any way write functional code first, optimize it later if needed.

I live in a 3rd world country where 25 dollars is 1000 PHP to us and worth like my 3 months allowance, I pursued programming classes consuming my saturday weekends of time only to be uneducated by 3rd world quality programming teachers, the teacher would often just read the lesson in english which isnt our mother tongue language making it hard for majority of the students to understand, our lesson is takes 8 hours per saturday doing nothing,my classmates would usually sorround me in my computer to get help from me during the lessons, sometimes in each exam where we will need to build a program, my other colleagues would consume the 8 hour time and ask for more cus it aint enough, Me however who have experience in programming due to forge would just take 30 minutes to do it and leave my class and just save my allowance. I learned it all in programming with forge. So thank you forge, thank you forge staff, your sacrifices mean a lot to some people like me,

There is EVERYTHING wrong with both of them both design-wise and implementation wise. A string is an array of characters but I don't see you storing your strings as byte arrays. By your logic - it works so there is no harm in it, right? Even if it works it makes no sense logically - you are not going to use ByteBuffers for your numbers and you are thus not going to use a CommonProxy, the string is not annotated as Iterable<Byte> and your items should not be annotated with IHasModel. It also confuses people all around the world who look at your code - there is no Common side, so why is there a common proxy then? And some of them start using common proxy to execute code they consider common which is plain wrong and has lead to numerous issues, some of which I have helped people with on these very forums, so it IS HARMFUL! Don't just shrug it off because it works. If something works it doesn't mean it's right. If you know what you are doing then by themselves these classes don't do harm. It's a whole other story if you don't though. And a lot of people don't. You are still registering them individually though. Just this time your code is in your Item class instead of your event class. It is also in your proxy. You are actually legitemately writing 300% MORE code by using IHasModel. It also makes no sense design-wise since all items need models. A string isn't IHasCharacters for a reason. Again, this HAS caused issues some of which I had to help people with so it IS ACTIVELY HARMFUL. And in any case you can iterate your items just fine since they already share a common ancestor - Item! So the argument of "but I can iterate them now" is also invalid. It can't though. Proxies by definition contain code that will crash the game if ran on the wrong side. You can't share code between server and the client like this, it happens anywhere else but your proxy. Again, there were numerous issues caused by people trying to do exactly that. Again, if something works doesn't mean it's right and you can't say "code preference" either. You can use strings to store any information but you are not doing that and it's not just "code preference" even though it works. Yes you do, actually. There are multiple reasons to use object holders, the main of which is the fact that stuff in registries CAN BE OVERRIDDEN! If you don't use object holders you now have a useless thing that is not used in the game at all. No, they really don't. The main reason is that they offer no control over when the stuff initializes, so one wrong mention of a class that contains them and now you have nulls everywhere because they reference things that have not been instantinated yet. Actually around 20-30% of issues I have seen on this forum related to blocks/items have been caused by people using static initializers! It is actively harmfull! Additionally if that wasn't enough on it's own it breaks the whole "registries can override stuff" concept and it prevents reloadable registries. Worse, similar to bytecode editing it can and WILL break unpredictably when you least expect it regardless of "complexity". It already had for multiple people who then went to this forum. So please, don't encourage cargo-cult programming and spread misinformation. There is a reason we tell everyone not to use these things beyound simple design issues. There are guidelines to using forge for a reason. Even if you yourself know how everything works you are actively confusing people who don't and are creating more issues in the process. Imagine if opengl had no guidelines and people started doing stuff like IHasVertex for their buffers, or CommonShader that holds the "common shared" shader code, or god forbid used static initializers to instantinate VBOs and other stuff *shrugs*.

That makes sense. Its still possible to recreate this by editing the HTML markup while editing I think. I think that you shouldn't try to remove this because letting users customise their comments with markup is pretty cool. Apparently all you need to do is set the width style and the table-layout style to fixed.

I had the same problem and found the solution here: https://www.reddit.com/r/feedthebeast/comments/4zp2ku/is_it_possible_to_add_mods_to_the_1102_forge_dev/ (by brute force googling) Go to Run/"Run Configurations ...", select in tree left "Java Application"/<Name-of-your-ProjectFolder>_Client, go to "Arguments" Tab and remove in "VM arguments" "-DFORGE_FORCE_FRAME_RECALC=true" what should be the whole content of that textfield. This stops FML/Gradle to use any mod in its deobfuscated version; what means methods names, variables etc. in the foreign mod jar file don't get renamed into a human readable version while loading. With deobfuscation the mod become unable to load parts of itself by reference the name of classes/modules. If you want to add references to other mods (e.g. for dependencies) in your own mod you might need a more elaborated method. I would love to see the forge documentation extended by a section that explains deobfuscation much better than I try to do in the lines above ...

https://github.com/ichttt/MCLang2Json

MCPConfig on the forge repo allows for viewable decompiled code. However it doesn't have the tools to reobfusicate/package jar mods because that era of Minecraft modding is dead. And we should not be supporting it. As for the FG side of things, getting a raw Minecraft deobfed jar to link against will be possible.