Weapon sprites changing???

[mecurylighthouse]

ok heres my problem i created some new weaons sheilds armor stuff like that but in battle the weapons sprites always change if i equip the weopon to some one else or some times it'll show the charcter default by that i mean if jenna equips the light blade made it look like she has a staff but if i give it to felix it becomes a sword What do i have to do to edit this do i have to edit in hex if so i just need the adress and list of values etc   

[Knight of Purgatory]

ok heres my problem i created some new weaons sheilds armor stuff like that but in battle the weapons sprites always change if i equip the weopon to some one else or some times it'll show the charcter default by that i mean if jenna equips the light blade made it look like she has a staff but if i give it to felix it becomes a sword What do i have to do to edit this do i have to edit in hex if so i just need the adress and list of values etc   

@Tumjaiyu
More necroposting...

[Rolina]

There is no way to determine what weapons change to what sprites yet.  I don't know if we even know what the game does to determine that.

[Misery]

I'd like to know this too. But there are so many ways it could be done in, I wouldn't even know where to begin looking... very likely the number of the item is used to determine what graphics are displayed. Somehow. But without the when and the how, I don't think that's very helpful to know, and it might not even be correct.

[Daddy Poi's Oily Gorillas]

I wouldn't even know where to begin looking...

0812CAD0 = Item/Battle sprite reference

01FF bits are the item.
FE00 bits are the battle sprite. (Weapon)
FFFF ends the list.

[Rolina]

Is there a way to make this easily editable? 

[Misery]

Geez, it was that simple? So I guess what you're saying is first 15 bits are the sprite number and last 17 bits are the item number?

Is there a way to make this easily editable? 

This is a static list of declarations, so editing the definitions for existing weapons should be simple enough to implement in an editor, but adding new ones might be a bit trickier (in an editor, not so with a hex editor). I imagine the editor would read the list and allow you to modify the existing item=sprite definitions...

[Daddy Poi's Oily Gorillas]

That's 7 bits, and 9 bits. Since this is a 16-bit list. Not a 32-bit one.

(Trickier, maybe, but I could simply implement a code scanner that finds all pointers with 08****** and updates them. From what I've seen, 08****** as in-code loaded values seem to be always pointers, I have yet to see an instance where it is not. Though, it may be possible.)

[Misery]

That's 7 bits, and 9 bits. Since this is a 16-bit list. Not a 32-bit one.

(Trickier, maybe, but I could simply implement a code scanner that finds all pointers with 08****** and updates them. From what I've seen, 08****** as in-code loaded values seem to be always pointers, I have yet to see an instance where it is not. Though, it may be possible.)

Oops, yes, of course. 16-bit list. I just... made a typo. In my brain.

As for the second paragraph here, I'm still trying to figure out why you'd want to scan for pointers. You're not planning to have the editor repoint the entire list, are you? (or is there no free space at the end of it?)

[Daddy Poi's Oily Gorillas]

Well, if you are going to add entries to this bank, you're going to have to either repoint this bank or the following bank or banks.

There happens to be other data after this bank. y'know?

(My idea for the editor was to allow for resizing of all banks while keeping them all in the same order.)

[Misery]

I... don't think we have the same definition of "bank"
Do you mean like, a data bank (could be any size)?
When I hear bank, I usually think of ROM banks (predetermined size).

Nice idea in any case, that would make the user not have to worry too much about free space or repointing. Think it could cause any issues? I can't think of any right now...
But I guess I'm going a bit off-topic now, this is more relevant to the editor thread.

[Daddy Poi's Oily Gorillas]

When I say banks, I mean data tables / databases / etc. I use those terms interchangeably.

Well, if the code isn't edited, I feel confident that there may not be any issues at the moment, atleast as far as Thumb goes, anyway. Otherwise, there may be a few things to watch out for. (Like be careful about using an 08****** data value for ldr-relatives if it isn't a pointer, etc.)

Not that I have fully coded that repointing method yet, but it should be similar to my function lister routine which was meant for listing all the functions that are in a code file.

[Rolina]

As far as I'm concerned, if we know of the data, and we know what it does and how to change it intelligently, then it should have editor functionality.  So if we know what data calls to what, then we could have a simple dropdown menu for it or something.  For the data after that, if we know what it does, I'm sure we could do something with that too.

[Misery]

As far as I'm concerned, if we know of the data, and we know what it does and how to change it intelligently, then it should have editor functionality.  So if we know what data calls to what, then we could have a simple dropdown menu for it or something.  For the data after that, if we know what it does, I'm sure we could do something with that too.

Editing the definitions for items which already are weapons is definitely no problem. Things like that, where you could simply swap values in a hex editor, are the easiest things to implement in an editor.

Editing the appearance of other items requires adding new definitions, and since there's probably not a lot of free space I think we'd need Teawater's proposed pointer scanning function for that. There shouldn't be any problem with that either, though.

If no definition for which sprite to display can be found, I believe the game goes with the default (0), which seems to be longsword or staff depending on what the character can wield.

When I say banks, I mean data tables / databases / etc. I use those terms interchangeably.

I think list or table would be the more appropriate terms. I know that in SNES hacking, a Bank is a specific, named portion of memory (in that case, banks are named $40 to $80 and all refer to a range of addresses). But it might not be the same for GBA, I wouldn't know.

[Daddy Poi's Oily Gorillas]

Editing the definitions for items which already are weapons is definitely no problem. Things like that, where you could simply swap values in a hex editor, are the easiest things to implement in an editor.

That is true until you decide that you want to make things user-friendly. Stuff like displaying sprites that the indexes refer to, and any other data you might consider.

Editing the appearance of other items requires adding new definitions, and since there's probably not a lot of free space I think we'd need Teawater's proposed pointer scanning function for that. There shouldn't be any problem with that either, though.

You could also get away with repointing the table manually yourself. Oh, and don't worry about space, since you should be able to expand the ROM to 32 MB without any problems, I think.

I think list or table would be the more appropriate terms. I know that in SNES hacking, a Bank is a specific, named portion of memory (in that case, banks are named $40 to $80 and all refer to a range of addresses). But it might not be the same for GBA, I wouldn't know.

Unfortunately, I don't know much about SNES. And I am not even sure how "banks" by that definition would apply to GBA? Unless it describes the different sections. BIOS, WRAM, IRAM, I/O, PALETTE, VRAM, ROM.  But I don't think I would necessarily call those "banks"... without someone actually documenting it as that.

http://dictionary.reference.com/browse/data+bank?s=t

data bank

— n
   a store of a large amount of information, esp in a form that can be handled by a computer

[Misery]

Editing the definitions for items which already are weapons is definitely no problem. Things like that, where you could simply swap values in a hex editor, are the easiest things to implement in an editor.

That is true until you decide that you want to make things user-friendly. Stuff like displaying sprites that the indexes refer to, and any other data you might consider.

Well, there is something called working iteratively. Meaning you make a bare bones implementation of every planned function before moving on to the next stage of refinement. This way, you avoid overworking certain functions while completely lacking others. The very first step in the process is to make the program able to change a specific value in the ROM, and that's not difficult to do.

I think list or table would be the more appropriate terms. I know that in SNES hacking, a Bank is a specific, named portion of memory (in that case, banks are named $40 to $80 and all refer to a range of addresses). But it might not be the same for GBA, I wouldn't know.

Unfortunately, I don't know much about SNES. And I am not even sure how "banks" by that definition would apply to GBA? Unless it describes the different sections. BIOS, WRAM, IRAM, I/O, PALETTE, VRAM, ROM.  But I don't think I would necessarily call those "banks"... without someone actually documenting it as that.

I suppose the word "bank" has no specific meaning in GBA hacking context, then. I still think using the word without stating you're specifically referring to a data bank feels a bit odd, but I won't push it.

[Rolina]

As much as I wanna push user friendliness, I have to agree with Mis here.  Gotta focus on priorities, and getting everything planned to work first takes priority.  After that we can work on making everything streamlined and user friendly.

[Aile~♥]

It doesn't even have to show the sprite. It just has to be able to pull the text from the ROM. That should be fairly easy. The text box would say something like:

Weapon Type: (0): Longsword/Staff

Unless you go in the editor and change Longsword and Staff to different names, such as changing Longsword to Sword and Staff to Scepter. You could probably pull the text from the item descriptions of the first weapon of each type. So if you changed Longsword to Sword and Staff to Scepter in the descriptions of the Longsword and Wooden Stick, it would then say:

Weapon Type: (0): Sword/Scepter

Not that hard, amirite?

[Misery]

I'm not even sure if it's a good idea to write the weapon type in the editor, since the graphics can be replaced.

[Aile~♥]

As I said, it could just read the weapon type text straight from the ROM, but that may be a good point if the different weapon types are completely character-exclusive so you get a "longsword/scepter/lance/chainsaw" situation where the same weapon type value does all of those.