How do I add new enemy to the existing group?

[gjoerulv]

The avatar :-o

We'd also finally have no more need to decompress and recompress the scene.bin file when we want to make certain kinds of mod. I can't tell you how much of a relief it was to not have to do that with the kernel.bin any more when WallMarket got finished.

There still are some unknown parts though. In the scene that is. In my case I haven't done anything to figure it out. When I think 'bout it shouldn't magic evasion be somewhere? I know we can AI it, but it would be magnificent to edit it directly.

 

[Kudistos Megistos]

A couple of things are still unknown (but not much). Still, it would be nice to be able to edit everything that isn't known in the same way that one edits raw formation data. It would at least save us time by having all the compressing done automatically.

 

[nfitc1]

0x0058     38 bytes     Unknown data

This is wrong. First of all, the address can't be 0x58 if the previous block is 32 bytes long and starts at 0x48. This starts at 0x68 and is 32 bytes long (I just fixed this). This dramatically narrows down what it could be.

Current observations (not confirmed)

0x68 is definitely 16 16-bit values and the order is significant. They don't have to be unique in the list, but each instance of an enemy has the same list. (related to attacks?)

0x9A I'm not sure about yet. It's either FFFFh or FFFEh. I don't have a list of which enemies have it which, but these seem to be the only options here and the default is FFFFh. Likely just a yes/no flag of tiny significance.

0xB4 seems to be alignment bytes and is always NULL. It could possibly have been initial statuses (Haste, Shell, etc), but got taken out.

 

[Kudistos Megistos]

I'll have a little look-see at these (although I won't necessarily look very hard ).

I've tried a couple of values at 0x00B4 and nothing noticeable has happened; if it originally meant initial status it probably has been taken out (although I would have thought that initial status would be a single byte).

I'll use my standard technique for finding out what (if anything) the others do.

EDIT:

I've noticed that some enemies have 32 FFs at 0x0068. Sweepers have 5e 01, Mono Drives have 05 01 and the Guard Scorpion and Grashtrike have 13 01. These values don't seem to correlate to anything else in the scenes; the Sweeper's 5e 01 here is the only occurrence of 5e 01 in that scene.

 

[secondadvent]

Actually, initial status would have to have been 4 bytes like the status immunities, because one byte alone cannot point to all the possible status conditions that can be active on the enemy, otherwise the status immunity section would have only been one byte, but that is only possible with 8 statuses, and there are definitely more than 8 .

it is likely that the 2 byte unknown was originally a fourth manip/berserk move that was scrapped for whatever reason at the end. as for the 32 byte unknown, that would require looking at every enemy's data to see if there is a possible pattern to be seen, it is hard to tell from a few enemies . here are a few more enemies and their values (including the ones you mentioned KM) maybe throwing a few out there will get some ideas flowing, though it would still be easier with a complete list of all enemies and their values:

Grunt - d200 (3rd/4th bytes)
Sweeper - 5e01 (5th/6th bytes)
Guard Scorpion - 1301 (11th/12th and 13th/14th bytes)
Grashtrike - 1301 (3rd/4th bytes)
Rocket launcher - d600 (first two bytes)
Blugu - d700 (3rd/4th bytes)
Special Combatant - d200 (3rd/4th bytes)
Smogger - d800 (5th/6th bytes)
Air Buster - db00 (5th/6th and 7th/8th bytes), 1301 (15th/16th bytes)

i think all of these share the same position as a specific attack the enemy uses (as in the same position as the 32 block of the enemy's attacks), so it could be something to do with the camera movement, guard scorpion has 1301 set in the same position as the two unnamed moves it uses to switch between stages, and grashtrike has it in the same position as it's silk attack. the way to figure out what it is would be to compare the way the moves are used with the value there, and with the value as FFFF (i.e. unused), but my guess is that is somehow changes the camera, possibly by "borrowing" the animation used by another attack. it is probably likely that my guess about what it does is wrong (since they would likely just replace the camera movement in the attack data instead of borrowing the camera from another), but it definitely has to be related to the moves in some way.

 

[Kudistos Megistos]

Actually, initial status would have to have been 4 bytes like the status immunities, because one byte alone cannot point to all the possible status conditions that can be active on the enemy, otherwise the status immunity section would have only been one byte, but that is only possible with 8 statuses, and there are definitely more than 8 .

I was thinking that it might work like the status defence and status attack parts of weapon and armour data that are one byte and can only identify one status. I'll have a look at this.

it is likely that the 2 byte unknown was originally a fourth manip/berserk move that was scrapped for whatever reason at the end.

That seems quite sensible. Have you tried putting anything in there to see whether an enemy can actually have a fourth attack? I don't think it would work, but...

as for the 32 byte unknown, that would require looking at every enemy's data to see if there is a possible pattern to be seen, it is hard to tell from a few enemies . here are a few more enemies and their values (including the ones you mentioned KM) maybe throwing a few out there will get some ideas flowing, though it would still be easier with a complete list of all enemies and their values:

Grunt - d200 (3rd/4th bytes)
Sweeper - 5e01 (5th/6th bytes)
Guard Scorpion - 1301 (11th/12th and 13th/14th bytes)
Grashtrike - 1301 (3rd/4th bytes)
Rocket launcher - d600 (first two bytes)
Blugu - d700 (3rd/4th bytes)
Special Combatant - d200 (3rd/4th bytes)
Smogger - d800 (5th/6th bytes)
Air Buster - db00 (5th/6th and 7th/8th bytes), 1301 (15th/16th bytes)

i think all of these share the same position as a specific attack the enemy uses (as in the same position as the 32 block of the enemy's attacks), so it could be something to do with the camera movement, guard scorpion has 1301 set in the same position as the two unnamed moves it uses to switch between stages, and grashtrike has it in the same position as it's silk attack. the way to figure out what it is would be to compare the way the moves are used with the value there, and with the value as FFFF (i.e. unused), but my guess is that is somehow changes the camera, possibly by "borrowing" the animation used by another attack. it is probably likely that my guess about what it does is wrong (since they would likely just replace the camera movement in the attack data instead of borrowing the camera from another), but it definitely has to be related to the moves in some way.

Something else for me to try

Of course, it might be that some or all of these things used to what the things we think they might be doing but have been dummied out, in which case we might be looking for a long time :roll:

 

[secondadvent]

yeah, it is possible that they are all dummied out, having to rewrite the entire pointing crap/removing the now unneeded data is much more work than just making it all useless .

i think i may have tried to add an extra move to the data after the manip attacks at one point in time, but do not remember the results, so it was likely that it did nothing  :roll:. no harm in testing it again though  :lol:.

oh, and i may not be right on this (nfitc1 is the "master of the kernels", so he would know for sure XD), but i think that the weapon status infliction is only one byte because only one status can be inflicted by one weapon, so they would only need to make it one byte, whatever the value is would be the status it can inflict (so 27/26 (depending if it starts from one or zero) would be the darkness status). for the initial statuses/immunities, it is possible to have all active at the same time (though not likely to happen, it is possible), so to do it the same as the weapon would take 32 bytes, one to show each active status, so the better way in that situation would be four bytes, each bit being a flag for a status, four bytes on a weapon that is only allowed one status to inflict is similar, more bytes than needed, though if it could activate more than one status it would be better with four. i hope you see what i mean, i am not the best at explaining things, and i may not even be right on the way the weapon status byte is... i am just assuming i am right .

yeah, i just checked again and adding another move to the spot after the three manip moves does nothing to the manip screen, so it is likely dummied out. and the second "status" section also did nothing, as you said... just making sure .