Leaderboard
Popular Content
Showing content with the highest reputation on 08/18/17 in all areas
-
Minecraft 1.12: The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum. Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do. New Policy on Coremods: Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices. 1) Coremod must be the coremod only, and no extra library/features/apis/etc. There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run. 2) Coremod binaries must be signed. This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage. For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack. For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html 3) Coremods should be visible source. This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it. The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods. Major Policy change: I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc.. In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements. It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out! Response From Sponge:1 point
-
HashMap is a common Java collection. It is just an implementation of the Map interface. A map just means there is a key and a value so you can look them up. So in this case you would add each entity as a "key" and the initial wait value as the "value". Then each tick you would iterate (loop) through the list of keys and for each on you would read the value and then set the value to one less (count down) and check if it hit zero (in which case you would remove the entry from the map). Whenever a butcher tries to harvest an entity you would just check if the entity exists as a key in the map, if it does it means it is not yet harvestable. Just search Google for Java HashMap examples.1 point
-
You can create a world data extension with a HashMap or similar collection where you map the entities to the time since last harvested, and update using the server tick event or world tick event. You would only need to add to the map when a successful harvest attempt happens (you don't have to have all the cows in the world in the map for example), and you could delete entries when the timer counts to zero or the entity dies. So it could be a fairly small and efficient map.1 point
-
As an alternative, in Java you can use the instanceof operator instead. So you could have put if (entity instanceof EntityCow)1 point
-
The 1.10-final branch Botania does have the Buildcraft API in src/api/java. StatCollector was renamed to net.minecraft.util.text.translation.I18n. This is deprecated because translation should be handled on the client using the net.minecraft.client.resources.I18n class or by sending a TextComponentTranslation.1 point
-
Check if the repo has different branches, left side of the page just below the "commits". If you're lucky, there will be different branches for different Minecraft versions. Not all will have this, and not all mods will be on GitHub. Some will be on BitBucket. Others may be in a private repo somewhere.1 point
-
I copied your advancements into my mod, modified them to use vanilla items and my mod ID for the parent advancements and then ran the game. When I loaded a world, I got an error saying that both advancements were missing a description element in the display object.1 point
-
You only need mobs to tick faster. The "everything else" in the game can be ignored. You can just call a mob's EntityLivingUpdate method as much as you want.1 point
-
1 point
-
1 point
-
1 point
-
I'll be yakuza karu hopefully. I am looking forward to it!!1 point
-
Hi i always looked for an yandere high scholl roleplay server i could be Paul_blart1 point
-
hi can i be sookie or not I have been looking for so long and I have finally found a group pleaseeeee.. xx1 point
-
Could I be SirCutieYuki? I've looked forever to find a yandere high school server!1 point
-
1 point
-
i can be taurtis or samgladiator if thats fine....1 point
-
You need to create a custom WorldProvider, and override calculateCelestialAngle. Then you need to register said WorldProvider to the wanted dimension(s), by calling DimensionManager#unregisterDimension(id) and then re-registering it with DimensionManager#registerDimension(id, DimensionType#register(...)) Though I would iterate over the worlds, and check their WorldProvider's first, and only change if the WorldProvider is an instanceof the overworld's WorldProvider, as some dimensions have "frozen" time, etc.1 point