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

Bucket Volume: Or, imperial vs metric.


hanetzer
 Share

Bucket Volume  

17 members have voted

  1. 1. Bucket Volume

    • 1000mb
      9
    • 1296mb
      3
    • Other
      5


Recommended Posts

2 hours ago, hanetzer said:

Honestly I don't think mb would be useful to keep around, or perhaps keep it equal to a bucket ounce/whatever

so folks doing chem mods which use liquids which never become blocks (or came from blocks) can stay metric.

I agree, they can define their derived units of measure to be whatever they want (in terms of conversion from the smallest possible unit i.e. atom or bucket ounce etc ), and display it to the user however they want.  I don't think that needs to be standardised between mods?  

I think the proposed 1296 ounces (81 * 16) seems a reasonable tradeoff between granularity (from a user's point of view) and the maximum blocks in an int (i.e. 2^31 / 1296 ~ 1.6 million)

 

nugget    16 oz
ingot    144 oz
block    1296 oz
pane    81 oz

1296 seems to be a good number if you just throw away the milliBuckets name and replace it with something non-metric.  For folks raised in metric countries, milliBuckets != 1/1000 is extremely confusing.

 

An alternative thought - perhaps you want even divisibility by each "voxel" in a block, i.e. 16x16x16 = 4096,  x 81 = 331776 atoms per block

 

ounce = 256 atoms

nugget = 16 oz =  4096 atoms 
ingot = 144 oz =  36864 atoms
block = 1296 oz =  331776 atoms

 

voxel = 81 atoms
single line = 16 voxels = 1296 atoms
pane = 16 lines = 20736 atoms

block = 16 panes = 331776 atoms

 

That give you a maximum of ~6400 blocks in a single 31 bit int.  That seems like plenty?

 

 

 

 

 

Link to comment
Share on other sites

1 hour ago, TheGreyGhost said:

i.e. 16x16x16 = 4096,  x 81 = 331776 atoms per block

This is too big of a number. Quick, what's 1/9th of it?

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Well the idea is that users won't know anything about atoms.  It's for the coders only.

The user will know about

ounces, nuggets, ingots, and blocks, or voxels, lines, panes, and blocks. 

 

Or some arbitrary measure such as grams, kilograms, tons, or just an inexact decimal representation such as 0.153 blocks.  They'll have no idea how many atoms are behind the scenes.  

 

Edited by TheGreyGhost
Link to comment
Share on other sites

Honestly I would say having so many units would be confusing to new players (and some old players).

I don't see how remembering ounces, nuggets, voxels and the conversions between them is easier than "144mb an ingot, 1000mb a bucket".

Without a unified measurement (mB), some modders may start to favor certain units over the others, or invent their own units based on atoms, causing more confusion in the system.

Edited by DavidM
  • Like 1

Some tips:

Spoiler

Modder Support:

Spoiler

1. Do not follow tutorials on YouTube, especially TechnoVision (previously called Loremaster) and HarryTalks, due to their promotion of bad practice and usage of outdated code.

2. Always post your code.

3. Never copy and paste code. You won't learn anything from doing that.

4. 

Quote

Programming via Eclipse's hotfixes will get you nowhere

5. Learn to use your IDE, especially the debugger.

6.

Quote

The "picture that's worth 1000 words" only works if there's an obvious problem or a freehand red circle around it.

Support & Bug Reports:

Spoiler

1. Read the EAQ before asking for help. Remember to provide the appropriate log(s).

2. Versions below 1.11 are no longer supported due to their age. Update to a modern version of Minecraft to receive support.

 

 

Link to comment
Share on other sites

4 minutes ago, DavidM said:

Honestly I would say having so many units would be confusing to new players (and some old players).

I don't see how remembering ounces, nuggets, voxels and the conversions between them is easier than "144mb an ingot, 1000mb a bucket".

Without a unified measurement (mB), some modders may start to favor certain units over the others, or invent their own units based on atoms, causing more confusion in the system.

that's the problem - i.e. an ingot is approximately 111.1111111 mB.  Your system of units has to be consistent.

 

The bottom line is that you have to make tradeoffs for the user, i.e. you either use a decimal representation that is inexact, or you define exact units which will be unwieldy numbers.  The whole metric vs imperial argument eg 15.363 kg vs 30 lb 3 oz.

 

One set of exact units works fine with "nice" numbers if you are dealing in whole amounts of nuggets (i.e. 9-based)

A different set of exact units is more "natural" if you want slabs (or 16-based such as 16x16x16 voxels)

 

When you mix the two together (for example you want to melt nuggets into panes) then you will always have residual bits left over that become messy.

 

If I were implementing a user interface for this, it would for sure be an inexact decimal representation (with an exact count behind the scenes).  For any practical use that I can think of, the user would not care if an ingot is shown as 111 mB instead of 111.11111 mB.

 

  • Like 1
Link to comment
Share on other sites

Bear in mind that more players use metric systems than imperial (according to minecraft server statistics, and the fact that there are few countries which still use the imperial system).

It is far easier for users to understand that half a bucket is 500mb, than it is for them to see 648 "atoms" (If that is the approach, I would prefer to use something like "voxellites" which has no real-world bearing than "atoms" which could cause huge confusion for users of chemical mods).

And to the next argument that you would just display it as "3 1/2 buckets" or 3 1/1296 buckets", that is hugely unnatural for me (and presumably many others).

 

I'm not sure what the issue with 144mb/ingot is. Why does a melted compound have to fit in the same space as a solid one? It doesn't in real life.

And as far as cauldrons, I think it's fair enough to just lose 1mb in a cauldron. Who cares about 1/1000 of a bucket of an infinite resource? And for those mods which have finite supplies of water, they usually add their own mechanisms for collecting/storing it, so the cauldron issue is moot.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Howdy

9 hours ago, Alpvax said:

Bear in mind that more players use metric systems than imperial (according to minecraft server statistics, and the fact that there are few countries which still use the imperial system).

It is far easier for users to understand that half a bucket is 500mb, than it is for them to see 648 "atoms" (If that is the approach, I would prefer to use something like "voxellites" which has no real-world bearing than "atoms" which could cause huge confusion for users of chemical mods).

And to the next argument that you would just display it as "3 1/2 buckets" or 3 1/1296 buckets", that is hugely unnatural for me (and presumably many others).

 

That's for sure... the long slow death of the imperial system can't come fast enough for me.  

Just to be clear - I'm not proposing that the users will ever know about the "atoms" or "voxellites" or "grains" or whatever, that's just an internal representation.  The amount of fluid is stored using an int, i.e. 

final int FLUID_AMOUNT_ONE_VOXELLITE = 1;
final int FLUID_AMOUNT_ONE_NUGGET = 4096
final int FLUID_AMOUNT_ONE_NUGGET = 4096
final int FLUID_AMOUNT_ONE_BLOCK = 4096*81;
//etc

addFluidVoxellites(int voxellites) {
  this.fluidAmount += voxellites;
}

addFluidNuggets(int nuggets) {
  this.fluidAmount += FLUID_AMOUNT_ONE_NUGGET * nuggets;
}

addFluidMilliBlocks(float milliBlocks) {
  this.fluidAmount += (int)FLUID_AMOUNT_ONE_BLOCK * milliBlocks;
}

 

 

9 hours ago, Alpvax said:

I'm not sure what the issue with 144mb/ingot is. Why does a melted compound have to fit in the same space as a solid one? It doesn't in real life.

 

THe round trip is the problem.  In real life, you get conservation of mass i.e. if you melt the compound then freeze it, you get the same mass as before.

if your ingot is 144/1000 of a bucket, then converting ingots to buckets and back again gains you several extra ingots.

If you define a bucket as 1296 "millibuckets", then every metric-system-based user thinks you've taken leave of your senses :)

 

Cheers

  TGG

 

Link to comment
Share on other sites

13 hours ago, TheGreyGhost said:

THe round trip is the problem.  In real life, you get conservation of mass i.e. if you melt the compound then freeze it, you get the same mass as before.

if your ingot is 144/1000 of a bucket, then converting ingots to buckets and back again gains you several extra ingots.

I don't see how that is true at all. Why does 1 block have to fit in 1 bucket? If we just accept that 1 block is 1296mb, everything works.

I don't see why we have to add the restriction that 1 bucket is 1 (solid) block. We can just accept that melting it makes it less dense, therefore bigger.

  • Like 1
Link to comment
Share on other sites

9 hours ago, Alpvax said:

I don't see how that is true at all. Why does 1 block have to fit in 1 bucket? If we just accept that 1 block is 1296mb, everything works.

I don't see why we have to add the restriction that 1 bucket is 1 (solid) block. We can just accept that melting it makes it less dense, therefore bigger.

Howdy

The problem is that you're breaking the minecraft conventions to do that, for an arbitrary coding implementation reason.

Minecraft convention is:

9 nuggets per ingot

9 ingots per block

1 block = 1 bucket (think lava or water being filled into a bucket and back again).

 

This magic number 1296 (16*81) is only important behind the scenes, as a coding implementation, the user doesn't need to know about it at all.  The whole millibuckets question is actually a bit of a red herring, because there are really two parts to this

1) what's the internal representation of a fluid (the "atoms" or "voxellites" or whatever)

