Jump to content
RealModScene

lprot

Members
  • Content Count

    17
  • Joined

  • Last visited

Posts posted by lprot


  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. 1 hour ago, gavin_darkglider said:

    Then you have to rework how it launches games also, and add a ton of unneeded code, which makes the xex take up more space, and eats up perfectly good hooks, that can be used for better features. You are locked to a limited amount, which is part of the reason why FSD was scrapped, and Aurora was born. I explained why it isnt going to be changed, in your other thread, so get over it, and use it as is, or dont use it at all. the option is up to you. We dont force you to use our software. If you dont like it, than feel free to write your own. Stop creating threads, to post in other threads about the same topics. Long story short, there will be no fixing of TU handling, as it is not broken, and works exactly as it was intended. As a member of team phoenix, I am telling you now, this is not going to change, as there are a ton of other things that are being worked on that are way more important, than appeasing one user, who doesnt want to get a bigger hard drive.

    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. 5 hours ago, gavin_darkglider said:

    I like to run aurora from a DVD. lol. Or from my network share. lol. Long story short, you should run aurora from an external media source(HDD, Flash Drive) and it doesnt matter which model xbox you are running. I think Felida's point is that you can run it from USB just as easy as a HDD.

    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. 23 minutes ago, felida said:

    You can always disable TU scanning, and never use the TU feature.. 

    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: 

     


  6. 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 :)


  7. 1 hour ago, felida said:

    Save space?? The same space would be used reguardless .. now the advantage would be in loading speed.. as aurora would not need to copy to the hdd, just rename.. 

    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 :)


  8. On 27.08.2017 at 5:05 AM, gavin_darkglider said:

    It does that, because if they arent in the aurora folder they will get deleted when you launch a game in aurora. this is how the TU manager in aurora works. They will let you apply old TU files, as some mod menus, and other glitches are "fixed/broken" with newer updates. This way you can have multiple updates, and choose which one you want to run when you launch the game. This also saves you from having to download different TU's more than once.

    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!


  9. 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! ******

    .


  10. 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...


  11. 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!

  12. Did you read the descriptions lprot? Or did you just see 'ftpserv' and assume?

    ; these options are never used directly by dash launch but serve to give the configuration program; a place to keep these values[Externals]; if true, the configuration application will start a FTP server (user/pass: xbox); if not present default is FALSEftpserv = false; if ftpserv is true, this is the port that will be used by the FTP server; if not present default is 21ftpport = 21; if true, the configuration application will start in launch mode instead of options mode; if not present default is FALSEcalaunch = false; if true, temps in installer and in guide (shuttemps option) will be shown in fahrenheit instead of celsius; if not present default is FALSEfarenheit = false
    I mean, perhaps you don't have the 'configuration program' running? As to warfighter, there are lot of things that can cause crashes, especially if memory is loaded with other plugins (for example, xbdm plugin, or newer versions of the FSD plugin.) Dash Launch itself is designed to take as little memory as possible, having the ftp server inside it does not work towards this goal and as you have seen can even cause problems with games... so it's not there, it's in a plugin (or in dedicated programs that have much more resources to work with in title space such as in the installer itself, or in xexmenu or fsd.)

    Well, I wrongly assumed :) As to warfighter + ftpdll.xex. I tried to run it with FSD plugin switched off. And even without FSD at all from Metro. No biggie, warfighter just crashes if you select play single. As to another plugins: I don't use any. Only FSD + ftpdll.xex. I beleive warfighter uses the same mem (or part of it) as ftpdll.xex...

×
×
  • Create New...