Aleph

Hexware

Recommended Posts

Bestimate I have is 4 hours. I would like some info on how the hack should be made usable (add in another structure like the first support table and tack on some space for event pointers? Should there be flags for determining whether to load simple text supports if events are unnecessary? etc.) and it'd be nice to have some kind of pre-assembled event data I can reference for testing - I haven't messed with the EA before because I never needed to and I feel I don't really need to use it or know how events work for this, either.

Share this post


Link to post
Share on other sites

how much per hour?

I'm not really sure about specifics since I'm assuming this is meant to be a community hack and not a personalized one.

But I'd imagine it should be made in such a way so that dialogue isn't necessary (ie you choose support and it just shows the level increasing) for those people who don't want support conversations and I'd also imagine setting up a new table somewhere in the 0xD00000-0xE00000 space for event and text pointers but again I'm not certain on specifics.

I guess I could write up and assemble some events and send a patch if no one else wants to?

Again, would FE4 styled stat boosts be possible after the convo?(My guess is it would require a separate routine)

Share this post


Link to post
Share on other sites

Should there be flags for determining whether to load simple text supports if events are unnecessary? etc.)

This would be nice, but if it's too much work it's not really necessary (and I did outline it in my earlier post).

(ie you choose support and it just shows the level increasing)

You know you can already do this, right?

Share this post


Link to post
Share on other sites

yeah but I mean for specific levels like Level C & B have no convo but A does

Share this post


Link to post
Share on other sites

Wouldn't a blank text convo do that?

As I've said, I see no reason why you wouldn't be able to do anything else you can do with events.

The interface should be decided by the community (since it is indeed a hack which will help everyone). If no one else speaks up then it falls on you to make suggestions, so the two of you may well be in charge of any "specifics".

As for keeping me from starving...I don't think it'd be any more expensive (and certainly not any less) than it was recently.

To address the more technical concerns:

