-
How can I make calls to methods that are common between Item and Block less sloppy?
This is what I was afraid of. I guess I got too stuck into this 1.12.2 tutorial series that I didn't stop to think if it was really needed. It's a good thing this has been caught relatively early. Thanks
-
Massive Coding Tutorial?
As someone who has been in a Programming Apprenticeship for nearly a year now, I agree with this statement but it is missing one important piece of information: clear aspirations, concrete goals and knowing what you need to learn (understanding of the domain you are about to dabble in). There have been many instances where I have tried to learn something on my own but I have not had a solid goal in mind. However, in this entire (nearly) year, I have learned 200% the amount of stuff I learned in the ~3 years prior. And no, that isn't entirely an exaggeration. I am just as shocked as you all will be at the sheer volume of stuff I have learned. But that is the effect that having concrete goals and sources of Domain Knowledge can (and will) have on your learning. Clear Aspirations just help you along in order to keep focused rather than fall into a Rabbit Hole (genuine technical term) and not make much progress. In terms of resources, you have these forums (for Domain Knowledge regarding Minecraft Forge), r/learnjava (for Domain Knowledge regarding Java) and you have so many sources of goals. Go ahead and try re-creating existing mods. If you spend an entire day struggling to figure out how to implement a specific piece of functionality for a mod, that's an indicator that you should leave it until you have more experience. All in all, if you have the determination to learn, there are plenty of resources out there on the internet. You only need to fire up Google and search for those resources.
-
How can I make calls to methods that are common between Item and Block less sloppy?
When creating 'BasicItem', 'BasicBlock', 'Basic[ToolName]' etc Classes, I have found that they all have some identical constructor sections. I have created a generic util method but I feel absolutely filthy for doing it this sloppy way. However, Generics don't allow you to call methods on the 'actual' type because that would break encapsulation. That was the only other way I saw this working. Is there anything I'm forgetting or missing out on? I just really feel like a heathen for doing it this way public static <T extends IForgeRegistryEntry.Impl<T>> void initItem(T item, String unlocalisedName, String registryName) { if (item instanceof Block) { ((Block) item).setUnlocalizedName(NameUtils.formatUnlocalisedName(unlocalisedName)); ((Block) item).setRegistryName(registryName); ((Block) item).setCreativeTab(ExampleMod.EXAMPLE_TAB); } else { ((Item) item).setUnlocalizedName(NameUtils.formatUnlocalisedName(unlocalisedName)); ((Item) item).setRegistryName(registryName); ((Item) item).setCreativeTab(ExampleMod.EXAMPLE_TAB); } }
-
Negative damage doesn't heal entities
Ah, ok, thanks
-
Negative damage doesn't heal entities
I am trying to make 'Healing Swords' but the method that I thought would work (taking a negative number from the HP would be the same as adding it to the HP) doesn't seem to work. In fact, negative damage doesn't even do anything which leads me to believe that there is some sort of validation on the attack damage handlers. Any idea what could be the cause of this? And also, is there a way around this or is there a different route I could take?
-
Question about Mod Info
I never said that I was modding with 1.13. I simply said that I got confused for a second by diesieben mentioning about unification
-
Question about Mod Info
Ah. Nevermind. I got confused for a second when you said about being unified in 1.13
-
Question about Mod Info
Ah, nice. Thanks. So, should I mostly ignore mcmod.info?
-
Question about Mod Info
Both the Mod annotation and the mcmod.info file hold a lot of the same data. What is the point of the redundancy? Especially seeing as though it would be fairly easy to forget to update the info in one after doing it for the other (when there are multiple values being updated). I want to avoid this situation as much as possible (DRY programming practice) so I kinda want to figure out a way to use the buildfile to inject values into both the java and mcmod.info so that I can centralise the changes. However, that isn't the point of this post. The point of this post is to rage at the authors of MC Forge for this blasphemy just a way for me to vent my frustration because I am sure there is a reason behind this design. I also want to get some sort of confirmation that there is a reason behind it just to ease my mind a bit too.
-
[SOLVED] GameRegistry.ObjectHolder method-based initialisation
Ah. That makes much more sense now. Thanks
-
[SOLVED] GameRegistry.ObjectHolder method-based initialisation
So it's gonna be a bunch of string literals then. Unless I do some form of Dependency Injection (or would that break shit too? If I call the method for loading it all in the preinit then I shouldn't run into issues?)
-
[SOLVED] GameRegistry.ObjectHolder method-based initialisation
Good point. Thanks dude
-
[SOLVED] GameRegistry.ObjectHolder method-based initialisation
I guess it's just a case of me going a bit overboard with the whole "reduce code duplication" idea...
-
[SOLVED] GameRegistry.ObjectHolder method-based initialisation
That approach is what I have seen multiple times online. However, I personally think that the logical place to define the names of items is within the respective item classes. I guess that is just a result of me working in Industry for the past 3 months as a Software Engineer Apprentice...
-
Can someone help me solve a problem
What is the folder contents of Gemology? It could be that you're missing the 'gradle' folder
IPS spam blocked by CleanTalk.