[SM]problems that i need help with

[Smiley]

Start by drawing these bigger graphics somewhere in the ROM. Then repoint the enemy's graphics there, adjusting # Bytes For GFX as needed and then begins the fun part, tilemaps. Here's a handy little doc for that.
Have fun! :^_^:

[Retroo]

thanks now lets see if i can do this

[Jordan5]

I've been trying to edit a room state from an event state to an item state. In doing so, i now always quickmet in with zero energy in both versions of SMILE that i have in several different roms, including an untouched one. I'll probably need help with the room state bit later, but does anyone know how i've managed to break quickmet and how to fix it?

[DSO]

I've had this happen at times before, search your computer for quickmet.srm, there should be multiple copies. You need to figure out which one to get rid of - I'd just rename them one at a time and seeing which ones you need and which one is causing the problem.

[personitis]

When changing a room state in any way involving an event state, you need to be aware of how the room header works. Specifically, this tricky little byte most people don't take notice of. I just closed all this stuff in Notepad as well <_<...

* person701 opens the document back up

So in the header, the event state will look something like "12 E6 00" (in a hex editor, cause bytes are reversed) where E612 is the "event state" and 00 is the event bit to check. After will be a pointer (so something like 34 12) that leads to all the properties of that state (enemies, FX, PLMs, etc). The thing to note here, is that the event state in room headers is the only state to have this extra byte follow it. Every other state will simply be "29 E6" or "40 E6" followed by the pointer.

In your case, you'll want to move everything from the end of the room header back one byte, and adjust pointers following room states (and possibly the scroll pointer) by subtracting 1. That or quickmet is indeed being screwy. In that case, I'm of no help. :=x:

[Jordan5]

I had deleted all the quickmet.srm files in the smile folders, didn't realise there was was in the emulator folder, thanks DSO.

Yeah i've read Jam's and Sting_Chameleon's guide, i thought i had it until i tried to change the room state and it said run-time error 383, 'text' is read-only. i'll start again anyway, thank god for back-ups! :heheh:

EDIT: I'm still getting run-time error 383. i've placed the FF byte after the scroll data but before scroll PLM data (so i don't have to change lots of low values). i then took 1 away from the door out and scroll pointers, pressed save > no. Any idea what i did wrong?
Oh, and the room in that state is a glitchy bug-fest. The Standard state works fine, however.

[JAM]

Any idea what i did wrong? Oh, and the room in that state is a glitchy bug-fest. The Standard state works fine, however.

That's what you should do: move all data after alternative event instruction by 1 byte to the left, before the Scroll Array starts and ajust the pointer.

Example.

Before:

Code Select Expand


12 E6 0E 56 D4 00 70 A0 01 02 03 04 ... D3 91 [Scroll Data]


After:

Code Select Expand


40 E6 55 D4 00 70 A0 01 02 03 04 ... D3 91 FF [Scroll Data]


[Jordan5]

That's what i've done but i still get run-time error 383 when trying to view the alternate state. Should i change it's pointer before i change the room header?

Also, why does the fourth byte ($56) change to ($55) when it's shifted left one byte in the code you showed?

[personitis]

That has to change because it's the pointer to the room's scroll data and everything was moved back one byte. And no, it won't matter what order you change everything in. As long as it's all changed and saved properly. On the subject of the issue, this definitely sounds like SMILE/quickmet not being happy. :\ Can't say I've ever heard of that error before either.

[knuckles]

On the subject of the issue, this definitely sounds like SMILE/quickmet not being happy. :\ Can't say I've ever heard of that error before either.

I'm sorry, but someone had to say it. [spoiler]
[/spoiler]
XD it probably is quickmet and smile as well I guess.

[JAM]

Also, why does the fourth byte ($56) change to ($55) when it's shifted left one byte in the code you showed?

Because the location of alternate state is also moved to the left, so its pointer should be tweaked too. It's your choice what to shift and what -- not.

Easiest solution will be shift $19 bytes after E6 E5 to the left. Then alternate state pointer will not be tweaked, but you'll lose 1 byte in bank $8F (not critical unless you want to have over 700 rooms in your hack).

What I suggest earlier is shift original state and alternate state. So, the single byte will not be wasted and can used by Scroll Data (if room have any) doors. Can't be used too. You have to move the doors too and shifting its pointer too. So, that byte will not be wasted and can be used by Scroll Data (if you alter pointer too and add one more screen).

Typical room:
[header]
[alternate state 2 instruction] (optional)
[alternate state instruction] (optional)
[original state]
[alternate state] (optional)
[alternate state 2] (optional)
[Door Out]
[Scroll Data] (optional)
[Scroll PLM Data aka Special Scrolling Data] (optional)

[Jordan5]

Awesome, that finally worked! i placed the FF where you said and shifted the door out pointer back one, then pressed no to copying data. (EDIT: I wasn't thinking, of course i didn't need to do that, whoops) A few times i pressed yes because Grime mentions it in his big room state guid, but i guess thats just for removing roomstates. Thanks for the help guys :grin:

[Retroo]

flexglow




edit ; fixed the middle one that says (D6 s04.s01) the other ones are stil there so i stil need help.