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

  • Thread starter Thread starter myst6re
  • Start date Start date
Status
Not open for further replies.
Well even with "async" there has to be a limit to the number it can do at once.  Perhaps 6? [hence priority out of 6]
 
request 2.

I have just found out that bank 1 and 2, bank 3 and 4, bank 5 and 6, and bank 7 and 15 are in fact, the same memory.

Therefore, when editing Bank 2 byte 0, I am actually using 2 bytes from bank 1 byte 0.

Maybe use 2 colours to show this?  If I edit "bank 2 byte 0", then "bank 1 byte 0" and "bank 1 byte 1" should show as already used.  Colour 1 would show those addresses allocated to the actual bank, and colour 2 would show those addresses allocated from the second bank.

At the moment, Makou gives the absolute impression that there are 15 separate banks of 256 bytes, which is not the case.

issue

Last night I decided to try and place some code in "init" but it would not work.  However, it worked fine when copied into "main". Is this an ff7 thing?  Do certain opcodes not work when in init?  I also noticed that showing dialogue messages and so forth will not work from init either.
 
Last edited:
request 2.

I have just found out that bank 1 and 2, bank 3 and 4, bank 5 and 6, and bank 7 and 15 are in fact, the same memory.

Therefore, when editing Bank 2 byte 0, I am actually using 2 bytes from bank 1 byte 0.

Maybe use 2 colours to show this?  If I edit "bank 2 byte 0", then "bank 1 byte 0" and "bank 1 byte 1" should show as already used.  Colour 1 would show those addresses allocated to the actual bank, and colour 2 would show those addresses allocated from the second bank.

At the moment, Makou gives the absolute impression that there are 15 separate banks of 256 bytes, which is not the case.
Click to expand...
Yes I know, I don't really know how to merge these banks, I'll consider your suggestion.


issue

Last night I decided to try and place some code in "init" but it would not work.  However, it worked fine when copied into "main". Is this an ff7 thing?  Do certain opcodes not work when in init?  I also noticed that showing dialogue messages and so forth will not work from init either.
Click to expand...
Some opcode can't work in init, I already disabled some in the editor (basically 3d model moves, text and modules calls -menu, minigame, change disc-), but I don't think there are disabled when you copy/paste a script.
 
You don't need to merge banks... just use 2 colours to show the person that they are used vars.  Let's say colour red means "this byte is referenced from this bank var " and blue is "this byte is referencing in the second bank var"

Obviously when writing to bank 1 var, this is a 1 byte colouring.  And when writing to bank 2, its 2 bytes that need to be coloured/

This sounds really more complicated than it is.  I'll provide a pic later.
 
Small issue:

Your "Background" state list starts at 1 (i.e. State 1).  It should start at 0. (i.e. State 0).
 
The way it looked like to is that State 0 is when all are unckecked (default or something). I don't know if this was intended, and this is just a guess anyway.
 
It's just an inconsistency.  Since the actual byte uses 0, the State should be 0.  No biggie, but it threw me when I set the wrong state because of it.
 
Possible big bug...
When exporting script files and the file already exists , makou prompts to replace the file... it does so.. but the resulting file is double what it should be.  It may be adding the data to the file in some fashion or other, not just replacing it.  Please check.
 
I noticed a bug for the psx version

When i modify something in a DAT  and i save the file, makou reactor write an additional "00" between the animation script and the akao, this change nothing for those who play on emulator, but for the PSP and material PSX that make the game crash 100%

Im not sure if the additional byte is the only difference, but for real PSX and PSP just adding or deleting a byte can cause the game crash
 
Did you actually test that? Normally zero padding is no issue whatsoever. Try inserting the “00“ on a unmodified .DAT file just at the location that you mentioned and change nothing else. Repack and check on your PSP, I can not imagine that it will hang up.
 
i cannot guarantee there is only "00"  as difference , i know we can fill the end of a file with 00 without changing the file, but this one is between the animation script of the field and the akao section

when i change a dat file manually with an hex editor(without makou reactor) the game works fine on PSP, when i do exactly the sames change using the tool the game crashes, i dont understand why makou reactor rewrite the file this way , since its possible to have any changes and still having the game working
 
Whether its at the end or not is all irrelevant, you can put “00“s between any sectors as long as offsets are right Im using this a lot with no trouble. The 00 being between animation and whatever is optimal, only an extra byte inside a set of data would be damaging. But in between zeroes are ok. I assumed that you made the conclusion that 00 at that location causes crashes as you noticed that difference from a MR edit and received a crash thus but I maybe test if that's really it.

Other than that you can also use a compare function in your hex editor to see what MR did to your file ;)
I've used edited DATs a lot on my physical PSX already.
 
Last edited:
yes i compared them already, and i think this "00" is moving the offsets, but now im not so sure because in that case even epsxe would crashes

i cant tell you all the difference because there is another problem, when i uncompress a dat file and then i compress it ( without even modify the file) the values are not the same than the original, so i checked in the wiki and its said that the DAT files use the same lzs compression, but these differences dont make my game crashes, but with these existing differences, i cannot tell you what other difference makou reactor did, the only noticeable one is the "00" just before the akao section

to solve this i just edit the dat with hex editor but thats a lot of works , if i could use makou reactor that would be so much faster
 
The word/dword alignment has been al old issue with Makou Reactor, I thought it was fixed already  :|
Let's see if myst6re can do something about it.
 
thats why i downloaded the latest version, all these bugs occurs when i was using 1.5.1, but i tried with 1.6.1 and its the same
 
Sheesh, Jeet you are actually right. The modified fields I used on my real PSX were hex edited after all. I just worked a field with MR and saved it in the ISO which crashed the game on PSX but not on epsxe.

This is truly bad as Im currently building a mod using it and I got my models and Kernel/Battle/Menu files perfectly working so it would be pretty sad to throw away physical compatibility for using MR.

Mystre6 can you please look at this? We love MR and we wanna use it :)
 
Yes but i solved it, changing everything manually with an hex editor, since i dont know well the structure of the DAT file, i use  makou reactor as an "example" , i keep an unaltered version of the DAT, i modify the other with wallmarket, then i compare the two dat file and change ONLY the desired changes, with this way its works perfectly on PSP, the problem is that it very time consuming.Because you have te re insert every files one by one too.

If makou reactor could works with PSX and PSP i could finish my mod in probably 2 or 3 days, using my "manual" method tooks me 3 weeks....its now finished but ruined my patience lol, look like PSX version is unloved for modders, probably because the difficulty , one bad step and everything crashes
 
Last edited:
Wallmarket DOES work with the physical consoles I'm using heavily modded Kernels on my PSX. I explained to you how to fix the kernel pieces and yamada, that's all it takes  ;)

On the .dat files did you actually compare a MR edited .dat file to your manually edited final product which was working? The changes would be interesting maybe it has sonething to do with the recompression or the tool saving directly into the ISO. Maybe we just have to edit the .dat files from a FIELD folder and reinsert manually.
 
Status
Not open for further replies.
Back
Top