World Editing: Transferring Water
@SimGuruModSquad I've managed to successfully transfer the entire layout of one .world file, with the same number of lots, to another, by performing the following steps: 1. First, I deleted the...
Forum Discussion
Hey @Zerbu,
As mentioned above, older worlds use a hard-coded scheme for loading some water resources which I expect is causing this issue. Specifically, the instance for these resources are derived from the world file name which means that if you copy a world file to a new name then the water resources will no longer have matching instances and the game will not find them.
This scheme is generally not used for newer worlds (ones released after initial base game launch) precisely because it's weird and confusing. There may be exceptions though. The worlds you are experimenting on are original base game worlds which is why you are having this problem.
Note that the water is split into a number of chunks and the number of chunks will vary per world file, depending on the dimensions of the world. So the number of resources involved will vary per world.
If the world file contains the resource 153d2219:00000000:0000000000000001, then this is using the new system and this problem should not happen.
But if this resource does NOT exist, then the code will look for water chunks using this scheme:
Types: 033b2b66 and 01661233
Group: 00000000
Instance: 64 bit hash of worldname_chunk-number
For example:
GD_wardVenue_01_0 = GD_wardVenue_01 Chunk#0, which hashes to e389c747890277a1
GD_wardVenue_01_1 = GD_wardVenue_01 Chunk#1, which hashes to e389c747890277a0
GD_wardVenue_01_2 = GD_wardVenue_01 Chunk#2, which hashes to e389c747890277a3
etc.
A couple options to fix:
Option # 1: Update these keys to reflect the new world name. These chunk resources may have gaps (i.e. chunks 0-8 might exist, then the next one is 12) so you can't stop looking once you find a missing one. The largest potential chunk number can be calculated using the data in the terrain resource but it's probably easier to just look from 0 to 100 (or something similarly large) to find them all (presuming you'll write code to do this conversion once you verify this is the root of your problem). And also, the resources are in the fullbuild/delatbuild packages - you should be able to just copy them over to the world file itself with the updated keys.
Option # 2: Convert the older worlds to use the new style system which is more elegant but means adding two new manifest resources (including the 153d2219 resource mentioned above). Should be pretty doable but there might be a wrinkle I haven't thought of with this approach. The nice thing about this option is that you don't need to make copies of the chunk resources (you can just reference the existing resources), and once converted to the new style you can rename the world without issue. Let me know if you want to go this route and I can document the resources involved.
Hope this helps,
-SGMS
As mentioned above, older worlds use a hard-coded scheme for loading some water resources which I expect is causing this issue. Specifically, the instance for these resources are derived from the world file name which means that if you copy a world file to a new name then the water resources will no longer have matching instances and the game will not find them.
This scheme is generally not used for newer worlds (ones released after initial base game launch) precisely because it's weird and confusing. There may be exceptions though. The worlds you are experimenting on are original base game worlds which is why you are having this problem.
Note that the water is split into a number of chunks and the number of chunks will vary per world file, depending on the dimensions of the world. So the number of resources involved will vary per world.
If the world file contains the resource 153d2219:00000000:0000000000000001, then this is using the new system and this problem should not happen.
But if this resource does NOT exist, then the code will look for water chunks using this scheme:
Types: 033b2b66 and 01661233
Group: 00000000
Instance: 64 bit hash of worldname_chunk-number
For example:
GD_wardVenue_01_0 = GD_wardVenue_01 Chunk#0, which hashes to e389c747890277a1
GD_wardVenue_01_1 = GD_wardVenue_01 Chunk#1, which hashes to e389c747890277a0
GD_wardVenue_01_2 = GD_wardVenue_01 Chunk#2, which hashes to e389c747890277a3
etc.
A couple options to fix:
Option # 1: Update these keys to reflect the new world name. These chunk resources may have gaps (i.e. chunks 0-8 might exist, then the next one is 12) so you can't stop looking once you find a missing one. The largest potential chunk number can be calculated using the data in the terrain resource but it's probably easier to just look from 0 to 100 (or something similarly large) to find them all (presuming you'll write code to do this conversion once you verify this is the root of your problem). And also, the resources are in the fullbuild/delatbuild packages - you should be able to just copy them over to the world file itself with the updated keys.
Option # 2: Convert the older worlds to use the new style system which is more elegant but means adding two new manifest resources (including the 153d2219 resource mentioned above). Should be pretty doable but there might be a wrinkle I haven't thought of with this approach. The nice thing about this option is that you don't need to make copies of the chunk resources (you can just reference the existing resources), and once converted to the new style you can rename the world without issue. Let me know if you want to go this route and I can document the resources involved.
Hope this helps,
-SGMS
