Final Fantasy Hacktics

Back again with another question.  I recently replaced the Draclua evtchr 31(49) with an identical movement swap of Alma for an event.  This worked perfectly. However, Draclua is pretty awesome, so I figured I would use a different slot and keep him around.

I had pretty much removed almost all evtchr's from my patch because they would be useless when story/events/characters are mostly changed up.  Honestly after playing around the evtchr thing SEEMED easy/obvious as fuck (short of actually creating the new animations).

Having a huge amount of evtchr laying around at my disposal, I figured I would just start with the first one.  First test I immediately noticed a very buggy result with only some of the animations displayed and then total sprite disappearance.  I chalked this up to the way the original evtchr was composed: 7/8 ovelia frames followed by 5 female knight frames.  I assumed that the knight frames were meant to use a different palette, so I shortened my frames to 7.... and then I got really irritated.

event.txt instructions

Results


I am half tempted to simply overwrite a different slot in the evtchr.bin but that wouldn't really solve my confusion.  As far as I know the order of the my animations line up with the variables, but perhaps I'm missing something here and I just don't see it  I haven't seen many questions about evtchr's and I plugged it in to the search bar.... so does anyone see what I'm screwing up here?

edit-I'm half tempted to think that I need to reorder the animations in a seemingly strange order matched up exactly with how it's done in the first event of the game....

double edit- ah fuck- I only just now saw the evtchr diagram on the wiki for instruction 11(unitanimate). I had just been looking at instruction 58(loadevtchr) - I might actually get this.  If I do I'll try to explain my screw up in this spot to justify this post....

 Yeah! Let's use my ignorance as a learning tool shall we!

My crash course on trying to learn about evtchr's actually brought me a lot of frustrating insight!  The best way to learn is in fact try (fail) try (fail) and try again until you know why.  Until recently I didn't know that a nifty spread sheet existed  (Xifanie of course ) to edit evtchr blocks. (wiki event instruction 11 page)

And boy, some (many?) of the actual blocks appeared to make little sense in the way they are numbered and organized.  Also, some contain frames that appear to be unused (why have duplicate Ovelia kidnapping frames on consecutive blocks). 

I was apprehensive to actually edit the evtchr with the spreadsheet, but I figured I could/should do a little learning through trial and error first anyway.  The handy evtchr_locations image showed where the animations SHOULD normally link, but sometimes not so much.  I ran through the first event in vanilla and wrote down to whom each evtchr belonged to figure out placement.  (If you see below ignore the mislabled animation #'s for Ovelia that was guess work).  Ramza starts at 61, Rad at 63, Simon 67 etc. However, many of the #'s listed don't pop up in a unit animation sequence.  This shortly became clearer.

(BTW the "UnitAnim(xID,xAl,xSQ,xEV,x00)" sometimes ends with 01 instead of 00 and I have only noticed this on evtchr's...weird)

Because I wanted to know where 58 through 5E were for my event: I created a simple grid to animate where my frames should be placed. 58 through 5e played out as such: H, D, E, V-quickly-to-W, alma sprite turn, C, B.

The "V-quickly-to-W, alma sprite turn" were all originally Agrias (5B+5C). It was neat to learn that 5B was in fact the two frame fast display. Also I assume that third Agrias frame (actually 5C) is linked to turn unit).  Before this I was under the impression that each animation linked to the sheets were static frames and not sometimes series of frames played out together.

Study of the evtchr sheet while closely looking at the sprite move commands showed me something that should have been clearer to me long ago.  (I largely ignored sprite move in favor of walkto for what appeared to be simplicity sake).  The reason I didn't see the other evtchr numbers pop up in "unitanimate" is because those frames were pulled up by sprite move.

While I had only seen the #67 pop up for Simon, I knew he also used the next two animations. 
The standard sprite Move dropped in by on copy of my evsp:
SpriteMove(xID,x00,+YYYYY,+ZZZZZ,+XXXXX,xMV,x02,+TIMER)  (MV of course is movement type ie speed)
Simon's:
SpriteMove(x13,x00,-00064,-00001,-00021,x02,x0C,+00100)
I couldn't help but notice that simon had 0C where normal I would see 02
And our Injured female:
SpriteMove(x84,x00,+00000,+00000,+00000,x02,x0E,+00046)
WaitSpriteMove(x84,x00)
SpriteMove(x84,x00,+00024,+00000,+00000,x02,x0E,+00062)
WaitSpriteMove(x84,x00)
SpriteMove(x84,x00,+00032,+00000,+00000,x01,x0C,+00026)

I hadn't seen this on my ffh travels before (although I'm sure this is known around) I didn't see on my evsp, nor the info on the wiki.  Hopefully this info helps someone- (OR I get totally corrected) either way...

That first EVTCHR slot is buggy and doesn't work quite right.

The UnitAnim doesn't end in 01 or 02, but the second to last byte can be 01 or 02 depending on which ram block you call the EVTCHR
to.

You should really update to the new config.ini btw

Try a different slot and see if you still get an issue. If you do then post your actual EVTCHR sheet as well as the entire event script and I
will see what's going on. I've done a lot of work with EVTCHR and it's pretty simple for me now, especially the higher up on the sheet that the
EVTCHR is, since not ALL EVTCHR slots actually allow full use of the sheet to match up to the image you posted. I know that the very first
slot gave me issues when I tried to use it in Jot5, so I just said fuck that one and started using others. Lemme know if you need anymore help.

