Jump to content
RealModScene

mexpress22

Members
  • Content Count

    9
  • Joined

  • Last visited

  • Days Won

    1

mexpress22 last won the day on October 6 2016

mexpress22 had the most liked content!

Community Reputation

10 Good

About mexpress22

  • Rank
    RMS Freshman
  1. My girlfriend was setting up her sons Unity account and now we are getting Log in Failed. She activated the email but for some reason we still can't log him in. Not sure if maybe she spelled the username wrong. His user name is KrazyKatGamer.
  2. thanks for the response. Regarding #1 the idea isn't to reinvent the wheel but maybe utilize the games database (whether it was already created or not-sorry for my ignorance) for other functions like omitting TU's that do not match corresponding games in the scanning process and creation/modification of the title update database. for #2 in order for aurora to scan and log a tu it first has to be in one of the scannable locations. I am suggesting only scanning a single specified folder. As unity does not have tu>300mb (and some <300mb are not avail), we must place tu's that we find in their appropriate locations so that once a title scan is initiated, aurora can find it and now recopy to that same location. If a tu is misnamed or incorrectly placed it will not work. This can also happen when dl'ing from unity via Aurora on some files. Either the file name is incorrect or the installation path resulting in a failed tu. If aurora is already detecting the installation path upon launch of the game, maybe just an added step to ensure file name is correct. also by having only one specified folder to add new tu's and the updated database/scanning process would allow us to add multiple tu's at once that we could rename (ie CODBO2 tu17 or FarCry4 TU8) without worry of the tu failing once activated nor worrying about getting it in the right location. Renaming allows for easy sorting on the pc plus I am unsure of how one currently would be able to add an additional tu that isnt available via unity without first deleting the current title update as they very likely will have the same file name. Current unity dl's bypasses this name matching issue of tu's through its ingenious database and backup process. However unless your title update is directly saved to the title update database, you cannot place the 2nd TU in its scannable location without deleting/moving the first one. This does not allow for the easy switching between tu's on first use. After the deletion of the original tu, copying of the new tu, and new scan, one should still be able to select from TUs as they are now both saved in the backup and logged in the database, but the initial process of adding both requires multiple steps increasing the chances of error. Plus, the more tu>300mb we run into the more problems will arise ie minecraft. Adding one more step in the title update/database process to check base version against games database would ensure that only correctly matched tu's would be added to the database. with #3 I was unsure if aurora could move said files as long as they weren't dl'd directly through aurora. In order to add dlc, we must copy to the correct folder. If the folder is not there, (ie an xex with no current tu or content) we must create the folder with the right folder stucture. I was suggesting using a single folder that aurora could scan and log the proper location of the content (be it xbla, dlc, game save, etc) and place in the correct location similar to the process of tu management. Content would still be handled by the kernel but properly placed by aurora, thus reducing more content related errors. Again, comparing file attributes to the games database could omit the organization of content that didnt match a corresponding game in your paths. and 5 im unclear you what mean. I wasnt referring to playing the game more referring to a logging feature that would let us know what tu's or files were skipped or renamed during the modified scanning/database creation process. that way if we are scanning in new tu's we would know why the system added or didnt add them to the database, ie the base versions didnt match or the file name was incorrect. for games launched via odd or any other method not through aurora's game paths, title updates would still have to be manually added or allow an exception for database matching to allow addition of tu's that do not have a corresponding game path. the suggestions in 5 were only additional tweaks to the modified database process above.
  3. First off let me start by thanking all the developers, testers, and the scene for contributing so much allowing me to progress to where I am. That being said, I am nowhere near the understanding of all the underlying processes. So when reading these suggested tips, I am in no way assuming that they are reasonable in application, nor needing to be done in the manner outlined below. This is just how I've interpreted the processes already being used and reapplying them to maybe acheive fewer errors that take away from what our systems can really do. When a game path is scanned, info (game name, title id, media id/base) is logged to an existing or newly created database or similar file(maybe this could also be used in the implementation of a current request to extract game titles/title ids to csv.) Just like in the creation of the title update database, games already logged would be skipped only updating with new additions/changes to the library. Scanning of title updates would scan only one folder, let's call it "Content Needs Added." Any title updates that need to be added to the system either through Unity or manually would go to this folder. Manual files added would require a title scan. Unity downloaded files would force an automatic scan or force addition to the database, just like the current behavior. Instead of logging to the title update database the original file location and file name, aurora would log the correct file location and original file name that is contained within the file (similar to what happens when Horizon or 360 Content Manager handles the file). Comparing against the above game database file created in step 1, files not matching the media/base would be skipped. Title updates already in the database would be skipped, just like the current behavior. If the same detection of file name/file location could be applied to other content like xbla, game saves, dlc, etc, then maybe we could use the "Content Needs Added" folder for adding other content. The same way aurora copies, moves, and deletes tu's, maybe the same could be applied to this other content. Scanning against the games database file in step 1, would allow omission of files that do not match a corresponding game. Comparing the games database, the title update database, and the available files on Unity might also help the implementation of another request for notification of new available tu's. Additional suggested tweaks log results of Content scans to inform of mismatched content, actions taken, etc ie "Title update tu00004_0000000 was not added due to no matching media/base in Games database" or "Title update tu000001_0000000 was renamed to tu00000a_00000" or "DLC for title id/game name was added". allow user selected options for what happens to files in the "Content Needs Added" after manual or forced scans ie "Delete all files after organizing," "Only delete files that are successfully organized," "Delete nothing (default)," or "Delete nothing and replace files with corrected file names." Any selection other than default would turn on the logging suggested in above. Thanks for your continued efforts!
  4. If Aurora could detect the base version and the correct installation path from the file itself then instead of storing to the database the file's original location and file name, then Aurora could backup file to be written to the correct location with the correct file name thus eliminating user error and errors with misnamed or misdirected files. Through trial and error I have discovered a handful of files that would only work if transferred via horizon, others only through unity via Aurora ie. Assassin's Creed tu1 on unity is a tu00000_000004 file but is directed by unity/Aurora to install to hdd\Cache\. If the same file is handled by Horizon, it's correctly placed in the appropriate folder. Kung Fu Panda SOLL's tu found on this site is misnamed and will only work when using Horizon to recover the correct file name. But on the flip side, COD BO2 when using Horizon will not work, but if dl'd through Aurora, it works fine. Having a general folder that we (as end users) could place all content items (xbla, tus, save files, dlc, etc) and let Aurora manage based on the file's info. How awesome to no longer have the support thread be diluted with Content issues. Even better if Aurora could scan the xex's in game paths and only organize the files in the "Content Dump Folder" if they matched the title id and base version of the corresponding xex.
  5. I have noticed that when switching to the stock dash that there seems to be some issue with remounting the hdd or usb. Typically I have to insert a new usb to force the system to remount and refresh devices. Maybe a script to force a refresh and remount after changing to the stock dash would help.
  6. That's also been done with no luck. Tried ftp, also tried transferring to usb and copying via xexmenu and Aurora file mgr-seperate times of course. I am noticing its only happening to items whose install path is hdd\Content\0x16\title Id#\000B0000\tu file. Hdd\Cache\Tu file(s) do not give me any issue regardless of install method. Edit: SOLVED: Stupidity 360 content manager has a "rename (friendly)" and "rename (default)" feature which essentially renames your dlc, xbla, tu's etc by using the file name and package title elements of the respective package. However, when changing to friendly naming and back again, the package data for the package's title is blank for uppercase TU's and tu00000_000001 (generically named) for all lower case tu's resulting in a misnamed title update file. Aurora recognizes it, builds the dB, but once loaded it fails due to incorrect file name. The only reason I was using the rename feature was to help sort through my collection and as a reference when compiling Content items. Names would be changed back to default before transferring back to xbox and worked for everything except tu's. Lesson learned. Horizon was able to recover the correct file name from all affected items and all tu's are now working. Maybe a feature to implement could be for Aurora's dB title update process to recognize incorrectly named/organized content items and alter the dB to properly place them. Horizon is able to recover the correct file name and install path, can Aurora integrate this as well? This would allow for a "Content dump" folder that we could place any new content in and Aurora could manage without fussing with possible file name and file location errors.
  7. Just to be thorough I tried placing tu6 for Rise of the Tomb Raider (tu00000001_0000000) in the Cache folder (hdd\Cache\tu file) and let Aurora rescan after deleting the original tu through Aurora (select game, press y, select title updates, press x, etc). Aurora backs it up after a restart, let's me enable it but upon playing tu0 is still displayed and dlc does not work. Dlc and tu show ok in nxe so they're not corrupt. I'm stumped.
  8. I have lower case tu's in Content\0x16\title id#\000b0000\update file & upper case Tu in Cache\update file. I've put them there manually via xexmenu, ftp via 360 content manager, horizon to usb mu and transferred via nxe and also Aurora file manager and xexmenu to no avail. Always ensuring to scan and enable in Aurora after transferring. And like I said above,Ive also deleted the data folder and started with fresh tu's. Same issue. Ive successfully transferred over 70 other games xbla and xex, however the only tu>300Mb that has succeeded was minecraft and that was more luck than science. Cant remember what hokey back and forth order it required until Aurora would load it.
  9. Jtag falcon running 17502 cannot get any manual title updates to apply. Media and base versions match. tu's going to their respective locations. Scan is finding them and I am enabling them prior to loading game. If I download through Aurora (tu's<300Mb) all is well. If I were to download the exact same tu from unity on pc and ftp, USB xex transfer, or horizon to usb nxe transfer then Aurora will recognize and even appear to load tu (additional time is noticed in "tu loading" progress bar) but tu0 still appears in bottom corner. I've tried multiple files, deleting aurora's data file and starting over. Problem games are: Rise of the Tomb Raider (tu6), Lego Avengers (tu5), far cry 4, kung fu panda, Lego star wars tfa (tu2), Lego jurassic world (tu3), minecraft and story mode (tu46-47 & tu7 resp.). Please help.
×
×
  • Create New...