mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2025-01-11 01:40:56 +00:00
Code Issues Releases Wiki Activity
57318b022d
CC-Tweaked/src/main/java/dan200/computercraft/shared/PocketUpgrades.java

88 lines
2.9 KiB
Java
Raw Normal View History

Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
/*
* This file is part of ComputerCraft - http://www.computercraft.info
Happy new year!
2019-01-01 01:10:18 +00:00
* Copyright Daniel Ratcliffe, 2011-2019. Do not distribute without permission.
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
* Send enquiries to dratcliffe@gmail.com
*/
package dan200.computercraft.shared;
import dan200.computercraft.ComputerCraft;
import dan200.computercraft.api.pocket.IPocketUpgrade;
import dan200.computercraft.shared.util.InventoryUtil;
import net.minecraft.item.ItemStack;
Update CC: Tweaked to 1.13 Look, I originally had this split into several commits, but lots of other cleanups got mixed in. I then backported some of the cleanups to 1.12, did other tidy ups there, and eventually the web of merges was unreadable. Yes, this is a horrible mess, but it's still nicer than it was. Anyway, changes: - Flatten everything. For instance, there are now three instances of BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no more BlockPeripheral (thank heavens) - there's separate block classes for each peripheral type. - Remove pretty much all legacy code. As we're breaking world compatibility anyway, we can remove all the code to load worlds from 1.4 days. - The command system is largely rewriten to take advantage of 1.13's new system. It's very fancy! - WidgetTerminal now uses Minecraft's "GUI listener" system. - BREAKING CHANGE: All the codes in keys.lua are different, due to the move to LWJGL 3. Hopefully this won't have too much of an impact. I don't want to map to the old key codes on the Java side, as there always ends up being small but slight inconsistencies. IMO it's better to make a clean break - people should be using keys rather than hard coding the constants anyway. - commands.list now allows fetching sub-commands. The ROM has already been updated to allow fancy usage such as commands.time.set("noon"). - Turtles, modems and cables can be waterlogged.
2019-04-02 12:27:27 +00:00
import net.minecraftforge.fml.ModContainer;
import net.minecraftforge.fml.ModLoadingContext;
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
import javax.annotation.Nonnull;
Improve our JEI integration a little bit - Turtle and pocket computers provide a "creator mod id" based on their upgrade(s). We track which mod was active when the upgrade was registered, and use that to determine the owner. Technically we could use the RegistryLocation ID, but this is not always correct (such as Plethora's vanilla modules). - We show all upgraded turtles/pocket computers in JEI now, rather than just CC ones. - We provide a custom IRecipeRegistryPlugin for upgrades, which provides custom usage/recipes for any upgrade or upgraded item. We also hide our generated turtle/pocket computer recipes in order to prevent duplicates.
2019-03-16 01:49:02 +00:00
import javax.annotation.Nullable;
import java.util.*;
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
public final class PocketUpgrades
{
private static final Map<String, IPocketUpgrade> upgrades = new HashMap<>();
Improve our JEI integration a little bit - Turtle and pocket computers provide a "creator mod id" based on their upgrade(s). We track which mod was active when the upgrade was registered, and use that to determine the owner. Technically we could use the RegistryLocation ID, but this is not always correct (such as Plethora's vanilla modules). - We show all upgraded turtles/pocket computers in JEI now, rather than just CC ones. - We provide a custom IRecipeRegistryPlugin for upgrades, which provides custom usage/recipes for any upgrade or upgraded item. We also hide our generated turtle/pocket computer recipes in order to prevent duplicates.
2019-03-16 01:49:02 +00:00
private static final IdentityHashMap<IPocketUpgrade, String> upgradeOwners = new IdentityHashMap<>();
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
Turn inspections up to 11 OK, so let's get this out of the way, there's some actual changes mixed in here too. I'm really sorry: - Turtles can now not be renamed with unnamed item tags (previously it would clear the name, this seemed a little unideal). - commands.getBlock(s)Data will also include NBT. Now, onto the horror story which is these inspection changes: - Make a lot of methods static - Typo fixes - Make utility classes final + private constructor - Lots of reformatting (ifs -> ternary, invert control flow, etc...) - ??? - Profit! I'm so going to regret this - can pretty much guarantee this is going to break something.
2019-03-29 21:21:39 +00:00
private PocketUpgrades() {}
Update CC: Tweaked to 1.13 Look, I originally had this split into several commits, but lots of other cleanups got mixed in. I then backported some of the cleanups to 1.12, did other tidy ups there, and eventually the web of merges was unreadable. Yes, this is a horrible mess, but it's still nicer than it was. Anyway, changes: - Flatten everything. For instance, there are now three instances of BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no more BlockPeripheral (thank heavens) - there's separate block classes for each peripheral type. - Remove pretty much all legacy code. As we're breaking world compatibility anyway, we can remove all the code to load worlds from 1.4 days. - The command system is largely rewriten to take advantage of 1.13's new system. It's very fancy! - WidgetTerminal now uses Minecraft's "GUI listener" system. - BREAKING CHANGE: All the codes in keys.lua are different, due to the move to LWJGL 3. Hopefully this won't have too much of an impact. I don't want to map to the old key codes on the Java side, as there always ends up being small but slight inconsistencies. IMO it's better to make a clean break - people should be using keys rather than hard coding the constants anyway. - commands.list now allows fetching sub-commands. The ROM has already been updated to allow fancy usage such as commands.time.set("noon"). - Turtles, modems and cables can be waterlogged.
2019-04-02 12:27:27 +00:00
public static synchronized void register( @Nonnull IPocketUpgrade upgrade )
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
{
Turn inspections up to 11 OK, so let's get this out of the way, there's some actual changes mixed in here too. I'm really sorry: - Turtles can now not be renamed with unnamed item tags (previously it would clear the name, this seemed a little unideal). - commands.getBlock(s)Data will also include NBT. Now, onto the horror story which is these inspection changes: - Make a lot of methods static - Typo fixes - Make utility classes final + private constructor - Lots of reformatting (ifs -> ternary, invert control flow, etc...) - ??? - Profit! I'm so going to regret this - can pretty much guarantee this is going to break something.
2019-03-29 21:21:39 +00:00
Objects.requireNonNull( upgrade, "upgrade cannot be null" );
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
String id = upgrade.getUpgradeID().toString();
IPocketUpgrade existing = upgrades.get( id );
if( existing != null )
{
throw new IllegalStateException( "Error registering '" + upgrade.getUnlocalisedAdjective() + " pocket computer'. UpgradeID '" + id + "' is already registered by '" + existing.getUnlocalisedAdjective() + " pocket computer'" );
}
upgrades.put( id, upgrade );
Update CC: Tweaked to 1.13 Look, I originally had this split into several commits, but lots of other cleanups got mixed in. I then backported some of the cleanups to 1.12, did other tidy ups there, and eventually the web of merges was unreadable. Yes, this is a horrible mess, but it's still nicer than it was. Anyway, changes: - Flatten everything. For instance, there are now three instances of BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no more BlockPeripheral (thank heavens) - there's separate block classes for each peripheral type. - Remove pretty much all legacy code. As we're breaking world compatibility anyway, we can remove all the code to load worlds from 1.4 days. - The command system is largely rewriten to take advantage of 1.13's new system. It's very fancy! - WidgetTerminal now uses Minecraft's "GUI listener" system. - BREAKING CHANGE: All the codes in keys.lua are different, due to the move to LWJGL 3. Hopefully this won't have too much of an impact. I don't want to map to the old key codes on the Java side, as there always ends up being small but slight inconsistencies. IMO it's better to make a clean break - people should be using keys rather than hard coding the constants anyway. - commands.list now allows fetching sub-commands. The ROM has already been updated to allow fancy usage such as commands.time.set("noon"). - Turtles, modems and cables can be waterlogged.
2019-04-02 12:27:27 +00:00
ModContainer mc = ModLoadingContext.get().getActiveContainer();
Improve our JEI integration a little bit - Turtle and pocket computers provide a "creator mod id" based on their upgrade(s). We track which mod was active when the upgrade was registered, and use that to determine the owner. Technically we could use the RegistryLocation ID, but this is not always correct (such as Plethora's vanilla modules). - We show all upgraded turtles/pocket computers in JEI now, rather than just CC ones. - We provide a custom IRecipeRegistryPlugin for upgrades, which provides custom usage/recipes for any upgrade or upgraded item. We also hide our generated turtle/pocket computer recipes in order to prevent duplicates.
2019-03-16 01:49:02 +00:00
if( mc != null && mc.getModId() != null ) upgradeOwners.put( upgrade, mc.getModId() );
}
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
public static IPocketUpgrade get( String id )
{
Automatically generate impostor recipes Previously we would register the recipes within our code, but the advancements were written manually. This now generates JSON files for both the advancement and recipe. While this does mean we're shipping even more JSON, we'll need to do this for 1.13 anyway, and means our advancements are guaranteed to be consistent. On a side note, a couple of other changes: - Turtle upgrades are now mounted on the right in the creative menu/fake recipes. This means the upgrade is now clearly visible in the inventory. - We no longer generate legacy turtle items at all: we'll always construct turtle_expanded. - Several peripheral items are no longer registered as having sub-types (namely advanced and full-block modems). - We only have one disk advancement now, which unlocks all 16 recipes. - We have removed the disk conversion recipes - these can be exposed through JEI if needed.
2019-03-16 00:15:31 +00:00
// Fix a typo in the advanced modem upgrade's name. I'm sorry, I realise this is horrible.
if( id.equals( "computercraft:advanved_modem" ) ) id = "computercraft:advanced_modem";
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
return upgrades.get( id );
}
public static IPocketUpgrade get( @Nonnull ItemStack stack )
{
if( stack.isEmpty() ) return null;
for( IPocketUpgrade upgrade : upgrades.values() )
{
ItemStack craftingStack = upgrade.getCraftingItem();
Be less strict in comparing upgrade crafting items We currently generate the crafting item once when the upgrade is first created, and cache it for the duration of the game. As the item never changes throughout the game, and constructing a stack is a little expensive (we need to fire an event, etc...), the caching is worth having. However, some mods may register capabilities after we've constructed our ItemStack. This means the capability will be present on other items but not ours, meaning they are not considered equivalent, and thus the item cannot be equipped. In order to avoid this, we use compare items using their share-tag, like Forge's IngredientNBT. This means the items must still be "mostly" the same (same enchantements, etc...), but allow differing capabilities. See NillerMedDild/Enigmatica2Expert#655 for the original bug report - in this case, Astral Sourcery was registering the capability in init, but we construct upgrades just before then.
2019-01-19 21:57:21 +00:00
if( !craftingStack.isEmpty() && InventoryUtil.areItemsSimilar( stack, craftingStack ) )
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
{
return upgrade;
}
}
return null;
}
Improve our JEI integration a little bit - Turtle and pocket computers provide a "creator mod id" based on their upgrade(s). We track which mod was active when the upgrade was registered, and use that to determine the owner. Technically we could use the RegistryLocation ID, but this is not always correct (such as Plethora's vanilla modules). - We show all upgraded turtles/pocket computers in JEI now, rather than just CC ones. - We provide a custom IRecipeRegistryPlugin for upgrades, which provides custom usage/recipes for any upgrade or upgraded item. We also hide our generated turtle/pocket computer recipes in order to prevent duplicates.
2019-03-16 01:49:02 +00:00
@Nullable
public static String getOwner( IPocketUpgrade upgrade )
{
return upgradeOwners.get( upgrade );
}
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
public static Iterable<IPocketUpgrade> getVanillaUpgrades()
{
List<IPocketUpgrade> vanilla = new ArrayList<>();
Update CC: Tweaked to 1.13 Look, I originally had this split into several commits, but lots of other cleanups got mixed in. I then backported some of the cleanups to 1.12, did other tidy ups there, and eventually the web of merges was unreadable. Yes, this is a horrible mess, but it's still nicer than it was. Anyway, changes: - Flatten everything. For instance, there are now three instances of BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no more BlockPeripheral (thank heavens) - there's separate block classes for each peripheral type. - Remove pretty much all legacy code. As we're breaking world compatibility anyway, we can remove all the code to load worlds from 1.4 days. - The command system is largely rewriten to take advantage of 1.13's new system. It's very fancy! - WidgetTerminal now uses Minecraft's "GUI listener" system. - BREAKING CHANGE: All the codes in keys.lua are different, due to the move to LWJGL 3. Hopefully this won't have too much of an impact. I don't want to map to the old key codes on the Java side, as there always ends up being small but slight inconsistencies. IMO it's better to make a clean break - people should be using keys rather than hard coding the constants anyway. - commands.list now allows fetching sub-commands. The ROM has already been updated to allow fancy usage such as commands.time.set("noon"). - Turtles, modems and cables can be waterlogged.
2019-04-02 12:27:27 +00:00
vanilla.add( ComputerCraft.PocketUpgrades.wirelessModemNormal );
vanilla.add( ComputerCraft.PocketUpgrades.wirelessModemAdvanced );
Move registration methods into a separate class - All "named" entries (blocks, items, recipes, TEs and pocket/turtle upgrades) are registeredin one place. - Most client side models/textures are registered in ClientRegistry - we can't do item colours or TEs for now, as these aren't event based. - A little cleanup to how we handle ItemPocketComputer models.
2019-01-12 17:51:26 +00:00
vanilla.add( ComputerCraft.PocketUpgrades.speaker );
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
return vanilla;
}
Improve our JEI integration a little bit - Turtle and pocket computers provide a "creator mod id" based on their upgrade(s). We track which mod was active when the upgrade was registered, and use that to determine the owner. Technically we could use the RegistryLocation ID, but this is not always correct (such as Plethora's vanilla modules). - We show all upgraded turtles/pocket computers in JEI now, rather than just CC ones. - We provide a custom IRecipeRegistryPlugin for upgrades, which provides custom usage/recipes for any upgrade or upgraded item. We also hide our generated turtle/pocket computer recipes in order to prevent duplicates.
2019-03-16 01:49:02 +00:00
public static Iterable<IPocketUpgrade> getUpgrades()
{
return Collections.unmodifiableCollection( upgrades.values() );
}
Move API registration into separate classes There's several reasons for this change: - Try to make ComputerCraft.java less monolithic by moving functionality into separate module-specific classes. - Hopefully make the core class less Minecraft dependent, meaning emulators are a little less dependent on anything outside of /core. Note we still need /some/ methods in the main ComputerCraft class in order to maintain backwards compatibility with Plethora and Computronics.
2018-12-10 23:46:50 +00:00
}
Reference in New Issue Copy Permalink