Jump to content

[1.9 or higher] [not that revolutionary] Multiple dimension-dependent configsets


robijnvogel

Recommended Posts

So before proposing my feature request to you, I am first going to state that this would require some BIG changes and that it may not be feasible to implement these on a Minecraft version that already has a lot of mods, like MC 1.7.10 or 1.8.9.

If accepted and implemented quickly, MC 1.9 may be possible, but I guess this can not be implemented any sooner than MC 1.10.

 

So here is the idea: Introduce a new structure for config settings, to allow users/modpack makers to have a separate set of configs for separate dimensions. This would allow for different dimensions to handle for instance, the energy usage of machines, the generation of structures (using multiple Overworlds with the Forge Essentials Multiworld function) or other mod-specific settings in different dimensions separately.

 

Actually this "multiple config sets for the same modpack" idea is the general idea behind my Void of Magic/Tech modpack that is distributed via the FTB launcher. There is, however, a Minecraft forum thread for the pack as well, and there HeadsUpHigh suggested to me that I should take this Idea to the next level.

 

On the Minecraft Forums, HeadsUpHigh and be have been discussing this feature on the Minecraft Forum for a bit and I think that that discussion describes the way we visualize the possibility of this system better than I can explain it here.

This is why I am linking the first comment in this discussion here.

If you want to know more about the general idea behind my modpack that led to this feature request, you can read about that in the OP.

I walk amongst titans.

Link to comment
Share on other sites

There's nothing to make this easier on mod developers either. It'll only be effective if a lot of mods implement this in the same way.

Otherwise there will maybe be one mod that is going to pick up on it and since no other mods have it, the functionality in that one mod will never get used.

I walk amongst titans.

Link to comment
Share on other sites

This isnt "revolutionary" or anything special. Its something ive been thinking of doing for a long time. Just mever gotten around to doing.

The issue is we are not rewriting the config system unless we start using a more SANE save format. I would like to use json, but the whole not supporting comments is the issue.

 

We need to find a pragmatic way to save config objects to a easily edited, standard, format with comments.

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

We need to find a pragmatic way to save config objects to a easily edited, standard, format with comments.

 

I recently stopped using all my about-year-old configs based on Forge Configuration in favor of HOCON format (https://github.com/typesafehub/config).

I can only say I am like... infinitely satisfied. You have more readable JSON format which can have comments and can be even sent to clients as serialized JSON, I mean - how fun is that! And the API - it is so nice and tidy (gotta love e.g: default fallbacks).

 

If any, I'd recommend you guys utilizing this or something of this sort.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

Problem with using hocon is the license may be a issue (need to read it) and shipping it.

Also its onternal api is bad for what we want modders to see. But its something i could look into.

 

Skimming the github on my phone makes the .conf format seem powerful... but also TO powerful to the point where its to complex.

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

Problem with using hocon is the license may be a issue (need to read it) and shipping it.

Also its onternal api is bad for what we want modders to see. But its something i could look into.

 

Skimming the github on my phone makes the .conf format seem powerful... but also TO powerful to the point where its to complex.

 

What about the .ini format that IC2 uses? Or isn't that any more structured than the current .cfg format?

I walk amongst titans.

Link to comment
Share on other sites

ini is flat, flat is bad. It also is not strongly typed and doesn't have mechanics for things like lists or the like.

Really all I want is a implementation of the JSON WRITER that supports comments, no extra fancy shit, just that.

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

This is probably a horrible way of doing things, but I store my configs in json using the format:


{
  "thirst-enabled": {
    "description": "Should DayZ thirst be enabled?",
    "value": true
  },
  "debug-mode": {
    "description": "Should DayZ log extra information?",
    "value": false
  },
  "structure-generation-chance": {
    "description": "1 in x chance to generate a structure in a given chunk",
    "value": 60
  },
  "show-world-type-warning": {
    "description": "Should DayZ warn if the worldtype is not DayZ?",
    "value": true
  },
  "spawn-zombies-in-default-world": {
    "description": "Should DayZ zombies generate in the surface world?",
    "value": false
  }
}

Link to comment
Share on other sites

  • 2 months later...

My only suggestion would be YAML.

I know it isn't perfect, I would rather have the braces there to show the hierachy, but it allows comments in addition to everything JSON allows (as far as I am aware).

Alternatively someone could write a custom format (probably JSON-based) that allows comments. It could even be as simple as a custom JSON parser.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

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