Jump to content

An ID expansion addon?! (and other ideas)


DeathHammer000

Recommended Posts

Hello. My name is DeathHammer000.

 

I am a lover of mods (with 275 in my game and counting!). Yet there are things that trouble me and other like me...

 

1.7.2, I understand, was very hard for the Forge guys to update to. Modders also had trouble updating. In fact, I could only find 80 worthy mods for my 1.7.2 modpack and the 1.8 snapshots are already being released!

 

I, therefore, use 1.6.4. There are many more mods for this version, however, because of the sheer number of mods I have, I don't have enough block, entity and biome IDs left. And the Forge devs are not working on 1.6.4 anymore.

 

My idea is an ID expansion addon/patch which allows more IDs for EVERYTHING. Potions, enchantments, blocks, biomes... EVERYTHING.

 

I would appreciate it if someone could make this for Forge 9.11.1.965.

 

I would also like a mod backporting tool (modders are now concentrating on 1.7.2 and are adding features that will most likely never be in 1.6.4).

 

I really do hope that someone can make these tools.

 

Thank you.

Link to comment
Share on other sites

No, as support for more IDs must be added by mojang.

 

We can do it, but it would mean breaking compatibility with vanilla worlds. So we won't.

Read the EAQ before posting! OR ELSE!

 

This isn't building better software, its trying to grab a place in the commit list of a highly visible github project.

 

www.forgeessentials.com

 

Don't PM me, I don't check this account unless I have to.

Link to comment
Share on other sites

I'm not sure as to how that would occur; I'm pretty sure that Forge can store vanilla data (which vanilla can use) and mod data (which it can't) separately to avoid such things. The other option would be to change base files in Minecraft using Forge, but that would be very risky.

 

My logic also tells me that a block with ID 2788 should still register in a system with more IDs.

Link to comment
Share on other sites

1.7.2, I understand, was very hard for the Forge guys to update to. Modders also had trouble updating. In fact, I could only find 80 worthy mods for my 1.7.2 modpack and the 1.8 snapshots are already being released!
It's been out long enough there is no excuse for modders to not have updated.

I, therefore, use 1.6.4. There are many more mods for this version, however, because of the sheer number of mods I have, I don't have enough block, entity and biome IDs left. And the Forge devs are not working on 1.6.4 anymore.
OMG you use a billion mods and your limited resources are taken up.. For shame!

My idea is an ID expansion addon/patch which allows more IDs for EVERYTHING. Potions, enchantments, blocks, biomes... EVERYTHING.

So... re-writing how the entire ID system and all related things work breaking all compatibility over the network, file saves, player data, etc... because you want more ids...

I would appreciate it if someone could make this for Forge 9.11.1.965.
NEVER ask for support with old systems, it's your choice to use old versions. We do not support nore endorse it.

I would also like a mod backporting tool (modders are now concentrating on 1.7.2 and are adding features that will most likely never be in 1.6.4).
You.. want... a backporting... tool.. How exactly do you expect such a tool to work.... Seriously.... As for backporting in general, no, if you want new features/fixes/functionality UPDATE thats what updates are for. Not our problem if you don't feel like updating to another MC version.

 

I'm not sure as to how that would occur; I'm pretty sure that Forge can store vanilla data (which vanilla can use) and mod data (which it can't) separately to avoid such things.

And then when vanilla tries to read said data, because it physically cant store the numbers you're talking about it either overflows, reads missaligned, throws a negative bound error, or whatever side effect of whatever system was in place.

The other option would be to change base files in Minecraft using Forge, but that would be very risky.
Yes, very.. Not to mention screwing over compatibility with anything else out there for minecraft.

My logic also tells me that a block with ID 2788 should still register in a system with more IDs.
It would, but what happens to ID 5000 or 33000...

 

Ya, no, if you want new features, fixes, tools, update to the latest version.

If you want to use your old stuff that's fine, just have to work within the limitations of the system in place.

 

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

When I found out that my post was locked by an admin, I felt resentment; I did not have the chance to explain what I meant in terms of the ID expansion system that I proposed and about what I meant.

 

So here's the comment and what I really meant to say:

 

"Hello. My name is DeathHammer000.

 

I am a lover of mods (with 275 in my game and counting!). Yet there are things that trouble me and other like me...

 

1.7.2, I understand, was very hard for the Forge guys to update to. Modders also had trouble updating. In fact, I could only find 80 worthy mods for my 1.7.2 modpack and the 1.8 snapshots are already being released!

 

I, therefore, use 1.6.4. There are many more mods for this version, however, because of the sheer number of mods I have, I don't have enough block, entity and biome IDs left. And the Forge devs are not working on 1.6.4 anymore.

 

My idea is an ID expansion addon/patch which allows more IDs for EVERYTHING. Potions, enchantments, blocks, biomes... EVERYTHING.

 

I would appreciate it if someone could make this for Forge 9.11.1.965.

 

I would also like a mod backporting tool (modders are now concentrating on 1.7.2 and are adding features that will most likely never be in 1.6.4).

 

I really do hope that someone can make these tools.

 

Thank you."

 

When I was told that support must be added by Mojang, I thought of a solution - a separate storage system. I got this reply:

 

"And then when vanilla tries to read said data, because it physically cant store the numbers you're talking about it either overflows, reads missaligned, throws a negative bound error, or whatever side effect of whatever system was in place."

 

What I meant was for a system to be in place that prevents vanilla from reading the mod data, so that such errors/crashes are avoided. And even if you don't support it anymore, then there should still be someone willing to add support for an older version of Forge.

 

But I read the rest of the post from LexManos and got this remark: "OMG you use a billion mods and your limited resources are taken up.. For shame!"

 

How is having 275 mods a shameful thing?! I really did feel antagonised - and this was all because of a suggestion. I really do expect better - especially from an admin. And then to leave me with a locked post with no chance to explain what I mean (I admit, that was an error on my part) - I was outraged. A simple idea should not be met with something like this.

Link to comment
Share on other sites

We are only a 4-strong moderation team, and Lex isn't known for being nice to people.

 

I strongly advise you read his post again, as he underlines the technical reasons why the things you're asking for won't work. It's not just saving of IDs itself, it's the network code and a whole lot of other shit that need to be modified to accomodate the changes you're asking for. All of which Forge will not do, as it is too invasive and we risk breaking saves and other mods.

Read the EAQ before posting! OR ELSE!

 

This isn't building better software, its trying to grab a place in the commit list of a highly visible github project.

 

www.forgeessentials.com

 

Don't PM me, I don't check this account unless I have to.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I think i've found a more "generation friendly way" of generating random blobs of mineral around the ore. This both does the trick and make the generation work flawlessly (albeit i need to make some adjustments). I just ended up thinking "MAYBE there is another Feature I can use to place the minerals instead of doing it manually" And, low and behold, SCATTERED_ORE  is actually a thing. I don't really know how "orthodox" this solution is, but it works and rids me of all the problems I had witht my original "manual" implementation. If anybody has any insight on why my original class could've been causing lag to the point of freezes and chunk generation just refusing to keep loading new chunks, I'm also all ears:   Here is the full if (placed) block for anyone with a smiliar issue: if (placed) { // Define the block to replace surrounding blocks with BlockState surroundingBlockState = BlockInit.ABERRANT_MINERALOID.get().defaultBlockState(); RuleTest stoneReplacement = new TagMatchTest(BlockTags.STONE_ORE_REPLACEABLES); //Tag which indicates ores that can replace stone RuleTest deepslateReplacement = new TagMatchTest(BlockTags.DEEPSLATE_ORE_REPLACEABLES); //Tag which indicates ores that can replace deepslate // Create a list of TargetBlockState for the Aberrant Mineraloids List<OreConfiguration.TargetBlockState> targets = new ArrayList<>(); targets.add(OreConfiguration.target(stoneReplacement, surroundingBlockState)); targets.add(OreConfiguration.target(deepslateReplacement, surroundingBlockState)); // Create a new OreConfiguration for the Aberrant Mineraloids OreConfiguration mineraloidConfig = new OreConfiguration(targets, 9); // vein size // Create a new context for the Aberrant Mineraloids FeaturePlaceContext<OreConfiguration> mineraloidCtx = new FeaturePlaceContext<>( Optional.empty(), world, ctx.chunkGenerator(), ctx.random(), offsetOrigin, mineraloidConfig ); // Generate the Aberrant Mineraloids using the SCATTERED_ORE configuration boolean mineraloidsPlaced = Feature.SCATTERED_ORE.place(mineraloidCtx); }  
    • bonjour , j ai trouver une vidéo très intéressant sur Minecraft comment voler des villageois sans qu'il sans rendent compte en 37 manière , c est très intéressant a voir et surtout  le refaire après    Je vous les met le lien de la vidéo YouTube : https://shrinkme.cc/ZlHy 
    • Wow, thanks @scientistknight1 ! That was exactly it. The issue: I was extending BaseEntityBlock, which implements getRenderShape as invisible for some reason: public abstract class BaseEntityBlock extends Block implements EntityBlock { ... public RenderShape getRenderShape(BlockState p_49232_) { return RenderShape.INVISIBLE; } ... } Looking at the Implementation on Block, it calls BlockBehaviour, which returns RenderShape.MODEL. Overriding it on my Entity did the trick.   public class AutomataStartBlock extends BaseEntityBlock { ... @Override public RenderShape getRenderShape(BlockState p_49232_) { return RenderShape.MODEL; } ... } It now works. I wonder why why BaseEntityBlock returns INVISIBLE, though.
    • The issue occurs here: CREATIVE_MODE_TABS = DeferredRegister.create(Registries.CREATIVE_MODE_TAB, MOD_ID); Exception message: java.lang.NoSuchFieldError: Class net.minecraft.core.registries.Registries does not have member field 'net.minecraft.resources.ResourceKey f_279569_' The mod loads and operates without any issues during debugging in the development environment. However, it crashes when loading the mod through the official Minecraft launcher. This problem did not occur in versions 1.20.1 or 1.20.4. How can I resolve this error?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.