Question: How can I make a dimension permanent (no chunkloader to maintain it)?
rockobonaparte opened this issue ยท 9 comments
Is there a way to make certain dimensions permanent? I have two dimensions I want to make accessible without maintaining a creative dimension builder. From what I understand, even the creative dimension builder needs to be chunk loaded. I am having very odd problems with ChickenChunks and would be fine with not needing any kind of chunkloader in the same chunk as the dimension builders. Is this at all possible?
FWIW I am still in 1.7.10 with the Baby's First Space Race mod pack where I am trying to do this for tutorial dimensions. I'm getting reports about lag and ChickenChunks messing up, so I am trying to mitigate some of that.
You can do this with some tricks. You can save the dimension information to json and then load it back. See https://github.com/McJty/RFTools/wiki/RFTools-Commands for more information about the commands to do that (savedim/loaddim). So save the dimension information to a json, edit that file to change the maintenance cost to 0 and then load it back in game
It looks like it is working but it might be for unrelated reasons. I think I have been through this before as the power to the dimensions is at maximum. The maintenance cost is still there after re-import, but I don't see it going down. So it's working... I guess? I'll be letting it run some more to see if my player gets wheezy and the world collapses.
I was doing a playtest with a server and found myself with mining fatigue and slowness in one of the dimensions where I had done this. I dumped the dimension records again from there and it looked like there was no RF cost nor any active effects. I'll just dump it here instead of paraphrasing it since it's just 64 lines:
{
sphereBlock_meta:0,
baseSeed:-6424019368066218103L,
tendrilBlock:1,
liquidSphereBlock_meta:0,
liquidSphereFluid:9,
fluidBlock:1128,
features:[],
liquidSphereBlock:1,
celestialBodies:[4,10,],
worldVersion:1,
liquidSphereBlocks_meta:[0,],
terrain:0,
rainStrength:-1.0f,
extraOregen_meta:[],
lakeFluids:[],
sphereBlocks:[1,],
hugeLiquidSphereBlocks:[],
baseBlock:1,
respawnHere:0b,
forcedSeed:0L,
hugeSphereBlocks:[],
version:1,
extraOregen:[],
skyType:4,
effects:[],
name:"""",
baseBlock_meta:0,
hugeLiquidSphereBlocks_meta:[],
mobs:[
],
shelter:0b,
fogColorFactorB:1.0f,
liquidSphereFluids:[9,],
peaceful:0b,
ownerM:7963761145333762950L,
canyonBlock_meta:0,
ownerL:-5862956953970957917L,
fogColorFactorG:1.0f,
starBrightness:1.0f,
fogColorFactorR:1.0f,
probes:0,
sphereBlocks_meta:[0,],
canyonBlock:1,
pyramidBlocks:[1,],
actualCost:0,
owner:"RockoBonaparte",
noanimals:0b,
thunderStrength:-1.0f,
controller:0,
hugeSphereBlocks_meta:[],
biomes:[],
structures:[],
liquidSphereBlocks:[1,],
hugeLiquidSphereFluids:[],
probeCounter:0,
pyramidBlocks_meta:[0,],
patreon1:0L,
dimensionTypes:"""",
sphereBlock:1,
sunBrightness:1.0f,
digits:"""",
tendrilBlock_meta:0
}
Yeah the dimension now collapses on any regular user trying to enter it. This is in a server environment BTW. So just zeroing the actualCost field is insufficient.
FYI I'd probably just fire off a pull request with something in it myself, but I'm still figuring out how to get the runClient config to work with a CoFHLib dependency. I'm not sure how I'm supposed to set that up.
McJty, I think I have found some useful information after pulling the source down, thumbing through it a bit in IntelliJ, and trying some things.
It looks like the killer is the maintenance cost, and that doesn't appear to be what is imported or exported as actualCost. I see right where it's making the decision to start causing ill effects on the players that it is doing a calculation based on the maintenance cost. This is saved into RFToolsDimensionManager.dat. I was able to hack the NBT data and set the maintenance cost to zero. When I viewed the realized dimension in-game afterwards--after restarting of course--the maintenance cost was not zero, but it did not drain power any more either. I am doing more experiments to see if this takes care of things for me.
I wanted to add that I had a second dimension to which I wanted to do all this. I had done the same things, but its power had already drained to zero. When I went into it in creative mode, I could see a black sky with a bright sun, so it was still performing adverse affects. This seems consistent to how the logic it is coded. If there is no power left, it will do bad effects. I would recommend changing that.
Specifically, I would suggest wrapping logic around the call to handleLowPower(id, power, doEffects, cost) in DimensionTickEvent.java so that it doesn't trigger if the maintenance cost is zero.
I would also request some method of easily setting the maintenance cost to zero for regular civilians that aren't throwing hatchets at their NBT data. ;) Or alternately, if /rftdim setpower maximum setting defaulted to a permanent maximum, which is what I suspect people really want. I think this would be equivalent in the scheme of things here.
Dimensional Anchors Mod is a great alternative to Chicken Chunks from what I've noticed btw, they can even be configured to require Fuel. As far as the Chunk Loader, have you tried placing the Dimension Builder INSIDE the Dimension you're trying to Power (with a remote power supply hooked up of course)? When combined with the item that allows you to traverse an Un-Powered Dimension, this should in theory work fine. this would also allow you to remotely cut the power to it, as well as potentially not even needing a Chunk Loader (even still, could probably just use a Spot Loader on it to keep a 1x1 Chunk loaded).
New users of my pack have complained that they're insta-dying in one of the dimensions, so I do not think the conventions we tried in 1.7.10 actually are working.
I'm starting to work on a 1.10.2 update to Baby's First Space Race and will try to tackle this problem myself. I can't remember what RFTools was using to represent power consumption, but I recall it calculated it once as a numeric value (integer or floating point) and used that in all subsequent power consumption math. The more graceful solution would be to add a boolean value to indicate not to actually consume power and either update the setpower command to manipulate it or add a new one. That boolean would have to be added to the saved data and would have to be robust enough to default when old dimension data files are loaded with it. I have a strong impression McJty has done this in a robust way I can mimic. If not, I'll just use Float.-Infinity or an integer -1 to represent the same logic and drizzle that everywhere.
I am busy augmenting HQM to help me import my old quest book so I am not getting to this right away. I still wanted to share my idea because I've had a few issues with submitting pull requests getting rejected because they violate "vision."
