Forum Discussion

ZerbuTabek's avatar
8 years ago

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 .world file I wanted to replace, created a copy of the one with the layout I wanted to swap it with, then renamed the copy to the name of the original.
2. Then, I edited the DWorld resource (0x810A102D) and World Objects (0xFCB1A1E4) and updated the lot IDs to match those of the original world.
3. Then, I transferred resource 0x17C0C281 from a backup copy of the original world, which seems to be necessary as the game will crash in Live Mode without it.*
4. Finally, I transferred over all the LOBJ (0x91568FD8) and LDNB (0x12952634) resources. Without those, the game would hang at the loading screen on new saves. I presume they're related to premade lots.

I was able to almost successfully transfer the entire layout of one world to another, except for the water, which seems to be stuck on the original. I tried this twice - once I replaced the north world in Newcrest with the starter world in Oasis Springs and there was no visible water at all, then I tried replacing the community part of Willow Creek with the community part of Oasis Springs, and there was a bit of water which seems to be from the original world.


(The screenshot shows the community part of Willow Creek with its entire layout replaced with Oasis Springs using the steps above - the lighting has also been changed but that is unrelated to the thread)

*I know that water isn't stored in resource 0x17C0C281, as even before I replaced it, I was still able to access the world from Build Mode and the problem still occurred. This problem occurs even when the lot IDs are literally the only thing changed, which strongly suggests that water is defined somewhere outside the .world file.
  • Hey @Zerbu, quick update:

    This is likely because the code requires that some of the instances in the world file match the world file name (i.e. the instances are a hash of a string that includes the world file name). So if you rename the world file, then the code can't find these resources if the keys aren't also updated. I believe the water is the only system doing that, but will need to review the code to see if there are others.

    Not an ideal system and I believe this was changed for worlds that shipped after the initial base game. So for example if you tried the same experiment on non-base game worlds then I expect you would not have this issue.

    I'll post more details when I can.

    -SGMS
  • 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
  • Sorry about the late reply, I was busy working on something unrelated.

    For just transferring, the first option would probably be easier, but I'll likely want to add features that let the user customise the water (for example, change the textures) so I'll probably need .bt files anyway. :)

About The Sims 4 Mods & Custom Content

Find expert tips, troubleshooting help, tutorials for mods and custom content, and The Sims 4 patch files in our forum.4,690 PostsLatest Activity: 29 minutes ago