It is time for another public test version again.
A thing that RFTools has been struggling with for a while is the famous dimlets.cfg and me having to yell at people occasionally for deleting that file when they shouldn't. That has to stop. So first a bit of history and explanation on how things used to work and how they will work from now on:
First you need to know that all dimlets have numbers (id's). These numbers are assigned dynamically based on presence of other mods (for the biome and liquid dimlets), and based on user blacklisting of certain dimlets. So that basically means that (for example) the dimlet 'Dimlet Plains Biome' can be number 102 on one client and 110 on another. This number is fairly important and should remain constant for a given world. Otherwise that 'Dimlet Plains Biome' can suddenly become a 'Dimlet Liquid Lava'. All these numbers are written in 'dimlets.cfg'. When a new mod is added and that mod has new liquids or biomes then new dimlet ids will be assigned automatically and added to dimlets.cfg. If such a mod is removed then the dimlet ids that belong to things from that mod will no longer be used and they will also not be reused for new dimlets. So that part is ok.
These numbers have to be known on both the client and the server so that means that both the client and the server will have to calculate these numbers based on their config and whatever mods are present. Because the server is the master you really want to have the same numbers for a given dimlet on the client as well as on the server.
There are two major problems with this approach:
- dimlets.cfg contains the important mapping so if you remove that file the client or server will calculate it again. If things have changed (new biomes/liquids/...) that can mean that dimlets will get different ids. So suddenly the dimlets you already had will become different dimlets. Not good!
- dimlets.cfg can differ between server and client because maybe the client only got updated from modpack version A to version C while the server got updated from A to B and then from B to C. That means numbers can be differently allocated. In this case what appears to be a certain dimlet on the client will actually be something else since the server is supposed to be the master.
The second problem was fixed in version 2.30. From that version on the server sent over information about the dimlet ids to all clients that connect. The client corrected its internal ids to the new values it got from the server.
The first problem should now be fixed in the dev release that I just made. Basically in this new version dimlet ids will now be stored with the world itself. dimlets.cfg will only be used to let people blacklist dimlets (set them to -1). When using an older world with this new version of rftools the ids from dimlets.cfg will be converted to the new map that is stored with the world. From that point on the numbers in dimlets.cfg will no longer be used. This is a fundamental change. I did a test on single player and with a local test server and things appear to work. A good way to test this is to first start up your world (single player and/or server) and fill a chest with all kinds of dimlets. Remember what you put in there. Then put the dev version of rftools in it and see if the chest is still containing the same dimlets.
If this works then the problem with dimlets.cfg being outdated and/or removed will be a thing of the past. Forever
The latest dev build can be downloaded from:
https://drone.io/github.com/McJty/RFTools/files