Disney Dreamlight Valley [0100D39012C1A000]

morarin · Saturday at 2:59 PM

patjenova said:
Here it is for 1.23.0
[00# Mastercode Get Craft 0xB4BFF00 (Select First Item)]
040A0000 08CB4F04 F0014053
040A0000 08CB4F08 F9078262
040A0000 08CB4F0C AA0203F3
040A0000 08CB4F10 1706704E
040A0000 04E51044 14F98FB0

And this is an example code you could try.
[(ZL) Change Selected Crafting Recipe To DreamSnaps Decor Reward]
580F0000 0B4BFF00
580F1000 00000040
780F0000 00000018
640F1000 00000000 01DF2085

Thank you, patjenova. Your code helped me understand Khuong’s old crafting recipe code more correctly.

I need to correct my earlier understanding. I was mainly looking at the pointer-code part of Khuong’s old code, and I missed that the Master Code also had the part that saves the recipe pointer into a scratch slot. After reading your v1.23.0 code, I realized that Khuong’s old code was not simply a normal pointer chain. It was also using a hook-assisted saved pointer mechanism. So I think your code is best understood as a proper v1.23.0 update of Khuong’s old crafting recipe code.

Both versions use the same basic idea:

Code:

hook Meta.CraftWithRecipe$$GetRelevantInventory
save CraftingRecipeItemData* to a scratch slot
read that saved pointer with Atmosphère pointer code
edit recipe->result_->itemID_

The v1.23.0 master code is:

Code:

[00# Mastercode Get Craft 0xB4BFF00 (Select First Item)]
040A0000 08CB4F04 F0014053
040A0000 08CB4F08 F9078262
040A0000 08CB4F0C AA0203F3
040A0000 08CB4F10 1706704E
040A0000 04E51044 14F98FB0

Each `040A0000` line writes one 32-bit ARM64 instruction to `main + offset`.

So these lines:

Code:

040A0000 08CB4F04 F0014053
040A0000 08CB4F08 F9078262
040A0000 08CB4F0C AA0203F3
040A0000 08CB4F10 1706704E

write this small code cave:

Code:

0x7108CB4F04: ADRP X19, #0x710B4BF000
0x7108CB4F08: STR  X2, [X19,#0xF00]
0x7108CB4F0C: MOV  X19, X2
0x7108CB4F10: B    0x7104E51048

And this line:

Code:

040A0000 04E51044 14F98FB0

patches the original function at:

Code:

0x7104E51044

The original instruction there is:

Code:

0x7104E51044: MOV X19, X2

After the patch, it becomes:

Code:

0x7104E51044: B 0x7108CB4F04

So the game jumps to the code cave.

The hooked function is:

Code:

Meta.CraftWithRecipe$$GetRelevantInventory

In v1.23.0, the relevant argument is `recipeData`, which is a `CraftingRecipeItemData*`.

For an IL2CPP instance method on ARM64, the native register layout is usually like this:

Code:

X0 = this
X1 = first normal argument
X2 = second normal argument
X3 = MethodInfo

So in this case, `X2` appears to be:

Code:

CraftingRecipeItemData* recipeData

This also matches the original function. The game does:

Code:

MOV X19, X2

and later reads:

Code:

LDR X8, [X19,#0x48]

`CraftingRecipeItemData + 0x48` is `ingredients_`, so `X19` is being used as the recipe object.

Now the code cave:

Code:

ADRP X19, #0x710B4BF000

`ADRP` loads a 4KB page address into a register. Here it loads:

Code:

X19 = 0x710B4BF000

ARM64 often builds an address as `page + offset`, because a full 64-bit absolute address usually cannot be used directly in a normal load/store instruction.

Code:

STR X2, [X19,#0xF00]

This stores the 64-bit value in `X2` to:

Code:

0x710B4BF000 + 0xF00 = 0x710B4BFF00

In main-offset form:

Code:

0x710B4BFF00 = main + 0x0B4BFF00

So this line saves the current `CraftingRecipeItemData*` pointer to:

Code:

main + 0x0B4BFF00

Then:

Code:

MOV X19, X2

restores the original instruction that was replaced by the hook.

Finally:

Code:

B 0x7104E51048

returns to the original function, immediately after the replaced instruction.

So the code cave is basically:

Code:

*(u64 *)(main + 0x0B4BFF00) = recipeData;
X19 = recipeData;
return to the original function;

The segment table is important here:

Code:

Name      Start           End             Permission
.text     0x7100000000    0x7108CB5000    R-X
.rodata   0x7108CB5000    0x710966E958    R--
.data     0x710A4FC000    0x710B1014C0    RW-
.bss      0x710B1014C0    0x710B4BF138    RW-
Imports   0x710B4C0008    0x710B4C17A8    R--

The code cave is placed at:

Code:

0x7108CB4F04

This is inside the `.text` segment and before `.rodata` starts at:

Code:

0x7108CB5000

Since `.text` has execute permission, unused padding near the end of `.text` can be used as an ASM code cave.

The saved pointer slot is:

Code:

0x710B4BFF00

This is after `.bss` ends:

Code:

0x710B4BF138

and before Imports starts:

Code:

0x710B4C0008

So it is in the padding area after `.bss` and before Imports. More importantly, it is still in the same 4KB page as the end of `.bss`:

Code:

0x710B4BF000 - 0x710B4BFFFF

Since `.bss` is writable, this page is likely writable at runtime. That makes `0x710B4BFF00` suitable as a small 8-byte scratch slot for saving a pointer.

So the address usage is:

Code:

0x7108CB4F04  -> executable .text padding, used as ASM code cave
0x710B4BFF00  -> writable .bss-end padding, used as saved pointer storage

After the master code saves the recipe pointer, the example code can use it:

Code:

[(ZL) Change Selected Crafting Recipe To DreamSnaps Decor Reward]
580F0000 0B4BFF00
580F1000 00000040
780F0000 00000018
640F1000 00000000 01DF2085

Line by line:

Code:

580F0000 0B4BFF00

This loads a 64-bit pointer from:

Code:

main + 0x0B4BFF00

into Atmosphère Cheat VM register `R15`.

Because the master code saved `recipeData` there, this gives:

Code:

R15 = CraftingRecipeItemData*

580F1000 00000040

This dereferences:

Code:

R15 = *(u64 *)(R15 + 0x40)

`CraftingRecipeItemData + 0x40` is `result_`, so now:

Code:

R15 = ResultInstance*

780F0000 00000018

This adds `0x18`:

Code:

R15 = R15 + 0x18

`ResultInstance + 0x18` is `itemID_`, so now `R15` points to:

Code:

&result_->itemID_

Finally:

Code:

640F1000 00000000 01DF2085

writes the 32-bit value `0x01DF2085` to the address in `R15`.

So the pointer code is basically:

Code:

recipe = *(CraftingRecipeItemData **)(main + 0x0B4BFF00);
result = recipe->result_;       // +0x40
result->itemID_ = 0x01DF2085;   // +0x18

The object path is:

Code:

CraftingRecipeItemData + 0x40 -> result_
ResultInstance + 0x18 -> itemID_

This is the same basic design as Khuong’s old v1.8.6 code.

Khuong’s old code saved the recipe pointer to:

Code:

main + 0x0B9B0F08

and then read it from the crafting recipe code.

Your v1.23.0 code saves the recipe pointer to:

Code:

main + 0x0B4BFF00

and then reads it from the new pointer code.

So the mechanism is:

Code:

hook GetRelevantInventory
save CraftingRecipeItemData* to scratch slot
read saved pointer with Atmosphère pointer code
edit recipe->result_->itemID_

One small note: the posted example title says `(ZL)`, but the shown pointer-code lines do not include the usual button wrapper. If it should only run while holding ZL, it would normally need:

Code:

80000100
...
20000000

As far as I can tell, patjenova is one of the most active cheat-code contributors on GBAtemp. His codes often show techniques that seem to come from many years of studying, updating, and reverse engineering different cheat-code patterns. In that sense, his codes are probably much better learning material than my own codes, since I usually only make and share practical, game-specific codes for the games I personally play.

patjenova · Saturday at 3:55 PM

morarin said:
Thank you, patjenova. Your code helped me understand Khuong’s old crafting recipe code more correctly.

I need to correct my earlier understanding. I was mainly looking at the pointer-code part of Khuong’s old code, and I missed that the Master Code also had the part that saves the recipe pointer into a scratch slot. After reading your v1.23.0 code, I realized that Khuong’s old code was not simply a normal pointer chain. It was also using a hook-assisted saved pointer mechanism. So I think your code is best understood as a proper v1.23.0 update of Khuong’s old crafting recipe code.

As far as I can tell, patjenova is one of the most active cheat-code contributors on GBAtemp. His codes often show techniques that seem to come from many years of studying, updating, and reverse engineering different cheat-code patterns. In that sense, his codes are probably much better learning material than my own codes, since I usually only make and share practical, game-specific codes for the games I personally play.

dont be so hars on yourself. You did a great job with this game and came furter than most people did. But you are correct in a way that code making can only be achieved by learning codes.

annieraccoon · Monday at 5:20 AM

patjenova said:
Here it is for 1.23.0
[00# Mastercode Get Craft 0xB4BFF00 (Select First Item)]
040A0000 08CB4F04 F0014053
040A0000 08CB4F08 F9078262
040A0000 08CB4F0C AA0203F3
040A0000 08CB4F10 1706704E
040A0000 04E51044 14F98FB0

And this is an example code you could try.
[(ZL) Change Selected Crafting Recipe To DreamSnaps Decor Reward]
580F0000 0B4BFF00
580F1000 00000040
780F0000 00000018
640F1000 00000000 01DF2085

Thanks a bunch, patjenova. You're one of the greats! I took khuong's old pointer & searched it with breeze. Tons of results to try one by one. I then manually searched for where the new asm cheat would go (by copying and pasting a large chunk of the instructions from the old main file, and from the new main file into 2 notepad windows on my computer...then I searched & compared where the new asm instruction would go based on where it was in the old game this is very time consuming, but it's been the easiest method for me...) Brute force...lots of patience

, too much tenacity.... I can sometimes get that stupid festive fish to inventory then the game crashes. I'm no good with pointer codes, but my result seems like it was probably way too many lines for what it needed to be. I'll be seeing what I can do with what you posted now. You're far better than I am, so I will probably have more success now using your code as a template. Awesome! Thanks for the assistance!

Post automatically merged: Monday at 5:54 AM

morarin said:
I am not really a general cheat-code maker. I mostly like decorating games, so I learned some DDV cheat-code / IL2CPP / ASM basics to give myself more freedom in the game. I also learned in a similar way. For Fashion Dreamer, I studied and reproduced some of Thor Hammer’s cheats to understand how IL2CPP game cheats work. So I agree that reverse engineering other people’s cheats is a very useful way to learn.

About Khuong’s old crafting item code, I think it is useful to separate two things:

what the pointer code does

how Khuong originally found the pointer

The old v1.8.6 code is:

Code:

80000100 580F0000 0B9B0F08 580F1000 00000040 480D0000 00000000 00000018 640F01D0 00000000 07270E68 480D0000 00000000 0000001C 640F01D0 00000000 00000001 20000000

This is not ARM64 ASM. It is an Atmosphère Cheat VM pointer code.

Roughly, it does this:

Code:

if (ZL_is_pressed) { p = *(u64 *)(main + 0x0B9B0F08); result = *(u64 *)(p + 0x40); ``` *(u32 *)(result + 0x18) = ITEMID; *(u32 *)(result + 0x1C) = AMOUNT; ``` }

Here, R15 and R13 are Cheat VM virtual registers, not ARM64 X15/X13.

Since this code was made for v1.8.6, I checked it against the v1.8.6 dump.cs.

There are two possible structures to compare.

First, `CraftWithRecipe.Types.Request` in v1.8.6 has:

Code:

CraftWithRecipe.Types.Request +0x18 = craftingRecipeItemID_ +0x1C = amountOfCrafting_

So if we only look at the final writes:

Code:

write +0x18 = ITEMID write +0x1C = AMOUNT

then Request is still possible.

But the code does one more important thing before those writes:

Code:

580F1000 00000040

That means:

Code:

R15 = *(u64 *)(R15 + 0x40);

Now compare that with `CraftingRecipeItemData` in the v1.8.6 dump:

Code:

CraftingRecipeItemData +0x18 = iD_ +0x20 = name_ +0x28 = displayName_ +0x30 = iconAddress_ +0x38 = prefabAddress_ +0x40 = result_ +0x48 = ingredients_ +0x50 = recipeType_

And `CraftingRecipeItemData.Types.ResultInstance` has:

Code:

ResultInstance +0x18 = itemID_ +0x1C = amount_ +0x20 = state_

So the full pointer chain matches this very cleanly:

Code:

selected CraftingRecipeItemData +0x40 -> result_ result_ +0x18 -> itemID_ +0x1C -> amount_

That is why I think the code is more likely modifying the selected recipe’s `ResultInstance`, not a temporary `CraftWithRecipe.Request`.

In pseudo-code:

Code:

selectedRecipe = *(CraftingRecipeItemData **)(main + 0x0B9B0F08); result = selectedRecipe->result_; result->itemID_ = ITEMID; result->amount_ = AMOUNT;

Khuong’s comment also supports this:

That makes sense if the code changes the loaded `CraftingRecipeItemData.result_` object. Once changed, that recipe stays modified in memory until the game reloads the recipe data.

So for v1.23.0, I do not think the final offsets are the hard part. The same basic layout still seems to exist:

Code:

CraftingRecipeItemData + 0x40 -> result_ ResultInstance + 0x18 -> itemID_ ResultInstance + 0x1C -> amount_

The hard part is finding the new equivalent of:

Code:

main + 0x0B9B0F08 -> currently selected CraftingRecipeItemData*

That first pointer is what needs to be rediscovered.

I also do not know exactly how Khuong originally found it. He may have used memory search, pointer search, dump.cs/IDA, GDB, or a mix of those.

However, because the recipe stays changed until reload, I do not think a simple search like this is enough:

Code:

select recipe A search result Item ID A select recipe B filter for result Item ID B

That assumes the same address changes from Item ID A to Item ID B. But I think each recipe has its own `ResultInstance`, and the thing that changes when selecting another recipe is probably the selected recipe pointer:

Code:

selectedRecipeSlot = recipeA; selectedRecipeSlot = recipeB;

So the target should be the selected `CraftingRecipeItemData` pointer slot, not a changing `itemID_` value.

For actually adding holiday/event items like festive fish, I still think save editing is usually the easiest method. It is much easier than creating a new cheat code, and there is already a guide here:

Disney Dreamlight Valley: Adding Currencies and Items

But I completely understand wanting to study the cheat itself. Even if save editing is easier for this specific goal, reverse engineering Khuong’s code is still useful for learning how the game stores and accesses data at runtime.

Post automatically merged: Saturday at 12:56 PM

About the online chests, I had not really thought about that problem before because I usually play online. So I did not realize how annoying the blue moonstone chests could be for offline players. I have confirmed that they can be moved or removed in real time with an experimental Grid Edit expansion code I made. It allows normally restricted objects, including the blue moonstone chest, to be selected/moved/removed in Grid Edit mode. However, I have not released that code because it can be dangerous. More accurately, some parts of it can create save states where the game may no longer boot normally. The problem is not only removing objects, but bypassing too many placement / validity checks. That can allow objects to spawn or be placed in places where the game normally never expects them to exist. So for this specific problem, I still think save editing is the simpler and safer method.

I think the blue moonstone chest item is probably this one:

Code:

2010000064,ItemSpawning/MoonStoneChest,RecurringEvent.LootPresent1_DisplayName,RecurringEvent,FALSE,None,None

If you search the save for:

Code:

2010000064

you may find something like this. In my save, I found:

Code:

"220": { "ItemSpawning": { "RecurringEventItemID": 2010000064, "NextOccurrence": "2026-07-04T00:00:00Z", "EndDate": null, "LastOccurrence": "2026-07-03T03:43:21.837559900Z" } }

I have not tested this specific save edit, but I suspect changing `NextOccurrence` to a far future date may stop the blue chest from spawning until that date.

For removing an already-spawned blue chest, I think the GridObject removal method I explained earlier in this thread should also work. If you can find the blue chest’s GridObject entry in the save, deleting that GridObject entry should remove the chest. Unfortunately, I cannot give an exact example from my current save because I disabled automatic spawned objects, including the blue moonstone chest, with my test code. So my save currently does not contain a blue chest GridObject entry to use as a sample.

Yeah, I've broken so many save files with my trial & error way of doing things that starting over, or reinstalling the game has become standard. Im more surprised when I DONT have to restart, and even if I do restart I don't care. I don't feel like I've lost anything that's impossible to get back. I have my save saved at the point just after I get all the tools & off I go! As a matter of fact, a couple times, I updated the scramblecoin figurine code wrong & somehow blocked myself from being able to use any other figurines than what you start with, but I finally fixed it...then started over. it's so similar to some of your other 'get all' codes that all I have to do is change a few numbers. Works great

!

Ill have to look at the save from my computer before it goes back on the switch. I wonder if it is something with the date, but that date eventually passes ev en on the switch when offline & the chests don't respawn. the night thorns don't even respawn for some reason, but I'm not complaining, I'm just curious as to why now. Happy accident maybe. Stopping a few things from respawning will likely be my next task, so thanks for the very detailed explanation on how one might go about that.

I never noticed the khuong's master code had anything in it for the item asm &pointer cheat. I always do away with the master codes in my games for a layout where only the off codes are the master, or they just function as the all-in-one off code. I use AI to help me understand why the pointer code was written how it was then "decrypt" it to a code I can search with breeze & take 200 years trying them one by one with the paired asm. I'll have to go back & look at those lines from the old code that I tossed aside because they didn't go with anything. I definitely need more knowledge when it comes to pointer codes. They're more confusing, so thanks for breaking it down like you did. That makes it a bit easier. Thanks for sharing so much of your process. It continues to be extremely helpful!

morarin · 2026-07-08T16:10:22+0100

DDV_Honeyglow Woods Key Art 1920x1080.jpg

{MasterCode}
04000000 055ED83C 6B1302A8
04000000 07356980 A9BA7BFD
04000000 07356984 F9000BFB
04000000 04F48F9C 97FFFE41
04000000 04F4CD98 941A1D3E
04000000 04E35830 D10283FF
04000000 04E35AA0 D101C3FF
04000000 054AA2D4 39412268
04000000 054AB214 39412288
04000000 0549EBFC 394092C8
04000000 05495028 B9401F48
04000000 0333C804 F9406800
04000000 0333C808 B40002A0
04000000 0333C80C B9402041
04000000 0333C810 AA1F03E2
04000000 0333C814 9400229B
04000000 0333C818 F9406E60
04000000 0333C81C B4000200
04000000 0333C820 AA1F03E1
04000000 04E0E870 2A0003F5
04000000 04E0E914 39411108
04000000 04E0E944 7100051F
04000000 04E0E948 1A9F17E8
04000000 04E0E960 54000141
04000000 04E0E964 52800068
04000000 04DEF620 944FCDD4
04000000 04F225B8 F8018D00
04000000 04F69130 97D14770
04000000 04F6976C 542710CB
04000000 0549135C 0B180101
04000000 055BFD1C B9402A78
04000000 055BFD20 0B140316
04000000 054226A4 B94026E8
04000000 054226AC 0B150108
04000000 055D6374 0B180108
04000000 055D6378 F81F03BF
04000000 055D9D6C 1A89B2B8
04000000 055D9D74 1A89B115
04000000 05EF8828 2A0303F5
04000000 08020250 1A9F17E0
04000000 0803CB14 71000D1F
04000000 0803CB18 1A9F17E0
04000000 05A17E88 543831A1
04000000 05EEAC94 5400032D
04000000 05EEE17C 6B08013F
04000000 05EEE180 540000AA
04000000 05EEE184 2A1F03E0
04000000 051526CC 37000140
04000000 05152708 54000081
04000000 05152AC8 B9403108
04000000 05152BEC B940016B
04000000 056696EC 360014C0

[R MoveSpeed x2]
04000000 0350162C 1E204140
04000000 03501630 1E204161
04000000 03501638 1E204182
80000080
04000000 0350162C 1E2A2940
04000000 03501630 1E2B2961
04000000 03501638 1E2C2982
20000000

[EnergyNoDecrease]
04000000 055ED83C 6B1F02A8

[CurrencyNoDecrease]
04000000 07356980 52800000
04000000 07356984 D65F03C0

[R PickupToMax]
04000000 04C5877C B94017FA
04000000 04C589A4 4B19035A
80000080
04000000 04C5877C 2A1B03FA
04000000 04C589A4 2A1F03FA
20000000

[ZL NoConsumeItems]
04000000 04C59130 D10283FF
04000000 04C59134 A9047BFD
04000000 04C59AD0 D10243FF
04000000 04C59AD4 A9037BFD
80000100
04000000 04C59130 52800020
04000000 04C59134 D65F03C0
04000000 04C59AD0 52800020
04000000 04C59AD4 D65F03C0
20000000

[FreeCraft]
04000000 04F48F9C 52800000
04000000 04F4CD98 52800020

[CookKeepItems]
04000000 04E35830 D65F03C0
04000000 04E35AA0 D65F03C0

[AlwaysCriticalSuccess]
04000000 054AA2D4 52800028
04000000 054AB214 52800028

[AlwaysBurning]
04000000 0549EBFC 52800028

[AlwaysActivityBonusRewards]
04000000 05495028 52807D08

[EasyFishing]
04000000 0333C804 F9406660
04000000 0333C808 AA1F03E1
04000000 0333C80C 94001B91
04000000 0333C810 F9406660
04000000 0333C814 52800001
04000000 0333C818 AA1F03E2
04000000 0333C81C 94001B39
04000000 0333C820 1400000C

[--SectionStart:ForceFishRarity--]
00000000 00000000 00000000
[ForceNormalFish]
04000000 04E0E870 52800035
04000000 04E0E914 52800008
04000000 04E0E944 7100051F
04000000 04E0E948 1A9F07E8
04000000 04E0E960 54000140
04000000 04E0E964 52800028

[ForceUncommonFish]
04000000 04E0E870 52800035
04000000 04E0E914 52800008
04000000 04E0E944 7100091F
04000000 04E0E948 1A9F07E8
04000000 04E0E960 54000140
04000000 04E0E964 52800048

[ForceRareFish]
04000000 04E0E870 52800035
04000000 04E0E914 52800008
04000000 04E0E944 71000D1F
04000000 04E0E948 1A9F07E8
04000000 04E0E960 54000140
[--SectionEnd:ForceFishRarity--]
00000000 00000000 00000000

[EasyGardening]
04000000 04DEF620 D503201F

[InfMiningRock]
04000000 04F225B8 F8018D1F

[EasyUnlockCritter]
04000000 04F69130 52800020
04000000 04F6976C D503201F

[PetFriendshipMax(add)]
04000000 0549135C 2A1503E1

[MountBondMax(add)]
04000000 055BFD1C 52A00036
04000000 055BFD20 729C6CD6

[FriendshipMax(add)]
04000000 054226A4 52A00028
04000000 054226AC 729C6CC8

[XPMax(add)]
04000000 055D6374 529FD008
04000000 055D6378 72A001E8

[CurrencyMax(add)]
04000000 055D9D6C 1A89B138
04000000 055D9D74 1A89B135

[EasyClaimDuties]
04000000 05EF8828 52800035
04000000 08020250 52800020
04000000 0803CB14 7100111F
04000000 0803CB18 1A9F07E0
04000000 05A17E88 D503201F

[ClaimAllAchievements]
04000000 05EEAC94 D503201F
04000000 05EEE17C B9007668
04000000 05EEE180 B9009268
04000000 05EEE184 14000004

[--SectionStart:EasyScramblecoin--]
00000000 00000000 00000000
[6Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 528000CB

[12Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 5280018B

[15Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 528001EB

[18Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 5280024B

[21Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 528002AB

[50Points]
04000000 051526CC 1400000A
04000000 05152708 14000004
04000000 05152AC8 52800008
04000000 05152BEC 5280064B
[--SectionEnd:EasyScramblecoin--]
00000000 00000000 00000000

[--SectionStart:FixCodes--]
00000000 00000000 00000000
[FixMissionRewards]
04000000 056696EC D503201F
[--SectionEnd:FixCodes--]
00000000 00000000 00000000

v1.24.1 Cheat Code Update Notes

These codes were updated for v1.24.1. Most of the codes were updated automatically and only checked briefly, so please report any issues if something does not work correctly.

Important EasyGardening change:
EasyGardening no longer includes the “no seed consumption” effect. EasyGardening now only makes crops ready to harvest immediately after planting. If you want the old behavior, use EasyGardening together with ZL NoConsumeItems while holding ZL. This change was made to give users more control and more options.

GetAll codes and WelcomeVanellope are still excluded for now. As usual, they will be added later after manual updating.

Status	Codes	Notes
Looks OK at a glance, but please report any issues	R MoveSpeed x2 EnergyNoDecrease CurrencyNoDecrease R PickupToMax ZL NoConsumeItems FreeCraft CookKeepItems AlwaysCriticalSuccess AlwaysBurning AlwaysActivityBonusRewards EasyFishing ForceNormalFish ForceUncommonFish ForceRareFish EasyGardening InfMiningRock EasyUnlockCritter PetFriendshipMax(add) MountBondMax(add) FriendshipMax(add) XPMax(add) CurrencyMax(add) EasyClaimDuties ClaimAllAchievements 6Points 12Points 15Points 18Points 21Points 50Points FixMissionRewards AutoSpawnDisable	No obvious issue from a quick check. These still need normal in-game testing.
Looks suspicious, will be manually updated soon	SellToTrash ShowAllCraftingRecipe InfHarvesting	These need manual verification. SellToTrash has suspicious branch/address changes after automatic updating. ShowAllCraftingRecipe needs its original/restore instruction checked. InfHarvesting has one address that looks suspicious and should also be checked manually.
Excluded for now, will be added later after manual updating	GetAll codes WelcomeVanellope	These are excluded as usual because they are difficult to update reliably with automatic updating. They will be added later after manual updating.

Additional note about expansion DLC ownership data in the save file

After purchasing, downloading, installing, and launching Honeyglow Woods on Nintendo Switch, I noticed that the expansion DLC-related ownership data in profile.json changed.

This is only an observation from my own save data after legitimately purchasing and launching the DLC. I am not presenting this as an unlock method, and I am not claiming that these fields alone control DLC ownership. The game may also check Nintendo entitlement data or other ownership/cache data outside the save file.

Relevant data in my v1.23.0 save

Code:

    "LastKnownBoughtExpansions": [
        "Expansion1PackExpansionPass_Nintendo_OnlineKey",
        "Expansion2PackExpansionPass_Nintendo_OnlineKey",
        "Expansion3PackExpansionPass_Nintendo_OnlineKey"
    ],
    "LastKnownBoughtExpansionsAnyPlatform": [
        "BaseGame",
        "Expansion01",
        "Expansion02",
        "Expansion03"
    ],
    "LastKnownBoughtSeasonalPacksAnyPlatform": {},

Relevant data after launching v1.24.1 with Honeyglow Woods owned

Code:

    "LastKnownBoughtExpansions": [
        "Expansion1PackExpansionPass_Nintendo_OnlineKey",
        "Expansion2PackExpansionPass_Nintendo_OnlineKey",
        "Expansion3PackExpansionPass_Nintendo_OnlineKey"
    ],
    "LastKnownBoughtExpansionsAnyPlatform": [
        "BaseGame",
        "Expansion01",
        "Expansion02",
        "Expansion03",
        "WinnieDLC"
    ],
    "ExpansionPackOwnershipByPlatform": {
        "Nintendo": {
            "Entries": [
                {
                    "PackName": "Expansion1PackExpansionPass_Nintendo_OnlineKey",
                    "PackType": "ExpansionPack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "Expansion1PackGoldEdition_Nintendo_OnlineKey",
                    "PackType": "GamePack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "Expansion2PackEnchantedEdition_Nintendo_OnlineKey",
                    "PackType": "GamePack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "Expansion2PackExpansionPass_Nintendo_OnlineKey",
                    "PackType": "ExpansionPack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "Expansion3PackDeluxeEdition_Nintendo_OnlineKey",
                    "PackType": "ConsumableEditionPack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "Expansion3PackExpansionPass_Nintendo_OnlineKey",
                    "PackType": "ExpansionPack",
                    "Type": "Type_Purchased"
                },
                {
                    "PackName": "MiniExpansion1PackExpansionPass_Nintendo_OnlineKey",
                    "PackType": "ExpansionPack",
                    "Type": "Type_Purchased"
                }
            ]
        }
    },
    "LastKnownBoughtSeasonalPacksAnyPlatform": {},

Main difference I observed

Compared to my v1.23.0 save, the main new entries related to Honeyglow Woods / Winnie appear to be:

Code:

    "WinnieDLC"
    "MiniExpansion1PackExpansionPass_Nintendo_OnlineKey"

The existing Expansion3 entries were already present in my v1.23.0 save, so they do not appear to be newly added by Honeyglow Woods. Also, LastKnownBoughtSeasonalPacksAnyPlatform still exists in the same area of the save data and remains an empty object in my v1.24.1 save.

Based on this save data, Honeyglow Woods / Winnie-related ownership does not seem to be added to LastKnownBoughtExpansions in the same way as the main expansion packs. Instead, the relevant new entries appear to be WinnieDLC and MiniExpansion1PackExpansionPass_Nintendo_OnlineKey.

Disney Dreamlight Valley [0100D39012C1A000]

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum