You are not logged in.
I need your help with some strange glitch i encountered on a playthrough of a little hack i'm working on.
I played everything without any problems so far, but things got really strange when i arrived in Lavender town... :0 spooky
Seriously though, i just arrived into the city and Mr Fuji was in his house, he would give you the flute and everything, although the dialogues of the other NPCs correspond to the ones when Mr Fuji is still kidnapped, if i go to pokemon tower, i can rescue him normally, and the NPCs would change dialogues accordingly.
At first i thought i screwed up the script for lavender house, but no, the script was equal to that of vanilla red/blue, then i tried starting a new game and activate the walk through walls gameshark code to get fast to Lavender town and Mr Fuji was indeed not in the house.
Finally i checked all the event constants i added to see if one of them overlapped with the Mr Fuji event, but none of them did.
Do you have any idea of what may have caused that glitch?
Thanks in advance :D
Biggest thing I would suspect is something mixed up on the Hide/Show table, something out of order. A prior script may be triggering FUGI's hide/show index value while trying to do something else and your test didn't "work" because you skipped the triggering script.
It would explain why he is visible and interactable while the rest of the townsfolk behave as though he has still been kidnappped; no event flags are changed, but the hide/show index has been flipped.
Pokemon: Project Neo A Pokemon hack 15 years in the making...
Hey! Thank you for your advice :)
I started a new game, but i sharked a level 100 so i can advance quickly through the game, i triggered the same events i did on the last playthrough, but everyhing went normally this time.
I also checked the hide-show constants and data, but nothing changed the flag of Mr Fuji, except for the Mr Fuji rescuing event itself.
Everything seems normal, however i'm still intrigued about what happened there.
I've had players report similar things. Some people say that Mew for example doesn't disappear after they battle him, but when I try to retrace their steps to duplicate the bug, he always disappears for me. They've also reported the guard on Unknown Dungeon disappearing too soon, but I haven't managed to duplicate it either. It seems like there might be something screwy with the hide/show events in general. Gen 1's system is pretty weird anyway. One of these days I'm probably going to just rewrite the way it's handled, since that's pretty much my answer to anything Gen 1 did strangely. But in your case, I'm not really sure what to tell you other than to try to pay attention what things you did leading up to it if you can duplicate the bug again, so that you can have an idea of what might be misfiring and causing it to happen. You could also try debugging it, but it might be annoying since you don't have any idea what's causing it. Basically you'd just be setting a breakpoint on his hide/show byte and playing through waiting for something to change it when it isn't supposed to be.
I think that's a good idea, i'll set a breakpoint on Mr Fuji's hide-show byte on BGB and see what happens. I'll have to start a new game tho, so this may take a while...
Thanks for the advice guys :D
See you later
It sounds like you were using an old save after shifting wram inadvertently. Starting a new game should be enough to fix it.
If you were desperate to use an old save and knew where the shift was, you could shift those areas in the save file. You might also want to consider having a function that sets all the flags for each part of the game accessible from a debug menu. Making that might be more productive than playing through again.
Yes, i was using an old save file, however, i don't know when or how wram gets shifted when i change or add a script.
I'm almost sure that was it, since i can't reproduce the glitch now, and most importantly, i haven't come up with a better explanation.
About the save file, i don't mind starting a new game... mostly because i enjoy doing this.
The only way i can come up with is checking what is the flag for Mr Fuji in both the original RB and in my hack, and i bet they're going to be different. Unfortunately, i have no idea of how the wram got shifted after changing the scripts, but at least i can assure that the glitch was caused by that shift by knowing what data is stored where Mr Fuji's hide-show flag was before the script changes.
Thanks a lot comet :D
Editing a script probably won't shift wram. It would have happened indirectly, by adding an event flag, hide/show object, etc. Adding to any list with a "NUM_..." constant at the bottom will likely cause a shift. Adding Pokemon, for example, will increase the size that the pokedex flags take up for every 8th pokemon you add.
Well, in that case, what i did that could have shifted wram was adding an event constant which included a new hide-show constant on its definition.
I thought if i added the hide-show constants at the end of the list would assure that wram addresses would not get moved but i guess i was wrong. Is it because that data isn't located at the end of one of the banks?
As for the event constants, i simply created some events andreferenced them in some of the 'empty' event constants that aren't referenced anywhere else. I guess that's why wram doesn't shift when i add more of them.
Well now we're getting complicated.
Event constants are not added in wram, per-se. They are a shorthand variable so we don't have to remember an adderess and bit value, we just need to remember "EVENT_WHATEVER" and the macro calculates it all out for us.
WRAM is going to shift because most of the WRAM addresses have become fluid thanks to variable labels instead of hard addresses; IE wMyVariable instead of $d123; no matter how the memory shifts, it will AWLAYS pull the right value for wMyVariable, but a hardcoded address means it will always go RIGHT to that memory address.
When the addresses are fluid, it is easy to add things to it because it won't break anything. BUT, if the memory map for the game changes, and you load a memory file that is allocated differently than its current memory map, it will try to load the wrong values.
At that point, anything new that needs storage can shift the WRAM values, but its often going to be something like NUM_POKEMON, a CURMAPSCRIPT variable for a new map, etc. So if you added a map, a curmapscript variable slot for it in the WRAM, and loaded a save file for a version that did not have the curmapscript variable, it will read WRAM a byte off from where the new variable was introduced unless you subtracted a byte from a near-by block of loose or undefined variables (usually you see a block in the WRAM file like "ds 128").
Something I have taken to doing has been when I work on something like maps, pokemon, items, etc. I go ahead and block out near-to the full number of possible elements in the memory. I have my Pokemon set to 254, my items set rather high, etc. so that the memory is allocated for it already. Then, when I do decide to actually add a monster or item or map, all of the key values are in place and the memory already allocated so my old saves don't bork. They still do from time to time, but not as often.
Last edited by daMoose52 (2016-10-25 13:42:23)
Pokemon: Project Neo A Pokemon hack 15 years in the making...
There seems to be something i still don't understand...
Hide-show constants are stored in RAM in the form of binary switches, and each switch takes the space of 1 bit, where both possible values mean hide and show. Then, these constants are identified with an index number, very much like pokemon and items, this index number can go from $00 to $ff.
In order to store this data, we need 32 bytes in the ram (8 switches per byte, so 256 switches make 32 bytes), of course, like the case of pokemon and items, not all index numbers are used. Which means that in the RAM, it doesn't matter what are the switch values for unassigned constants.
Then, we have that the constants themselves don't take any space in the RAM, but what does take space is the switches.
So, why would adding another hide-show constant shift the RAM if it's already included in the 32 bytes assigned for that? the only difference i see is that one more bit wouldn't be unassigned anymore.
It is correct that adding a few hide/show constants should not shift wram. An easy way to check what got shifted in wram is build your hack, then build vanilla pokered and compare the .sym files.
The wram symbols in the sym files are at the bottom. Finding the first symbol in your hack that has a different address from the original sym file indicates that memory was shifted immediately before that symbol.
The sym files are not sorted unfortunately. But you can remove the majority of the lines at the beginning that are rom address, so that only lines from ram are left, and then sort the lines in ascending order, in a text editor like Notepad++ or any other text editor that allows file line operations like sorting.
sort pokered.sym | grep :[CD]