MP2E
-
Posts
89 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by MP2E
-
-
Awesome, MP2E. I hope this text editor works out well and serves the purpose we need it to serve.
Thanks!
Hey MP2E, how is your program figuring out what duplicate text isn't used by the game? I know there's some unused text in the game in the prologue, dealing with Noishe and Alec and Ethlin, and I'm not sure if this text is included in some pointer array or not. But my big interest is leftover text that isn't included in a pointer array, like we see in games like Chrono Trigger. You have any ideas on an automated way to detect text not in a conventional table?
Duplicate text is handled by creating a merge tag and inserting it at the beginning of the original bit of dialogue, so that when I write an encoder it will write the script in multiple places. As for unused dialogue, it should handle it as long as the game doesn't reference it in the PPT tables.
I'm kicking around a few different ideas as to how to find the tables. I could:
A) Identify sections of valid Shift-JIS or EUC-JP text, then finding the 'boundaries' around said text. Then search for the address of the beginning of the text and note where it's pointed from.
B) Identify the pointer tables themselves, then verify they are pointing to text by jumping to the address and matching it to a 'fuzzy template'
Probably B will end up in the final product.
Great news! This will surely speed up the translation! (And also nice to hear that the pointer offsets I gave you worked!)
So let me get this straight- Resire will dump a script, which you can then edit, and then insert it back into the game? I've just been a little confused about what it actually does.
Also guys, I think that this topic is quickly escalating in to a big argument. If you don't think gringe is a good translator, or that you just don't like fan translations, that's fine, you're entitled to your opinion. But if you don't like how we're doing this, then please refrain from posting about it. All this does is derail the thread and take up space.
Resire just dumps the script, I'm planning on writing another program that reads the scripts that are output from Resire and reinjects it into the ROMs
One question, will your program be able to handle scripts that are longer than the original? Thus require more space than the original space reserved for Japanese script. How will that work within your program?
This is actually outside of the scope of Resire itself because it only dumps scripts, but the reinjector will support injecting larger scripts, yes. How it can do this is:
A) Identifying unused space and using a control code to jump to an unused address to resume the dialogue (Risky)
B) Using an extended ROM and using that space as the area to drop longer dialogue bits (Safer)
Most likely I will write the injector to only do B, and later extend it to support A, if needed.
I'm writing each component as a separate tool, for now, but I'm already tossing around the idea of combining them into a text editor with a GUI after each component is complete.
-
Documentation of the script format is feature-complete. Updates will come as I find new information about the project, but now the main focus is on the text dumper. I have decided to dub it "Resire", for now. I simply like the name, it has no bearing on what the light spell will actually be called. :P
Resire will support FE4 and FE5 text dumping, it will have it's own new script format that will be based off of JTEC(probably very light changes in terms of the actual format, all around). Resire will automatically remove repeat text instead of just flagging it. An 'automatic' dumping mode will be added at some point that will automatically locate all of the text in the ROM and dump it without PPT tables. And finally, no more crappy EUC tables! I found a great library that will re-encode everything into UTF-8 without using that silly table.
Resire is written in Haskell to minimize bugs. I'm building it module by module and heavily case testing before I move on to the next part.
Resire's source will be posted to my github repository as soon as I deem it fit for public release.
EDIT: Ah totally forgot, I used the jtec dumper to dump all of the character names from FE5 using the JTEC Dumper tool and a PPT table provided by joesteve. It seemed to work perfectly! I haven't tested the other PPT tables because I've been working on my text dumper, but things are looking good.
And finally.. I guess Project Naga now encompasses FE4 and FE5? FE4 is the first priority but FE5 seems to be a secret agenda of everyone involved :P
-
Ooh that would be great, actually :) I'm sure I could learn a few things from it at the very least. If it's better than my base and isn't too invasive, I may just use that instead.I think there are some Japanese patches which do a similar thing, and which also rearrange/adjust the SRAM to take advantage of different ways of storing items/skills/stats. (in this case, the expansion--I think the patch I'm think of is actually primed with pointers prepared to take advantage of the new space, like in Xenesis's expansion patch for one of the Advance Wars games.
(Provided you can find it, no worries if not)
I figure you already are working on your own stuff though, so there's not much they could do to help you other than be a curiosity piece. I wouldn't even know where I've saved them to either :/ But it's super nice just to read some more knowledge on this stuff from you, so yeah, I got mad respect for you :)
Thanks! I appreciate it, motivation++ :)
I'm not too far along just yet, I have a lot of information related to fe4 and I've hacked out a few rough utilities but I want to refine the text dumper/injector quite a bit before any actual ROM hacking occurs. This means it's the perfect time for suggestions, though!
(Sorry for the derail, further discussion of FE4/FE5 should probably go in the Thracia translation thread.)
-
Ah, yeah seems as though there are some misconceptions. There is actually a tool called Lunar Extend that will automatically extend a ROM for you. I used 48MBit HiROM to output a 6MB file that is pretty much the same as the original. It has 2MB tacked on to the end and one byte is changed, which is for the board PCB identifier.
Higan generates a manifest just fine and Snes9x simply loads the file. ZSNES can work if they make it able to autodetect the mapper.
You can make ROMs up to 8MB like the thread specified, the main reason I wouldn't recommend 8 is because then you can't flash it on a cartridge unless you have an SD2SNES or something. That's also why I didn't bump up SRAM, it's already at the cartridge maximum.
I may actually look at seeing if I can make a 4MB version later so that people don't destroy rare cartridges to sell reproductions. I don't really know how much empty space is in FE4 but judging from the previous translation, a decent amount.
I can post a patch if anyone would like to look at the bare Japanese ROM just extended. In fact, it's probably a good idea to post it just to make sure everything can play it. I did some testing and everything seemed to work fine, but I only tested the latest snes9x and higan
EDIT: it seems that Snes9x only somewhat recently supported larger ROMs. I guess I was used to bsnes :P
-
more detail can be found here: http://legendsoflocalization.com/mother-3/
that particular part of the site has not updated recently, but rest of the site has (click on "other games") There is even some fire emblem information in the q&a section.
WRT "space is cheap", it is until you hit the max rom size, at which point you run out of memory addresses, which are allocated on a hardware level. Past that point, the console is simply not equipped to handle a larger rom. For the relatively new gba, this is 32mb(which is large enough for most fire emblem related purposes). For the snes, this is 4mb, which is essentially all used for the Japanese versions of FE4 and 5 already. (you can exploit an emulator bug to go up to 8mb, but this is not recommended as newer emulators do not do this, and many tools have issues.)
Yes, for the GBA that is the max limit. My original comment was showing appreciation for getting around that limit. Thanks for the link, though.
No, the limit isn't 4MB for SNES games. The console’s two largest games, Tales of Phantasia and Star Ocean, had sizes of 6 MB. I am using the same mapper in FE4 to give us 2 more megabytes of space.
Also "Exploit"? "newer emulators don't support this?" I'm sorry but I have NO idea what you are talking about. My ROM works perfectly fine on everything but ZSNES. And ZSNES is ancient and can barely be called "accurate", so I don't really care about supporting it anyway.. Use higan or snes9x.
-
There exists another game called "Mother 3" that is also 32 MB, mainly due to the absurd level of detail(graphical and otherwise) in that game, as well as an absolute ton of unused content due to a long development cycle(including my avatar as of this posting). It is actually known to that game's community that you need to be careful about what flashcart you are using (Ironicaly, the M3 brand does not work). This is also why exactly one romhack exists(and that one reactivates unused content): there is almost no free space to use. The translation patch actually had to recode an existing part of the game specifically to free up space.
Suddenly I have even more respect for the Mother 3 team. I could only dream of one of my future translations even being *compared* to it.
And they had to figure out what was unused and swap it out, you say? Yikes... Some smart people had to be involved in that.
EDIT: FWIW I think there's nothing wrong with expanding the game ROM. Space is cheap. FE4 and probably FE5 will end up being expanded
-
The points are moot, because when my toolset is complete, you will be able to change the names by changing one reference and rerunning the tool on a Japanese ROM. Everyone can have their own FE4 translation, if they want, it doesn't matter to me. The only translation recommended by bookofholsety and I will use the NoA localization, but I do not mind if others release alterations.
I also plan on releasing a Japanese ROM that only has the original bugs fixed, and nothing more.
The toolset will go beyond that, hopefully allowing for complete ROM hacks of FE4 without too much hex editing.
Btw, progress report: I've been documenting the JTEC tool and it's pretty great. It has code that detects multiple occurrences of the same text and marks it as such! Also, tons and tons of control codes have been found and documented. I'm above 60% through with the documentation, and I expect to be done with the script docs by the end of the weekend.
Initial tests of my heuristics algorithm that detects text has shown that it definitely seems possible, though there are a few red flags right now that I need to touch up. Keep looking for those pointer tables guys!
-
Sorry to say holsety, but the others are right. Those are simply the names as-is from the j2e tool that takes the ROM and spits out the dialogue. For instance, if you notice next to Arvis is '00B1', that is how the game knows Arvis. His name is associated to him only by game code and chrnam.txt. The names are put into the script for readability reasons, who the hell wants to memorize that Arvis is character 0x00B1? :P
All the same, it's Arvis in Awakening and that's IS, so your original point stands.
(subjectively, I like Arvis better. Alvis sounds ridiculous... Alvis and the Chipmunks, anyone?)
I recently found Twilkitri's dumper and it's pretty awesome. I'm going through the source and updating the documentation now, and afterwards I'll write another dumper.
My dumper is going to be interesting in that, I think I have found a way to autodetect the pointer to pointer tables, via tracing through the ROM and recognizing combinations of bits as valid Japanese text patterns(whether EUC or Shift-JIS). This could help a lot with FE5. Also, j2e and Twilkitri's dumpers seem to make a ton of duplicate dialogue... To avoid driving translators to insanity, I'm going to remove repeat dialogue sequences by appending any unique addresses on to the original dialogue so that the injector knows to inject into more than one place.
Really, it might not even need to be reinjected. It seems a bit silly that text occurs in more than one place(and boy does it ever.. according to j2e's util anyway)
-
As someone who is very much used to Sword of Seals...
Binding Blade. It's the localization used in Brawl and it was then canonicalized in Awakening.
Sorry but that puts the nails right in the coffin.
-
According to the bits of documentation I've collected, FE5's text format and FE4's are pretty similar. I don't think it would be difficult to write a tool that covers both use cases, if you're interested in collaborating. All I need is a text file with a set of pointer tables to the dialogue, and then I can probably figure the rest out through trial and error and tinkering with my tools.
Edit: I should probably note what qualifications I have. This is my first ROM hacking project, so I'm not particularly familiar with hex editors or the tools around here..
I *have* worked on various Doom ports, video game console emulators, and helped write Doom64 EX which is a recreation of Doom64 for PC. C, C++, and Haskell(last one I'm still learning) are my tools of choice, but I also know bash, python, 6502 ASM and I'm picking up 65c816 asm decently quick.
Any help on the actual hacking side of things is greatly appreciated! Particularly, documentation or snippets of code, which work as better documentation oftentimes. I need information D:
-
Use a ROM extender tool like Lunar Extend to create the empty space you need and put your dialogue in the empty space. All you need to do then is swap out the dialogue pointers for pointers to your now free space.What about the pointers? The English is going to be longer than the Japanese so I need more space.
Also note, I'm working on a utility to dump and reinject text into FE4. If FE5s script format is similar it shouldn't be difficult to modify. It's not going to be like FEditor though, its just going to dump the dialogue in text files.
-
are you fucking serious i swear i JUST fixed that
should be fixed now (if it's not i'm reverting it because i'm too tired to deal with this)
Yep that fixed it!
-
STEALTH UPDATE
Last update worked great, now it crashes before it writes the ROM with
>>> Traceback (most recent call last): File "run.py", line 288, in <module> main(sys.argv) File "run.py", line 282, in main processCmd(state, input) File "run.py", line 270, in processCmd execCmd(state, command, *args) File "/home/cray/Fire Emblem/random/cli.py", line 123, in execCmd return COMMANDS[cmd](state, *args, **kwargs) File "/home/cray/Fire Emblem/random/cli.py", line 20, in __call__ return self._func(*args, **kwargs) File "/home/cray/Fire Emblem/random/cli.py", line 20, in __call__ return self._func(*args, **kwargs) File "run.py", line 134, in randomize state.unitdata = util.randomizeJobs(rom, ver, **opts) File "/home/cray/Fire Emblem/random/util.py", line 79, in randomizeJobs inv[index] = chooseItem(ver, rom, rank, job) File "/home/cray/Fire Emblem/random/util.py", line 90, in chooseItem itemlist.append(0xA) AttributeError: 'dict' object has no attribute 'append' -
the fix patch links are dead it seems.
I can't seem to get either of the patches, they are dead
-
<3 #HYPE
Thanks again guys! I'll post more after I've played a bit :)
-
Naga is the only god I need 8)
-
I guess I could ask, since we have a new FE5 translation anyone working on a newer FE4 translation?
Nothing yet to show though. I'll post a thread when I have some actual progress, this project was started about a week ago.
@all
What ROM version of Thracia 776 is needed for this translation patch, btw?
-
At the moment I'm using "true" randomization, but it actually wouldn't be too hard to just shuffle things (well, it would take me a bit to algorithm it out but ~oh well~)
i don't really have time to iron that out for a 0.1 release, though (0.1 will be just weapons+classes)
Sounds like I'll just have to man up then :P Thanks for the hard work.
-
Yikes. Is this because FEeditor has no ability to repoint data internal to Binding Blade, so it just swaps out the text pointers and tacks the actual text data on the end of the ROM?
I can't see any other reason why it would do that, but even still that doesn't really make sense. It could at *least* check the pointer of dialogue it is removing to see if it extends beyond the stock ROM boundaries with a list of their sizes in a text file, and if so, zero out the block of memory. It's essentially C's version of malloc, demalloc, remalloc except ROM mapping.
That doesn't even sound hard to implement. It's a shame I don't know Java(ewww.... Never understood the fascination with it >_>)
-
it's ok
with the python randomizer you'll have the wonderful chance to get screwed not only by class randomizations but also by the randomized weapons getting screwed!
have fun!
I was actually a bit disappointed that Ephraim's *didn't* tbh. I wanted a shot at a ballista-sword or something equally crazy :D
Are you using all of the current playable classes and "shuffling" those along with actual weapon hitrates/values/effects? I feel like that would work better than "true randomness".
Though either way would work with some sort of underlying tiering system in place.
... I imagine with some tuning, quite a few versions and some careful thinking there could be an *almost* fully procedurally generated FE game :D How amazing would it be to be able to generate a randomized ROM, according to a few switches?
A fan can dream :P There may be some huge limitation I'm missing...
-
I managed to get Ephraim's tool to work in Linux, works on OS X too. Don't bother with wine, use Mono with the Mono-Basic package. It will run the Event Assembler too.
With that said, I have no idea how you all are getting past the first level on Hector Hard Mode. I've generated 8 roms and I have not been able to even get to Wire. My friend tried 10 different random scenarios until Hector was a Nomad, and then he got to Wire... Aaaand both matthew and hector couldn't do ANY damage to him and he would have had to gain 5 levels, all with Str stat gains, to get hector to be able to do even one damage.
Yeah... I think I'm going to hold off until the python tools release. :P While a neat idea, this seems to be horribly broken. No rush, just make it playable please x.x
EDIT : I realize I could have not randomized hector, but where's the fun in that?
-
I completely agree.Oh my bad, I completely misunderstood.Skirmishes, now that I think about it, should be more rare, and should give out good items, while the tower and ruins are where you go to level low and high leveled characters, respectively.
Looks great, Faratras' critical is pretty epic :o
-
You should definitely be using the English version. The Japanese version will *not* work with that patch. Patches are merely changes applied to addresses in memory, so the file they are applied to must be the EXACT SAME FILE, byte by byte. In layman's terms, if the location or size of anything in the ROM is changed(which I can personally guarantee has happened here) the ROM will be corrupted.
It's pretty silly that ips patches don't have some sort of checksum verification built-in. But I digress.
If you're having issues with the North American English version too, that's something we might actually be able to help with.
VisualBoy Advance is a quite an accurate GBA emulator, and it should have no problem on a game as trivial(CPU tricks-wise) as Fire Emblem. Use the correct ROM first and if that doesn't work, go find a copy of VBA-M. It's a more up-to-date VBA.
-
Wow #HYPE! :P Looking forward to leafing through the Python code as well.
Gharnef's Improved FE4 Translation Patch
in NES and SNES Era
Posted