2) what do we do with the currently-accepted user convention of "millibuckets"

 

personally I think the best answers are:

1) 4096*81 = 331776 units per block (i,.e. final int FLUID_AMOUNT_ONE_BLOCK = 4096*81;) which allows exact representation of all the standard objects that we're interested in (and hence gives conservation of mass with no round-trip-gain-or-lose-mass problems);

2) leave milliBuckets as 1/1000 of a bucket, and present it to the user in an (inexact) metric format eg "one nugget = approximately 111 mB"

 

-TGG

Link to comment
Share on other sites

16 hours ago, TheGreyGhost said:

1 block = 1 bucket (think lava or water being filled into a bucket and back again).

I don't agree with that logic.

Yes, 1 bucket of a fluid is 1 block of the fluid (although it actually doesn't quite reach the top, so you could argue that is not true), but there is nothing saying 1 solid block is equivalent to 1 bucket of that material melted down.

Liquid doesn't have ingots or nuggets, so those solid conversions do not need to apply to them.

If we keep it as 1 block of a solid becomes a bucket-and-a-bit, all it means is that you don't fit an even number of blocks into your tanks. But I don't see why that is an issue, because once you have converted it to a fluid, whatever you're using it for (machines?) probably doesn't care about the solid amount.

If you want to transfer exact amounts, use the blocks. They are probably easier to transport anyway (there is a vanilla mechanic for it, and you can usually carry 64 per inventory slot as opposed to the 1 in a bucket).

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

The main problem in this debate is not ingots. While ingots point out a clear flaw in the fluid units since 1000mb does not work with vanilla crafting, it is fair to say that does not have to match. However, the fact that forge fluid units are incompatible with two out of three of Mojang's one fluid container, that is bottles and the cauldron, is a huge problem. By this incompatibility, we are stuck with no fluid amount attributed to water bottles, and no mods can safely use bottles or cauldrons as a fluid container due to competing standards. Yes, in Java the cauldron can only hold water and bottles just water or potions, but in Bedrock it works on any fluid and there is a good chance that will one day end up in Java, so it needs to be considered in modding APIs.

 

As soon as you write off cauldrons as an "acceptable duplication" or 1/1000mb as an acceptable loss, you negate an entire vanilla mechanic being used in fluids at all, because if its an acceptable dupe for water, anything using that is an acceptable duplication. It is terrible game design to expect your math to not work out so you delete remainders or duplicate amounts. It is also terrible mod design to actively ignore mechanics in the base game like that.

 

An additional point is does it really matter that a bucket is 1000 parts? Players only see "I need X amount to craft this", that number can mean whatever modders want. I think its much more likely a player is thinking "1 bucket lets me craft 10 of these" than "I need 100mb to craft this" as the way you obtain most fluids is by the bucket.

Link to comment
Share on other sites

Or you do edge-condition checks.

Water bottle? 333mb (oh no a loss)

Cauldron? 333mb / 666mb / 1000mb (depending on state)

 

Worried about someone pulling 333 out of your widget and putting it in a cauldron, then sucking it out of the cauldron to generate fluid? Don't be. They need to do that 1000 times to get ONE extra block worth of liquid. The game already has matter generators in the form of cobblestone generators.

 

Or maybe you don't. You can only pull 999 out of a cauldron, but in order to fill it you need to push 1000. Big deal.

Edited by Draco18s

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

It is a big deal. Any fluid duplication is fluid duplication, which is bad design. You may think 1mb is almost nothing, but some mods add fluids that are expensive enough and used in small enough quantities that it quickly becomes a big deal, and automated users exist that let you automate "do thing 1000 times" super easy, so now my mod becomes a free fluid generator. I will not subject my mod to such an obvious fluid duplication bug even if its as "trivial" as you claim. That is just taking a broken system and using it despite it being broken.

 

And no, disabling pulling buckets out is equally bad. Players should not have to suffer and lose vanilla functionality because forge fluid units do not work with vanilla. Until we have something divisible by 3, fluid stacks are not practical to use for cauldrons or water bottles.

Edited by KnightMiner
Link to comment
Share on other sites

58 minutes ago, KnightMiner said:

And no, disabling pulling buckets out is equally bad.

Yeah I never said that.

 

And if fluid duplication is that big of a deal, then suffer the 1mb loss instead.

Edited by Draco18s

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

You miss the point. The 1mb loss is disabling pulling buckets out. Because you cannot pull 999mb as a bucket. Any method that lets you pull out 999mb as a bucket brings back the duplication.

 

 

Let me try to put the duplication more in terms that most players are used to. What if I told you for a low cost of 7 iron and a catalyst of 8 ingots of a particular metal, you could receive a free nugget of that metal in about 20 seconds, and easily an ingot in a minute or two? This could be used to produce enderium, manyullyn, draconium, any metal you have in your modpack. Would you consider such an exploit to be acceptable duplication? The standard for fluid for a nugget is a measly 16mb, and for an ingot 144mb. Neither is a lot if you can get a free 1mb in a few seconds.

 

When you look at duplication as acceptable because on a grand scale it means little, you forget that not all recipes work on a grand scale. Some recipes simply need 16mb of a fluid for an expensive resource. And really, the idea that any duplication is simply "acceptable" is stupid. If you think buckets are unlikely to get switched from 1000mb, argue that it is unlikely to be switched and why, I could accept that argument. But arguing that what we have right now causes no problems that cannot be easily solved is ridiculous.

Edited by KnightMiner
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

    • Although that too has issues. The forge defined configuration files are loaded after registration
    • Unless I have misunderstood your requirements, I don't think what you are trying to do is going to work.   The closest things in minecraft are banner patterns or paintings. But these are registered in code (not what you want) on both the client and the server. Then when it loads resource packs on the client it looks up the texture for each one.   It does it this way because the game defines what should exist, then lets the user/modpack developer give them textures (with you providing a default texture).   You seem to want to populate a registry from what textures exist in a resource pack? So kind of the reverse. This isn't going to work for at least 2 reasons: * By the time resource packs are loaded, the registries are frozen - It is too late. * Servers don't even load resource packs, so there is no way it can use this mechanism    You need some other mechanism to populate your registry. e.g. a configuration file holding the names of what should exist, but it doesn't sound like what you want?
    • For the most part, this worked, somehow more mods were outdated and i need to fix them
    • You have a version of oculus from the beta (1.2.5) The latest version is mc1.19-1.2.5a, if that doesn't work contact the mod author https://www.curseforge.com/minecraft/mc-mods/oculus/files  
    • ---- Minecraft Crash Report ---- // Hi. I'm Minecraft, and I'm a crashaholic. Time: 8/10/22 7:20 PM Description: Mod loading error has occurred java.lang.Exception: Mod Loading has failed     at net.minecraftforge.fml.CrashReportExtender.dumpModLoadingCrashReport(CrashReportExtender.java:85) [?:?] {re:classloading}     at net.minecraftforge.fml.client.ClientModLoader.completeModLoading(ClientModLoader.java:188) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.lambda$null$1(Minecraft.java:508) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft$$Lambda$3569/1174919051.run(Unknown Source) [?:?] {}     at net.minecraft.util.Util.func_215077_a(Util.java:320) [?:?] {re:classloading}     at net.minecraft.client.Minecraft.lambda$new$2(Minecraft.java:504) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft$$Lambda$3352/424832797.accept(Unknown Source) [?:?] {}     at net.minecraft.client.gui.ResourceLoadProgressGui.func_230430_a_(ResourceLoadProgressGui.java:113) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at net.minecraft.client.renderer.GameRenderer.func_195458_a(GameRenderer.java:481) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.func_195542_b(Minecraft.java:977) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:607) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.main.Main.main(Main.java:184) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_51] {}     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_51] {}     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51] {}     at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51] {}     at net.minecraftforge.fml.loading.FMLClientLaunchProvider.lambda$launchService$0(FMLClientLaunchProvider.java:51) [forge-1.16.5-36.2.34.jar:36.2] {}     at net.minecraftforge.fml.loading.FMLClientLaunchProvider$$Lambda$420/566698125.call(Unknown Source) [forge-1.16.5-36.2.34.jar:36.2] {}     at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:37) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:54) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:72) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.Launcher.run(Launcher.java:82) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.Launcher.main(Launcher.java:66) [modlauncher-8.1.3.jar:?] {} A detailed walkthrough of the error, its code path and all known details is as follows: --------------------------------------------------------------------------------------- -- Head -- Thread: Render thread Stacktrace:     at net.minecraftforge.fml.CrashReportExtender.lambda$dumpModLoadingCrashReport$7(CrashReportExtender.java:88) ~[?:?] {re:classloading} -- MOD jei -- Details:     Mod File: jei-1.16.5-7.7.1.152.jar     Failure message: fml.modloading.dupedmod     Mod Version: 7.7.1.152     Mod Issue URL: https://github.com/mezz/JustEnoughItems/issues?q=is%3Aissue     Exception message: MISSING EXCEPTION MESSAGE Stacktrace:     at net.minecraftforge.fml.CrashReportExtender.lambda$dumpModLoadingCrashReport$7(CrashReportExtender.java:88) ~[?:?] {re:classloading}     at net.minecraftforge.fml.CrashReportExtender$$Lambda$3599/485371408.accept(Unknown Source) ~[?:?] {}     at java.util.ArrayList.forEach(ArrayList.java:1249) ~[?:1.8.0_51] {}     at net.minecraftforge.fml.CrashReportExtender.dumpModLoadingCrashReport(CrashReportExtender.java:86) [?:?] {re:classloading}     at net.minecraftforge.fml.client.ClientModLoader.completeModLoading(ClientModLoader.java:188) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.lambda$null$1(Minecraft.java:508) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft$$Lambda$3569/1174919051.run(Unknown Source) [?:?] {}     at net.minecraft.util.Util.func_215077_a(Util.java:320) [?:?] {re:classloading}     at net.minecraft.client.Minecraft.lambda$new$2(Minecraft.java:504) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft$$Lambda$3352/424832797.accept(Unknown Source) [?:?] {}     at net.minecraft.client.gui.ResourceLoadProgressGui.func_230430_a_(ResourceLoadProgressGui.java:113) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at net.minecraft.client.renderer.GameRenderer.func_195458_a(GameRenderer.java:481) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.func_195542_b(Minecraft.java:977) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:607) [?:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A}     at net.minecraft.client.main.Main.main(Main.java:184) [?:?] {re:classloading,pl:runtimedistcleaner:A}     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_51] {}     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_51] {}     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_51] {}     at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_51] {}     at net.minecraftforge.fml.loading.FMLClientLaunchProvider.lambda$launchService$0(FMLClientLaunchProvider.java:51) [forge-1.16.5-36.2.34.jar:36.2] {}     at net.minecraftforge.fml.loading.FMLClientLaunchProvider$$Lambda$420/566698125.call(Unknown Source) [forge-1.16.5-36.2.34.jar:36.2] {}     at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:37) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:54) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:72) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.Launcher.run(Launcher.java:82) [modlauncher-8.1.3.jar:?] {}     at cpw.mods.modlauncher.Launcher.main(Launcher.java:66) [modlauncher-8.1.3.jar:?] {} -- System Details -- Details:     Minecraft Version: 1.16.5     Minecraft Version ID: 1.16.5     Operating System: Windows 10 (amd64) version 10.0     Java Version: 1.8.0_51, Oracle Corporation     Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation     Memory: 507993864 bytes (484 MB) / 1791492096 bytes (1708 MB) up to 3817865216 bytes (3641 MB)     CPUs: 4     JVM Flags: 4 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx4096m -Xms256m     ModLauncher: 8.1.3+8.1.3+main-8.1.x.c94d18ec     ModLauncher launch target: fmlclient     ModLauncher naming: srg     ModLauncher services:          /mixin-0.8.4.jar mixin PLUGINSERVICE          /eventbus-4.0.0.jar eventbus PLUGINSERVICE          /forge-1.16.5-36.2.34.jar object_holder_definalize PLUGINSERVICE          /forge-1.16.5-36.2.34.jar runtime_enum_extender PLUGINSERVICE          /accesstransformers-3.0.1.jar accesstransformer PLUGINSERVICE          /forge-1.16.5-36.2.34.jar capability_inject_definalize PLUGINSERVICE          /forge-1.16.5-36.2.34.jar runtimedistcleaner PLUGINSERVICE          /mixin-0.8.4.jar mixin TRANSFORMATIONSERVICE          /forge-1.16.5-36.2.34.jar fml TRANSFORMATIONSERVICE      FML: 36.2     Forge: net.minecraftforge:36.2.34     FML Language Providers:          javafml@36.2         minecraft@1         kotori_scala@2.13.8-build-3     Mod List:          forge-1.16.5-36.2.34-client.jar                   |Minecraft                     |minecraft                     |1.16.5              |NONE      |Manifest: NOSIGNATURE         forge-1.16.5-36.2.34-universal.jar                |Forge                         |forge                         |36.2.34             |NONE      |Manifest: 22:af:21:d8:19:82:7f:93:94:fe:2b:ac:b7:e4:41:57:68:39:87:b1:a7:5c:c6:44:f9:25:74:21:14:f5:0d:90
  • Topics

×
×
  • Create New...

Important Information

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