ROM Hack [Release][NTR Plugin] Fantasy Life

  • Thread starter Thread starter Nanquitas
  • Start date Start date
  • Views Views 194,145
  • Replies Replies 331
  • Likes Likes 24
Ah, right. I was basing the address based on where dosh is stored in the save - whereas the working value in RAM is copied elsewhere and not accessed directly from the RAM copy of the save like storage is

most other codes that work on the 0x007***** memory region (generally where the copy of the save is) seem to be offset by 0x5000 consistently so try the following:
Code:
[Stackable Storage x99]
D3000000 0070D4D8
C0000000 000005DC
80000004 000005C4
70000004 000009FF
2000000A 00000063
D0000000 00000000
D0000000 00000000
DC000000 0000003C
D1000000 00000000
if that doesnt work, try this version (derived from the life rank code addresses. don't use the rank codes, though. they break too many things):
Code:
[Stackable Storage x99]
D3000000 007259D8
C0000000 000005DC
80000004 000005C4
70000004 000009FF
2000000A 00000063
D0000000 00000000
D0000000 00000000
DC000000 0000003C
D1000000 00000000
 
Ah, right. I was basing the address based on where dosh is stored in the save - whereas the working value in RAM is copied elsewhere and not accessed directly from the RAM copy of the save like storage is

most other codes that work on the 0x007***** memory region (generally where the copy of the save is) seem to be offset by 0x5000 consistently so try the following:
Code:
[Stackable Storage x99 (v1)]
D3000000 0070D4D8
C0000000 000005DC
80000004 000005C4
70000004 000009FF
2000000A 00000063
D0000000 00000000
D0000000 00000000
DC000000 0000003C
D1000000 00000000
if that doesnt work, try this version (derived from the life rank code addresses. don't use the rank codes, though. they break too many things):
Code:
[Stackable Storage x99 (v2)]
D3000000 007259D8
C0000000 000005DC
80000004 000005C4
70000004 000009FF
2000000A 00000063
D0000000 00000000
D0000000 00000000
DC000000 0000003C
D1000000 00000000
Hello again. Just tested both, to make sure which one worked. It appears that the first of those two codes, labelled v1, works. I tested this by having both in the cheats.txt file, labelled v1 and v2, restarting the game without saving between tests. Do these codes require CTRPluginFramework-BlankTemplate.3gx? Or can it be used in Citra itself?

Kind regards.

Edit: On a related note, is there a way for you to convert the code you did for KingGoose to EUR region? I've tried -0x5000 from the first line, same as your example for the v1 code, and it does not seem to work for me.

Kind regards.
 
Last edited by ryuragnas,
the general stricture of the code is setting the offset, a loop count, two conditionals (to only affect certain items), a write code, closing the two conditionals, an offset jump to the next slot, then initiating the loop so it should be compatible with emulators so long as they can handle to loop code correctly

as for the aspect ratio code, that area of memory generally isn't modified by codes, so I would have to manually search for the value. If adding 0x5000 doesn't work (you seem to have subtracted, instead, if I'm reading your comment right) its likely in a unpredictably different location due to how files get loaded (different text for the localization can affect where later data gets loaded into ram due to the different file size. if data you want to edit falls between such differing files, the offset to convert codes will be inconsistent). That said the code acts very strangely as-is. sure, the camera is zoomed out a bit, but its forced to that position so when in a crafting minigame that tries to zoom in/out a bit as you succeed in button inputs, it jerks around in a way that could cause problems for certain people (making them feel physically ill or worse) so its really not something I encourage anyone to use aside from specific cases like taking screenshots or broader areas of the map (IE: for a guide on locations in the game)
 
the general stricture of the code is setting the offset, a loop count, two conditionals (to only affect certain items), a write code, closing the two conditionals, an offset jump to the next slot, then initiating the loop so it should be compatible with emulators so long as they can handle to loop code correctly

as for the aspect ratio code, that area of memory generally isn't modified by codes, so I would have to manually search for the value. If adding 0x5000 doesn't work (you seem to have subtracted, instead, if I'm reading your comment right) its likely in a unpredictably different location due to how files get loaded (different text for the localization can affect where later data gets loaded into ram due to the different file size. if data you want to edit falls between such differing files, the offset to convert codes will be inconsistent). That said the code acts very strangely as-is. sure, the camera is zoomed out a bit, but its forced to that position so when in a crafting minigame that tries to zoom in/out a bit as you succeed in button inputs, it jerks around in a way that could cause problems for certain people (making them feel physically ill or worse) so its really not something I encourage anyone to use aside from specific cases like taking screenshots or broader areas of the map (IE: for a guide on locations in the game)
Following your instructions to add 0x5000 to the value instead of subtract, I changed it, and got this as the zoom. Can you share if you got a bit of the skybox and such when you re-wrote the code for KingGoose? If yes, then I won't worry about the skybox being seen. Otherwise, I'm not sure if the code is correct.
 

Attachments

  • FL3DS-EUR-Screen-Zoom.jpg
    FL3DS-EUR-Screen-Zoom.jpg
    694.1 KB · Views: 73
The hard part is it looks a bit different on actual 3DS hardware than in the emulator. A lot of the data in that memory regions affects various aspects of the game's rendering and the address you hit seems to have actually affected camera angle (which is interesting, to say the least, but is likely not the address you need).

To be absolutely sure whether it worked or not, try standing in the same spots as some of Goose's screenshots he used to show off his HD texture mod and see if the angle/range of view is the same. You can also verify by entering a crafting minigame (The original address Goose was working with only updated during certain map transitions and only updated its effect on the game under certain conditions. The address I used updates immediately - but it doesn't play nice when the game tries to change it, causing the camera to 'panic' in crafting minigames as the code keeps fighting how the camera is supposed to zoom in and out)
 
Last edited by iSharingan,
hello all so am useing this code but it only works on slot one. is there a way to make it work on other save slots? usa version 3ds not emu
[Stackable Storage x99]
D3000000 0073F058
A0000000 FF0000FF
DB000001 00000000
D3000000 00700F40
C1000000 00000000
DC000000 0003B400
D1000000 00000000
DC000000 00007598
C0000000 000005DC
80000004 000005C4
70000004 000009FF
2000000A 00000063
D0000000 00000000
D0000000 00000000
DC000000 0000003C
D1000000 00000000
 
hello all so am useing this code but it only works on slot one. is there a way to make it work on other save slots? usa version 3ds not emu
I already addressed that here. Basically I was trying to be clever, but the game was simpler than I assumed, lol (and only had all 3 saves in RAM at the same time when on the screen to select one to play).
 
do you by chance have something for skill xp multiplyer?
also thank you didnt relaize that was what that post was
 
not as a multiplier, no. Still, if you overcap your skill exp when save editing it will jump straight to 20 then next time you use the skill (or to 15 in the case of Sprint and Sneak since they don't have increased caps) even if you haven't unlocked the level cap increase yet (though it will revert to level 15 after saving and loading in that case - but nothing breaks)
 
Judging by the memory region and value written, its almost certainly an ASM code altering the game's original code. its likely incomplete as it only affects one axis (causing the image to stretch strangely), so a second line would likely be needed to adjust the other axis or the registers modified may be passed the wrong value - which may be outside my level of experience (unless I get lucky, lol). If I get something to work I'll let you know. On further analysis in RAM, it actually seems to be a Float value. This may be simpler than I thought.

I don't make codes like these for money - since, as any artist will tell you, once money enters the mix you no longer work based on your passion and start doing it for the money, which in turn kills the fun of what you're doing and makes it a chore. It can very easily ruin what you enjoyed about it in the first place, so I simply don't accept money for it. If anything, I would, however, appreciate an end to the gatekeeping and a rescinding of the exceedingly petty permaban issued on a first offense (that would literally never happen again) in the FL discord server all those years ago - so when FLi to releases I can offer my mechanics research/game data compilations to the other players there that enjoy the series. True, I don't *need* back in for any personal reason, but I do like to offer my aid to those that appreciate it - since doing my usual RAM work/data spreadsheets/mechanics analysis only for personal reference feels like a waste.

Alright I got it: After crunching the numbers between the original value and what your code changes it to, the value at that address is the aspect ratio, not the FOV. Its changes the aspect ratio from the innate 5:3 to 2.96:1. Judging from your Reddit post requesting the same thing, Goose, it does almost exactly what you want: converts the game from the default 400:240 (citra bypasses the exact pixel count while keeping the ratio, so its effectively 1800x1080) to 3200x1080 resolution. Since you want 3:1 aspect ratio the solution should be as simple as resizing the Citra emulattion window to 3840x1080 and making sure the render method stretches to fit. The new value for the code should be:
Code:
[Aspect ration 3:1]
007461B8 40400000
{Use if resizing the Citra window stretches the rendered image}

Its also possible resizing the window itself is enough and you won't even need the code.

EDIT 2:

Did some more tinkering on nearby addresses and I think I managed to do what you wanted after all. The address you have in that other code is indeed the aspect ratio, but I manged to find different values nearby that affect the X and Y rendering zoom. Normally the game updates these values when entering and exiting buildings to make the camera closer to the character, so with this code on it will always be a fixed distance back from the player. NPC names/thought bubbles/HUD/etc. is unaffected by this value, so it should work nicely. I tried to keep it proportional to the screen ratio to avoid stretching, but it may need minor adjustments:


Code:
[50% Render Zoom (From Outdoor Zoom Values)]
DC000000 00746004
00000000 3F266666
00000014 3FA66666
{Also overrides automatic slight zoom-in when indoors, so all maps will appear the same distance regardless of normal behavior.\n\nMay make crafting mini-games difficult}
I don't know if these messages are still being answered today, but I would like to know how I could reduce the rendering by 20%, since I play on mobile, and that distance in the size of a cell phone screen is a bit uncomfortable, the code works quite well, but I wanted to know how I can edit it or if you can make one that fulfills the same function, only with a little less distance between the camera and the character or the world as such, like 20% more or less, if what was increased was 50% I would like to reduce it by 20
 
I'd need to go back in and find the original values at the address to know which way to modify the numbers - which isn't something I'm able to do right this second.

that said, if you want to do it yourself (and have access to a memory viewer for the game), the addresses are 0x00746004 and 0x00746018. Simply take the original values there, plug them into a floating point value converter like this one, then set a value halfway in between the origimal and the modified values (modified values are 0x3F266666 -> 0.65 for the first address and 0x3FA66666 -> 1.3 for the second)
 

Site & Scene News

Popular threads in this forum