• Please make sure you are posting in the correct place. Server ads go here and modpack bugs go here
  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

Poll: RFTools Dimension Builder Penalties

Do you want to incure a constant RF cost in order to keep a created dimension accessible?

  • Yes, but not too much

    Votes: 13 12.4%

  • Yes, and a lot more RF for very complicated dimensions

    Votes: 69 65.7%

  • No, the RF cost at creation time is sufficient

    Votes: 17 16.2%

  • Other (clarify in response)

    Votes: 6 5.7%
  • Total voters
    105
HeraBulldog said:
Different tier's of the complexity

Do this!!
Click to expand...

This is actually already done. There are dimensional shards in RFTools dimensions. I'm busy updating the wiki right now which will contain a lot of information about all of this.
 
McJty said:
So, do I have to worry about this? There are a few things I *could* do:

  • Somehow try to alter rarity distribution so that in case of a smaller sample the rarer items become rarer (not sure how I would do that though).
  • Make the RF/tick different *after* creating the world. If I do this it would still not be as expensive as a full diamond block world for example but maybe a percentage of the cost it would have been should be used then. I don't really like the unpredictability of this though.
  • Something else?
Suggestions?
Click to expand...

Why wouldn't you want a random dimension to cost exactly what it would have if it had been assembled manually from its component dimlets? Or am I misunderstanding the problem?
 
McJty said:
Do you still have the dimension tab of the first empty dimension you made? In that case can you do shift-right click on it and give me the output of that? It is a bit long but you should also find it in your log files so that's easier to copy/paste here.

BTW. Did you also delete your world? Because this does look as if you were entering a pre-made dimension that you created using other parameters first (in a previous version of rftools) and then reenter later. Some of the random generation things have changed.
Click to expand...
I wish it was that simple... but although I did not actually delete any of the worlds I created using older versions of your mod, the world containing this dimension was brand-new and created using Beta 5.

In any case, here's the output form the dimension tab:
Code: 
Terrain: TERRAIN_NORMAL
   Base block: Cobblestone
   Tendril block: Stone
   Base fluid: Molten Steel
Feature: FEATURE_CAVES
Feature: FEATURE_NONE
Feature: FEATURE_TENDRILS
Sun brightness: 1.5
Star brightness: 1.5
Celestial angle: 0.2

I created a new world just to test this very bug. First thing I noticed is that the dimension was labeled "Id 8" in the dialing device. I was in the dimension with ID 7, I'm fairly sure, when I opened the previous world up a few minutes earlier. A minor bug, this is; probably inconsequential.

The shift-click output of the realized (empty) dimension tab in this world is as follows:
Code: 
Terrain: TERRAIN_NORMAL
    Base block: Cobblestone
    Tendril block: Stone
   Base fluid: Molten Steel
Feature: FEATURE_CAVES
Feature: FEATURE_NONE
Feature: FEATURE_TENDRILS
Sun brightness: 1.5
Star brightness: 1.5
Celestial angle: 0.2
This looks exactly like the random features in the dimension in the other world. Interesting... I did not exit out of Minecraft between leaving that world and creating this one- could that have something to do with this and with the above "Id 8" thing?

Upon exploring this dimension, I find the same glitchy tendril slices as in the other dimension, but no dirt or grass to be seen outside of the tendrils.

So, I closed Minecraft entirely, then made yet another world from scratch, and created another dimension from an empty dimension tab in it. This time, it was assigned to Id 2, as I would expect for the first RFTools dimension in a world, but once again was filled with cobblestone terrain, stone tendril slices, and oceans of molten steel. As in the previous world, I did not see any remotely normal-looking terrain- it was all cobblestone, molten steel, Chromaticraft crystals, GeoStrata vents, and the occasional Thaumcraft node. The right-click output from the tab is identical to those posted above, except the "Feature: " lines are in a different order.

I generated another dimension in this world with the same dimlets as the third dimension I created in my first Beta 5 test world (two Digit Zeros), and got a dimension with the same features (stone tendrils and lakes of glue and flux goo).

So it looks like RFTools is caching used dimension IDs in memory, and not properly clearing that cache when leaving a world. However, the algorithm you use to select random features and such seems to be pseudorandom, with its seed determined by the contents of the dimension tab. This first of these bugs seems very minor, although the source probably lies deep in your code somewhere. The second one, though, looks to me like it could be fixed by seeding whatever random number generator you're using with some combination of the dimlets used and the world seed. Or just forget the seed and let Java come up with one for you, to ensure that everything that's supposed to be random actually is, abandoning any sort of consistency.

And I still don't know what to think about those tendril slices. I did find one in the last world I generated, amid numerous regular tendrils. However, in the cobblestone and molten steel dimensions, there were no regular tendrils at all- only slices.

Side note: Whenever I use a matter transmitter to go to a new dimension, I end up glitching into the ground. Not a big deal when I'm in creative mode, but could be annoying in survival. Especially if the platform is the only thing between you and a lake of molten steel. Increasing the player's y-coordinate a bit would probably fix it.

CheshireKatt said:
Why wouldn't you want a random dimension to cost exactly what it would have if it had been assembled manually from its component dimlets? Or am I misunderstanding the problem?
Click to expand...
Currently, the cost of a dimension is determined exclusively by the actual dimlets used in enscribing it. This is a useful feature because it lets you know exactly what a dimension will cost as soon as you hit the button in the Dimension Enscriber, before you actually put any RF into it. This way, if you find out that the dimension is too much for your power system to handle, you can just hit the "Extract" button and scrap it without committing any resources, power, or disk space at all.

Under the current system, to my understanding, the actual properties of the dimension are not determined until the dimension is fully built, so if the cost was based on the actual properties of the dimension, there would be no way to tell if your power system could handle it until you paid the (potentially substantial) creation and time costs. If the dimension turned out to be too expensive, you'd have spent that time and RF for nothing, and may scrap the dimension tab to get the dimlets back. This also leaves the never-to-be-used dimension on the server, but impossible to power- an annoyance for server admins with limited disk space and to other players using RFTools's teleportation devices (note that all existing matter receivers, including those generated in RFTools dimensions that have never been visited, appear on the Dialing Device), no doubt.

As for the problem of players randomly winding up with cheap-to-run dimension full of valuable resources, I'm not sure there's much need to worry about it until people actually playtest the mod. If it turns out that players who don't power through TE and RFTools progression in order to start generating random dimensions as quickly as possible typically already have a reliable supply of diamonds and such by the time they get an overpowered dimension, I don't see much reason to change it.
 
Someone Else 37 said:
So it looks like RFTools is caching used dimension IDs in memory, and not properly clearing that cache when leaving a world. However, the algorithm you use to select random features and such seems to be pseudorandom, with its seed determined by the contents of the dimension tab. This first of these bugs seems very minor, although the source probably lies deep in your code somewhere. The second one, though, looks to me like it could be fixed by seeding whatever random number generator you're using with some combination of the dimlets used and the world seed. Or just forget the seed and let Java come up with one for you, to ensure that everything that's supposed to be random actually is, abandoning any sort of consistency.
Click to expand...

I'm indeed caching dimensions in memory but I have code to clean it up after closing. I guess this is somehow going wrong. I will have to check what is happening here. Thanks for testing this.

Side note: Whenever I use a matter transmitter to go to a new dimension, I end up glitching into the ground. Not a big deal when I'm in creative mode, but could be annoying in survival. Especially if the platform is the only thing between you and a lake of molten steel. Increasing the player's y-coordinate a bit would probably fix it.
Click to expand...

I also noticed this.
 
OK so I made a copy of my Direwolf20 server and added this mod to it and a friend and I played with it for a few hours trying to break it. We did get a few client side crashes but that may have been due to other mods and teleporting in general does cause some client side issue. The server never produced any errors other than some TPS issues while generating terrain. So I'm impressed so far.

