- 5,256
- Posts
- 16
- Years
- Age 26
- Leicester, UK
- Seen May 30, 2024
Yes, see Lost Heart's post.
Help Thread: Script Help Thread
- Thread starter Spherical Ice
- Start date
- Status
Yes, see Lost Heart's post.
- 959
- Posts
- 11
- Years
- Age 24
- he/him
- Fallarbor Town
- Seen Oct 20, 2023
Followed what Lost Heart said and fixed the script. The amount of help and I've received from this thread, as well as stuff that I've learned, is tremendous. You guys are the best!
"Correct type of freespace" FF isn't the the correct type. If you have to tell XSE to look for FF bytes that should send off a signal that it's not the default to use, especially since 00 is the definition of nothing. If your issue with this is sound corruption, again like I've told you before that issue is fixed and not only that, I've been working on Emerald ROMs for two years now and I had to TRY to get sound corruption. I don't ever use freespacebyte 0xFF and I never even use FSF program unless I'm working in programs like NSE or Advanced Series which require manual insertion. If you have a script with #dynamic 0x900000 and then the offset box has 900000, if you compile and 1) it has FF space or 2) data is already there, it will compile to the first available 00 space after 900000 that corresponds to the exact amount of space needed for the script. It's actually more efficient than FSF since you'll input something like 64 bytes needed when you might only need 50 and not only that, FSF has been known to give out false offsets. I'm sorry but in my opinion this isn't the best choice of solution, though it is available for use. (Just stating my opinion and info on it, not aiming to attack you)
What I think you SHOULD do, as ANY emerald hacker should do or will do eventually, is expand your ROM to 32MB which you can do in XSE. And when you do this, make sure to fill with 00 space. That way you have tons of more free space to use and you'll be set for finding offsets 0x1000000 and greater. I've used this method on both of my hacks and never have problem with free space or having to insert extra commands to find a certain byte
Telinc1
Weirdo Extraordinaire
- 168
- Posts
- 10
- Years
- Sofia, Bulgaria
- Seen Apr 3, 2020
Let me clear this up a bit. This info is gathered from a ton of sources I don't even remember (pretty sure it was from this forum), but here's the deal. For the longest time, it was assumed 0x00 was the freespace byte in Emerald. Problem is, most 0x00s are not actually freespace, but rather part of the sound or instrument data or something (my memory is kinda foggy). Emerald's freespace byte is 0xFF, it's just that older tools like XSE think it's 0x00 because that's what everyone thought when they were made. That's exactly why sound corruption occurs in Emerald. Then the bigger problem is that Emerald doesn't have an enormous chunk of 0xFFs like FireRed does, so you're just better off expanding the ROM to 32MB using 0xFF as the freespace byte to ensure tools won't overwrite what they shouldn't (I'm pretty sure AdvanceMap's INI lets you configure what freespace byte to use). This is actually quite a debate, if GBA games use 0x00 or 0xFF as freespace, but as far as Pokémon hacking goes, it's practically settled that 0xFF is the freespace byte in all the games.
tl;dr; 0x00 is not actually the freespace byte in Emerald. Most 0x00s are part of music data, which causes sound corruption. 0xFF is the true freespace byte and there's not much of it, which is why most Emerald hackers expand their ROMs.
Edit: Here's the thread that I got this from. Provided to you thanks to a simple Google search.
Edit 2: By the way, let's not let this turn into a flame war. I've said what I'm almost sure is correct, provided sources and that's it. Never gonna answer another question again.
tl;dr; 0x00 is not actually the freespace byte in Emerald. Most 0x00s are part of music data, which causes sound corruption. 0xFF is the true freespace byte and there's not much of it, which is why most Emerald hackers expand their ROMs.
Edit: Here's the thread that I got this from. Provided to you thanks to a simple Google search.
Edit 2: By the way, let's not let this turn into a flame war. I've said what I'm almost sure is correct, provided sources and that's it. Never gonna answer another question again.
Last edited:
00 is used in sounds, but they aren't in extensive amounts. You're not going to find 50 bytes of 00 space for a song. There are other things in the ROM that use more 00 space than songs and that is in all GEN3 games. Sound corruption is more likely to occur in Emerald though because XSE doesn't look for FF because that's how Hackmew designed XSE.
Alright so around 0x370000-380000 for example there are blocks of 00 space. Those are completely fine to use. The 3D8000 block is fine to use too. The 640000 - 643000 as well. 649000-64B000, etc. The more famous 00 space to use is A00000 - AFFFFF. BA0000 - BFFFFF also. Pockets of 00s in the C00000s and D00000s as well as a big chunk between DF0000 and E3C000. E3C000 - FFFFFF is the only FF space in the game. Any space in between or bigger chunks are 00. Why? Because Gamefreak intended the absolution of anything 0 which is NOTHING to be a free space byte. FF is normally used for fillers and ending of scripts / commands / etc. I can almost guarantee you that ANY GBA game you open in a hex editor you'll see FFs at the end with a whole bunch of 00 blocks in between. That is left over freebyte workspace they didn't use (I used Care Bear GBA game as an example lol). You start out working any GBA ROM with 00 space because there is nothing to it. It neither starts nor stops functions. FFs are usually used as that since most games don't have functions or features that run up to 255 in decimal.
The fact that you say 00 is used in music data is proof that it is the freespace byte. Gamefreak used it as their free space byte! I don't see how people are blind to this? That's why there isn't much FF space because it isn't meant to be used because Gamefreak didn't need it. It's a 16mb game because GBA games were meant to be 16-bit. There are some that managed 32mb and some that managed 4mb ... but the typical was 8mb or 16mb. N64 is what ranged from 8mb to 64mb ... the reason I say this is because the standard for the sizing is for the GBA cartridges themselves. They are cheaper to make and easier to work with. GBA is 256 megabit = 32 megabyte max. Emerald didn't need the space past E30000 so they FF it so the GBA system recognizes that there is 16mb of data in usage in the cart. YES, the FF space is free space. BUT 00 was MEANT to be free space for these games. Emerald's freespace byte is 00 and no if ands or buts around that.
Sound corruption is made out to be this big con for Emerald too like it happens to everyone. I only know one person it happened to and it's literally like four bytes that need to be changed to fix it. It's not you overwriting data for songs that causes it. Just because you work on FireRed roms you have this misconception that sound corruption and the FF space limit is what makes Emerald a more tough ROM to work with. Since most of us want to make bigger maps, make bigger tilesets, add more animations, add more scripts, more events, map header data, etc. we need more for the game. Emerald has a lot more data than FireRed like the Battle Frontier. This is why FireRed has more space available. They had bigger dreams than Emerald which was already almost at it's cap so with the newly developed GameCube to hold 64mb easily, they decided to continue on in that system to make bigger things like 3D models. Mystery Dungeons came out afte XD and yet they still released it as a GBA game ... namely because the 32mb carts are cheaper and inside of MD they used the entire game ... except they had some free space they didn't use ... which is used as 00 space.
"tl;dr" your mind is foggy because whatever you learned isn't all correct. you work on FR and therefore you accept anything you see about EM. EM freespacebyte = 00.... but so is FF. All games use both but in different ways and FF is a freespacebyte but is not intended to be the freespace byte of the ROM. You can't just go around saying FF is the freespacebyte because your mind is foggy but oh you remember hearing about it in the past from your tons of sources you can't cite or remember. Look in the ROMs and read up about GBA ROMs and how they used the space before you jump on the FF bandwagon. Plus just by amount alone there are more free 00 banks in the ROM than FF as if that isn't evidence enough.
- 44
- Posts
- 8
- Years
- Seen Sep 21, 2016
Does anyone know why this script plays every time the tile is touched, even though I put "clearflag?"
Sayuri
人生忘れられた
- 276
- Posts
- 8
- Years
- Boston, MA
- Seen Sep 11, 2016
clearflag is the opposite of setflag; it sets the flag's condition to 0, which basically tells the game "this flag hasn't been set yet." Essentially what your script is doing is creating an infinite loop, as you're saying "If the flag has been set, unset it and continue the script. Once this script is finished, set the flag."
If you wanted it to give the Pokedex the first time you activate the script, then say/do something different afterwards, it'd look something like this:
Spoiler:
Sayuri
人生忘れられた
- 276
- Posts
- 8
- Years
- Boston, MA
- Seen Sep 11, 2016
Whenever I compile this script
and then decompile it, it comes out as this:
It cuts off the rest of the script. Is there a reason it does this? Is it something I'm doing or is it a bug? It's happened to me before but now I can't fix it. Any help would be appreciated
Spoiler:
and then decompile it, it comes out as this:
Spoiler:
It cuts off the rest of the script. Is there a reason it does this? Is it something I'm doing or is it a bug? It's happened to me before but now I can't fix it. Any help would be appreciated
- 154
- Posts
- 9
- Years
- Seen Jun 23, 2018
it also happen with me it has many reasons for this . it is because you dont put the commands in right places or your advance map or xse have any problem as much i know try to recompile it with new offset and use advance map 1.92. to add script.
Can you provide the whole script(with all dynamic pointers), so we get more context?
Yeah, just put 'releaseall' before end.
- 154
- Posts
- 9
- Years
- Seen Jun 23, 2018
still it is not working still getting freeze
Same problem as mentioned before - you need to use variables for green script tiles :).
- 154
- Posts
- 9
- Years
- Seen Jun 23, 2018
i also try that not working
Something is clashing, your script and something else. Perhaps you've tried editing another script or accidentally reused the same offset.
For #dynamic just use 0x740000/800000. There's no need to free-space-find the number.
It will! :) Check your variable info on the tile, make sure it matches the setvar in your script, etc.
- 154
- Posts
- 9
- Years
- Seen Jun 23, 2018
i checked it more then one time but not working
Show me the new script? :) and if possible an a-map screenshot.
Line 6:
You have no #org @change. Also you're using dynamic offsets really wrong ): just put #dynamic 0x800000 at the top of your script and leave it at that.
- 154
- Posts
- 9
- Years
- Seen Jun 23, 2018
Last edited by a moderator:
- Status