Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relocating the addresses in memory for the players party #31

Open
NoelDavies opened this issue Dec 22, 2020 · 3 comments
Open

Relocating the addresses in memory for the players party #31

NoelDavies opened this issue Dec 22, 2020 · 3 comments

Comments

@NoelDavies
Copy link

I've had a LOT of people asking me to add support various rom hacks, for Pokélink but the data in memory seems to have all changed (which is what we used to represent the user's team live on their layout).

From what I can gather, with your help and using some of the code on in this repo - I can find the party data in memory and add support for rom hacks and help the poke-streaming community.

Would be great to work with you, even if just to get an idea of where to look, any struct changes, etc.

Hope you're having a good Holiday season!

Cheers

@NoelDavies
Copy link
Author

I saw #27 and was wondering if anybody can point me in the direction of the live battle addresses. We have so many people looking to run games built on DPE!

@Skeli789
Copy link
Owner

Okay, so the player's party address hasn't changed from FireRed. The big change is the fact that the party is no longer encrypted. This repo isn't really responsible for that, though. It's really done by the CFRU.

As for live battle addresses. Beyond what's in the default FR, it's very tricky to track them. Most of the new things like timers (such as Trick Room) and statues are dynamically allocated in memory at runtime. I'm also constantly updating that struct, so unfortunately there's really no way to set it in stone.

@NoelDavies
Copy link
Author

NoelDavies commented Jan 14, 2021

Is there any go-to addr pointers, or we could resort to what we do for citra, and dynamically scan for these if they're set at runtime, and not changed from that point? 🤔 We already track vanilla FR stuff live, but if that's changed we could introduce a new approach for any CFRU-based hack?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants