[PSX/PC] Field Editor - Makou Reactor (2.1.0)

  • Thread starter Thread starter myst6re
  • Start date Start date
Status
Not open for further replies.
Yup I written this page
Click to expand...
Hah, funny.

Don't worry about it, myst6re. This is a hobby, not a job :)  Thanks for making Makou Reactor. It's a great tool.
 
Opcode FC - FMUSC

This sets the next music to play from the field list.  Hence if Tools > Sounds > music2 = makoro

And FC parameter is 02 - the next field music that will play will be makoro. In other words... it is

Set music #2 for next field after battle. The counterpart of opcode BC - BMUSC.

The field music will only be changed after a battle. So moving from field to field will not initiate any change after a FMUSC.

For example, in the field rckt32, the boss music must carry on after the battle (after the Palmer fight). So next battle is set to boss music with BMUSC  and the next field music is ALSO set to boss music using FMUSC.
 
Last edited:
Battle mode flags in Makou are a little confusing vs the actual value.

Flag 1 is the 7th bit of byte 1 (0x80), and flag 8 is the 0th bit of byte 1 (0x01).  That's really annoying when debugging the game.

Flag 1 should be 0x0001
Flag 16 should be bit 0x8000

?

Same with battle mode 2 (32 bit mode)
 
I'll need NFITC1 or someone else to confirm this, but it looks like opcode 22 Battlemode2 only makes use of 24 of the 32 flags. From what I can see, the flags are placed into memory addresses starting CC0DC5 - but CC0DC8 is never used because 620002 is not mov [edx+40],cl.

So at most only FF FF FF can be set. I set all 32 flags and that's what I got until I made the amendment above.  I think it's academic anyway, since i'm almost certain those bits are never used in ff7 script.

In fact, the only use that battlemode 2 has seems to have over battlemode 1 is that it includes bit 24 (wrongly(?) flag 16 in Makou) which stops the party victory pose. None of the other flags are set in script and I doubt they were ever given any use.

Note: in memory "disable victory celebration" is represented as hex 00 00 01. Game Over (Battlemode 1 and 2 set the same bit of course) is 01 00 00. 

taking memory starting CC0DC5 (reverse order byte)

0x01 Disable Game Over
0x200 Countdown timer
0x400 Preemptive Strike
0x800 Cannot escape from battle
0x2000 Do not play victory fanfare
0x4000 Activate Battle Arena
0x8000 Do not show battle rewards
0x10000 Disable victory celebration [can only be set with battle mode 2]

As you can see... it's more nonsense bloat with the finished field script.
 
Last edited:
Is the resize all windows thing still going to incorporated would save a crap load of time.
 
I would love if there was a macro in this to allow all boxes to me placed as far to the bottom left as possible. Maybe all boxes of ID X placed wherever you choose. It would help a ton for my Subtitle mod.  I agree to the auto-size all thing too.

On a side note. I'm using the reunion/because with menu overhaul on, but even if a box is auto-sized there is still a huge gap o the right end. And solution i don't know about for this?
 
Your best bet is to use ts which can autosize all dialogue just with a simple decode encode.

Until Mystere adds any option, the best way to subtitle is to use ts - then create a program to add #cy 230 to every entry. (#cy 230 will set Y to 230 and centre X).

That's how I'd do it, but I appreciate not everyone could create such a program.  Still it wouldn't be that big of an issue. You'd just add a search for '-------------------' then add the info on the line below it.
 
Last edited:
Yeah i remember you telling me that before. I did try it but even with your instructions i couldn't grasp it. I know it's easy but i had no luck. Just one of them things haha
 
Correction to Akao documentation. I've been testing it in the PSX version to avoid any errors brought on by PC port.  I was also notified by someone that field code allows for multiple effects to be played at the same time (like the Summon effects in battle). This isn't working in PC version.  I did some digging, and here are the amendments:

OPERATION 0x20:

The parameter is assigned to a channel. Since operation 0x20 can only take one parameter, it is in fact no different to operation 0x28.

OPERATION 0x21:

Allows 2 effects to be played using channel 1 and channel 2. This is simply a short-hand way of using operation 0x28 and 0x29.

param1=Panning,
param2=Effect ID for channel 1
param3= Effect ID for channel 2

OPERATION 0x22:

Allows 3 effects to be played using channel 1, channel 2, and channel 3. This is a short-hand way of using operation 0x28, 0x29 and 0x2A.

param1=Panning,
param2=Effect ID for channel 1
param3= Effect ID for channel 2
param4= Effect ID for channel 3

OPERATION 0x23:

Allows 4 effects to be played using channel 1, channel 2, channel 3, and channel 4. This is a short-hand way of using operation 0x28, 0x29, 0x2A, and 0x2B.

param1=Panning,
param2=Effect ID for channel 1
param3= Effect ID for channel 2
param4= Effect ID for channel 3
param5= Effect ID for channel 4

You see how ridiculous this is?  It's just to save every last byte in some really crappy way.  Again. Just confusing and useless.  If not using my DLL, you can fix these broken OPERATIONs by just using the working counterparts.  I.e., for operation 0x23, you'd use 0x28, 0x29, 0x2A, and 0x2B to set the 4 effects.

It's not even like 0x21,22,23 were even needed.  They could have just checked to see if an argument was zero and then skipped if so - but stupidly they use 0 for the "stop effect".

OPERATION 0x30

Play a sound effect on channel #4, and ignore operation 0xF1 [param1=Panning, param2=Effect ID]

http://wiki.qhimm.com/view/FF7/Field/Script/Opcodes/F2_AKAO

Updated. I think that's everything now.
 
Last edited:
OPERATION 0x23:

Allows 4 effects to be played using channel 1, channel 2, channel 3, and channel 4. This is a short-hand way of using operation 0x28, 0x29, 0x2A, and 0x2B.

param1=Panning,
param2=Effect ID for channel 1
param3= Effect ID for channel 2
param4= Effect ID for channel 3
param5= Effect ID for channel 4

You see how ridiculous this is?  It's just to save every last byte in some really crappy way.  Again. Just confusing and useless.  If not using my DLL, you can fix these broken OPERATIONs by just using the working counterparts.  I.e., for operation 0x23, you'd use 0x28, 0x29, 0x2A, and 0x2B to set the 4 effects.

It's not even like 0x21,22,23 were even needed.  They could have just checked to see if an argument was zero and then skipped if so - but stupidly they use 0 for the "stop effect".
Click to expand...
When I was trying to fix the observatory SFX, the first thing I tried to do was ditch the Akao 23 and put the SFX onto four separate channels but the same issue occurred; the 4th SFX would override the other 3 and be the only audible sound. There must be something about the SFX files themselves that's causing the problem; the function itself I think might be OK as it works under certain conditions when using other SFX.
 
Are you sure that there isn't any other effect playing?  A normal "play effect" uses channel #1 for example.

If it is the sfx, I can check that too.
 
A silly question from my side, but what if the sound buffer of the game is to small? Though it really is only an idea which springs into my mind. I mean we shouldn't forget that the PCs at that time weren't so potential as they are now.
 
Last edited:
A silly question from my side, but what if the sound buffer of the game is to small? Though it really is only an idea which springs into my mind. I mean we shouldn't forget that the PC at the time weren't so potential as they are now.
Click to expand...
Could be; the SFX in the observatory are all 1min+ in length but when I used SFX that were only a couple seconds in length it seemed to work okay.
 
I can't see the sound buffer being the issue.  Buffers are always super small.  The data is streamed from a file.
 
It's looking more and more like my fault to be honest haha.  But let me know if you can see any addition operations in the file (by looking at hex) that should not be there. Should only be 100 or so addition ops in group 11. 

edit.

Oh, ok, something is up.  Phew.  Thought I'd made a right mess of that.  ;D


Also note to people:

http://oi66.tinypic.com/2j4obqt.jpg


This is the general way that the field script works in game.
 
Last edited:
Love the tool, I searched around inside to see if its possible to export the walkmeshes as obj or fbx files, but I couldn't find anything.
I also couldn't find a way to export the backgrounds complete with their animated parts.
Deiling for FF8 also had the same things, so it might just be something you aren't personally interested in doing, or maybe its an planned feature.
Or (and this could be quite likely...) I'm just completely missing a really simple option somewhere.
 
I searched around inside to see if its possible to export the walkmeshes as obj or fbx files, but I couldn't find anything.
Click to expand...
There is a walkmesh editor included and it is very full featured, but even after learning it can be tricky. The game requires defining what triangle edge leads into what triangle. so for example line 2-3 of triangle 53 leads into triangle 54, and to get back line 1-2 of 54 leads into 53. So not only does each point of the triangle have an x,y,z but also the edges have to be set. I'm fairly certain that an obj wouldn't have this information when you imported it back into the field file and you would still have to define all those edges. But if it could be worked out that would be a nice feature to have.

I also couldn't find a way to export the backgrounds complete with their animated parts.
Click to expand...
To export all the background layers export the files using the tool Palmer, then edit the png files with an image editor. After making your changes you use palmer to generate the modpath texture to get the changes in game. The palmer links seem to be dead, but I'm sure you can find it somewhere or someone can re-upload it.
 
Status
Not open for further replies.
Back
Top