
| Hello and welcome to KOEI Warriors (Forum), the official leading Rank 1 forum of ZetaBoards free online service of thousands of message boards aimed at video gaming; specifically the best KOEI TECMO fan site online! With over 35,000 forum members already a part of the community and millions of comments recorded! Thank you for visiting, we hope you enjoy the message board! You're currently viewing our forum as a guest. By signing up and experiencing KOEI Warriors message board you will have access to features that are member-only such as customizing your profile, sending personal messages, voting in recognized polls, and more importantly discussion and the latest news from KOEI TECMO with fellow fans of their products. Our Members Only section via joining will grant you KOEI Warriors graphics, downloads and more. We also have social network pages on Facebook, Twitter and a videos channel on YouTube, so please find us there. If you need any help please don't hesitate to ask a member of staff/moderator. Thank you. Regards, KOEI Warriors Staff Team Join our community at KOEI Warriors (Forum)! Already a member? Welcome back, please login here and enjoy KOEI Warriors (Forum). |
| DW7PC Translation Patch; Discuss it here, not there | |
|---|---|
| Tweet Topic Started: Wed Mar 28, 2012 2:18 pm (3,095 Views) | |
| PyroBunta | Tue Aug 7, 2012 4:34 am Post #376 |
|
Soldier
![]() ![]() ![]()
|
By the way (I don't know if this is the right section but...) this is a screenshot of DW7 on my PC. As you can see, the lighting/shadows seems to be screwed up. Is there something I'm doing wrong? The second pic looks normal in the Gallery but in battle everything seems to have gone dark. Does patching the english patch affect this?![]()
|
|
|
| AhmadLight | Sun Aug 19, 2012 1:43 pm Post #377 |
|
Soldier
![]() ![]() ![]()
|
you have to install the game if the patch worked earlier time, you have to install a clean copy of the game copy the patch files to the main folder The most important thing is to run Patch.bat using right click>>>run as admin hope that works for you |
|
|
| godforpeople | Sat Oct 13, 2012 11:22 am Post #378 |
|
Soldier
![]() ![]() ![]()
|
No hope :'( |
|
|
| Mitsubasa | Wed Oct 31, 2012 5:25 pm Post #379 |
![]()
Sergeant
![]() ![]() ![]()
|
No one gonna finish patching this?
|
|
|
| bustamon | Tue Nov 13, 2012 8:41 pm Post #380 |
|
Soldier
![]() ![]() ![]()
|
English patch is still being worked on, but the people working on this need some great help. |
|
|
| Brule | Sat Dec 15, 2012 4:06 pm Post #381 |
|
Soldier
![]() ![]() ![]()
|
Sorry to bump this old thread, but, i donwloaded a patch from the internet, that probally was taken from here, but the only thing that is translated is the Main menu, and officers names, everything else is still in japonese, weapons, all in-game texts, descriptions of itens(weapons), Cutcenes, etc.... so, i wanted to ask, is that all that was translated, or there is a more recente version of the patch, or maybe is because my Windows 8, because i saw some comments at firsts pages talking about not working well in Windows 7 64 bits. and can you guys give a link to the most recente version of this patch? thanks in a advance |
|
|
| tripodsgames | Sun Feb 24, 2013 6:32 pm Post #382 |
|
Sergeant
![]() ![]() ![]()
|
I went back to do the translation, I will soon put it to download![]() Full image Text does not appear complete.
Edited by tripodsgames, Sun Feb 24, 2013 7:03 pm.
|
|
|
| AldoMC | Tue Apr 2, 2013 11:03 am Post #383 |
|
Soldier
![]() ![]() ![]()
|
Surprised by this last post ^^ |
|
|
| tripodsgames | Wed Apr 10, 2013 11:52 pm Post #384 |
|
Sergeant
![]() ![]() ![]()
|
translation in progress |
|
|
| evernessince | Sun May 5, 2013 5:20 am Post #385 |
|
Soldier
![]() ![]() ![]()
|
If you manage to pull a translation off that would be amazing! I hope everything goes well as I love playing this game but not being able to read most of the battlefield messages really puts a damper on things. Anyways Good luck and thanks for the effort! |
|
|
| Lavos | Wed Jun 26, 2013 11:44 am Post #386 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
That's what we always got stuck on tripod, and is why the project died. We had all the English text and had no problem putting it into the JP version, but there are in-built character limits somewhere so all text will be cut off. A good reverser was needed to reverse the .exe and find out where it's happening and remove it, but there isn't one. Oh, also, Chinese patchers already fixed these problems I think:
Broken English cause it's just google translate, but they seemingly managed to sort it out. So besides digging into the file formats from the start or in the .exe, you can try to figure out the file formats through the Chinese patch. A good file to look into is 4581 (4581 in the extractor, numbered 4580 in the patch) which is the chronicles menu. EDIT: On second thought, after digging around the files, they haven't fixed it after all... I've been digging around the file formats, and the DICT file works like this: Starts with 4 bytes per string table, each one is the start of the table. So 4581 begins with:
6 tables, starting at 0x18, 0xb104, 0x5382c, 0x5b968, 0x61c90 and 0x6729c. Since this file covers the whole Chronicles menu, which has 5 sub-pages, that's as it should be. The last table isn't a DICT, I have no idea what it is. The header for each table is 2x8 bytes (or maybe 1x8 bytes followed by 2x4 bytes), the first table header in 4581 is:
I don't know what the first 8 bytes are, it may even be something even weirder, like 2x2 bytes, 1x4 bytes 1x8 bytes. Because the fourth byte changes randomly and I don't know why. Second table header for example, is:
So I don't know the exact layout there or what the first half does, but the second is the length of the table. So the first table is B0EC long, and that plus the table offset will give us the location of the next table, so B0EC + 18 = B104 (the same as the file header gives as our next table). The B104 table ends at 048728 + b104 (its offset) = 05382c, and the length itself is 048728, etc. After the 16 bytes of the table header, are the locations of each string as 4 bytes. It's relative to the start of the table, so add the table offset to get the absolute position within the file. In this file, every 3 entries make up one character entry. The first 3 from the first table in 4581 are:
So that's 0920 + 18 = 938, which is the start of the layout data for that entry. Second one is the header string, third one is the text content. So it's like: http://i.imgur.com/0JdvvE4.jpg The layout affects the page visually, so which textures to load, like the map/character etc, the header is that first string marked as 2, then the content is 3rd. I only went through the second table's layout code, and got this:
That's for the b104 table which is the generals bio page (the one from the screenshot). Since each page has a different layout things change a bit, but generally the last 5x4 bytes or so are the ones that change what you load visually. All of the first 20x4 bytes I have no clue on. So that's all there is there, no in-built character limit and no data on actual text box positions or the whole frame layouts that I can see. Unless it's contained within that last table which it may be (original and CN one match so nothing I can pick up on testing really), then it's not saved in the text files. At least not in these files. There are other XL header files with no text in them, they may be responsible. The XL files with text don't seem to have a table like this anyway, so I don't think it'll be in there. They have a very similar format by the way, except it's just 1 entry per string instead of 3, there's no layout information or anything. So in the end I have no idea where the information is stored for the proper page layouts. If you make any progress, then yay. ![]() EDIT2: Still playing around trying to find any sort of layout data, this time I was looking into file 31, which has all the story text for the game. Each entry here is 8 bytes, 2x2 bytes and 1x4 bytes. First 2 bytes are the character whose portrait is shown, followed by which of their portraits. So for example, this is the first entry for Jin's story: 2000000099f40b00 2000 is the code for Sima Yi's portraits, then you can set the next 2 bytes to select different portraits of his. Each character only seems to have 5 though, if you set it to an invalid number (anything above 5000) then none load at all (but the correct name at the bottom remains - weird). 0000 - Xiahou Dun 1000 - Dian Wei 2000 - Sima Yi 0010 - Some random guy (http://i.imgur.com/BZshh7i.jpg) So after those 4 bytes, the next 4 is the string location, again relative to the table, the offset is shown at 0c - 0f from the start of the table. So, yeah, again a few configurable things but nothing to do with the text boxes themselves, or the animation played or voice sound file played. There's gotta be some big file that has all this stuff in it. I assume it's going to be set out per map/mission. It's just a pain that it's not kept with the text, randomly guessing at files without knowing how any of them work is ugh. EDIT3: Going about this differently now, I figure now it's just easier to patch in the .exe directly. I've almost found it (I think): ![]() Yeah, it's not *quite* right LOL. Seems I edited the font size rather than just the string length, but, not too far off I don't think, as soon as I find the right piece of code it may (hopefully) be ok. Little bit more progress (if it can be called that): ![]() I don't know how I broke it so badly. I don't know why it broke the frame and the textures, and I don't know why it put a texture after where it usually cuts the string. EDIT: The above method is definitely right, this function is the whole text frame box, I can corrupt textures and things around it. Still though, it seems to use offsets I can't find as to where it loads things. The string length value effectively controls the number of times it loops through the characters in the string. It's at the end of the frame loading function (0x58c3e0 in my 16MB exe). 0-28: the standard string length, any value between this is fine. String will output those characters. 29: Byte of character portrait texture 2a: Byte of texture where the name of the speaker is 2b/2c: Bytes of character name (the one who's speaking) 2d/2e/2f/30: unknown, first couple probably more character name bytes 31+: crash So depending how high you set the string, other stuff will get removed. Set it to 29, char portrait will be put into the string (and broken like the pic above) at byte 29, but everything from 2a onwards will be ok. Set it to 2a, portrait and the name texture will be broken, other stuff fine etc etc. When you get to 31 it crashes but I don't know why, likely an out of memory error? Maybe it's just overwriting other needed code bytes? So, what's needed to begin with is to offset these further so they're not broken. The string is set correctly, but then other stuff is being set back onto the bytes where the string is, it's not the string overwriting texture, so it must happen after the string processing. The problem is though, it doesn't seem to be just a simple +29 offset from the start of the string, it's going to be some stupid offset for the whole data segment which is something I don't know how to identify and is too hard for me to work out. I'm no good at reversing at all. So, I can't find it. I'm gonna give up now. ![]() EDITX: Going through some of the text box code just trying to see what does what. First part controls the left side texture. 58c426 and 58c42b control the x and y of the texture for instance. You can move it around like: http://i.imgur.com/XiRzFyH.jpg First function call to 5886f0. Seems to further affect the above texture, including the offsets for where the texture is. So you can modify that again like http://i.imgur.com/6b6xvmL.jpg by changing the offset values. This function is called a lot, every few frames, even with no text box, so it must control more than just that. After that there's another small texture that you define: http://i.imgur.com/nanQdlw.jpg with lots to change. Second function call is the same as before, but takes this texture as its offset. keeps going still with that texture after the call. 58c5fe seems to be the texture to load. At 58c6d8 it goes into the texture where the text is, again same values editable, position and all that jazz: http://i.imgur.com/mvPk2Xp.jpg also the texture: http://i.imgur.com/VINzLLO.jpg and call the same function which runs every few frames like the others. 58c964 gets into the text box of the name. Right after that is the texture that's behind the name. Frame function called again. Bit more name texture stuff after it too. Function calling starting from 58ca82 is the name itself. 58ca82 is the x value, 58ca83 the y. Can put his name right over his stupid mouth. http://i.imgur.com/heXZFQ5.jpg lol >:D The float at 58ca88 is the scaling, you can scale it up: http://i.imgur.com/5W5BeSc.jpg From 58caaa it takes in the pointer for which string to load for the name. This function loops through the string byte by byte, firstly checking for specific bytes it sues as control codes, 0a for a newline, 1c sets the colour and removes it etc, like for character names, blue for allies, red for enemies. After that, it has stuff for setting the location of where the next character goes, which is weird. I mean like this: http://i.imgur.com/2jdHm9Q.jpg I can set the second character on top of the T there. All this function does as far as I see is actually get the string to process, it's strange that that's in there. It loops through characters in the file until it finds byte 00, which is the string separator of course. Back to the character name string, you can again move the character positions as it loops through each character (it takes in 2 bytes if it's sjis and still runs per "character" as displayed). After that I'm not sure what the next function does, although I changed 1 value and the camera in the game went mental, screen went black, string corrupted and the volume of the dialogue sort of doubled. Odd. So skipping that down to 58caea we start editing the text string itself. 58cafd controls the x: http://i.imgur.com/8uYnRrs.jpg Just below that is the y. Starting the with the function args it takes the x/y, then 58cb48 is the size of the string: http://i.imgur.com/MAqYurg.jpg Something strange then goes on, I can make the string like http://i.imgur.com/QswCaEq.jpg and I don't know what that is. Second half of this function controls spacing between words: http://i.imgur.com/l7Kl43G.jpg So I suppose it does what it did earlier, but only for the space character. Just after that function at 58cb62 we control the newline, how far down it is from the first, then start adding variables for our string. arg5 = 0, arg4 = 1, arg3 = 28 (the all-important character length (40 in dec)), arg2 = string pointer, arg1 = some other pointer to something. Not much to say about that, after the string everything isn't visible so I can't easily see what it does. This is where I get stuck, but after going through the frame loading I can be sure it's not in there. So going backwards before the frame loading, just before that function is called we have EAX set to which frame we actually want to load. By just changing this up/down by 4 bytes you can get different text boxes: http://i.imgur.com/GgBAUwe.jpg Here's the very first string in the game (0000): http://i.imgur.com/dm18vee.jpg Note that it loads the correct voice and everything along with the text. You can see his cut off name there, as the name function is limited to 5 bytes. Extending that gives the exact same errors as extending the string itself does, just fyi. Just after that as we're calling the frame-load function, we have a few args to play with. First we can move the frame itself at 564b51 (along x): http://i.imgur.com/zNraAYT.jpg as well as y just before the call. It also passes the text pointer and name pointer ofc. EDITX2: I believe I've now found why it's broken, but attempting to fix it is kinda impossible again, because there's just so many damn offsets, and the function that reads the string through loads every few frames with all the frame data, which really is the problem. The offset needs to be fixed before all this goes through which isn't easy as memory changes on every load. Just so much to trace. Anyway, there are layouts made for the whole frame data, including the string, the textures, the voice clips, the sounds, like literally everything. The reason why it errors is because there are only 40 "blocks" of this data available where it saves all the string information, so as soon as you set it to 41, the very next field it overwrites is already populated (which in this case happens to be the portrait texture data). That's why the string reads it in, and the portrait disappears, likewise as you go up. What's ultimately needed is to add more of these fields, and to set the original pointer of the portrait texture (and hopefully that should offset everything below block 41 as well) down loads more bytes. If we have more data fields available to write our string into, it won't break other stuff, and should work out. The difficulty is just finding the origins of these things though they're offset 9 quadrillion times and then done so through every single frame as well. If anyone wants to play with it, then just follow EBX when it's passed into the function that loops the string (58cb62) and it's argument 1. Changes per load, but that's fine, it's essentially the layout and read we need to change, the write is fine as-is. Hell of a lot of tracing to do, but having found what I think is the real problem, it's definitely heartening. Next 2 ports of call are: 1. Find the frame data generation function and have it output more fields. 2. Find where portrait texture is written and update it to start writing further down to match our increased number of fields (characters). Pretty much these alone would solve the problems for story text (I think and hope). Note that there are so many string declarations, and this only applies to story text. Menu strings, name strings, load screen strings etc will all have to be done afterwards. method should be largely the same though, so once that's done for the story text it should be easier to figure out and fix for the rest. I'm hoping (sort of) that they use this format for DW8 if it comes to PC as well. With all this experience of how it now works, patching that should be easier, and can be sorted out when it's not just me alone by myself rambling like a mentalist to no one. Ok so the generator function (for story) is at 563f40. Has 3 main calls which populate stuff. Each "block" is pretty much the same: 80 75 A1 00 00 00 30 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The only value that changes here is the 8th byte, goes between 00, 40, 80 and c0. The pattern seems random, no idea what this is. In the function we first loop a bunch of times, arg1 is start position, arg2 is block length (all the below are 38 (56 dec)), arg3 is loop count, arg4 and 5 are pointers to other functions, not sure what they are. Maybe the functions to get the layout information: 1st call: 4 times, not sure what this is. 2nd call: 28 times, this is where our string goes. 3rd call: 1 time, this must be portrait since that's what breaks when we loop once more in the string. 4th call: 1 time, name texture. This is what breaks at 42 string loops. 5th call: 5 times, this is where the speaker's name goes. 6th call: 1 time, this is likely the "next page" arrow texture as that breaks last before the offset problems. There's possibly more calls and layout before this (header stuff?), buuuut. Going to try extending our string layout, the offset should carry over. Right after that function we have another call which lays out 2 blocks of 1c length fields. No idea what this is. This might be animation/sound played. No idea. This is likely why it gets offset problems above 31, the layout information of the above is a lot different so that would throw everything off. Extending the string there unfortunately doesn't work by itself, changed it to 29, along with string loops. However, instead of showing the broken frame like normal, offsets went out just after the string data. All these offsets are hardcoded in read and write it seems. It offsets from the start of what I assume to be the frame data. So, need to find the hardcoded offset for the read as well. Bit of progress: ![]() Trying to update offsets, but there are so many it's difficult. But as you can see, now with our string at 29, I've fixed the portrait disappearing (the scaling is off a bit, dunno how that happened - but it's there), that's the important thing. String is still broken though so just as I suspect, there's going to be more offsets needing editing. BIG EDIT: ![]() I ****ing did it! Yaaaaaaaaaaaaay! After editing all those goddamn offsets, hundreds of 'em over so many functions. Now, there are a couple problems remaining: 1. Voice is lost, so there's some more offsets somewhere for voice, or I updated them incorrectly, not sure which. Need to find that. 2. The arrow texture on the right there is missing, so that has un-updated offsets as well. But for the string itself, the limit is goddamn broken yo! I only updated the fields to add 1 extra for a 41st character, now obviously that isn't sufficient, I'll need to go back and re-update everything to up it to about 120, which I think should be ok. So after I find and fix those 2 problems, I'll have to go through everything all over again and fix the offsets once more, story text will be translatable without getting cut off. I could give out the exe if anyone's actually wanting to get the Eng files from PS3 and fix them up and import them into the game to help. After that though, I'll have to do the same thing with all the other string types in the game, menu text, loading screen text etc etc all use completely different functions, so each one will have to be reversed and changed as well. Phew, I'm pretty happy right now. EDITXYZ: After losing edits and trying to fix everything etc etc, it's still not perfect but ehhhhh, this is as close as I can get right now: ![]() So right now everything is right apart from the next page arrow there. Its offsets must be wrong, but there's no side effects right now, it all works fine over multiple talks (different functions are called for first talk and subsequent talks). Voice is all fine now, I edited too many offsets first time, so I know the 0bx ones relate to those now, which makes it more likely that they are the voice/animation. For setting a 41st character editing those aren't needed, but I'm kinda dreading a bit that they *will be* needed to be edited when I set something higher than 41. Bleh, higher you go, more difficult this gets due it breaking more things and by a much bigger amount each time so it's easier to hit an error. I'll have to figure this arrow problem out before I go upping it any more. Really need to nail down all offsets and make them all perfect before I move on, cause even though it has no effect on the game now, it will do when it's a billion bytes away instead of just 56. To try and find this I need to manually edit memory and narrow it down, so just noting it down: 8075a1 headers: 1st block: left texture 2nd block: middle texture 3rd block: texture behind the text 4th block: right texture 5th - 46th: string After string: 1st block: portrait 2nd block: name texture 3rd/4th/5th/6th/7th block: name Here I hit the data that changes every frame, hmmm. It matches up with the layout data, but that leaves me kinda stumped as to where the arrow texture is. Grrr. Oh wait, no, the arrow texture should be the data that changes, because it has an animation. Right, makes sense. Need to find the offsets. EDITZ: Yeah ok this is really crappy. The code after the arrow function is really damn difficult to offset. I've got everything before it all working and set, but if I increase the string length as I have been, then more blocks will just get constantly cut up by this function which is updating every frame, right now it's updating over the arrow texture block, that's why it's broken. But I can't figure out how to move it properly, it has a ****tonne more offsets and coding than everything else, and I can't get it moved and working. God damnit. This whole thing would be so much easier if everything wasn't loaded per frame, and I could just rip out the string part to free memory and make it as big as I want, but no, it takes everything as one massive chunk. Even putting aside the updating function, there's a hell of a lot more code which is added after all of that too. I'm back to losing faith again, because of the sheer amount of work needed here, and because it's as simple as changing 1 number in their source code. EDITYY: Well I've gone for an entirely different tack now, and instead of trying to mess with a billion offsets that I can't find, I write all the string fields into empty memory, and I've written my own function from scratch to handle writing the frame data. It's pretty much complete right now (for story text, again they're all different). I've finally gotten the game into a state where it doesn't crash, and I'm loading 120 characters right now. However, the frame doesn't actually display at all right now. There are offsets being set relative to where I've moved the string data, so they're essentially reading beyond the string and into empty data. So yeah, it is back to offset editing, however, it's all relegated to my own function. What goes in and comes out is set correctly, so I no longer have to go for x amount of time over loads of completely different functions. I've entirely narrowed it down to the single call my function makes. That call splits into many others along the way, but I have a definite start and end point, so I know exactly where I have to trace through, and that really helps. So, huge progress made today I feel. All of the difficult work should be pretty much done (I really hope <.<), and it's just grunt work left. I'll keep going with this, but if this method turns out to not work, or I hit something somewhere that makes it a lot more difficult than offsets, like lots more coding is needed, then I'm just going to give up. EDITZZ: ![]() Again, a bit more progress. Using my function, I can now load the string correctly (first time ever) as you can see. The other stuff is broken, and it crashes directly after displaying the string (which happens instantly, not faded in), but I think I may know why that is. But phew, finally, a correctly-loaded string. EDITZY: Fixed the crash and read-in problem, now the string all fades in as it should. Still the other textures and stuff on the frame aren't showing up, more offsets to find. Getting closer though. ![]() Ok it appears there's yet another internal write limit for each frame. Changing nothing but the amount of fields I add, while keeping all of my modified functions and code in, and keeping the string in empty memory etc, it loads the frame fine. So, the final piece of this puzzle is another arbitrary limit somewhere. But I can't see where it writes to memory which could be it. All the data fields still get read and written every frame, so what the balls is going on. EDIT: RIGHT! I *think* I've found the issue. It requires more coding, so I just have to figure out how to make this all work. Oh man, I'm so close I can feel it! Hmmm, more difficult than I first thought, but I think this does control a lot. ![]() I can get it to this point for a split second, but it basically just crashes instantly. Here's the state I'm at when I fix it to not crash: ![]() Just managed to find the name and fix those offsets. There's gotta be more. Hmmm. Not sure if this is better or worse lol: ![]() Think this is progress: ![]() Had to re-write 2 of my functions, since I found the first one wasn't doing what it really should, as it looped over the whole frame I think it was reading empty data, and that's why the textures weren't showing. I *think* I fixed that as per the screenshot above, but as you can see the arrow doesn't load (I'm not going to sweat over that), but also the texture is faded and the string isn't complete. I still have 2 functions where I just indiscriminately add the offset to get to my string, I think I might have to re-write those as well to manage the offset. Although I did check them before and found they didn't go before the string start or beyond the string end. Ah, the arrow is there. It loads at the start with the texture, it's just really faded and sits behind the text box. How did I manage to move it behind the text box... The textures are actually fine, if I just move it out the way you can see: ![]() Bytes 24 - 27 control RGBA, so you can just set the 27th byte to 00. By default they're all set to FF, never seen it differ from that, but you can play with the colours. Found something interesting doing this as well, here: ![]() You need to look at the image and squint. I set it to the best colours I could to show it off. Black background with full white (ffffff) text. With the normal white background and black text, you can't see it. You can just about make out the following characters after "n" from the screenshot before. You can see "ew" and then "123" at the end of the line. So, the string is there! It's fully loaded and all good. But, wtf. It won't show up, as you can see the image before, it gets stuck at the N, and the rest won't show up, but you can see there that is actually loaded and it's there. For some reason though it's like, set to almost invisible, even though the opacity is at the maximum FF. This is really strange. It's no doubt tied into the text box being at the front of the frame for whatever reason. So without messing with the colours myself, I can see that after the n, the colour of the remaining text changes to all black. This is very weird, I suppose I'll have to trace the function and see if I can find out what's going wrong when it loads "n." Hmm, it does seem like an offset problem. Right now I'm thinking it uses an offset relative to the position of the data block. So for example, everything up to where it crashed before will work (to 30 (hex)), but then after that, it's going beyond where it can find things. So like, if the original is at c6c494, and it does +b0c (as an example), then it finds what it wants, so if the last char is at c6d494 it gets the last block at +bc0, but now I increase the loop length for my string and I go to c6d4cc, when it does its +bc0, all of a sudden it's looking in memory it didn't expect, which is either empty or has data for something else. So what I figure I'll need is to get to the original last point, then do some kind of reverse counter minusing 38*loops done. Or, if it is doing it like this anyway, then it should have specific blocks that it's writing/reading to somewhere else, so ideally I'd have to expend those as well, but bloody hell that would break even more crap. So, when pausing on the first frame after it loads the text frame you can see: ![]() Lo and behold, the missing part of our string is there, but then as the box fades in it basically disappears. So again that brings me back to this weird "text box texture is loading in front of everything else and it shouldn't" problem. Ok, so it's nothing to really do with texture layering, it seems that the character just invert opacity with the texture. So as the texture gets closer to FF, the characters get closer to 00. BUT, they don't actually change in memory at all. By lowering the central texture opacity I can get them to show up. God damnit, how can that even happen. <.< That's what's happening with the other textures too btw, as the texture they share space with increases opacity, they lose opacity. Maybe that does make it a layering issue, I don't know. maybe something to do with load order as to which is increased/decrease. So, yeah. It seems to be considering part of the text as texture. I can mess with the texture, and it messes with just the part of text that doesn't show up right, like: ![]() Notice how the only text affected is the broken stuff that disappears. All the rest of the text is never changed, but modifying only the texture behind the text, affects that section of text. So, for some specific reason, the game is taking in the data fields beyond 30 as texture fields. So I suppose I have to go tracing around for "30." -------------------------- Hugest edit: -------------------------- ![]() Did it at last! God damn, been working on this for so long. Having done almost no work in asm before and very limit coding experience, I traced through so much code, figured out how a lot of it works, and even wrote my own functions from scratch to handle the code and make these changes work, and there we are. Done it. Broken the string limit and made it work. A proper English translation is now in the realms of possible, this is definitely more than just a proof of concept. Maybe I'll be able to get some help with it too, in the 14 years time when someone reads this thread. As stated before, this currently only makes this type of text work, the text in cities. It doesn't apply to names, menu text, load text or text in battles. Those functions will have to be re-written as well. But now that I have (I think) a good idea of how things are laid out and how it runs, hopefully it'll be much faster to get them working. I'm hoping the coding isn't as complicated as this is, or... yeah... The battle messages might be, bleh. >.< EDIT Seven thousand one hundred and fifty three: So the next step was to get the name working, since it shares the same function, and then I'd be done with this whole frame. ![]() So there we go. The names were limited to 5 characters as I said before (in case you missed it, and I don't blame you if you did), I've upped it to a huge 32, and the highest I counted was 14, so it's more than enough. Story text frame, completely finished. Think I'll move onto menu text now. It's going to be such a huge pain this one. I foresee a lot, *lot* more work needed than this. -.- EDIT: Yep, found the function, and it's absolutely mental. God damnit. Argghh. It does so much crazy stuff, the area for this is huge, not like the story dialogue. From what I see, at the top it lays out a LOT of texture info. The page itself, followed by big select box layout. This includes select box textures itself, and the string it's currently selected. Below that there's more textures, then finally it has the strings themselves. Same layout as before, in that it's 38 bytes per data field, all the same variables. But it goes 6*38 for char string, followed by 38*0c for the katakana name. I don't need to mess with the second field, as the patch should just blank the string anyway. Now, I'm not sure if the select box copies data from this area, or loads all of it all over again, I'll leave select box for now and just work on normal strings. It does the same per-frame function as well, so it's running over my already-modified function. I'm going to have to make such ridiculously long check jump chains for all of these things, ugh. This won't be fun. T.T More revisions: So firstly I hit a bug with my story function, the portrait wasn't showing up on first talk, but it was always there on second talk onwards. I tried fixing it but I couldn't. There's too many offsets around to do with textures and stuff to get it all working, so I went back to the idea of needing of jump chaining, and I really don't like logic mazes at all. That's why I just took the whole block. So basically each function is like this: |header|texture----------------|text-----------------------------------------------------------|texture-----| |text------------|texture--|text----------|texture-----|otherstuff| That's just an example, every frame has a different layout, as the pages are laid out differently. So essentially, to avoid annoying mass conditionals in looking for *just* the text and jumping back and forward, what I did was just take from the start of the first text block to the end of the last text block, and everything in between. That way, I only had ever do 2 check. "Are we at the start of the text?" and add an offset, and then "Are we at the end of my offset text block?" and minus the offset to get back to the original. Simple(r). For the story frame, it has the string, then 2 blocks of texture data for portrait and name texture, then the name itself. So I was taking the 2 blocks of texture data with me. That broke offsets. I tried fixing as many as I could but could never get them all. So that's why I did that, but since it doesn't work properly, I've gone back to figuring out logic mazes to jump back/forward and I only move text. It's easier in the sense that I won't break other code that's really difficult to find, but it's also harder to actually code because there's so much logic you have to think through to get what you need. Anyway I figured out a new way of doing it, and it works pretty well. My story function now looks like this: http://i.imgur.com/JHAB9Ys.jpg and I'm pretty happy with it. All the jumping conditionals are at the top, difficult to sort out. This layout I should be able to copy to the other functions, so that's at least good. However, it does have its downside. I have to have 2*text data as jumping conditions for the start/end, and also a block of code that sets it all back to look for the next text data block for each one. So it's 3 blocks of code total per text string, essentially. It's not huge for something like the story function which only has 2 string, the line being said, and the name of the speaker. But, in the gallery for example... There's like, hundreds. The name of every character just for a start off, I have to add every character *3 blocks of code, that's going to get completely ridiculous very fast. Second thing though, I moved onto trying to sort out in-battle messages, but hit a bunch of bugs. Firstly as it calls the same per-frame function as everything close, I've had to compartmentalise my code. I now have a unique identifier to know where the function is called from, and then I just jump over to my various blocks of code. So I can essentially opt-in what I'm trying to code and not break everything else, instead of trying to opt-out everything apart from what I'm trying to code which is how I had it before (not realising that the same function is called for more than just story) and it would have never worked. So, this change helps a lot. Secondly, names in in-battle text can't contain ASCII characters. It automatically tries to take in 2 characters, as opposed to usually in other text where it runs through a function which checks. So all ASCII characters becomes starred, as they don't correspond to valid locations in the font bitmap. I'm not going to try to patch this function, because a, I can't find it, and b, it makes no difference in the end. So what I've done to fix this, is just up the character count. Where before I had it at 32, which was way more than enough for ASCII, I've put it up to 52, so that's 52 with 2 bytes per character, so 28 characters. Simple easy fix that doesn't involve me screwing with more, and difficult, code. So that's the state I'm at right now. I don't have any updates I can show visually, new pages that have been fixed yet or anything, but huge improvements have been made in response to the bugs and just, new information that I ran into. I have found an interesting thing about names though straight away: ![]() His name should be a continuous string. Every 4 characters it's breaking things as you see. Not sure what that's about, I'm just starting on fixing the battle frames. Going to work on the actual text before I try to find the overhead names though. Just noting this down for myself before I lose it. header/28 string/9 unknown empty/3 frame texture/1 portrait/4 name. 1st loop string c4d2878, name c4d3414. 2nd loop string c4d3548, name c4d40e4. Distance b9c Hmmm. The 4 characters of the name are hardcoded. It's not a loop that takes in a loop count like normal. That makes this quite annoying, ugh. EDIT: Almost got battle messages working: ![]() Hit an odd error right now though, need to figure out what's making it go wrong. The game does weird jumps that it shouldn't do. I can fix fix it manually, but since this runs every frame I can't fix it forever lol. A wrong value is being set, need to find it. EDIT: Yeah, I can't fix this. Game is breaking itself over and over, and I can't figure out how to get it to work, so I really want to give up now. It's taken too much of my time, and because there's many hundreds of screens, fixing all this just isn't viable. The first message shows up fine, but beyond that everything's broken: ![]() Finally got it to a point where it doesn't crash at least. That makes testing easier. EDIT -1^2-1: Ok, I think I know what the problem is. Every frame it generates essentially an "end" point for the string, which is looped to until it matches. The end point is based off the character length of the string, and I'm getting mis-matches between my strings and the layout. The default layout is 28 blocks for the string, then it goes into other data afterwards. The string data starts at 0cxx2878, and ends at 28*38 = 8c0 bytes from that point, which then has other data, which in this case is texture data. Soooo, any string length up to 28 will be fine, because whatever number you have it'll set the end point before the end of the string layout and jump out of the loop with no problem. But when I set my string up to 78, now it's saying read until 78*38 = 1A40 bytes from the start of the string. That makes it set the end location way beyond the original string, 2878+8c0=3138, which is where texture data starts, but when I have 78 it's set at 2878+1a40=42B8, so it reads way too far, and requires the loop to read into all kinds of texture data and other strings even, per character, before it hits that location to jump out. Now, in this function they actually made it really annoying, they added in a blank dword randomly after one of the blocks which is never even used. This breaks the reading because it's empty when it requires the value that it uses as a function call (a17580), so that's where I was always hitting an error, because it hits this blank value which broke all the offsetting. Before I figured out how it actually worked I was just doing a direct check on the location that was being read, and basically said "If we're at the blank dword, add 4 to the current offset" so I'd skip over it and stop the crashing. Buuut, that was what caused half the visual errors in the pic above, as it was basically reading loads of extra data beyond the end of the string still. So like, it was loading a bunch of textures when it was only supposed to be loading one character, then loading the textures again later, probably in a different location after they had been updated. That was half the problem, and now the string itself was the other, like you can see strings overlaid on strings. This is because it works based off the string length itself. So, if I had a first string that was 78 characters long, that displays fine as it's the first one. But then, if the next string is only 28 characters, only 28 blocks of data are written out of our possible 78, and the rest aren't blanked out or anything. So it ended up reading the 28 characters of the new string which had been updated, but then also the remaining 50 characters were read in as well which were still our old string. So anything that wasn't updated was still there, because the memory isn't wiped, because it only writes exactly the characters of each string, instead of writing all 78 each time and filling unused blocks with blank stuff, which is how other frames work. So yeah. I haven't fixed this yet, need to figure out a good way to make it work, because I can't just directly say "jump out of loop if we're at this value" because all my offsets are different. Still though, this function really annoyed me, I couldn't figure out why it was erroring at that blank dword every time, or why that specific offset was being set for the check to jump out of the loop. I think my approach will need to be something like, save the string length where it generates the offset to end at, add that to my fixed offsets, then I'll need to use another bit of code which works out how much is needed to reset back to the right point. But then, I have to patch the offset that it generated as well? Hmm. After I fix this I still have to move onto stupid name lengths, and I have no idea how I'm going to do that because it's all hardcoded and there's no loop. I'm going to have to make my own, but I really don't know where to start with it. Another week of my life into figuring out that one. I don't know if I should try to turn it into ASCII or not, that's going to be even more difficult, and I think I can just make it look the same in the bitmap anyway. But then, I don't know if I can even edit the bitmap properly. The offsets that determine where a character is placed are generated in different functions, it might just be set to add x spacing for jis character and y spacing for ascii character, in which case editing the bitmap won't help anyway, and nor will changing one function, because every single page will have to be changed. EDIT: Yep, the above fix worked: ![]() Now I correctly only read the exact length of the string, instead of all 78 characters (and the extra texture data). Fixed it in just a few lines compared to the hacky code I had before to make it work. So, battle messages, broken the length there. I should also say that the textures on Xiahou Yuan are broken somehow: ![]() He found a great new way to ride his horse. That's actually how he rides it, he's not mid-jumping off or anything. No other character is broken at all. I really don't know how that's happened. It started happening a while ago, but now my code is really unobtrusive and doesn't touch anything other than text, so I don't know why it's broken... This may be something I can't actually fix. It's going to be related to this error no doubt: http://i.imgur.com/PLD0z98.jpg If I exit the map and try to load another then I get this error. I somehow accidentally made a hero invisible now: http://img541.imageshack.us/img541/3382/gqix.jpg You can see him on the minimap, and Xiahou Yuan still tries to hit him. The invisible hero doesn't hit me and I don't take any damage. Yuan can't kill him either, and nor can I, lol. I wonder if I'd have an invincible hero if I did it to the player. EDIT: Ok, Xiahou is back to normal. The problem, as usual, came down to me being a ****ing moron. I took a blowtorch to my face a lil bit and fixed the problem (it was the same problem that caused the crash on reloads, that's fixed too). So now, battle messages really are finished. The length is broken, and each subsequent message displays as it should. So there, that's done now. I'm going to try look at names now. Firstly, they have to be longer, they're hardcoded to 4 characters, so that's not good. And secondly, I'll try to turn them into ascii if I can, but that's going to be a lot more difficult. EDIT: Yeah, editing names isn't going to happen, sorry. it seems every character name is generated at startup into bitmap locations, which makes it very difficult to find the function that writes it to begin with. But also, each part only has 8 bytes for it (each character is 2 bytes, representing x and y in the bitmap I assume). I don't think there's enough free memory to re-write every character name from 8 bytes to 40 or more. But even if there is, I can't find the function, many other functions will rely on it, and it still doesn't solve the problem of it being SJIS, which I don't think I'll be able to solve. So as it stands now, I think I'll have to leave names as they are, so they're all be just asterisks. Sorry. Yeah, these numbers seem to line up. Looking at the memory and font bitmap, first character for my Xiahou Yuan name is at b4 in memory, and the next character i is at bf, and yes that matches up with the fontmap in terms of decimal numbers. So it doesn't seem to be absolute positions or anything in memory, but there's something which sets absolute positions in a function somewhere that knows the difference. If I just replace the characters in the bitmap then it just loads like half of 2 characters, which is where the character would be. Interestingly though, when I set the string to ascii, it sets the character to 5500, which is going to be the code for the asterisk. This is why the overhead names are broken. It uses this data here. It loads the correct number of characters that I set as the name in the string file (so Xiahou Yuan is 11 characters, so it tries to read 11*2 bytes), and it seems to write out the whole thing, but then after that the next names are written back over it. So I imagine the function is set like, read string, process and write each character, set index+8, loop until finished. So it writes the 11 characters of my string, but then overwrites it, visually like: xxxx123: Xiahou Yuan Then index +8 (to our xxxx123) So at xxxx12b it's: ou Yuan and then it overwrites that with maybe a 2 character string for the next name, so the whole thing becomes: xxxx123: Xiahアダ Yuan Then it moves on 4 bytes and breaks it again etc etc. This must be why it broke a few characters in my earlier screenshot. But in that one, it only broke every 4 characters, so hmm I dunno, seems to be a weird combination of inserting and replacing data. Unless it only uses what I have here as a base and writes it out to memory elsewhere where it does leave gaps. Interesting. But still, finding this function that writes this is sort of impossible, I'm not sure how to find something before it becomes accessible in memory, or even right as it becomes accessible. EDIT: My post is now too long, so moving onto the next one. Edited by Lavos, Sun Jul 14, 2013 8:13 pm.
|
|
|
| elgaladwen | Mon Jul 8, 2013 5:38 pm Post #387 |
![]()
Lady of Leaves and Starlight
![]() ![]() ![]() ![]()
|
Very impressive work. Good luck with the rest of it, if you decide to continue! |
|
|
| Sera | Tue Jul 9, 2013 1:21 pm Post #388 |
![]()
Legend
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
It seems your hard work is bearing fruit, good job! |
|
|
| Lavos | Sun Jul 14, 2013 8:13 pm Post #389 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
~Following on from the end of my last post~ You can see the result of editing the bitmap here while doing a "PAUSE": http://i.imgur.com/bIjhkIn.jpg Each SJIS character takes up twice the space as ascii characters do in the bitmap, so all I did was replace M-Z of SJIS with A-Z of ascii. And you can see what it does there. EF are the 5th and 6th characters obviously, but with 2 times the space taken, they're in the position of the 3rd character of SJIS. Since I'm replacing M-Z, M+3 is P, so you see it displays that as the first character of PAUSE, A and E, the larger characters there, are obviously below M, so they're unchanged. And the others work out in the same way. For some reason it just seems that the ascii characters are out of range or something of the bitmap. This problem isn't just about reading in 2 characters instead of 1 (but that is also an issue), it's that it's writing out 5500 for every ascii character, i.e invalid. There are too many and too difficult steps to fixing this problem, because of the way they coded. So, honestly I'm going to have to lay this problem to rest and just move on. If anyone wants to try fixing it, look towards the function at 00511B30, and the instruction at 00511B8D directly points to the memory location of the first character of the name, so you can try and follow things from there. EDIT: Well I moved onto trying to fix the menu for weapons. ![]() Not quite working as expected yet. Weirdly, the bottom one is working just fine as you can see, while every single other one is broken. What's also interesting is that if I remove the bottom seal, then the text for the 4th seal shows up (which is the new last seal). A70 per seal? It seems to work based on the positions available. There's 9 seals on the list that you scroll through, so there's 9*a70 bytes for each seal. There's 25 for textures, then 0a for the seal name. Figuring out the length there enabled me to find where it writes the layout at startup, but it writes it as the big a70 block, I can't move the whole thing because it'll move all the textures and that's just more trouble than it's worth. Looking at conquest mode now: DA 08 DF 01 00 00 64 00 1E 00 02 00 00 00 00 00 00 00 00 00 0C 00 F2 00 00 00 00 00 F4 01 01 00 10 89 00 00 0F 89 00 00 00 00 00 00 00 00 01 Entries per hex. 2f bytes each mission. Only part worth paying attention to is the dwords at 0x20 and 0x24 which hold the mission name and mission description string locations EDIT: Ok so I wrote a script just reverse the endianness of the English Xbox files, so I can get them into the game, and here: ![]() I'm glad to say that at least works. However, as you can also see, the English version has no newlines, and relies on automatic text wrapping. That makes this whole thing a hell of a lot more annoying, as it means I'll have to insert newlines myself into the strings, and then update all the offsets as well. Bleh. EDIT: Ok re-wrote the script to add in newlines: ![]() It's looking pretty good I reckon. Ignore the cut-off text, I just haven't patched that yet. But getting this into ascii helps with that. EDIT: Right, patched the lengths: ![]() I already knew the text would end up overflowing. The original plan was to reduce font size when I changed the font. But honestly I don't think that would add enough space to completely fit in the string anyway, having slightly smaller text. I don't want to make the text too small. I also don't want to get into stretching textures. In addition to that though, it'd take more annoying code work to find how it sets the text offsets and patch that, which I don't really look forward to. Personally I'd rather just leave it because it's easier. It shouldn't annoy people too much I hope. ![]() This goes off pretty bad, ehhhh. Phew. I actually thought there were more innate problems, but it just turns out that the CN import tool is dumb, and for some reason instead of updating the zipped/unzipped size longs in the index with the size of your file, it instead just cuts your file to the same length as the original. WHY. It's ****ing appending it to the end of the archive, there's no size restriction. So dumb. Forcing me to fix more things manually, ugh. EDIT: Ok, patched up another text file from Eng, all the story and battle-type text: ![]() ![]() So that's all done. Since I already patched the battle message length, so those are ok. ![]() Again, not all lines are perfect, like that. Since the texture doesn't get any bigger than that, but, you'll just have to deal with that. Both battle messages and story text broke themselves, so I've pretty much just spent all of today re-writing them to fix it. I don't know what happened to battle messages, maybe I wrote over its code by accident once. And I have no idea how story text broke itself. I noticed it crashed the game ages ago but couldn't be bothered fixing it. Don't know where that went wrong when I didn't touch it, oh well. ![]() Working now though. Text overflows in some of these boxes again obviously. A combination of my automatic newlines (The boxes can only really support 2 lines of text) and the biggish font size. The game is really crashy right now though. After 1 battle it pretty much just crashes if you try to look at or do certain things. I don't really know why yet, but I have a feeling it may be due to not moving the edited text far enough away. I add 01000000 generally, but I think that might not be far enough, and other data is both overwriting the string, and my strings overwriting it, leading to crashes. I think I'll need to try moving them all further away. That's what I did with the story text at least while fixing it just now. I did only move it to 03000000 instead, but it seems to be fine there. I don't know if I'll really have to go crazy and move it like 20000000, I hope not. It also randomly crashes in some battles too, again don't know why. Runs fine the whole time then bam 5 minutes in, random crash. EDIT: Yeah, it looks like conquest text is being over-written at least. After completing any battle and then trying to select a hex which has more than 1 mission in it (i.e it has to load text), or a city, le crash. I'll try moving it further away. EDIT: Yep, that fixed it, no more crashes. Can play consecutive battles and it doesn't just break. I'll remember that from now on, and set my offsets a lot further up. So, just a couple more things to fix and conquest mode will be completely done in terms of exe patching. When just going over hexes, the descriptions/name there are written differently, so I need to patch those as well. After that I guess I have to go back to seals, which I just don't want to do, that's why I went onto conquest mode instead lol. EDIT: Found another crash, legend mode text. It makes absolutely NO sense at all this. It's the exact same piece of code, it works perfectly for actual story mode text (talking to people in camps), but for some reason it crashes legend mode. It makes no sense at all. It's the exact same code, I've gone through it so many times and everything is right. I don't know why it's wrong. At all. So, ultimately a crash obviously takes precedence over a text effect, so I've had to remove the fade-in text effect on text. Sucks, but really doesn't effect much. I'm sure most people wouldn't have even realised it. EDIT: Finally figured out what was wrong with chrrox's texture extraction script with ARGB32 files. The channels are all wrong. Had to swap red and green, and blue and alpha channels, and then it's right. So I can start doing texture replacements. I know they already did it in the old patch, but I'm trying to replace them with originals and not just create my own. Headhorr replaced the textures with the originals, and managed to properly merge file 31, two big time sink problems that would speed this all up. Sucks he's not around and never shared his files. >.< Especially file 31, I don't know how we merged that properly... The files are crazily different. Finally got my hands on XL, now these are so much closer, phew. 31EngXbox: num strings in table 0: 120 num strings in table 1: 30 num strings in table 2: 64 num strings in table 3: 110 num strings in table 4: 700 num strings in table 5: 5848 31EngXL: num strings in table 0: 121 num strings in table 1: 30 num strings in table 2: 72 num strings in table 3: 150 num strings in table 4: 1094 num strings in table 5: 7175 31JP: num strings in table 0: 120 num strings in table 1: 60 num strings in table 2: 72 num strings in table 3: 150 num strings in table 4: 1344 num strings in table 5: 7175 1 random added string in the first table for some reason in XL, that's weird. EDIT: Ok, I think I've pretty much done it finally, only missing one string now, so basically it's loading one string above what it should. Which is currently causing all kinds of hilarious mix-ups: ![]() Nope, nevermind, more strings missing. Not finished yet. Ok yep, *NOW* finished it looks like. Can't see any wrong text anywhere. Awesome. That file was le sux. However, Challenge Mode does crash for some reason. It's very very odd. Everything else in the game works perfectly, there's no bad strings that I can see, all other modes and battles work without any issues at all. EDIT: Ok fixed that. There was a bunch more strings in table 5 I didn't get. So now it all works, all string numbers match up. The only thing left untranslated in the file right now are the options, just because there obviously aren't any on PS3. I'll do those manually a lot later. Last problem there is newlines. Now, I have no idea how to go about doing that other than manually. Since this file is a massive crockpot of strings throughout the game, I can't easily split them up and just newline each section differently, because it'd take like 1000 different sections. I'm sure there are a few things you could do to speed it up, but a lot of it will have to be done manually. At least in terms of defining the sections you want to use x-length character newlines. So, you know, if anyone wants to do that, it'd be really helpful. EDIT: Edited the options menu allllll manually. God it was horrible. Had to write it all manually, and then write like a hundred offsets manually. Ugh. ![]() Ignore the cut-off text as always, just means I haven't patched it in the exe yet, but it's all English.. I didn't really know what to call the "Units" one, it's basically number of units, but that sounds weird and is quite a long string. Hope that doesn't confuse people. I'm doing all the textures right now. A lot of them require me to manually update every element, which is time consuming and boring. Especially this character list file used in the character selection page: EDIT: @Matis: I'd get banned if I did that. This thread would already be at the post limit if I made a new one for each edit. ![]() Ok, every texture is now replaced. Phew. All except 1 actually, one that I can't find. It just has names used when viewing warriors in the Gallery. The files are quite similar in terms of layout and position, in the archives for both JP and PS3 XL, and the file I'm missing is directly after one that I do have. There's 2 files that have the names in them, the first one containing names and textures for the menus, the second one just has more names since they can't all be fit in 1. I have that first texture, but the second with more names, not here. I don't know if the extract script failed or what. Oh well, maybe they don't get changed, doesn't really name any difference either way. There are a few things I haven't done though, those are the textures with names shown in battle, and camp names. The reason I haven't done either is because they're actually broken in the script. A8R8G8B8 files come out broken. The red/green and blue/alpha channels are reversed. I'm no way fixing hundreds and hundreds of files manually. If someone can make a script or some kind of macro for Photoshop or something that can fix it automatically for me, then I'll do it. So with textures done, I'm going back to text again. Here's what I know of the tables now for anyone who wants to play with them too: short - string 'XL' short - always 1300 short - table length short - number of bytes after the header size declaration short - data count, the number of data blocks short - data size, the size of each block long - header size variable - x number of bytes, as defined by the short up there ^. These are included in the header size. I don't know what these are for. I thought they would be describing the data structure or something, but I can't really see any specific connection. Scholar text added and newlined: ![]() ![]() If only file 31 was this easy to newline. QQQQ Hmmm. It seems something is actually hugely wrong with with the XL scholar file. It's missing loads of stuff, which is really weird. It's not cut off the end or anything normal, but literally some of the strings are just missing. In XL: Which one of Cao Cao's officers was the first to .Cheng Yu.Xun You.Guo Jia.Cai Mao.Cheng Yu saw that the ship was moving too fast and he warned Cao Cao, "If the ship is carrying supplies, it could not be moving that fast. In 360 (and as it should be): Which one of Cao Cao's officers was the first to realize that something was amiss?.Cheng Yu.Xun You.Guo Jia.Cai Mao.Cheng Yu saw that the ship was moving too fast and he warned Cao Cao, "If the ship is carrying supplies, it could not be moving that fast. The full-stops are the string terminators. Notice the "first to realize that something was amiss?" part. In XL after "to " it just, ends. That part of the string is just missing. But it doesn't break anything else, it carries on perfectly fine as you can see. The ends of the files in both versions are the same. Another thing that makes it more definite is that all the offsets are right, with these cut off strings. If data was being lost somewhere, the offsets would still be set to their originals and thus be incorrect in the file with those bytes missing. But no, they're all right, so it was definitely generated this way. I checked it out in the actual LINKDATA file directly, and that's exactly how it is, and the filesize as defined in the index is the correct size (with missing parts of the strings). So this can't be down to any sort of corruption, because everything matches, this really must be how it is. Was this ever patched on consoles? Was this a problem at any point? Some of the questions are broken, and I'm not sure why. In my string output they're all correct, and testing them in the file they're all correct too. HERP. It's the fault of the importer again. Of course it is. God damnit I'm just going to have to write my own. Ugh. EDIT: Ok, finished writing my own importer. It only works on text, because textures have to be re-packed to a specific format. I'll just add those manually, since I've already finished pretty much all of them, I don't need to update or test them any further, so it's ok. Text on the other hand, I do keep testing. So now this works, I won't get random strings disappearing or coming out wrong in the game, and then ending up spending ages trying to fix files that aren't broken (as I have been doing I now realise). It's not *that* bad though, because I'd need this script for when DW8 comes around eventually anyway. EDIT: Argghhhhh! Just spent like 3 hours trying to fix a goddamn problem that I introduced accidentally without knowing. All of a sudden I found every story box was using Xiahou Dun's icon and name, and it was like really bugged, the frame took ages to load. It wouldn't load until the normal time that the voice stops, but the voice didn't load until that point either. It's like the first time I went back to the modified exe in days, and I thought everything was broken. Searching around all over it testing, couldn't find any issues. Then I thought it was to do with a different file than it actually was, and I was back to scripting. I thought my newlining somehow broke everything, since that was about when it happened, so I was messing with newlines. Then I thought my import was broken, or maybe there were specific file size limits and that's why the CN tool cuts up files (even though it worked before), so I was testing all that against the CN tool and stuff. Just messing with all these files for so, so long. In the end all it turned out to be was that I ended up processing my story text file when I wanted to change the newlining a bit, but I didn't change the structure setup I had. I use the same function for a few of these files. I should probably make a function for every file, but eh. The file layouts are all different so I have to make sure I set it up to support them. It was taking in a long instead of 2 shorts, so it was reversing them incorrectly (second short is the portrait type, like they have normal/angry/sad etc). That's why everyone had their portrait/name set to Xiahou Dun, because it was reversing them as a long instead of 2 shorts, and setting the portrait number (which is nearly always 01 - just normal) into the character who's speaking short, and that's why everyone was Xiahou Dun - he's number 01 in the files. Moving the character short into the portrait short is what made the loading break. Since player characters only have 5 or 6 portraits, and non-player characters just 1 or maybe 2. So when it's set beyond that it breaks, and it's like to like 5a or whatever since there's so many characters, which is way invalid for a portrait number. So yeah, that just took me on a whole round-a-bout for hours, so I'm gonna leave this for today now. I've been doing it ALL day anyway, need a rest. EDIT: Ok, new day. Need to actually identify and find the rest of the text now. So far it's been easy as the files have been at the start of the archive, but now I'm just sort of randomly trying to find the text files within the other ~11.5K files. Fun tiems! Need to then try and match them with the CN files, so I can get the file numbers for the JP version. They're pretty close so far, at the start of the archive, XL has a randomly added 26 files, the same 26 repeated. So 1-26 is like it is in PC, but then it does those same 26 files again, all exactly the same file sizes and stuff. Then a bit alter there's another 2 added (so diff is 28). With offsetting those, I can try and find the files. It works so far, so it can lead me to assume files don't here if I can't find them. Making this list for myself because it's hard to keep track of. File numbers are JP-XL (XL start from 0, so +1 them all. I should really fix this but I don't want to extract 8.6GB again): 31 - 56 - misc/other 32 - 57 - story 40 - 67 - battle messages 45 - 72 - conquest 46 - 73 - scholar 4422 - 4449 - DLC? Don't know. Has a DLC tag at the end. It's just some conversation text. 4576 - 4603 - Unlock requirements for voices/wallpapers and some other stuff for the gallery menu 4578 - 4605 Warrior unlock requirements. Again gallery stuff I think. 4581 - 4608 - Dictionary (Encyclopaedia) 4584 - 4611 - Tutorial 4591 - 4618 - Loading screen warrior info Zipped files: 43 - 70 - Movies, a weird mix. Reading this changes the story like crazy, lol. "Zhuge Liang... It is in your hands." "Jiang Wei and the traitor are here!" "Zhou Yu must command our army." "As a new recruit of Wei, I must train, and earn your trust." "That's the Ma Chao that I know and respect." "Lord Liu Bei's land of benevolence... We must make it a reality." "I will not sit here and wait for death. I will kill him, and reclaim Wei!" It's like, what the hell is going on, lol. 41 - 68 - Movies 4425 - 4452 - Conquest stuff? JP 3825 - 4304, XL 3852 - 4331 (423 files total, there are gaps in places) - I think these are all story battle strings. Seems to be 2 per map, first one has defeat strings, second one success strings. A bunch of breaks in these files, but seems to be ok since they weren't listed as zipped files apparently. The file format of these is mental though. I don't know how I can fix this yet. I highly doubt, *highly* double that I'll reverse the whole file. I'm more looking into only replacing the string table at the end. Still thoguh that seems crazy in this, I cant see how even that works yet. DLC content must be all the >10000 numbered files. Which still doesn't exist by the way. So I still need them if I'm going to fix any DLC stuff. EDIT: Ok, I decided to figure out the texture packing format to try and make the texture extraction script work correctly. It kept erroring on files and etc etc, as I mentioned earlier with a missing texture, it's because the extract error'd out before it got to that one. So, I did figure it out and I fixed it. Soooooo many more textures, and now they're actually right. RGB32 textures are still broken in terms of reversed colour channels, but DXT5 are all fixed. Battle names: JP 2760 - 2974 (ignore 2926 - 2931) XL 2714 - 2927 Location names: JP: 3385 - 3458 XL: 3333 - 3407 (XL has 2 more for some reason) EDIT: Ok, wrote a script to reverse the colour channels, now I've converted all the broken RGB32 files to be as they should, woo. I can replace those textures now as well. EDIT: So going through a couple more odd textures that I've found now. The text that floats overhead (like skill points gained etc), also ending victory/defeat textures: ![]() This file is actually really hard to fix. The 2 kanji that make up the words here are different elements, and placed in different locations (the second kanji is smaller and below the first one in JP if you look). So, I have to split the word in half, and put half into each box, and then move each half to the correct place to get them to match up properly. This is what the default Eng texture looks like in XL: ![]() I mean, god damn, how annoying is that. They fixed victory, but I had to cut that one in half as well for JP. I don't particularly mind testing stuff, but this one requires me to actually close, re-open AND play through a battle to get to. EDIT: Ahhhh, really getting stuck on the file for loading text. It's annoyingly contained within basically their mini-archives with table layouts, and it's alongside 4 textures. Originally it's supposed to be zipped, but I can't re-pack the whole format of the file, so all I'm doing right now is replacing the text table, but it's making the game really crashy for some reason. Some (probably most) pages work fine, but if I keep reloading then it'll always end up crashing. But that's why I think I have figured out the unknown bytes after header now, and they do describe the data structure, which really helps me. 0 - long 1 or 4 - unknown, haven't seen them used yet. longlong maybe? 2 or 5 - short 3 or 6 - byte I'm not sure why there are 2 of each, signed and unsigned? I don't know. Either way, with this it makes my code both a hell of a lot smaller, and much more friendly between files, since I no longer have to worry anything about changing structures. I can just edit a few lines for where the strings re, string length I want etc. The loading warrior info text is still crashing the game even after doing this, I have no idea why. The file is definitely fine. I've tried both the original JP with just updating string locations and no other data, and now I've (correctly) converted the XL one as well. Both crash the game randomly. It's not as if it always crashes (which would clearly indicate a bad file). It can load x number perfectly fine, up until it hits certain ones it doesn't like, and then crashes. But since a bunch of them work, and my own string outputter shows them all to be fine, it's really strange. Maybe absolute offsets are doing me in again. Since this file isn't a file by itself and is just a table tagged onto essentially 4 textures, maybe that's messing with it. Worst-case scenario is that loading screen text won't be translated. Not the end of the world though really. EDIT: Having same issue with Encyclopaedia text. Just feels like permanently dying. Sigh. Also, painfully, all the movie text and map-specific strings are kept in zipped files, of which I don't know where they are, and there's going to be hundreds. Go go gadget Windows sysinternals! EDIT: Ok all 423 files patched and working! Now *ALL* story text is changed and working. I've now done most of the files, couple more to go. 432 files in total done, minus encyclopaedia and loading screens because of the crashes. About 15MB, that's a lot of text. EDIT: Cut-scenes patched in: ![]() ![]() Both in-game and movie ones. As always, ignore the cut-offs, it's not exe patched yet, just patched the files to English. CN patch has 439 files, I've fixed up 436. That's minus encyc and load text, so looks like only 1 file difference now for text. Found it and fixed it. So now, number of patched files are le equal! So that should be all text (minus the 2, which I have anyway and should be right <.<) and minus all DLC since I don't have access to those files. Everything else should be done, pretty sure I've done nearly all the textures too (if not all). So for archive editing, I think I'm basically done. I do still need to go through fixing newlines in files, but I can't do that properly until I edit the string limits so I can see what actually breaks. I'll do another pass with that later on. So now, back to exe editing I guess. That's really the last main step, also takes the longest and I dislike it the most. That's why I ran away to do the files instead. >: Turns out that last file hangs the game as well. That makes no sense either. It's only 1Kb with 14 strings in it, so I've tested all of them, and there's nothing wrong at all. Everything matches everywhere, yet it hangs. Not a complicated format either, no unknown data. Simple list of offset>string. Same format used in other files that I've fixed without issue. I've even changed it manually since it's so small, so I know it's not wrong. I'm pretty much thinking now that there's either absolutes being used in the exe somehow, or the game just can't use ascii in some places. There's no reason for this to be crashing things at all. EDIT: Ok, half of the total conquest-specific stuff is fixed now I think. ![]() If you're wondering what's different to the previous screenshot, I fixed the hex title (which was limited to 7 before, so it would have said "Sun Ce " instead of "Sun Ce Legendary Battles") and "Stage rank" (which was "Stage R" before) string limits. Remaining now are the mouse-over type ones which are a different function, and the difficulty select. EDIT: Difficulty select patched (these were all limited to 3 characters) ![]() Basic highlight-over-hex strings patched (different functions to the ones before, as every screen is. Sigh): ![]() And it turns out towns and the highlight on legendary battle hexes are different strings too, so I have to fix those 2 kinds of hex, then I'll be done with conquest finally. EDIT: Ok, conquest mode is now completely 100% done. Phew. A bunch of screens down, a *hell* of a lot more to go. Fixed up the main menu strings: ![]() EDIT: Ok I'm doing scholar now, and I sort of need people's opinions I guess. Originally it looks like this: http://i.imgur.com/5k3rtbs.jpg And you see "(Easy)" overwrites "Question" at the top, because that's just how it's laid out. Now, I have an easy option to remove the (Easy) string: http://i.imgur.com/u9Dzvrg.jpg It already gives the question difficulty with the texture on the right, so the information isn't being lost or anything. So, should I keep this string hidden so it's not overwriting stuff? Or should I leave it as the original with both strings kept in? Personally I think it looks better removed. EDIT: Right, scholar is now all finished. The longest explanation/questions go off a little bit, but again, nothing I can do about that. ![]() Most questions aren't huge blocks of text like that, that's just sort of, a worst-case scenario really. EDIT: End battle screen patched: ![]() EDIT: ![]() Menu patched at LONG last. I'm really really tempted to put together a composite image and just show you how much code it took to do that. It's ridiculous. It's exactly why I don't want to do this, fixing pages like these with so many strings. The seals page is going to be more than double this too. So, yeah. You can pretty much count out me patching shops or the gallery, and likely I won't do a bunch of other pages either. There's just no way. The amount of work required is way way too much just for me. Anyway, with the image, as you can see, I'm, going to have to edit the "Sworn Ally," "Skill Points" and "Guardian Animal" strings down to just like, "Ally," "Skill" and "Animal." "Skill" or "Skills" I don't know yet. EDIT: Ahh finally! ![]() This is annoyingly difficult. Game is still crashing for some reason as I navigate these pages. As you can see, I didn't do all the strings on this page, mainly because I just cba. You're not really missing anything. I did the weapon names on the left to account for not doing them at the top of the page. You know what everything there is, anyone can figure out "Att" is going to be "Attack" and etc. The things I may patch later would be the weapon type and the description, but that would be a lot later, and still a maybe. I'm just trying to do the seals atm, since they're actually needed for gameplay. K, think I finally fixed the crashes there. Zzzz next page. EDIT: ![]() Seals page itself partly patched. I haven't yet edited the seal description fully. I've changed the write location, just haven't set up the read yet, that's why it's just blank. But right now the game crashes when switching back pages. This is because for some cross-over frames (the slide in/out animation), the function runs too many times, which messes up my counter and then breaks everything. I don't know how to fix it yet. I'm stuck here. EDIT: Yeah! I FIXED IT! Mother humping mother ****er. Goddamn that was difficult. Seals pages fixed now. I basically had to add in a frame buffer for the required frames, and then reset everything. The weapons list page > seals page is 7 frames, and seals page > weapons page is 18 frames. At least, for the way my code works. I assume the actual animations are equal length, but with the way I have my code, my functions are changed over at different frames. The main problem is that the seals function is used by EVERYTHING. All of these pages use the same thing, but in different memory locations, AND they run a different number of times, with cross-over points where they run even more different numbers. It's like, the weapons page example runs 6 times when you're on it, which represents the weapon seal + 5 seals on the weapon, and the main menu only runs twice, which are the 2 weapon seals for your 2 equipped weapons. However, while transitioning the page from main menu > weapons, it then runs 8 times, for the 2 on the main menu, and the 6 on the weapons page. This is the functionality that messes things up for me, because it breaks my counter and the read/write. Again from weapons > seals, it runs 6 for weapons, then 6 + 9 for weapon seals and the 9 visible in the seal list that you can scroll through. But the 6 from weapons page are different in memory locations to the 6 for the seals page. So while transitioning again it runs 6 + 15 times per frame, then once the transition is over, it only runs 15 times. This ****s my counter. So anyway, I've had to split up the seals function for the different pages to be able to note down the start/end points. However, I can't set which page I'm on properly, because the seals function runs basically before EVERYTHING else. So there's at least 1 frame where it's running the wrong function before I can set the correct page. But, further to that, there's NOTHING unique in the weapons page vs the seals page. That's really why I set the names on the weapons page, because I had to edit a function to set which page I'm on for the seals, and that is unique vs the main menu. The main menu doesn't call that weapon name function. But the problem is, everything the weapons page calls, the seals page calls as well. I can use the seal description to set my seal page start, as that's unique to the seals page, but the weapons page has nothing unique at all. There's no unique trigger like "This string is only called on the weapons page, so set our current page to weapons page." Which is the way other pages work. So it's really annoyingly difficult to figure out how to set my code back to be the weapons page from the seals page. Right now I think I have it like, every frame it's set to weapons page through the weapon name function, but if I'm on the seals page, I then overwrite it with the seals page number, along with some other stuff. So yeah, had to add in weird code there to get this working. But it finally works, so that's good. There's 1 more page I have to fix now to stop crashes, and that's the weapon select screen. Since all these pages use the same seals function but a differing number of times and differing memory locations, I have to edit them all or it's just insta crash for that page. ![]() Almost forgot to fix the seal descriptions. Well, that's done now. Text isn't newlined yet, but the page is done now in terms of exe patching. EDIT: Ok, I patched the last crashy screen, but I've done something really weird. ![]() The equals signs at the end of every string just appeared out of no where. They weren't there before, but all of a sudden, they're here. I haven't even touched the weapon names on the left, but you can see it's on the DLC weapon that's still in Japanese. The only reason you can't see it on the Eng ones is because they're still character limited. I don't even touch those AT ALL. And, it's not just that page either. ![]() This is completely different code that doesn't even interact with eachother. Seals page is the same, has equals signs on everything. Even blank strings which I didn't patch either, like the one above Cao Cao's name, I don't touch that. Literally every string in the game has it. The main menu, legend mode, in-battle messages, story, scholar. Everything. Why dis happenz! EDIT: Fixed it. Had a jump 9 bytes too far back, after I must have added in something and moved stuff. Quite annoying that it didn't crash really, because then I'd have found it straight away. I still don't understand at all why it broke *everything* in the game, even for things that don't run over that jump, but oh well. All seal-related stuff should be ok now, in that it doesn't crash the game at least. I know gallery seals are blank, but if they don't crash then I don't care. EDIT: No, I'm wrong. Gallery works fine too, I guess it used some same code that I've already done. Two bird'd that. EDIT: Things were still crashing when I kept going through pages, especially in Legend Mode, and I couldn't figure out why. Eventually I did, and it was that I was using a different character to who I was using in Conquest (Cao Cao in Conquest, Pang De in Legend Mode). Cao Cao had 2 5 seal weapons equipped, but Pang De's second weapon only had 4, and that again was throwing my counter off and causing crashes. As was the main F1 menu page. So, at 4am, as it usually is, I found a better solution to all this, and that's to reset the counter every frame in the read code, rather than trying to do it on page changes while offsetting for fade in/outs. That fixes the problems of the counter going wrong during frame changes, since I can loop however many times I want, and it doesn't matter where I end up, I don't need to perfectly end my counter back at 1 for the next frame, since I just set it back to 1 directly later on. It also fixes other weapons having differing amounts of seals, because that also makes the function run less times, which was essentially causing the same problem. The complicated method always comes first, then you realise, herp 1 line of code elsewhere can alleviate these problems. So, that fixes up all the crashes, but now it's introduced another issue, which I basically knew would happen since I realised the problem, and that's this: ![]() You might have to view the full image to see the white text against the background. But yeah, basically, if you switch from a weapon with x number of seals on it, to something with less than the previous one had, then you'll get that effect. The seal text remains on the page. This is because the function runs less times when there's less seals, it just runs once per seal. In the case above, the weapon has no seals on it, so the function only ran once (for the seal on the weapon itself), and never did anything about the seals you can equip. Older seals aren't overwritten with anything. But, the read function still goes over that memory, so my edited read still jumps up to where I've offset seal x and reads it. So, yeah, they remain there and don't get overwritten. It's the same sort of thing as the battle messages did that I explained before. Now, a "proper" solution to this would be to use a counter and some sort of loop in the read function to only read the amount of characters that were written, however, to incorporate all of that would be bloody annoying, and long, and difficult, since I would have to move *everything* related to it somewhere else. There's no space to add that much in. So, I'm still thinking of ways to easily fix it right now. I thhiiinnnkkk what I can get away with, is making a function to set the alpha of every character to 00 (invisible) before the seals are written, then only the new seals would be written and set back to being visible. EDIT: Yeah, the above fix works. Now I have to edit the actual seals page as well, since the same problem happens there. EDIT: Dialogue choices for characters in Conquest patched: ![]() EDIT: Skills page patched: ![]() Not newlined yet. EDIT: I was completely wrong about the crashes. They haven't gone anywhere. I found that I could crash the game with 100% certainty if I switched character in Legend Mode and then tried to go into the weapons page. All I've been doing now is crashproofing and crashproofing and crashproofing and crashproofing. In the end, I don't think I'll be able to fix all the crashes. So, just an fyi, expect crashes, because I won't be able to fix them all. EDIT: Ok, stuff re-written many many times. Now I'm at a point where I just can't crash the game any more. I've gone in and out of every menu hundreds of times, changing seals, weapons, in/out/in/out over conquest/legend mode, switching characters, more in/outs and changing things. I've just baited it as hard as I possibly can to crash, and it's not. I can't say the crashes are "fixed," because it's just so precarious that the potential must still be there. But, I think I have made big progress to stopping them. However, the more you play, the more stages and stuff you go in, just the more memory the game uses which could eventually cause crashes to happen. I don't know if the game will continue working if you play like >30 minutes. But, I've basically done as much as I can now in this regard for now, so I'm moving on. Things left to fix left now are Legend Mode-specific things; medals and mission selection. Narration text isn't in English. I don't know why. It must be in one of the files I couldn't fix due to crashes. I'll have another look at that after, but don't get your hopes up there. I also had a quick look at cut-scenes, aaaannnddd I may not be able to patch those, because they use a very strange function which doesn't work as normal. I had a quick try to fix things but I couldn't. I'll take another look at that, but again, don't get hopes up. Cut-scenes may remain un-patched. EDIT: Medals patched. Was a lot longer than I first thought it'd be. ![]() ![]() Haven't newlined the description text. The second "or higher" goes out of the box and is hard to read. Can't do anything about that though. EDIT: Legend Mode battle selection patched: ![]() Secret weapons: ![]() EDIT: Difficulty patched. ![]() That now concludes the patching I'm going to do on Legend Mode. Sooooooooo, I now have to work on the "other" stuff. That being looking at cutscenes again, then looking at character names. Cause, if you noticed, everyone's just had asterisks over their heads. I probably can't fix it, but gotta check again at least. EDIT: Found the actual code for cutscenes. Fixing it was a lot more difficult than I first thought it would be, and it's still a really big mess. ![]() EDIT: Some progress made with overhead names, only slight though. I've found the function which writes the names to memory at startup and edited it only to move things further away. It still takes in 2 bytes so that's not fixed or anything, don't know if I even can. Also found the function which writes the overhead names into the usual blocks of characters that I'm familiar with, so I can get the read there too. Sooooo, everything I really *need* I've found (I think), but now it largely comes down to if I can understand and patch this code, that mostly being the startup write. EDIT: Yeah, I can't fix the scaling on names. It's all based off screen position so it scales mentally when I try to use absolutes. I don't know how to make it all scale properly, so I'm leaving that. Still, need to fix the read to make it read properly from my bigger blocks. Can't make the addresses work though. EDIT: Ok, I managed to write a function that fixes the names: ![]() However, there are many downsides to this as well. One, it's only for SJIS, which requires me to re-type EVERY name (there's hundreds) into SJIS. Secondly, look at the massive gaps between the characters, I can't fix that, I tried. The problem there basically came down to the fact that the sizing between letters scales based on screen position, I tried subbing absolute offsets to make the characters closer together, but yeah, it goes all wrong as the name moves across the screen. I don't know how to make it scale properly. But with names in SJIS, it makes basically everything look stupid, because the font is all different with huge gaps between all the letters. ![]() I don't know if I should (or want to) sacrifice a lot of looks just to enable overheard names. What do you think? EDIT: Yeah, I'm not going to patch names. Turns out there's another issue anyway and they all get messed up. They look absolutely horrible like that anyway, so I'll just leave it. You'll just have to learn who people are by their portraits and stuff, or find someone better at this than me. ![]() So, with that settled. I think all that's left is to go through and fix the newlines again, then start putting together a patch. Edited by Lavos, Sun Aug 18, 2013 4:26 pm.
|
|
|
| Matis | Fri Aug 2, 2013 8:08 pm Post #390 |
|
Soldier
![]() ![]() ![]()
|
God damn, Lavos. Impressive work. Using this post so you have an excuse to stop editing yours and make another. And to show my full support. Great work, man. |
|
|
| Astus | Fri Aug 2, 2013 8:31 pm Post #391 |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I really, really admire the work you've done here. Very extensive and very impressive. I would have loved to have been able to help but my knowledge of such matters is unfortunately very little. Much respect though, dude. :). |
|
|
| mygunufac3 | Fri Aug 2, 2013 10:34 pm Post #392 |
|
"Wyrd bið ful aræd" Fate is Inexorable
![]() ![]() ![]() ![]() ![]()
|
I am forever in your debt.
|
|
|
| Lavos | Sun Aug 4, 2013 1:09 am Post #393 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
Just putting it out there, but DLC content isn't on the XL PS3 disc, so I can't translate any DLC content. That means: Added weapons Added Conquest stages (and all related battle messages for them) Added costume names Added BGMs All can't be translated. So unless someone is able to send me DLC files, I can't fix any of that stuff. I don't know if that counts as piracy or whatever though. I am only talking about DLC files, nothing more than that. Mods will have to make a call there I suppose. But if someone can get them off their PS3 HDD if they have them, that'd be great. Edited by Lavos, Wed Aug 7, 2013 11:28 am.
|
|
|
| Kold | Mon Aug 5, 2013 7:47 pm Post #394 |
|
Soldier
![]() ![]() ![]()
|
I had no idea there was still progress on this, just randomly came to look and saw your stuff. Good luck and godspeed, man! |
|
|
| Adonas | Sun Aug 18, 2013 7:15 am Post #395 |
|
Soldier
![]() ![]() ![]()
|
would u happen to have a link of the patch? |
|
|
| Lavos | Sun Aug 18, 2013 7:25 am Post #396 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
I haven't released one yet. |
|
|
| Adonas | Sun Aug 18, 2013 7:29 am Post #397 |
|
Soldier
![]() ![]() ![]()
|
ya just downloaded the jap but no english what so ever on this ![]() ya just downloaded the jap but no english what so ever on this ![]() Edited by Adonas, Sun Aug 18, 2013 7:29 am.
|
|
|
| Lavos | Mon Aug 19, 2013 1:48 pm Post #398 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
Ok, I've posted a v1 patch over at http://s13.zetaboards.com/koeiwarriors/topic/7093148/1/ |
|
|
| godforpeople | Fri Nov 22, 2013 10:02 am Post #399 |
|
Soldier
![]() ![]() ![]()
|
What a pretty nice work Lavos. If I could help you I will. Hm can I give some advice? Why dont you use the Japanese Name on that box or whatever that used to be(when officer talking) And you can just change the Japanese name into english at the top of their body in the battlefield, right? Sry for bad english-.- Edited by godforpeople, Fri Nov 22, 2013 10:03 am.
|
|
|
| Lavos | Tue Apr 1, 2014 6:36 pm Post #400 |
|
Tiger General
![]() ![]() ![]() ![]() ![]() ![]()
|
Having a little crack at the stage scripts, seeing what's what. Bloody hard to figure out so much data with nothing to go on, just trying to change things to see what they do takes a bunch of time, especially in opening/closing the game, just to find it crash at the start. Just noting this stuff down here for myself so I don't lose track and forget. Using script 3826 (Wei's Yellow Turban stage). Table 0x54: Table 0xC0: I think this table may contain setup data for the map. I'm not sure but I think they're in blocks of 80 bytes. Copying blocks over from another file (every file has this table as 0x3c00 long), slowly edits things. Copying over data from Cao Cao solo in Dong Zhou's castle map, I managed to set my bodyguard to be one of the handmaidens from that map, replacing Xiahou Yuan. She also spawned in entirely the wrong place, the gate right up near Zhang Jiao. So maybe they don't use absolute coords, but some sort of list of points on the map? Through trial and error I've found the bodyguard block is at 0x2c0. Long at 0x28 determines starting position. No value breaks the game. It seems the game somehow sets the spawn to the nearest entry point. So yeah, definitely not absolute coords for starting positions. Long at 0x30 is the unit type. You can set anything that's a valid unit, even things that don't have models and can't do anything. I gave myself a tiger bodyguard: ![]() Just mauling up my enemies for me. Table 0x3CC0: Table 0x4080: Character's voiced lines relating to story, listed by number, 4 bytes each. 0x262B is Xiahou Yuan's first line right out the gate. Replacing the entries following this with other numbers changes their lines. This only changes the text shown and the voice (they match), it does not change the name of the warrior saying the line, nor the portrait. Don't yet know where these are referenced, no doubt that will include warrior name/portrait. Need to get a list of characters as they are in game. If I find out what Xiahou Yuan is it might make this easier. Table 0x41A4: Names of map locations. This one has 黄巾党本陣, 東関所, 村 etc etc. The English version of this file (from the console disc itself) doesn't even have these translated or removed. I guess they handle it elsewhere though. Table 0x41D4: Bunch of tables, bit of unused text. Changing values in these tables isn't affecting anything that I can see. Table 0x4368: Now here is our meat and two veg. I'd guess that this is our trigger list or possibly our startup list too, i.e which characters what locations etc. Table starts off with a list of longs which correspond to entries below it. I think they're possibly a list of triggers, with just a bunch of opcodes and variable-length parameters. Somehow gave myself a second bodyguard, and it's me! ![]() So I've identified the entry at 0x5CAC - 0x5D34 for being the first voiced line by Xiahou Yuan: Looking at bytes 0x5D28 - 0x5D34 0x5D28: (A0000000) 0x5D2C (40000000) - long, name and portrait of the speaker. 0x5D30: (6000000) - long, the number of the voiced line as defined in table 0x4080. The original is set to 6, so it pulls the 6th entry (game does EAX*4+base offset). This one determines both the text shown and the voice used. Table 0xFEFC: Map's text strings. Just the ones that show up like "Cao Cao is in trouble, save him!" Not the voiced story-like lines. Don't know where or how these are referenced yet. Table 0x010853: List of opcodes from the game exe, no idea what they do yet, but this should hugely help in defining what the opcodes are and their parameters. All params and opcodes are 4 bytes: Codes: 0fa 0 - Map-specific notices. Takes 1 paramater. The entry number of the string to show defined in one of the tables for the stage. 0a - Map-specific text opcode. Takes 2 parameters. Name/portrait and line number defined in one of the tables in the stage file. 14 1e - Unknown. Takes 2 parameters. dc - Takes 11 parameters 136 - Takes 3 parameters 460 - Takes 2 parameters. More text-related stuff. c350 - Text, x has done y opcode - takes 10 parameters. Same type of text as "assist x." Non map-specific. c352 - Voiced text, defeating enemies - takes 3 parameters. Third var is unit number. File 32's string table. c353 - Voiced text, raising morale - takes 3 parameters. First var is line number. Think these may include saving heroes as well, can't tell. Second var is unit number. File 32's string table. c354 - Voiced text, defeated and approaching enemy lines - takes 4 parameters. First var is the entry number. I think these may differ per character, I don't think every character would have the same line count, but maybe. For Xiahou Dun, 00 and 01 are approach lines, 02 is a defeat line, etc etc. Second var is 00 for ally, 01 for enemy. Third var is unit number (00 for Xiahou Dun). File 32's string table. 01869e - Takes 3 parameters. EDIT: So on a different tangent, I sort of went back to look at the text stuff to maybe have it not crash if I could update it in-place, rather than my mega-hacky route of actually writing out ALL the text elsewhere and jumping back and fourth during each frame, which caused huge problems around moving text (like seals, it copies the text around), and finally I actually sort of succeeded. ![]() Obviously it has problems as you can see. The frame box has entirely disappeared, and for some reason there's a massive gap between the text on the second line there. EDIT: ![]() Yeah I did it! Updated in place, and working. I had to edit a billion hard-coded offsets as I figured I would have to, but it's working. At least this way shouldn't be able to crash and be so random unlike the method I used before to get the same effect. Although, one missed offset can make things **** up. I have to find and edit every offset that first lays out, then writes, then updates per frame, for every single "piece" of this table. This in-game battle table for instance has 4 pieces: The text of the message, the portrait frame, the speaking warrior's name, and then one last bit that I don't know what it does, nothing visual I don't think. There are so many pieces and so many different places they're laid out, written to, updated and read from, it's a huge huge amount of work, more than my previous way of doing things I'd probably say. But in the end, should be less crashy I'd hope. But honestly I'm not sure about stuff like seals, because that was real embedded code. There's so so so many things that come right after that seal table, that then needing to try and move 100 tables further down would be just impossible. Through manual editing of the character locations I can verify that ASCII works for the name: ![]() But I really don't understand all the code around it and why it gets set incorrectly to asterisks. I can't find it even referencing Xiahou Yuan's name at all to attempt to build the offsets from. I could create all the positions manually a-z A-Z, but without it referencing the name I can't know what characters I need. EDIT: I actually got names working: ![]() Now, I KNOW it's not pretty. I don't know why there's a gap between the i and the a (in the code all characters are the same distance apart), I don't know why the last n is stretched, and I know the size looks too big. Firstly I'd say this isn't ****ing easy lol. I think the n is stretched just because it's crossing an element boundary. If it was further on maybe it would be ok. Other smaller names don't have their last character stretched. The i and the a problem, I have no idea. The problem with making things smaller is that I can only do it by absolute values, which if you don't play at 720p will **** things up I think. I already use one absolute to set the character spacing (as the game is hard-coded to 4 characters, there's no spacing set for over 4). It would be alright for me and those that play at 720, but eh. EDIT: ![]() BAM! How's that for their names! Oh yeah. I'm pretty stoked with that. It took sooo much coding and logic mazing to get it to work, was just sat staring at my screen for over an hour trying to figure out how the billion jumps and trigger bytes I was setting would work. Glad I finally got it. EDIT: Ok now I think I know why I was having problems and the place I can fix it. How to I'm not sure about yet, but I want to get some stuff down before I forget it about the string writes: Firstly text colour is gained by getting the value at the end of our text block, the second of 4 longs written after the final text block. eax*4+0B33B60 gives us the colour. Then we get the character who's speaking. The is the first block after the final text block, and also the function's called with this as a param. ptr at 0B332B0 contains the start of the character names table. We do ecx*8+esi+14. 14 for the header, esi is the start of our character name table, and then our character count times 8 to get the right location. All characters are stored as 2 bytes, even if ascii, so that's why it's *8, for 4 characters. This is why names are broken though, all characters, if have ascii, are set to 5500 (that asterisk). So clearly the thing that generates these names doesn't work for ascii, and just gives invalid (default) 5500. Manually editing these to whatever character I want makes it run fine. This is the table where overhead names are pulled from too. yesterday I spent ages just making the names on the battle story work, but now I know that characters are pulled from here as well, I can fix two birds with one stone, sort of. Looping still required as it is hard-coded to 4 characters though. The characters used are the font element number. So the first character in the fontmap is a space, so 00 in the name table is a space, the second element is a comma so 01 is a comma etc etc. Ascii is waaaaaay down the very bottom of the font map. Seems there's 64 elements per row, will take forever to count down there. D: Ok after a lot of searching I then got a bit smarter and found them. The blocks are 32*32, image is 4096*2048, so there's 8192 possible blocks, just counted backwards from the end. Problem is now though, ascii blocks are actually 16*16, not 32*32 like the rest of the file. Not sure how to manipulate that. EDIT: L0000l. I was messing with floats trying to make this work, and look what I ended up changing his name into: ![]() "NONONONO" I think the game's trying to tell me something. O: EDIT: Ok so instead, I've now been working on maybe getting overhead names to work, which requires entirely re-mapping the whole bitmap, and fixing hundreds of offsets to every function that gets characters from it, and finally got a bit of progress on that front: ![]() Not over his head, space is broken, most characters' names aren't what they should be. Still have a real long way to go with it, mostly in regards to fixing offsets, but, progress! EDIT: ![]() BAM BAM BAM! Yeah! I did it! Overhead names are now officially working. EDIT: Ok I did actually hit a lot of bugs. Fixing offsets fixed most of them, except this really really weird one where ALL spaces in the game disappeared from text. Every single one. I couldn't figure it out at all, spent so many hours on that, ugh. In the end it was a single errant offset that was wrong by 4 bytes. For the amount I had to change and the fact that I only got 1 wrong, I should probably be grateful. So names are now finally done and working without issue. Tomorrow I'm going to try and do a bit of styling. Like extending the message frames, messing with the line positioning, changing text size etc. Once I'm happy enough with it (I might just say screw it if it turns out to be a pain), then I'll move onto fixing other things I guess. If I can get a load more of these functions fixed, this will hopefully end up being a huge update for the patch I already put out. May look again into trying to fix the dictionary and load text as well. EDIT: So I said I was going to work on styling, and firstly I wanted to find text scaling, how that worked, and obviously lower all the text sizes. That would help us keep text within frames, and the default text is pretty big anyway. So how about this? ![]() I'm pretty good at styling I think. This looks fine. EDIT: So yeah, I've basically now hit an issue that I can't fix, and that's with editing screens that are written at startup (ala the in-game menu screen, and all of its sub menus, like weapons, skills, seals, etc etc). I can't manually edit a billion offsets for every single string I want to edit, sorry. Been trying to JUST increase the "Attack" string from 3 characters to 6 and I can't, because the amount of **** you have to edit to move everything in every single table down, as well as their writes and reads, is absolutely impossible. The time alone it requires is just way way too long for me to want to do any more. So unfortunately again it comes down to ridiculous hard-coded array sizes which are referenced a billion times that prevents me from making a better patch. Shame too, I really like the work I did in getting overhead names to work, but now it'll never be seen. Oh well, bring on DW8. EDIT: Ok well I said I'm going to leave it, and I still am, but I wanted to get at least 1 working to prove that this can actually work, and I wasn't going to let the game beat me. Finally, it bears fruit: ![]() All I've done is make Sun Shang Xiang's name show up properly. By default that string is limited to 6 characters, I upped that to 40. Just for reference, here's how her name appears without the edits: ![]() Now, in making just ONE SINGLE ****ING STRING work, look at all the **** I had to modify: ![]() To modify ONE STRING ON ONE PAGE, that many edits are needed. Look at all the strings just on that pause menu, then think about all the strings on every subpage from the menu. The weapons, the seals, skills, stats, clothing, settings, everything. Then include the main menu, the encyclopaedia, the gallery, conquest, tutorial and on and on and on. There is no way I'm doing that amount of editing (and it's not even just the editing, I have to find all of these offsets first which takes a long long time), on a single string basis. If that was the whole main menu I'd maybe continue, but for a single string screw that. So there you go, I wasn't being ridiculous when I was complaining before and decided not to do it. EDIT: Keeping some stuff here that I need. name - 5b0 !done! (total 5b0, from frame 5b0) health/atk/def - 3f0 (total 9a0, from frame 9a0) !done! musou/power/speed - can't really fix due to its combination with the above and the oddness of its offset-getting, only lose a single "u" off musou though. ------------------------- "EX Attack" - 150 - base + E043C (total af0, from frame af0) "Unleash with types" - 380 - base + E06A4 (total E70, from frame e70) Weapon name - 620 - base + E08D4 (total 1490, from frame 1490) ------------------------- "Weapons, obtainable seals" - 1C0 - base + E0EF4 (total 1650, from frame 1c0) Actual weapon names - B60 - base + E1194 (total 21B0, from frame D20) Weapon seals - a80 - base + E185C (total 2C30, from frame 17A0) "Ally" - 70 - base + E22DC (total 2CA0, from frame 1810) "Ally" warrior name - 5B0 - base + E234C (total 3250, from frame 1DC0) "Animal" - 70 - base + E249C (total 32C0, from frame 1E30) "Animal" animal name - 620 - base + E257C (total 38E0, from frame 2450) ------------------------- "Gold" - 38 - base + E2A4C (total 3918, from frame 38) "Skills" - A8 - base + E2E3C (total 39C0, from frame E0) Edited by Lavos, Mon Apr 14, 2014 3:14 am.
|
|
|
| 1 user reading this topic (1 Guest and 0 Anonymous) | |
| Go to Next Page | |
| « Previous Topic · Archives · Next Topic » |



![]](http://z2.ifrm.com/static/1/pip_r.png)






















































































8:10 PM Jul 11