Jump to content
RealModScene

lprot

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About lprot

  • Rank
    RMS Freshman

Recent Profile Visitors

1359 profile views
  1. Well, I will tell my story. My Xbox 360 is NTSC ver. I can connect it to Live and also it is RGH (basically I reflash it into rgh when do not need live). I bought Disney Infinity 3.0 starter set and Marver Battlegrounds + Finding Dory sets. The problem is, my Disney Infinity 3.0 disc is PAL (media id 28463254). So I cannot update it from Live as my console is NTSC. For Media ID I found only TU6 which updates Disney Infinity from 1.0.0 to 2.0.0 so Marvel Battlegrounds should work, but it does not as TU6 has a bug that requires the console to be connected to live for language pack not caring about the fact that is is already downloaded. For Media ID 53AC08B4 (that is region free iso available on internet) we have only TU3 update from unity which is useless as does not support Marvel Battleground Playset. For Media ID 033466F1 (PAL) we have TU7 available that updates Disney Infinity 3.0 to 3.0.0 ver and it supports all Marvel Battlegrounds + Finding Dory sets and does not require live anymore. So I basically need one the following options: 1. ISO/GOD with Media ID 033466F1 and missing Finding Dory Playset (with language pack) 2. TU7 for Media ID 28463254 and missing Finding Dory Playset (with language pack) 3. TU7 for Media ID 53AC08B4 and missing Finding Dory Playset (with language pack) If anybody could PM me with that I would be very grateful, Thanks in advance. PS: I already have: 5638EE59BBBF402920C48DAB7BCF4D1582E8249C42 - Marvel Battlegrounds Playset 7F0ED8DDA5BDA11D6ADD933D1B658B63ED760DE142 - German Language Pack C4AEB18FF64DA8BFCDEAA624AAD87C89C171756E42 - Character Language Pack tu00000011_00000000 TU6 for media id 28463254 tu00000012_00000000 TU7 for media id 033466F1
  2. The idea of optimization is not only in saving space but in the speed too. Currently Aurora scans TUs every time you start it. I propose to do that only if you go to TU settings of the Title. If multiple renamed TUs in the same folder make the problem then you can creatre TU subfolder there and put that stuff there. TU handling in Aurora goes from FSD times and IMHO it needs to be changed these days.
  3. In fact, now it has alot of unneeded code as before the game lunch it copies TUs from cache to the place it lives from the start. So implementing the algo I suggest will just help to get rid of all that unneeded code (backuping, copying, cleaning etc). I was not telling that TU handling is broken I just told that it could be implemented more logically and in optimized way. Forums were created for discussions, right? Anyway I wrote a message to MaesterRowen about that let's see what he thinks about that.
  4. All those are workarounds.To fix TU handling in Aurora we can go two ways: 1. Add an option for manual handling of TUs by user (most easy IMHO) 2. Rework the algo. One thing is clear for me - it should not backup TUs on first start wasting time and space...
  5. Nah, thats the hard way as on 16Mb Corona you need to run Aurora from some hdd
  6. You can't because on the first start Aurora backups all TUs. Here I summarized what to be done to make it fast and not space consuming:
  7. Currently (as of v0.6) Aurora on first start scans Content and Cache folder for TU, fills the database and copies TUs it found to Aurora folder. When you set TU you like, it deletes TU in Content/Cache folder on Hdd and copies TU from Aurora folder to Hdd. If you download TU from Aurora it puts it in Aurora folder and if you activate it Aurora deletes TU from Content/Cache and copies from Aurora folder to Hdd. All of that is time and space consuming as Aurora makes a copy of all TUs (imagine if you got 10Gbytes of TU files) to it's own folder. Instead of all that complications Aurora could do: 1. Don't use it's own Title Updates folder at all and don't scan Content/Cache folders on start. 2. If user goes to Title Updates options of the Title in Aurora GUI, only at this time Aurora could scan corresponding Content/TitleID/000B0000 folder and /Cache folder for that TitleID and show the list of TUs for that title. Naming of the files in Content and Cache folder in it's original locations on Hdd should be like that: tu00000009_00000000 - for the currently active TU let's say ver 27 01_tu00000009_00000000 - for TU1 02_tu00000009_00000000 - for TU2 xx_tu00000009_00000000 - for TUxx If user activates TU2, tu00000009_00000000 gets renamed to 27_tu00000009_00000000 and 02_tu00000009_00000000 to tu00000009_00000000. If user downloads TU from xboxunity it downloads directly to Content/Cache folder and correspondingly gets renamed. For Cache folder: TU_XXXXX_XXXXXX for activated TU xx_TU_XXXXX_XXXXXX for other TUxx Hope I'm clear
  8. Yeah, save space as with the current algo it doubles TU as it keeps it in both Content and Aurora folder. Imagine what it dooes if you got 10Gbytes of TUs in Content folder... Moreover if you run Aurora from USB drive with free space left less then it is required for Aurora caching - bump PS: and I got that big number of TU updates in Content folder
  9. Well, logically it'd be more useful (for space concerns of course) to leave that TU where it belongs and just rename the file. For example tu00000009_00000000 to tu00000009_00000000.27 where 27 is the number of the TU. Or to 27tu00000009_00000000. That will allow to use any TU number you wish and save space. That way you don't need TU cache folder in Aurora. If implementing that is hard, I would kindly ask MaesterRowen to make an option in Aurora that will disable TU caching in Aurora folder, leaving management of TUs to the user. Thanks in advance!
  10. System info item in Russian locale is empty i.e. user has no clue that that item is clickable...
  11. I tried to compare CORONA_16MB.ecc and generated image_00000000.ecc and they differ. You can try yourself...
  12. This version can't build ECC for CB13181 of Corona V3 (Xbox S 16Mb ST NAND with 250Gb HDD). python script says that CB version is not eligible. J-Runner builds just fine.. Swizzy's xeBuild GUI version 3.0 Log Started: Sunday 27.08.2017 9:08:46 ================================== *** Some console information *** CB Version: 13181 Copying nand to ecc directory, this may take a while... Done! Parameters sent to python: build2.py nanddump.bin Building nand using build.py (this may take a while): Unpatchable Universal XELL Nand Image Builder * found flash image, unpacking... ECC'ed - will unecc. Found 2BL (build 13181) at 00008000 Found 2BL (build 13181) at 0000a000 Found 4BL (build 13181) at 00011df0 Found 5BL (build 1888) at 00016e70 * we found the following parts: SMC: 2.5 CB_A: 13181 CB_B: 13181 CD (image): 13181 CD (decrypted): missing * checking for proper 1BL key... ok * decrypting... * checking if all files decrypted properly... ok * checking required versions... ERROR: Unkown error! exitcode: 1 ERROR: There was one or more fatal errors: 1 errors during the build process Traceback (most recent call last): File "build2.py", line 455, in <module> assert build(CB_A) in falcon_builds or build(CB_A) in zephyr_builds or build(CB_A) in jasper_builds or build(CB_A) in trinity_builds or build(CB_A) in corona_builds, "CB "+str(build(CB_A)) + " not eligible" AssertionError: CB 13181 not eligible Cleaning data and temporary directories... Done! ****** The app has now finished! ****** .
  13. Well, I got rgh2 corona v3 (Xbox 360 S with 16Mb NAND and 250Gb HDD) which is not live banned. I have a few legit titles installed to internal HDD and TUs for them which I got from live. I don't write hacked stuff to internal hdd cause from time to time I return retail NAND, and go to live to get stuff. Then I reflash back to rgh2 image. So when I connect external HDD with Aurora on it - it starts fetching TUs from internal HDD. I see no point in that. Instead it'd be more logical to keep them there and just add location to database. I was waiting about 20 minutes while it copied all TUs from internal HDD to external one...
  14. Please add UTF8 in Extensions supported: in F3 FTP server. As non ASCII chars are displayed incorrectly. Here's an example how ftpdll.xex does it: Connect to: (19.12.2013 21:28:29)hostname=192.168.0.39:7564username=xboxstartdir=192.168.0.39=192.168.0.39220-xFTPDll 0.1 powered by SlimFTPd220-You are connecting from 192.168.0.190:52672.220 Proceed with login.USER xbox331 Need password for user "xbox".PASS *****230 User "xbox" logged in.SYST215 WIN32 Type: L8 Version: xFTPDll 0.1 powered by SlimFTPdFEAT211-Extensions supported:UTF8SIZEREST STREAMMDTMTVFSEXECSHDN211 ENDHELP SITE500 Syntax error, command "HELP" unrecognized.OPTS UTF8 ON500 Syntax error, command "OPTS" unrecognized.Connect ok!
×
×
  • Create New...