[Other✓] Why Dynamic Offset?

Hi there,
I am completely new to rom-hacking and went through some tutorials to get started.
- using FireRed, the XSE-Editor, Free Space Finder and Advance Map.

But the "Dynamic Offset" is causing me some headache: Whenever I compile the tutorial scripts the "new" Offset increases.
I assume that is because the editor looks for empty space and thus skips the space it had occupied with the previous version of the script. But doesn't that waste a lot of space?
Or is there actually an option to avoid that? If not, isn't it better to use static offsets?

For example:


btw. it was even weirder with emerald (hence why I swapped to FireRed until I get some experience).

edit: The solution:
to avoid the increase in the offset while compiling the same dynamic script again just add #clean at the beginning of the script, this deletes the last compiled script.
Hower if you compiled a different script in between you will have to use either #erase or #removeall, of which the latter seems more suitable. #removeall simply removes the whole script located at a given offset.
Carefull: Don't use #clean the first time you compile a script or it deletes the previous one.

Haha, I was just like that when I started scripting...

In Fire red when you use the offset 0x800000 it automatically finds another free offset even if you used it...

In Emerald, 0x800000 is not a free space, hence you must use FSF...

I think I didn't made myself clear...xD
Please don't hesitate to say it :)

Let me explain you how does the dynamic offset works (or at least how I think it works).
Think of the space in the ROM as a physical notepad, or a book, each byte in the ROM could represent a character in a book. When you write #dynamic 0x800000 at the beginning of the script, you are telling XSE to search for a free offset from there and start writing there, it would be like if you were writing in a notepad, and you were searching for a free page to write. The thing is that when you compile the script, it is written into the ROM, if it was a notepad, you would have wrote on that page.
That means, next time you try to find free space, the searcher will skip the space occupied by the code you compiled. If you press compile several times in a row with the same code, you will simply fill the ROM with the same script repeated that many times.
This implies 2 things:
.If you try to search for free space (or if you let XSE do it automatically via dynamic offset), the space occupied by your code will be skipped (that's why it gave you different offsets each time you compiled).
.You can force the game to rewrite code if you use the real offset by using 0x800024 or whatever the offset of your code is instead of #dynamic 0x800000, but you have to be careful, if your new code occupies MORE space than the old code, it will keep writing, this can lead to 2 things:
If the space following the code was free, there's no problem.
If a new script started in the next bytes, those bytes will get replaced, causing problems.
What can you do to not messing this up?
You can (and you should) save the scripts in a folder.
If you need to correct a script and the corrected script will occupy more bytes than the old one, you should use a new offset for a it so you don't mess things up. If the corrected script will take the same space or less, you can compile it in the same offset where the old one was (you can replace the rest of the bytes with nop, it takes 1 byte, to make it clearer: for example, if a command occupies 2 bytes and you don't need it, you erase it and you write nop nop there).
If you care about saving space and not letting unnecesary and unused scripts on the memory, you can have a base ROM without scripts and some test ROMs where you compile (using dynamic offset) without caring how much space do you take. When you are sure that you won't correct the code again, you can copy the base ROM and enter all the good scripts into it.

Was I clear? if you had any doubts just tell me.

Hi, thanks for the reply.
edit: answer to blaziken, just noticed your reply J9

But that only underlines my question: Why use Dynamic Offsets at all?
With a static offset I would only need to use the FSF once per script and furthormore, if I change the script later I wouldn't have to change the linked offset for the NPC since it stays the same.
The only problem I see is, that you might have to reserve some extra space in case your code becomes bigger, but that shouldn't be too hard (simply use the FSF twice and increase the step size). If you still run out of space you can still change the offset manually.

@Emerald: Yes, I didn't use 800000 in emerald, but it was really weird so I'm using FireRed for now. Basically the FSF found a usuable offset but the compiler used one a lot higher. Using the FSF again would then deliver the same offset as before and the compiler would change it to the same offset too.
That made it really annoying to find free space (and it always felt like wasting a lot of space).
But that might have had a lot of causes, since I could have screwed up the rom prior to the process. Anyway, I switched to FireRed because I can at least understand what is happening there (more or less). :D

edit: @J9794: Thank you, that made it clearer. Guess I'm just going to use static offsets for now (since I tend to compile three times in a row just to be sure it worked. ^^)

No prob, I'm glad I could help you. And I find dynamic offset to save some time, I just don't have to care about the offset, and that's nice when you are going to compile several scripts in a row. I copy the ROMs as checkpoints, write the next script, compile it, test it and correct it some times and when I think I'm done with it I save it and compile it in the ROM I used as a checkpoint.