Ideally the new data would be able to be allocated where desired. I'd probably include info on how to modify the hack to reference data at a given location and design the default state of that data to be compact. Something like an ASCII string the hack would use to recognize the end of the table. Which it would walk through each entry of it, or no entries if there aren't any, looking for matches of support level, character 1 and character 2 (or something like that) and execute the first match (not unlike how the game searches for which event to play based on the tile you're standing on). If no matches are found, it would use the data in the original support table, possibly generating the event code equivalent in RAM and jumping to that. RAM is executable on the GBA, but I guess with the much smaller memory space it isn't ideal to execute from RAM primarily - despite that modern architectures suggest that this is preferred. Not that it's relevant since the code being executed is byte code and the actual program counter of execution would still reference the ROM.

Edited by Insidious Silence

Share this post


Link to post
Share on other sites

supporteditormockup_zps3ab0314e.png

Does this help at all? It's basically what I outlined in my earlier post. If no event data pointer is detected, then the text there plays. If there is a pointer, then the event data plays instead. (Obviously a corresponding table would have to be set up in the data) I guess now would be a good time for people to come forward and suggest/request any additional features?

Edited by Agro

Share this post


Link to post
Share on other sites

Events can call any needed ASM routines on their own as well, so yeah, the key is making sure there's some way to actually increase the support level manually, right? Who knows, you might be able to just call the routine as it is right now using an ASMC and all we really need to know is the offset... *shrug*

Share this post


Link to post
Share on other sites

Hey guys I want the event supports thing to modify how the game works internally without changing how any of default supports appear and sound.

I think the things I have yet to address are the supports with unique music (Serra's come to mind) and the little "Support Lv. increased!" dialog box that appears at the end. I don't really wanna do yet another gross hack to pop up that little dialog, but if I have to I will. Is there an event code for popping up those little uncommon text boxes?

Related: Being sick sucks, viruses suck, trusted software linking to viruses from the program itself sucks (what the fuck, ManyCam?), the weather here sucks and people on the internet are being real fuckers lately.

Edited by Aleph

Share this post


Link to post
Share on other sites

As far as I know there's no event code to make those text boxes appear, but I guess you could look at how the give item code makes the text boxes appear? It uses the same sound effect/box (not text itself), after all.

Share this post


Link to post
Share on other sites

That's my current plan. I can also always dig around in the code and try to mimic it as well, but it's possible I can just use the give item dialog.

Share this post


Link to post
Share on other sites

The event support hack has been prototyped and is ready for debugging. I'll be needing some help with that. Also note that I took about 9 hours longer than I anticipated to write all of this code.

What code?

This code:

http://dl.dropboxusercontent.com/u/336940/Software/Hextator%27s%20Doc/Media/Games/Reverse%20Engineering/Console/NGBA/Fire%20Emblem/Game%20Doc/7%20-%20Blazing%20Sword/Menus/%5BHack%5D%20Event%20Supports/folDIR.html

So if I could have help with testing it and working out any remaining issues and their associated solutions and get some reimbursement for those 9 hours that'd be great.

Anyone helping to test the hack may feel free to ask for assistance with implementing it. It is presently allocated at 0x08D00000, so if you need a different location and don't have the tools to assemble the source then I can help with that.

Edited by Aleph

Share this post


Link to post
Share on other sites

Yep, I have no idea how to implement this...

Share this post


Link to post
Share on other sites

If you use the assembly patcher tool linked in the source file's comments you can patch a clean ROM with the .dmp file and test it that way. There's information about the format of the data you're meant to customize at the bottom of said source file. If you want to test it on a different ROM or need more details then you'll have to specify.

Share this post


Link to post
Share on other sites

so once its assembled how are we actually making it work? Is support event done through nightmare or is there something that has to be put in the actual event file?

Share this post


Link to post
Share on other sites

Well, as I've said, there's some data the hack references that you are meant to customize and there are notes about it in the source file. It's at the very end, which I've also said:

@ This is a variable length array terminated by a null pointer in all 3 of the event pointer elements of the last index's struct

ESUS_HACK_DATA:

@ Unit 1

.byte 0x00

@ Unit 2

.byte 0x00

@ Padding

.short 0x0000

.align 2

@ Level C event pointer

.long 0x00000000

@ Level B event pointer

.long 0x00000000

@ Level B event pointer

.long 0x00000000

Just go to ESUS_HACK_DATA and modify it as you please. This is the test data I've been using:

19 0E 00 00

9C EC CB 08 <- 8C EB CB 08 is also valid

00 00 00 00

00 00 00 00

So for example you would go to ESUS_HACK_DATA and enter those bytes, then add 16 0x00 bytes to terminate the list of support events.

0x19 is Lowen's char ID, 0x0E is Rebecca's, the 0x08CBEC9C pointer is in the C support slot and will load the event for receiving a talisman from the ruins of the chapter I was debugging on (I needed a readily available event pointer for quick testing). The other test pointer shown is the one for recruiting Renault in that same chapter.

Where is ESUS_HACK_DATA? That is a good question. If you assemble the source file yourself using my batch scripts, you'll see its location as the variable "ESUS_DATA_ORIGIN" in the .log file. This is especially good if you change the address to allocate the data and thus the value of ESUS_DATA_ORIGIN. If you're using it with the current 0x08D00000 address, which you should definitely not do for your actual ROM, ESUS_DATA_ORIGIN's value (and the location of ESUS_HACK_DATA) will be

63: 08d00248 0 NOTYPE LOCAL DEFAULT ABS ESUS_DATA_ORIGIN

Of course, you might not have to mess with that if your eyes are good. ESUS_HACK_DATA is allocated at the end of all other binary associated with the hack in a contiuguous fashion. What I've been doing is simply going to the address of the hack itself, at 0x08D00000, and scrolling in my memory viewer until I reach the 16 consecutive 0x00 bytes at the end.

Edited by Aleph

Share this post


Link to post
Share on other sites

Ah, okay. I think it makes sense now.

.set                ESUS_DATA_SIZE, ESUS_DATA_END - ESUS_DATA_START

Do I understand this line to mean that the assembler will automatically work out the length of the whole thing, and that we can continually add more support slots by repeating this segment:

@ Unit 1
.byte                0x00
@ Unit 2
.byte                0x00
@ Padding
.short                0x0000
.align                2
@ Level C event pointer
.long                0x00000000
@ Level B event pointer
.long                0x00000000
@ Level B event pointer
.long                0x00000000

whilst leaving

ESUS_DATA_END:

intact at (obviously) the end?

Edit: Alright, I'm feeling really dumb at the moment--I can't for the life of me figure out how to use the assembler and keep getting "The device is not ready". I thought it would require the Assemble ARM batch file so I went and got that and changed the file path in Assemble.bat accordingly, but now it says it can't find the ELF. what am i doing wrooong

Edited by Agro

Share this post


Link to post
Share on other sites

you gotta open up the bat file in a text editor and change everything that says "arm-eabi-something" to "arm-none-eabi-something"

on a similar note, the assembler is telling me "bll" is not a valid code

Edited by Brendor the Hungry

Share this post


Link to post
Share on other sites

There's an "include" directive near the top of the source code, near the place where you change the 0x08D00000 allocation value. It's including a file I put in a more general category of my doc that has the BLL macro's source.

The assembler can't predict the future. ESUS_DATA_SIZE is only being used to alert the Assembly Patcher how many bytes to write so that the 16 0x00 bytes are appropriately written at the end of the others. The length of the custom data is determined by how many entries there are from the start of the data to the entry which has 3 NULL pointers (0x00000000) in the Event Pointer slots for the C, B and A levels, as indicated in the comments.

This of course means that if you don't put an entry with null pointers and the code never encounters one by accident when browsing the ROM it will read off the end of the file and cause a memory access violation or something. Remember to terminate your variable length data.

Edited by Aleph

Share this post


Link to post
Share on other sites

for anybody who doesn't know

this is the assembly patcher, it isn't included in that directory; it's honestly pretty self-explanatory if you're using windows (hint: download the whole folder and click on "execute.bat")

alternatively you can use mine which is almost identical except it's in python

Share this post


Link to post
Share on other sites

If you use the assembly patcher tool linked in the source file's comments you can patch a clean ROM with the .dmp file and test it that way. There's information about the format of the data you're meant to customize at the bottom of said source file. If you want to test it on a different ROM or need more details then you'll have to specify.

Java is multi-platform too, so saying "if you're using windows" is moot. After all...anyone not using Windows is smart enough to understand a batch script and translate it appropriately.

Share this post


Link to post
Share on other sites

well i would really hope so but i know several people who don't know what to do with a class file

Share this post


Link to post
Share on other sites

i swear (can't say for certain) that python comes preinstalled on macs at least and they can just click (and i would hope that anybody using linux would know how to deal with both)

Edited by CT075

Share this post


Link to post
Share on other sites

Oh...I forgot about Mac users. Yeah, they might have trouble. ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.