Tech Editor - Period

[FaustWolf]

Oh, sweet, so there is a way to change what address the tech code pointers are relative to, on an individual basis? Like, if we wanted, we could use the editor to make Crono's "Cyclone" actually point to the "Cure" enemy tech just by changing that most significant byte (both techs have an index of 0x01)? Is this something already implemented in the tech editor, or will that be in an update?

I can generate a spreadsheet pretty quickly detailing where all the parts of the various enemy techs are. Should get to that tomorrow sometime. If I gave you an Excel spreadsheet would you be able to process that into a tab delimited text file? I might be able to do the conversion on my end too.

[Agent 12]

The adding the byte is just for the tech editors purposes so it know where to find it in the data in the rom.  Internally (to the rom) it's only local (two byte) pointers.

--JP

[FaustWolf]

Ah, hence the talk of copying and pasting the code manually. Since we know where the pointers to each tech's code are, I guess we can repointer if necessary.

Currently the tech editor prevents the user from inserting code that would make edited tech code longer than it originally was. If we repointer to make more room for a specific tech's code, will the editor adjust accordingly, or is it hard-coded to ensure that the edited tech code is less than or equal to the length of the original tech code?

[FaustWolf]

Here we go! 

A comprehensive tech address list based on all the testimony in this thread. I know the 7-byte graphics sections for the Double and Triple techs follow the single techs, so I'm hoping that the other types of data follow suit. However, other than the 7-byte graphics sections, it's mostly theoretical for the Double and Triple Techs.

Addresses for each component of the Enemy tech data are on the second tab, whereas player character tech data addresses are on the first tab. For enemy techs, I would suggest implementing only up to 0xBC for now, because slightly after that the tech code pointers get really weird. I suspect the game engine skips a portion of the pointers from around 0xD6372 ~ 0xD63BE and starts reading more pointers after that, but I still can't get all the numbers to add up, so I'm not quite sure what's going on there. But enemy tech data up to index 0xBC should be pretty safe for editing.

I'm not exactly sure what the "11-byte data" vs. the "12-byte data" was that JLukas had been referring to, but hopefully you do.    I hope one of those sections also includes the status inflicting/buffing aspects of techs, because I didn't look for those yet. I can snoop around for their addresses if they aren't included in either the 11-byte or the 12-byte data.

ATTACHMENT REMOVED PER JUSTIN3009'S OBSERVATIONS, REATTACHED IN A SUBSEQUENT POST

[justin3009]

I think the addresses are off.  I went in and checked Luminaire's 7-Byte GFX Info, and that was Confuse's data.

[FaustWolf]

Boy, am I glad I took a second look at the spreadsheet! Turns out a simple VLOOKUP table cleaned up immense incorrections. Now it should be perfect.

I still don't know quite what's going on with enemy techs after 0xBC. I suspect that a bunch of values are actually skipped and the functional addresses associated with positions after 0xFF are brought into the space that would be freed up by such a move. Seems like that's going to be really messy, but I'd recommend just implementing editing of enemy techs up to 0xBC for now.

EDIT: Here's a quick demo of the fact that this spreadsheet has correct addresses for double and triple tech info.
http://www.youtube.com/watch?v=hcJMp2aohvQ

[FaustWolf]

That's...one small step for fans, one giant leap for Frogkind.

This is extremely encouraging, because it took all of a few minutes to transfer the code -- just a matter of getting the tech code object pointers right. Unfortunately it looks like Hexagon Mist lacks code to make the caster actually do stuff. Frog Squash is 0x71 bytes or so, whereas Hexagon Mist is 0x44 bytes, so hopefully there's enough room to make Frog do stuff and for the screen to darken menacingly (if there's a command for that). Maybe bubbles should pop up all over the screen for added awesomeness.

[Agent 12]

Remember, object 00 (which you may have repointed) is the "caster" object.  So if you repointed that to someone doing nothing then frog will do nothing.  You can probably safely repoint it to .....like whatever Water's object 00 is.

--JP

[FaustWolf]

Bah, there might be something specific to the caster object in Hexagon Mist that's necessary for the Layer 3 effect to proceed, if that's possible. Frog does his spell animation, but the game hangs, with the animation playing and the enemies doing their "hit" animation, but the hexagon doesn't even appear.

I'm going to move on to Magus' Geyser for now.

[Agent 12]

It's probably a "wait for section" command.....water probably has a section ++ that hexagon mist doesn't have.

--JP

[FaustWolf]

That's probably it. Maybe if I just deleted the "wait for section" command...but then I'd be screwing up Frog's other spell, heh heh.

Yeowch! "Geyser" weighs in at a mighty 0x1B4 bytes, whereas Magus' "Black Hole" is only 0x99 bytes. Looks like it's time to experiment with pointering into unused space. I could probably just copy and paste the entire Geyser code there, then have all of Black Hole's object pointers point there. Actually, if we do that, we'd probably be able to replace any spell with "Geyser" because it would essentially be a set of object pointers, right? Is there any rule that a tech can't just be a set of pointers to objects existing elsewhere?

EDIT: Oh, of course! I could just go to Black Hole's root pointer in the code pointer table and repoint it to "Geyser" code pasted into the unused space.

EDIT: Stuffed Geyser's code at 0xEDC20, near the start of a block of unused space, and repointered Black Hole's tech code pointer to that location, and it's a mess. The code seems to grab the other player characters and move them as opposed to producing the little ghosties, so the game hangs. I'll have to study the specifics of how the code itself works before attempting this again I think.


EDIT: Scratch that, it's almost working! I made a simple error by copying all seven of the Geyser graphics bytes, when I should have left the first one alone (that's the one that tells the game engine which tech code pointer to use). Something's up though, because it's pulling from the Haste clock graphics pack as opposed to the ghost graphics pack, and has the wrong palette. If I figure that out, we'll have a fully working Geyser!

[Agent 12]

FW just wanted to let you know that I successfully used your excel sheet in a secret project I'm working on Worked like a charm.

--JP

[FaustWolf]

Sweet, can't wait to see the results! During my spring break next week I'll hopefully be able to whip up some new character techs based on enemy techs, and post one patch per tech.

[Mauron]

c) The most significant byte is hardcoded in the tech editor I believe something like if enemy tech use E0, else use D0 so I think if you repointed it you would be able to use my editor.

When I was working on dual techs for Magus, I had a problem getting the tech editor to read the new tech. I had modified the enemytech.txt file to make it readable by the editor. Earlier I had moved all techs into the 5Exxxx range to make room for the new ones. Is it possible that hardcoded byte was causing the problem, or was I just doing something wrong?

[Agent 12]

almost certainly yes.    The tech editor won't read from a another bank. 

--JP