What I liked
  • The ability to white list players on the destination teleportation receiver
  • The cost of the teleporters was reasonable so when you lost one because you had to leave it in a world it was OK. Just charge it up and remove the power source and the dialing device and you had enough charge to comeback home with.
  • The random structures that had more dimlets in them. Although, most of these structures were at ground level there were a few that were 20 to 30 blocks above ground level.
  • The use of the Dimlet researcher and scrambler.
  • The ability to recover dimlites from the dimension tabs you are going to reuse
  • The cost of peaceful dimlet. I felt this was spot on. It should cost a lot of energy not to have mobs spawn. We also used this to test the power loss effects. Although with this one the power loss was so quick we really didn't have time to analyze it to much. One second you saw a debuff the next you were dead. It might not be bad idea to somehow scale the debuffs on the energy consumption rate.
So on to what I think could be improved upon or seem to be errors (maybe mistakes in how I laid out the dimlets)
  • The default config made it very common to get various liquids instead of water. I didn't test this but from what I've read here I think that can be taken care of by changing the configs.
  • No way to copy a dimension tab. To me this was important because the players living in a void world. If they take the tab and builder into their void age and power it there and something happens to their power generation they would loose access to their base. So they should have a backup copy of their dimension tab stored someplace in the overworld (like an IC personal safe or TE strongbox) that way they could power their world externally again to re-enter their world and fix the power generation issue.
  • Possible improvement would be to have the enscriber recognize dimlets in an adjacent inventory or make special block that holds dimlets. That way they could be easily accessed from the enscriber's interface.
  • Maybe some additional tooltip info for the dimlets that give you an idea of the energy multiplier if this dimlets is used
  • If a terrain block is used (like dirt or coble) it overwrites ore generation. This could be a dimlet order issue as well and maybe my fault.
  • In one dimension I specified two biomes. Traveling several thousand blocks by two players in different directions we only saw one biome. EDIT: I just read on your wiki that this isn't enabled yet.
  • Can't add the efficiency dimlet to an existing dimension.
I'm not sure how much more I can test this. But, if you have some specific tests you want me to run let me know. I can even whitelist you on the test server if you want.

Keep up the good work!
 
Last edited:
If my understanding is correct, for the oregen dimlet, you have to specify what ore (or ores) you want to use. For example, if you use [Diamond Ore] [Dimensional Shard Ore] [Oregen], you should get veins of diamond ore and dimensional shard ore (in a very expensive dimension). I'm not sure how McJty's terrain generator determines what the ore veins look like, at what heights they are generated, how common they are, etc- I haven't tested that yet.

As for the duplicating dimension tabs thing, there was talk a few days ago about some sort of emergency battery that could power the dimension temporarily or otherwise make you immune to the debuffs and instant death for long enough to get your power system back online.

For adding dimlets to existing dimensions (at least the special dimlets- efficiency and peaceful mode both seem like reasonable things to upgrade a dimension with, but not terrain generation stuff), I'm not sure how feasible that would be with McJty's code, but it's certainly something I'd also like to see implemented, now that you mention it.

Also, I'm fairly sure that there's config options for when the different levels of low-power warnings take place. The level 0 warning seems to trigger the sunlight dimming, so I would guess that the other ones are for the debuffs. However, I couldn't tell you which one triggers what debuff.

Another suggestion I'd like to make is to scale the RF cost of the material dimlets based on what feature is filled with that type of material. I would think that a dimension made entirely out of diamond ore should require a whole lot more power than one with diamond ore tendrils or canyons (walls? ridges?), which should in turn require a lot more power than one with diamond ore veins. Especially if those ore veins are as difficult to find as in the Overworld.
 
Henry Link said:
What I liked
  • The random structures that had more dimlets in them. Although, most of these structures were at ground level there were a few that were 20 to 30 blocks above ground level.
