Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ProdigyTech compatibility #173

Merged
merged 21 commits into from
Jul 6, 2024

Conversation

Wizzerinus
Copy link
Contributor

@Wizzerinus Wizzerinus commented Jun 6, 2024

wow this is huge. I mean the mod does have a lot of things in it

I don't commonly work with Java so might have made some mistakes, the mod's recipe handling system is ridiculous (wow wee constant checks against ItemStack/OreDictIngredient because the author special cased them - I love that so much), and also some GS integrations are somewhat inconsistent (i.e. not sure what methods should be marked with @GroovyBlacklist). Otherwise it seems to work.

List of machines added: ExplosionFurnace, ExplosionFurnaceAdditives, RotaryGrinder, MagneticReassembler, HeatSawmill, OreRefinery, Solderer, PrimordialisReactor, AtomicReshaper, ZorraAltar.

@Wizzerinus
Copy link
Contributor Author

fixed the PR comments

@Wizzerinus
Copy link
Contributor Author

all of these should be fixed now

thanks for being patient with a person not very experienced with java ☺️

gradle.properties Outdated Show resolved Hide resolved

groovyscript.wiki.prodigytech.primordialis_reactor.title=Primordialis Reactor
groovyscript.wiki.prodigytech.primordialis_reactor.description=Turns organic matter into Primordium.
groovyscript.wiki.prodigytech.primordialis_reactor.addRecipe=Adds an item that can be converted.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

methods got renamed

groovyscript.wiki.prodigytech.primordialis_reactor.add
groovyscript.wiki.prodigytech.primordialis_reactor.remove

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

intended since those arent really recipes. could do addItem/ removeItem

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my point being that when you generate the wiki groovyscript.wiki.prodigytech.primordialis_reactor.add is the lang key checked, which doesnt exist. these lang keys should get renamed so they match the method names.

public boolean removeDampener(IIngredient dampener) {
for (ItemStack it : dampener.getMatchingStacks()) {
ExplosionFurnaceManager.Dampener externalDampener = ExplosionFurnaceManager.findDampener(it);
EFAdditiveRecipe recipe = new EFAdditiveRecipe(false, dampener, externalDampener.getDampening());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if ExplosionFurnaceManager.findDampener(it) doesnt find anything, it returns null, which then generates a NullPointerException on this line. this also happens to ExplosionFurnaceManager.findExplosive(it).
there should be an if (externalDampener == null) continue; to avoid this.


groovyscript.wiki.prodigytech.primordialis_reactor.title=Primordialis Reactor
groovyscript.wiki.prodigytech.primordialis_reactor.description=Turns organic matter into Primordium.
groovyscript.wiki.prodigytech.primordialis_reactor.addRecipe=Adds an item that can be converted.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my point being that when you generate the wiki groovyscript.wiki.prodigytech.primordialis_reactor.add is the lang key checked, which doesnt exist. these lang keys should get renamed so they match the method names.

gradlew Outdated Show resolved Hide resolved
Comment on lines 39 to 46
for (ItemStack it : explosive.getMatchingStacks()) {
ExplosionFurnaceManager.Explosive externalExplosive = ExplosionFurnaceManager.findExplosive(it);
if (externalExplosive == null) continue;
EFAdditiveRecipe recipe = new EFAdditiveRecipe(true, explosive, externalExplosive.getPower());
remove(recipe);
return true;
}
return false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wtf???

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah uh, I think this might be the only sensible way to do it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isnt. if you apply the change the convo below it will become much better

ExplosionFurnaceManager.removeAllDampeners();
}

public static class EFAdditiveRecipe {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont approve how this registry is done. Do not create a custom recipe class. Rather just use the existing explosive class and add a AbstractReloadableStorage<Dampner> field. See this for example

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasn't aware of the existence of AbstractReloadableStorage

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I not inherit from VirtualizedRegistry then? Not sure if I need to do anything if my "registry" doesn't contain recipes in itself

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok so, I looked into the PT's code and it requires an accessor mixin. I feel like a less destructive option is better.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Youd still have a VirtualizedRegistry<Explossive> with a field AbstractReloadableStorage<Dampner>. And there is nothing wrong with accessor mixins.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made a version of this, unfortunately it is the only sensible version (the other version requires having a custom class too with all the consequences).

@Wizzerinus
Copy link
Contributor Author

made the adjustments that made sense, not sure what to do with the other 2.

# Conflicts:
#	gradle.properties
#	src/main/java/com/cleanroommc/groovyscript/compat/mods/ModSupport.java
#	src/main/resources/assets/groovyscript/lang/en_us.lang
Copy link
Member

@brachy84 brachy84 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will probably change 1 or 2 things once its merged.

@brachy84 brachy84 merged commit 3c0af9b into CleanroomMC:master Jul 6, 2024
@Wizzerinus Wizzerinus deleted the compat/prodigytech branch July 7, 2024 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants