Yes, We also need some dates on when each entry was added. A Title key field would also be very helpful.
--------------------- MERGED ---------------------------
Coalesced file with .eng, .esp, .fra, .ger, .ita, .pol, .por, .rus extensions. 8 files total. All about 1.4-1.8MB. Just quicker to type than make a true list. I think the problem seems to be with sound, which seems to be a lot of the issues with quite a few on the list.
Last edited by srbeen,
I had no luck with Bayonetta 1 after dumping the game rpx and rpl.
I think there is still a bug in loadiine when loading .rpl files bigger than 4MB (Bayonetta has one rpl which is 8295KB for me).
3 more colums for USA, EUR, JPN would be also helpful to know on which console it was tested.
Last edited by golden45,
Just tested Deus Ex again. Log is short and sweet.
--------------------- MERGED ---------------------------
Food for thought, I tried COD ghosts which didn't load at all and it had two RPL files, one was about 5.5MB the other about 6.1MB.
Code:
[0] Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.--------------------- MERGED ---------------------------
Food for thought, I tried COD ghosts which didn't load at all and it had two RPL files, one was about 5.5MB the other about 6.1MB.
Last edited by srbeen,
It's not related with the problem.
How it works :
- The loader (responsible for loading the RPX and RPLs) retrieves the decrypted rpx/rpl data from IOSU by chunk of 0x400000 bytes (4MB).
- When the rpx/rpl is bigger than 4MB the next chunk is retrieved in other functions of the loader.
- For RPX it works fine because I just replace the data of the chunk that smash bros was supposed to received from IOSU (18MB, so 5 chunks max) and say when we want to stop retrieving more chunks.
- But for RPL, the data does not exist at all, IOSU does not know the file, and returns no data. It's more complicated with RPL because I have to convince the loader that it received data. For the moment it seems to work fine for the first chunk of data (4MB), but for other chunks I think it still lack of something to really work.
If the decrypted RPL files were dumped from the WiiU somehow outside the instance of a game loading, and provided they don't blow up from 15MB to 150MB, do you think it'd still be an issue? Could we basically 'prepare' the game files using the WiiU then place them somewhere on our SD to appease IOSU (Ya loader, I did do something, heres the results) and the loader (IOSU you are great, thanks for decrypting that for me so well and placing it here)? Or don't it work like that?
I am amazed at the code so far. Very good featureset for the limited resources you got to work with.
Mmm sorry but I'm not sure to understand your idea. Can you rephrase it?
One more line of code and it breaks the payload maximum size =)
Is there a way to decrypt/prepare RPL files that the game needs with another program, so that loadiine can just refer to them without needing IOSU at all during actual game play? I understood it as smash is basically limiting the size we got to work with and IOSU just ignores or fails to return RPL files completely. If IOSU can be used one time to create the necessary files, would that negate the chunk barrier and RPLs not being processed?
Yes. With and without the update on a EUR console. Very long loading time at startup tough.
Preparing the RPL files from another program seems very complicated, onr RPL file is loaded when a program calls the OSDynLoad_Acquire function.
When OSDynLoad_Acquire function is called with the name of the .rpl file, the loader is called, it looks into a table to see if the library has already been loaded, and loads it or not.
Also, when the program exits, the loaded libraries are unloaded. And I think also that libraries are linked to the process id.
Furthermore, the loader performs a lot of stuff on libraries, like setup the external functions, link with other libraries, and copy the result (modified rpl code) in the code memory range.
Anyway I'm close to achieve it for .rpl files bigger than 4MB
, it's just a matter of time.If you are interested, here is a small trace log of what the loader is doing when launching an application (browser loading here).
Last edited by golden45,
Preparing the RPL files from another program seems very complicated, onr RPL file is loaded when a program calls the OSDynLoad_Acquire function.
When OSDynLoad_Acquire function is called with the name of the .rpl file, the loader is called, it looks into a table to see if the library has already been loaded, and loads it or not.
Also, when the program exits, the loaded libraries are unloaded. And I think also that libraries are linked to the process id.
Furthermore, the loader performs a lot of stuff on libraries, like setup the external functions, link with other libraries, and copy the result (modified rpl code) in the code memory range.
Anyway I'm close to achieve it for .rpl files bigger than 4MB
If you are interested, here is a small trace log of what the loader is doing when launching an application (browser loading here).
I like how you nonchalantly claim you've solved this riddle while I am scratching my head just trying to comprehend it. I can follow the log and kind of understand what the loader is doing but I have no idea what each address means as it walks through. I am much better at physical mods like designing a LVTTL to TTL level shifter to downgrade the CB on 360s, or soldering 0406 resistors to SMT PICs so I have rapidfire, or wiring in a D2CKey with 30AWG wire wrap. I've got a lot of hardware and am pretty good at using it. I even wired an infectus into the Wii to dump the nand before BootMii released.
You mentioned time, I realize theres a language barrier but it reminded me of this photo.
And with that its 3AM here and I clearly need some sleep. You keep on doing what you do, because you are definitely awesome at it. I'll patiently wait and maybe chime in from time to time answering some forum questions so you can focus on implementing that thing I barely understand which will make the compatibility list all green.
Ahah sorry for the trace log and the adresses, it's not important.
Also I don't understand all of what the loader is doing, far from it. And it's very likely that I said some wrong stuff in my explanations =).
Also I don't understand all of what the loader is doing, far from it. And it's very likely that I said some wrong stuff in my explanations =).
Preparing the RPL files from another program seems very complicated, onr RPL file is loaded when a program calls the OSDynLoad_Acquire function.
When OSDynLoad_Acquire function is called with the name of the .rpl file, the loader is called, it looks into a table to see if the library has already been loaded, and loads it or not.
Also, when the program exits, the loaded libraries are unloaded. And I think also that libraries are linked to the process id.
Furthermore, the loader performs a lot of stuff on libraries, like setup the external functions, link with other libraries, and copy the result (modified rpl code) in the code memory range.
Anyway I'm close to achieve it for .rpl files bigger than 4MB
If you are interested, here is a small trace log of what the loader is doing when launching an application (browser loading here).
Golden, couple of questions.
The RPL + RPX limit is dependent on the size of the SSBU RPX that is loaded correct?
I've noticed on decrypting NUS updates that the rpx files can be different file sizes on the updated versions compared to the numbers posted on the compatibility list, including SSBU.
For example the prx size for SSB on the compatibility list is 20 443 328 but on update v32 it is 20,455,424. Do those extra 2000 bytes do anything for you (you said you were out of room for code...)?
hypothetically, What if an SSBU update made the rpx 50MB? If the update was installed via WUP would that updated prx be the one launched and be the one affecting the max rpx+rpl size?
On the other hand (I haven't checked all of the updates), what if a game that was just over the max prx size had an update that put it under the max size?
To clarify, by loader do you mean loadiine or the WiiUs internal loader?? I was thinking you were talking about loadiine but realize loadiine don't actually load up the browser so now I'm confused. and its getting later.
--------------------- MERGED ---------------------------
No. If so it'll work the other way too. Nintendo could make the RPX 5MB and kill compatibility. I'm thinking you are right. and Golden45 said it does the loading in up to 5x4MB chunks, as needed. I presume if theres a game with an RPX thats bigger than 20 443 328 but smaller than 20 445 424 it'd work. Good eye on the update sizes though, they would change as the executable gets revamped.
Similar threads
-
-
-
@ HiradeGirl:
Any TV with your PC connected with Citra and any smartphone to use as a screen using a free play store app.+1 -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