Click to expand...

Yes, I also noticed this. Seems that sometimes it still picks wrong spot.

  • The cost of peaceful dimlet. I felt this was spot on. It should cost a lot of energy not to have mobs spawn. We also used this to test the power loss effects. Although with this one the power loss was so quick we really didn't have time to analyze it to much. One second you saw a debuff the next you were dead. It might not be bad idea to somehow scale the debuffs on the energy consumption rate.
Click to expand...

Yes, I may add a scaling option there.

  • The default config made it very common to get various liquids instead of water. I didn't test this but from what I've read here I think that can be taken care of by changing the configs.
Click to expand...

As it works now I made liquids very common and made some exceptions for rare liquids. I think I should do this the other way around. Make liquids rarer in general and make water more common.

  • No way to copy a dimension tab. To me this was important because the players living in a void world. If they take the tab and builder into their void age and power it there and something happens to their power generation they would loose access to their base. So they should have a backup copy of their dimension tab stored someplace in the overworld (like an IC personal safe or TE strongbox) that way they could power their world externally again to re-enter their world and fix the power generation issue.
Click to expand...

You can already make a new version of your dimension tab. To do that you just put exactly the same dimlets in the same order in a new dimension tab and it will automatically refer to the other dimension that you created.

  • Maybe some additional tooltip info for the dimlets that give you an idea of the energy multiplier if this dimlets is used
Click to expand...

Yes, that is useful.

  • If a terrain block is used (like dirt or coble) it overwrites ore generation. This could be a dimlet order issue as well and maybe my fault.
Click to expand...

That is actually a Minecraft thing. By default ores only generated in 'stone'. You *can* override this manually (at the cost of a more expensive dimension) by adding the 'oregen' feature and manually specifying what ores you want to have. Then they should generate in the other base block. But I can't (at least not easily) affect the default ore generation and make that work in other kind of blocks.

  • Can't add the efficiency dimlet to an existing dimension.
Click to expand...

Indeed, this is something that you have to do in advance. I am considering a way to alter a dimension tab to add/remove dimlets that don't affect the actual landscape but add special features to it. But that will be a future feature though.


Thanks for the testing!
 
Someone Else 37 said:
If my understanding is correct, for the oregen dimlet, you have to specify what ore (or ores) you want to use. For example, if you use [Diamond Ore] [Dimensional Shard Ore] [Oregen], you should get veins of diamond ore and dimensional shard ore (in a very expensive dimension). I'm not sure how McJty's terrain generator determines what the ore veins look like, at what heights they are generated, how common they are, etc- I haven't tested that yet.
Click to expand...

Yes that's correct. I'm using:

addOreSpawn(block, information.getBaseBlockForTerrain(), world, random, chunkX * 16, chunkZ * 16, 7, 10, 12, 2, 60);

which means 12 veins from 7 to 10 size between height 2 and 60.

For adding dimlets to existing dimensions (at least the special dimlets- efficiency and peaceful mode both seem like reasonable things to upgrade a dimension with, but not terrain generation stuff), I'm not sure how feasible that would be with McJty's code, but it's certainly something I'd also like to see implemented, now that you mention it.
Click to expand...

Yes I will add something like this but in a future release.

Also, I'm fairly sure that there's config options for when the different levels of low-power warnings take place. The level 0 warning seems to trigger the sunlight dimming, so I would guess that the other ones are for the debuffs. However, I couldn't tell you which one triggers what debuff.
Click to expand...

Level 0: start diming
Level 1: Slowdown
Level 2: Slowdown + harm
Level 3: Slowdown + harm + poison

Another suggestion I'd like to make is to scale the RF cost of the material dimlets based on what feature is filled with that type of material. I would think that a dimension made entirely out of diamond ore should require a whole lot more power than one with diamond ore tendrils or canyons (walls? ridges?), which should in turn require a lot more power than one with diamond ore veins. Especially if those ore veins are as difficult to find as in the Overworld.
Click to expand...

