hoodwink_dude

November 22, 2018

8 minutes ago, diesieben07 said:

This. However, you need to be careful, since even though Block#setUnlocalizedName and Item#setUnlocalizedName have the same signature at dev time, they will have separate SRG names in the actual game, so you will not be able to have them implement a common interface. You'll need to write your own methods, still.

This is what I was afraid of.

12 minutes ago, V0idWa1k3r said:

Let me stop you right there. Don't create BasicX. There is already a BasicX, it's called X.(BasicBlock -> Block, etc.) This is an antipattern and should be avoided.

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

November 22, 2018

On 11/21/2018 at 5:19 AM, V0idWa1k3r said:

Not necessairly, programming is not all about learning, it's also about inventing - taking the puzzle pieces that you have(aka your existing code knowledge) and putting them together to make something new.

1

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.

November 22, 2018

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);
    }
}

August 7, 2018

Just now, Animefan8888 said:

There is a damage validation of sorts it simply doesnt allow damage less than 0. You should call setHealth or heal whichever exists.

Ah, ok, thanks

August 7, 2018

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?

August 7, 2018

On 8/5/2018 at 10:02 PM, Draco18s said:

Are you modding for 1.13 with Forge?

Yes?

Where'd you get it?

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

August 5, 2018

1 minute ago, diesieben07 said:

No.

Ah. Nevermind. I got confused for a second when you said about being unified in 1.13

August 5, 2018

Just now, diesieben07 said:

Mostly legacy. mcmod.info is for the third party tools to parse. @Mod is what FML uses.

This will probably be unified in 1.13.

Ah, nice. Thanks. So, should I mostly ignore mcmod.info?

August 5, 2018

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.

April 29, 2018

1 minute ago, diesieben07 said:

All that matters is that you create (i.e. instantiate) your registry entries (e.g. items) during some kind of event and register them during RegistryEvent.Register. The rest is completely up to you.

Ah. That makes much more sense now. Thanks

April 29, 2018

1 minute ago, diesieben07 said:

No! Do not do this! This breaks shit.

Registry entries must be created during the proper events (or at least preInit). Not "at some random point when my class gets loaded".

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?)

April 29, 2018

2 minutes ago, Cadiboo said:

Personally, I think the first way is great because it allows you to instantiate the same class multiple times with different names. Isn't this the ultimate reduction of code?

for example over half my items are instantiated in this way
public static final ItemBase TITANIUM_NUGGET = new ItemBase("titanium_nugget").setNugget().setBeaconPayment();

Or even this way

public static final ItemTool COPPER_SHOVEL = new ItemTool("copper_shovel", ItemTool.COPPER, ItemTool.SPADE_EFFECTIVE_ON, ToolTypes.SHOVEL);

Good point. Thanks dude

April 29, 2018

4 minutes ago, Cadiboo said:
yeah it is an odd way to do it, but it places all your registration logic in one file.

Whats wrong with putting
public Blah() {
	super();
	this.setRegistryName(new ResourceLocation(Reference.ID, "blah"));
	this.setUnlocalizedName("blah");
}
in every class?

I guess it's just a case of me going a bit overboard with the whole "reduce code duplication" idea...

April 29, 2018

3 minutes ago, Cadiboo said:

I don't know if this is what you were looking for but this is how I instantiate my items


public class ModItems {
	
	public static final ItemFlamethrower			FLAMETHROWER			= new ItemFlamethrower("flamethrower");
	public static final ItemHammer					HAMMER					= new ItemHammer("hammer");
	public static final ItemRailgun					RAILGUN					= new ItemRailgun("railgun");
	public static final ItemCoilgun					COILGUN					= new ItemCoilgun("coilgun");
	public static final ItemPlasmagun				PLASMA_GUN				= new ItemPlasmagun("plasmagun");
	
	public static final Item[] ITEMS = {

		FLAMETHROWER,
		HAMMER,
		RAILGUN,
		COILGUN,
		PLASMA_GUN

	};
	
}

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...

April 29, 2018

On 28/04/2018 at 9:02 PM, Bendythe1nkdemon said:

MC version is 1.12.2 forge version is 14.23.3.2655-mdk

What is the folder contents of Gemology? It could be that you're missing the 'gradle' folder

April 29, 2018

I want to reduce literals usage so that I have the flexibility to change the registry name in the future but I also don't want to create global constants. Considering the fact that getRegistryName is marked with the Final access modifier, the result should be constant for each class.

5ae57d1443bd9_Screenshot(254).png.03a2ac3450f293b440ce7c4c2d6ba5d9.png

Am I just being stupid or is there any way for me to achieve this without a Constants class?

April 21, 2018

Just now, diesieben07 said:

Your post was deleted. Why? I don't know. What was it about?

My mini utility that I created that basically automates the setup of a forge mod project folder while keeping the original mdk files safe.

April 21, 2018

I created this post about 5 hours ago and I have just came on to check up on it and I 'don't have permissions to view' the post. What is going on?

September 3, 2016

Forge Fernflower Repo

Console log pastebin

Alternatively, spoiler containing the console log here:

C:\Users\james_000\Downloads\FernFlower-master>gradlew build

:compileJava

warning: [options] bootstrap class path not set in conjunction with -source 1.6

Note: C:\Users\james_000\Downloads\FernFlower-master\src\org\jetbrains\java\deco

mpiler\modules\decompiler\LabelHelper.java uses unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

1 warning

:processResources UP-TO-DATE

:classes

:jar

:assemble

:compileTestJava

warning: [options] bootstrap class path not set in conjunction with -source 1.6

1 warning

:processTestResources UP-TO-DATE

:testClasses

:test