• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • PokéCommunity's Easter Egg Hunt is now on! If you're interested in looking for some eggs and earning badges, click here!
  • Our weekly protagonist poll is now up! Vote for your favorite Conquest protagonist in the poll by clicking here.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

Help Thread: Script Help Thread

Status
Not open for further replies.
Lost Heart said:
Since you're using Emerald, it's best to use the command 'freespace 0xFF' after the #dynamic command to ensure that the correct type of freespace is used.
Click to expand...

"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)

DraconianWing said:
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!
Click to expand...

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
 
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.
 
Last edited:
Telinc1 said:
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.
Click to expand...

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.
 
Does anyone know why this script plays every time the tile is touched, even though I put "clearflag?"

#org @start
checkflag 0x829
if 0x1 goto @snippet1
applymovement MOVE_PLAYER @move1
waitmovement 0x0
msgbox @string1 MSG_NORMAL '"MAILMAN: You're [player], right? Y..."
setflag 0x829
msgbox @string2 MSG_NORMAL '"MAILMAN: I have your Pokèdex here,..."
release
end

'---------------
#org @snippet1
clearflag 0x829
release
end
Click to expand...
 
Meister G. Rool said:
Does anyone know why this script plays every time the tile is touched, even though I put "clearflag?"
Click to expand...

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:
 
Whenever I compile this script
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
 
hi guys i am having problem with this script it is not working the game get freeze when player walk on it
Spoiler:
 
DogPolice said:
Whenever I compile this script
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
Click to expand...

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.
 
DogPolice said:
Whenever I compile this script
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
Click to expand...
Can you provide the whole script(with all dynamic pointers), so we get more context?

pokemon r said:
hi guys i am having problem with this script it is not working the game get freeze when player walk on it
Spoiler:
Click to expand...

Yeah, just put 'releaseall' before end.
 
DogPolice said:
Whenever I compile this script
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
Click to expand...

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.

pokemon r said:
i also try that not working
Click to expand...

It will! :) Check your variable info on the tile, make sure it matches the setvar in your script, etc.
 
Mana said:
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.
Click to expand...
i checked it more then one time but not working
 
Spoiler:

i am getting error in this script can anyone resolve the error is
(Error 13 type mismatch on line 6 missing #define)
 
pokemon r said:
Spoiler:

i am getting error in this script can anyone resolve the error is
(Error 13 type mismatch on line 6 missing #define)
Click to expand...

Line 6:
msgbox 0x4 @change
Click to expand...

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.
 
Mana said:
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.
Click to expand...

Spoiler:

still getting this error
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top