Ehh, if you compile a script multiple times and the address keeps increasing, go to the first version's script's offset and delete everything after it in your hex editor.

J9794 said:

No prob, I'm glad I could help you. And I find dynamic offset to save some time, I just don't have to care about the offset, and that's nice when you are going to compile several scripts in a row. I copy the ROMs as checkpoints, write the next script, compile it, test it and correct it some times and when I think I'm done with it I save it and compile it in the ROM I used as a checkpoint.

Click to expand...

What do you mean you "don't have to care about the offset"? Don't you need to change the offset set in Advance Map to link to your script? I don't fancy copy/pasting the new offset each time I compile.
With static offsets I could change the script without even touching Advance Map.

FBI agent said:

Ehh, if you compile a script multiple times and the address keeps increasing, go to the first version's script's offset and delete everything after it in your hex editor.

Click to expand...

That... sounds pretty good actually. :D
I only used the HxD once so far to replace a bunch of "00"s with "FF"s (following a guide) in Emerald, so I got some learning to do first, but I'll try that.
I still don't really see the advantage over static offsets though.
edit: actually nvm. I don't have to care about the allocated space with this method and only have to meddle with the starting offset if the script gets bigger than the free space. Thanks.

FBI agent said:

Ehh, if you compile a script multiple times and the address keeps increasing, go to the first version's script's offset and delete everything after it in your hex editor.

Click to expand...

Kasimsel said:

That... sounds pretty good actually. :D
I only used the HxD once so far to replace a bunch of "00"s with "FF"s (following a guide) in Emerald, so I got some learning to do first, but I'll try that.
I still don't really see the advantage over static offsets though.
edit: actually nvm. I don't have to care about the allocated space with this method and only have to meddle with the starting offset if the script gets bigger than the free space. Thanks.

Click to expand...

#clean

#readthedocs

PS: I don't even script and I know this.

Why on earth would you compile three times? The only way to be sure it worked is seeing the dialog box.

@daniilS: For the same reason I click the refresh button multiple times or save my games multiple times in a row: None at all.

Touched said:

#clean

#readthedocs

PS: I don't even script and I know this.

Click to expand...

Well excuse me for not having read all about everything in the two days since I started.

And based on the description #clean deletes the last used dynamic script so if I go back to an older script I would still need to use the hex editor version first.
(or maybe the #erase comand, before you complain again).

But thanks for pointing it out, that was exactly what I needed.

There's a major difference between saving/refreshing and compiling: while saving/refreshing may not work one time but work the other, it also doesn't give you any proof it actually worked. Yet saving/refreshing multiple times doesn't have any cons.
Compiling on the other hand will work exactly the same way any time you do it, and it gives you a direct proof of success, while doing it multiple times only makes things harder. #dynamic was made to simplify the process of scripting, not overcomplicate it.

daniilS said:

There's a major difference between saving/refreshing and compiling: while saving/refreshing may not work one time but work the other, it also doesn't give you any proof it actually worked. Yet saving/refreshing multiple times doesn't have any cons.
Compiling on the other hand will work exactly the same way any time you do it, and it gives you a direct proof of success, while doing it multiple times only makes things harder. #dynamic was made to simplify the process of scripting, not overcomplicate it.

Click to expand...

Yeah, but it is difficult to let go of that habbit. :D
It was only a sidenote anyways.


To conclude the topic:
to avoid the increase in the offset while compiling the same dynamic script again just add #clean at the beginning of the script, this deletes the last compiled script. Don't use it in the very first run of the script!
Hower if you compiled a different script in between you will have to use either #erase or #removeall, of which the latter seems more suitable. #removeall simply removes the whole script located at a given offset.

Thanks everyone. :)

Percy said:

Haha, I was just like that when I started scripting...

In Fire red when you use the offset 0x800000 it automatically finds another free offset even if you used it...

In Emerald, 0x800000 is not a free space, hence you must use FSF...

I think I didn't made myself clear...xD
Please don't hesitate to say it :)

Click to expand...

Hello, you seem like you can answer some questions i have:
1. Does XSE work on emerald? I have been triying to make it work but it never does what i intend it to do.
2. I have seen tutorials where people start with 0x800000 on emerald roms. Their scripts have worked to perfection so i don't know why should i use FSF for that.
3. Also, how do you use FSF exactly? Do you just count the bites according to the command help thingy and then replace "#dynamic 0x800000" with "#static 0xwhatever"?
4. Are there any tutorials for using XSE on emerald? All i find are fire red posts.

Thank you.