There is currently already a multiplier implemented for certain dimlet combinations. In the configs they are:

I:multiplier.Liquid.Terrain=10
I:multiplier.Material.Feature=1
I:multiplier.Material.Terrain=10

That basically means that for example, a material dimlet used as a modifier for a feature just has the same cost as it would have normally but if you use a material dimlet in combination with terrain the cost is multiplied with 10.
 
McJty said:
That is actually a Minecraft thing. By default ores only generated in 'stone'. You *can* override this manually (at the cost of a more expensive dimension) by adding the 'oregen' feature and manually specifying what ores you want to have. Then they should generate in the other base block. But I can't (at least not easily) affect the default ore generation and make that work in other kind of blocks.
Click to expand...
I like it when I learn something new. And that explains a lot. In this case I was trying to get a normal terrain generation but I didn't see a stone dimlet so I put in one for dirt. When the world generated it was all dirt (no grass) and digging down to find caves there was no ores. Re did the dimlets (removed the water and dirt dimlet and put in stanard terrain) and I got the single biome I was after with proper grass/dirt/stone and ore generation.
 
I'm busy fixing several things and working on some of the suggestions here. I'm also implementing a 'cost factor' which is applied after generating the dimension and which will be based on the cost of all randomly selected features. This is configurable. If you don't want this extra cost (the behaviour it is now) you set it to 0. If you want to pay the full prize then set it to 1. By default it is set to 0.1 (10%). So that means that by default you still get rewarded for being lucky and getting a good world but you might have some surprises in powering your world. If you would get a diamond block world randomly then you would only have to pay 100000 RF/tick instead of 1000000 RF/tick which is a considerable discount I would say :-)
 
2.00beta5 should have been the last beta. But I feel I have done a number of rather fundamental changes so another beta is released now:

http://www.mediafire.com/download/163idtj13cbdyj0/rftools-2.00beta6.jar

Changelog between 2.00beta5 and 2.00beta6:
  • Implemented a 10% extra cost after creation (configurable) to compensate for expensive random features you might get after creating a world.
  • Known dimlets now have a tooltip describing the cost, rarity and craftable information of that dimlet.
  • Reduced the chance that a random non-water liquid is selected for oceans from 0.4 to 0.2
  • Attempt to improve 'bad spot' selector for spawn platform. Also raise the spawn platform with 1 to prevent it being in the ground and possibly being overwritten by oregen.
  • Dimensions are now created with a seed based on the seed of the world itself. That way you no longer get the same features for the same series of dimlets.
  • Dimension information is now saved with the world. Previously dimension information was calculated again when the world loads. However, if a mod is added or removed, or if RFTools adds or removes dimlets then this can result in other features being selected for dimensions that are already created.
  • Properly unload dimension information when the game is unloaded and a new game is loaded.
  • Put honey on the blacklist. As a fluid for landscapes it doesn't behave very well.
  • Better cleanup before loading a new world.
  • Increased the height of the player with 0.5 after teleport to prevent arriving in the teleporter.
  • Added command to dump material rarity.
This time I did some effort to make sure worlds are compatible. However, since some of the features above were changes in the configs you will not get those features unless you make a new world and delete config.
 
I just finished the in-game manual (the dimension builder has its own book because the first one was already getting a bit full). I'm doing some final tests and tomorrow (if all goes right and nobody reports any major new bugs) I'll release the 2.0 release. So in about 10 hours from now hopefully.
 
OK found a small bug. I was crafting the dimlet for void. When I plucked it out of the crafting table I received "Structure Scattered" which according to NEI doesn't have a crafting recipe.

When crafting flat I received void. I just double checked what NEI was telling vs your wiki. They match. So I'm not sure why I'm getting the wrong dimlet. Again, I'm playing with your mod added to the DW20 pack (v1.0.2).
 
You must log in or register to reply here.
Back
Top