QuoteSpriteMove(x13,x00,-00064,-00001,-00021,x02,x0C,+00100)
I couldn't help but notice that simon had 0C where normal I would see 02
And our Injured female:
SpriteMove(x84,x00,+00000,+00000,+00000,x02,x0E,+00046)
WaitSpriteMove(x84,x00)
SpriteMove(x84,x00,+00024,+00000,+00000,x02,x0E,+00062)
WaitSpriteMove(x84,x00)
SpriteMove(x84,x00,+00032,+00000,+00000,x01,x0C,+00026)

I dunno why there would be something other than 02 in that slot, but I can say that by whats written here, unit 84 is moving back to its original position
(00000,00000,00000)
then along the X axis 4 pixels less than a panel (a panel being 00028) at quite a slow speed, then continuing along that x axis for another 4 pixels
passed that panel.

You will never use Walkto with EVTCHR as walkto forces a walking animation based on the speed you set it to, spritemove pairs with animations while
it moves the sprite, so for small movements that are done via EVTCHR rather than actuall moving very far, they use spritemove. I hope that makes
sense.

First thing you have to understand, is that each EVTCHR slot has its own coding for its frames and animations. That's why you can't just apply the same UnitAnim() to all slot and expect the same frame/animation to come out. With that said, it's totally doable to standardize most of the slots if you don't want to bother coding different frames/animations; you just need to know how to hex edit.

About that EVTCHR slot image:
I've made a huge mistake.

That thing shouldn't even be up anymore; it should've been replaced. I need to fix that today.

If you're lazy you can just try different slots until one works for you.

I updated it on the wiki as well, of course.

If you insist on using the older CONFIG.INI version for the time being, "x0261" for example would be "x61, x02" instead.

As for UnitAnim ending with x00 or x01, if you check the wiki it states so. You will find that kind of information for all event instructions, but the thing is, the effect of those are completely unknown, if they do have any effect at all. Basically, feel free to use any value, and if something odd happens, well it means we can discover a new aspect of the instruction!

Thanks for the replies!

QuoteI dunno why there would be something other than 02 in that slot, but I can say that by whats written here, unit 84 is moving back to its original position
(00000,00000,00000)
then along the X axis 4 pixels less than a panel (a panel being 00028) at quite a slow speed, then continuing along that x axis for another 4 pixels
passed that panel.

You will never use Walkto with EVTCHR as walkto forces a walking animation based on the speed you set it to, spritemove pairs with animations while
it moves the sprite, so for small movements that are done via EVTCHR rather than actuall moving very far, they use spritemove. I hope that makes
sense.

That makes perfect sense. I knew I couldn't use evtchr w/ walkto, I was just kind of thinking/typing my thoughts out loud.

QuoteFirst thing you have to understand, is that each EVTCHR slot has its own coding for its frames and animations. That's why you can't just apply the same UnitAnim() to all slot and expect the same frame/animation to come out. With that said, it's totally doable to standardize most of the slots if you don't want to bother coding different frames/animations; you just need to know how to hex edit.

This different layout for each slot definitely became clear!  It's good to know that they can be standardized.  I don't think that I will use but 2 or 3 new evtchrs, so I don't think I'll play around with your spreadsheet. (Not scared of hex editing/applying with orgasm *is lazy*)  However, I am actually a little excited now looking at the ability to adjust the size of the frames!  Am I crazy for thinking that I could increase the size to roughly the entire block and throw say a bahamut sized monster in there? Obviously not much could be done with one frame, but still interesting...

QuoteYou should really update to the new config.ini btw

I know....*is slow to change*.  The various upgrades to event instructions is really damn tantalizing!

QuoteAs for UnitAnim ending with x00 or x01, if you check the wiki it states so. You will find that kind of information for all event instructions, but the thing is, the effect of those are completely unknown, if they do have any effect at all. Basically, feel free to use any value, and if something odd happens, well it means we can discover a new aspect of the instruction!

I saw that and just had to ask because sometimes things become known before it becomes officially documented.  Not sure if it will lead to anything, but I'll mess around!

Quote from: CONMAN on August 03, 2014, 01:47:48 pm
I know....*is slow to change*.  The various upgrades to event instructions is really damn tantalizing!

I must say, things like the new Jump command are soooo great to use. I would recommend making the change asap

Yes you could create a bahamut sized frame, but honestly, I didn't code the spreadsheet to easily support multiple blocks in 1 frame because it would be extremely tedious and complicated to do so. I figured not enough people would want to do that, so I just said "fuck it". It's still possible, but you'll want to stick to a single 56x56 blocks or smaller when you can.

Also to note, if you did something like that with say a bahamut, it would only be for event, as EVTCHR does not work in battle.

If you try to start a battle with a EVTCHR present, it'll derp out graphically during the dark screen. (displayed winning conditions)

QuoteAlso to note, if you did something like that with say a bahamut, it would only be for event, as EVTCHR does not work in battle.

QuoteYes you could create a bahamut sized frame, but honestly, I didn't code the spreadsheet to easily support multiple blocks in 1 frame because it would be extremely tedious and complicated to do so. I figured not enough people would want to do that, so I just said "fuck it". It's still possible, but you'll want to stick to a single 56x56 blocks or smaller when you can.

This was really just a curiosity- the exact scene that came to mind for me was a bof style scene where Ryu would say meet Elder Dragon/Ladon or something and be granted extra powers or something. 

That sounds pretty cool lol, stuff like that CAN be done as Xif mentioned, but it's not gonna be easy. However if you can fit it into a single frame
that's easily doable via event.