Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

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


robijnvogel
 Share

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.
Patreon: http://www.patreon.com/lexmanos
Paypal: http://paypal.me/LexManos

BitCoin: 1Q8rWvUNMM2T1ZfDaFeeYQyVXtYoeT6tTn

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.
Patreon: http://www.patreon.com/lexmanos
Paypal: http://paypal.me/LexManos

BitCoin: 1Q8rWvUNMM2T1ZfDaFeeYQyVXtYoeT6tTn

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.
Patreon: http://www.patreon.com/lexmanos
Paypal: http://paypal.me/LexManos

BitCoin: 1Q8rWvUNMM2T1ZfDaFeeYQyVXtYoeT6tTn

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

 Share



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • im trying to figure out how to change my mod's forge version but i cant seem to find the forge version in the build.gradle . build.gradle: buildscript { repositories { // These repositories are only for Gradle plugins, put any other repositories in the repository block further below maven { url = 'https://maven.minecraftforge.net' } mavenCentral() } dependencies { classpath group: 'net.minecraftforge.gradle', name: 'ForgeGradle', version: '5.1.+', changing: true } } apply plugin: 'net.minecraftforge.gradle' group = 'net.mikeyypants' version = '1.0-SNAPSHOT' java { archivesBaseName = 'TestMod' toolchain.languageVersion = JavaLanguageVersion.of(17) } minecraft { // The mappings can be changed at any time and must be in the following format. // Channel: Version: // snapshot YYYYMMDD Snapshot are built nightly. // stable # Stables are built at the discretion of the MCP team. // official MCVersion Official field/method names from Mojang mapping files // // You must be aware of the Mojang license when using the 'official' mappings. // See more information here: https://github.com/MinecraftForge/MCPConfig/blob/master/Mojang.md // // Use non-default mappings at your own risk. They may not always work. // Simply re-run your setup task after changing the mappings to update your workspace. mappings channel: 'official', version: '1.18' // accessTransformer = file('src/main/resources/META-INF/accesstransformer.cfg') // Default run configurations. // These can be tweaked, removed, or duplicated as needed. runs { client { workingDirectory project.file('run') // Recommended logging data for a userdev environment // The markers can be added/removed as needed separated by commas. // "SCAN": For mods scan. // "REGISTRIES": For firing of registry events. // "REGISTRYDUMP": For getting the contents of all registries. property 'forge.logging.markers', 'REGISTRIES' // Recommended logging level for the console // You can set various levels here. // Please read: https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels property 'forge.logging.console.level', 'debug' mods { testmod { source sourceSets.main } } } server { workingDirectory project.file('run') // Recommended logging data for a userdev environment // The markers can be added/removed as needed separated by commas. // "SCAN": For mods scan. // "REGISTRIES": For firing of registry events. // "REGISTRYDUMP": For getting the contents of all registries. property 'forge.logging.markers', 'REGISTRIES' // Recommended logging level for the console // You can set various levels here. // Please read: https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels property 'forge.logging.console.level', 'debug' mods { testmod { source sourceSets.main } } } data { workingDirectory project.file('run') // Recommended logging data for a userdev environment // The markers can be added/removed as needed separated by commas. // "SCAN": For mods scan. // "REGISTRIES": For firing of registry events. // "REGISTRYDUMP": For getting the contents of all registries. property 'forge.logging.markers', 'REGISTRIES' // Recommended logging level for the console // You can set various levels here. // Please read: https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels property 'forge.logging.console.level', 'debug' // Specify the modid for data generation, where to output the resulting resource, and where to look for existing resources. args '--mod', 'testmod', '--all', '--output', file('src/generated/resources/'), '--existing', file('src/main/resources/') mods { testmod { source sourceSets.main } } } } } // Include resources generated by data generators. sourceSets.main.resources { srcDir 'src/generated/resources' } repositories { // Put repositories for dependencies here // ForgeGradle automatically adds the Forge maven and Maven Central for you // If you have mod jar dependencies in ./libs, you can declare them as a repository like so: // flatDir { // dir 'libs' // } } dependencies { // Specify the version of Minecraft to use. If this is any group other than 'net.minecraft' it is assumed // that the dep is a ForgeGradle 'patcher' dependency, and its patches will be applied. // The userdev artifact is a special name and will get all sorts of transformations applied to it. minecraft 'net.minecraftforge:forge:1.18-38.0.8' // Real mod deobf dependency examples - these get remapped to your current mappings // compileOnly fg.deobf("mezz.jei:jei-${mc_version}:${jei_version}:api") // Adds JEI API as a compile dependency // runtimeOnly fg.deobf("mezz.jei:jei-${mc_version}:${jei_version}") // Adds the full JEI mod as a runtime dependency // implementation fg.deobf("com.tterrag.registrate:Registrate:MC${mc_version}-${registrate_version}") // Adds registrate as a dependency // Examples using mod jars from ./libs // implementation fg.deobf("blank:coolmod-${mc_version}:${coolmod_version}") // For more info... // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html // http://www.gradle.org/docs/current/userguide/dependency_management.html } // Example for how to get properties into the manifest for reading at runtime. jar { manifest { attributes([ "Specification-Title" : "testmod", //"Specification-Vendor": "testmod authors", "Specification-Version" : "1", // We are version 1 of ourselves "Implementation-Title" : project.name, "Implementation-Version" : project.jar.archiveVersion, //"Implementation-Vendor": "testmod authors", "Implementation-Timestamp": new Date().format("yyyy-MM-dd'T'HH:mm:ssZ") ]) } } jar.finalizedBy('reobfJar')  
    • For an example look into the slab class (that all the slabs extend)  
    • You need to override the method getShape or getVoxelShape or something like that in your Block class and return your own VoxelShape
    • Maybe the method is not suitable for onArmorTick I want to set the monster not to attack the player   @Override public void onArmorTick(ItemStack stack, World world, PlayerEntity player) { List<MobEntity> mobEntities = getNearbyEntities(player); for (MobEntity mobEntity : mobEntities) { Optional<LivingEntity> target = Optional.ofNullable(mobEntity.getTarget()); target.ifPresent(res -> { if (res instanceof PlayerEntity) { PlayerEntity targetPlayer = (PlayerEntity) res; if (targetPlayer.getUUID().equals(player.getUUID())) { mobEntity.setTarget(null); } } }); }  
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.