[APLICACION] Iris Manager (v3.00)

@Estwald:
Thx 4 the fix... it works now as expected.
But... there seems to be the same bug in "extractps3iso" !?

And... I have a suggestion regarding "makeps3iso":
It should be mentioned in readme that "makeps3iso" detects splitted big-files and joins them.

Regards
Rudi
Dan_Aykroyd escribió:Estwald, estoy en MLT 4.46 + Cobra, ya tenía activado el modo discless en tu Iris Manager 2.60. Ahora instalé el PKG del 2.70, me aparecen los agradecimientos y se queda la pantalla colgada.

Tengo los plugins de ftp + test (para reiniciar la consola desde el joystick). En el IM 2.60B funcionaba todo perfectamente, aquí ni ingresa.

Alguna idea? Vi las páginas anteriores que comentabas que del programa no es, pero no tengo nada más raro y desde recién que instalé el IM 2.70 que no arrancó más tu manager.

Gracias!!!

PD: También intenté ir al 2.65 y hace lo mismo, se queda colgado en la pantalla de agradecimientos (no responde ni el botón PS mostrando el XMB)


Sobre los agradecimientos me aparece la pantalla y desaparece al cabo de unos segundos y aparece IRIS sin problemas por ahora.

Ahora se puede usar CFW 4.53 sin necesidad de ser Cobra para lanzar las ISOS con Mamba.
Solo es necesario estar en Cobra si se quiere jugar a PS2 ya que Mamba no lo soporta. Sobre lo que comentas puede ser por los plugins que tienes instalados, prueba de eliminarlos y probar sin ellos.

Yo estoy usando Habib 4.53 con iris Manager 2.70 con las isos que antes usaba, en el 2.65 y 2.60B y siempre me han funcionado perfectos, eso si no e puesto nunca plugins ni nada en la PS3 limpia.

Funcionan perfectamente por ahora.

Saludos.
xurxo1975 escribió:Aki estoy de nuevo!

Llevo un rato en CFW 4.53 HABIB, y intente lanzar varios juegos
El GT6 se me quedo colgado con este error
No hay espacio suficiente en el disco duro. Se requieren mínimo 32 MB. 0x0000001a[183]Y se queda ahí el Juego
El GTA 5 din problemas
Y el beyond 2 souls lo instale desde cero y tardo como 40 en instalar
Esto fue todo con el MAMBA

Y hablando de lo q dicen en otros foros, pues na que opinen…
Yo creo q lo dejas todo muy claro d donde sale todo
Un saludo



Ayer me pase al cobra de HABIB y el problema de GT6 ya no lo tengo, tambien noto q los juegos cargan mas rapido con el cobra que en el HABIB normal

Un saludo
alguien me puede pasar los sprx parcheados de 4.53?
una pregunta, se puede utilizar un disco duro externo en NTFS para ejecutar juegos en archivos sueltos en vez de ISO?
wenas:

A ver si alguno de vosotros que tengáis el juego "Injustice: Gods Among Us [BLES01673]" puede crear un iso y probarla que funcione.
La he realizado varias veces con el "makeps3iso" pero inicia el juego pero al cargar la ultima parte se me bloquea y no termina de cargar.

En cambio haciendo la ISO con el "genps3iso" me ha cargado bien.

Es para salir de dudas si es cosa mía.

Por cierto estoy encantado con la Mamba negra :) :) :) :) ...gran trabajo

un saludo
an reportado fallos lo va a arreglar de omento gasta el otro
Sí, aparquemos los errores de reconstrucción de ISO por ahora. Ya tenemos herramientas que lo solucionan (isotools de 3k3y y genps3iso de cobra). No son de código abierto pero seguro que hacen su trabajo: 3k3y y Cobra son los primeros interesados en vender ODDEs como rosquillas.

Lo que está intentando Estwald, portar funcionalidad del SM fuera del FW, no nos lo van a solucionar los fabricantes de ODDEs. :)

R.
belmonte_drums escribió:una pregunta, se puede utilizar un disco duro externo en NTFS para ejecutar juegos en archivos sueltos en vez de ISO?


No, no se puede.
nascar escribió:Sobre lo que comentas puede ser por los plugins que tienes instalados, prueba de eliminarlos y probar sin ellos.


Gracias Nascar, pero esto significa que van a dejar de funcionar los plugins con Iris Manager > 2.60B?

Tampoco son plugins muy "extraños"; simplemente 2 posteados por MLT y que venían funcionando perfectamente: ftp y test (para reiniciar desde el control).

Si es así me parece una regresión en el Iris Manager, ya que no veo por qué deberían dejar de funcionar dichos plugins.

Según entendí, el Iris ni siquiera debería estar cargando el Mamba (ya que estoy en Cobra) y los plugins solo debería cargarlos él mismo si Cobra ya no lo hizo antes (cosa que parece que tampoco se da cuenta el Iris Manager).

Puede ser un problema en la detección del Cobra por parte de Estwald, que "no vea" que el Cobra está cargado, intente igualmente levantar el Mamba y los plugins y ahí se cuelgue todo?

Espero que pueda solucionarse, porque realmente no quiero dejar de usar el ftp en background y me gustaría seguir para adelante con las versiones del Iris.

Gracias
Dan_Aykroyd escribió:Espero que pueda solucionarse, porque realmente no quiero dejar de usar el ftp en background y me gustaría seguir para adelante con las versiones del Iris.

Gracias


Si no es molestia en preguntar, ¿ para que un FTP en background ?
no acabo de comprender que uso se le puede dar a un FTP tal y como están las cosas, y más si estas en COBRA.

es solo curiosidad, no alcanzo a comprender en que escenario te mueves.

Iris tiene un FTP que puede arrancar como servicio...
Hola Mad, el FTP en background es el motivo por el cual me pasé a MLT desde Rebug :)

Es excelente porque arranca ni bien inicias la consola. Te paso dos escenarios donde me viene buenísimo:

1) Prendo la consola y me voy a la PC para pasar por FTP. Ya no más prender el TV, prender el joystick e ir hasta el Iris Manager para iniciar el FTP server.

2) Puedo dejar copiando juegos todo el tiempo, incluso mientras estoy jugando a otro! Esto es espectacular, para juegos de 10, 20, 30, 40!!! GB, puedo dejarlos copiando y jugar a cualquier cosa (o Showtime!). También funciona si salgo del juego en el que estoy y abro otra cosa, o si corro el reActPSN para activar algún rap, etc., no se corta! Eso lo probé particularmente y no se cortó nunca en los cambios de tareas.

Espero que me entiendas las bondades que le encuentro al FTP ahora :)
Gracias por responder Dan,

Si, visto asi es una 'comodidad', supongo que, según que juego, puedas notar que 'rasque' el disco o incluso ralentizaciones.

Personalmente me es más cómodo pasar los juegos a ISO, evitando centenares de ficheros sueltos, y pasarlos al interno si procede desde USB (en mi caso no al interno, porque es un espacio necesario para los que se instalan, que no va mi disco interno tan sobrado), y ejecutar TODOS los juegos desde externo, que gracias a las bondades del formato DISCO, van hasta los que se deberían ejecutar desde interno.

Tus razones son buenas ;) , pero yo me pillaria un DOCK de discos 3,5, y me lo llevo al pc (usb3.0), y a la play despues y problema resuelto a lo grande. Los DOCK no son caros, incluso puedes tener uno en el PC y otro en la PS3.. en 'negocio extremo' hay para escoger ;)
Gracias por las sugerencias Mad, la verdad que yo me fui para el lado contrario! :)

Nunca usé USB externos ya que me parece poco cómodo andar con el disco, además de quedar anti estético los cables y la cajita al lado de la PS3 (y pérdida de un puerto USB).

Lo que hice fue comprar un disco de 1 TB y usarlo de interno. Siempre pasé los archivos por FTP, pero desde que me pasé a MLT 4.46 y Cobra, convertí todo en mi NAS a ISO y ahora tengo una imagen por cada juego, que es la que copio via FTP. Estas ISOs están comprimidas con 7z al extremo, ahorrando casi un tercio de espacio por cada juego.

A la hora de jugar a algo ingreso al 7z desde Directory Opus, que lo lee nativamente, y copio la ISO via FTP (también es cliente FTP!). Ese es mi "ecosistema" para jugar hoy en día

Por eso evito discos externos ya que me parece engorroso y sobre todo ahora, con el plugin FTP, es más fácil todavía copiar los juegos con solo tener la PS3 prendida!

En fin... volviendo al tema original, por qué no funciona más el Iris 2.65/2.70 ahora? No se supone que soporte MLT 4.46 + Cobra + los plugins posteados por MLT??? (no webMan ni cosas raras)

Gracias
Dan_Aykroyd escribió:En fin... volviendo al tema original, por qué no funciona más el Iris 2.65/2.70 ahora? No se supone que soporte MLT 4.46 + Cobra + los plugins posteados por MLT??? (no webMan ni cosas raras)


Estamos en transición, hay que tener paciencia. Ahora mismo hay peticiones para que el "mamba'" soporte CFW 3.55, para que la emulación de PS2 del Cobra se incorpore al "mamba", algunos problemas con las herramientas ISO y los juegos con gran número de ficheros, etc... el tema de FTP, pues ya encontrará solución de una forma u otra.

R.
Rasterian, todos los problemas que mencionás son cosas nuevas introducidas por el Mamba o pedidos que hace la gente para que tenga funciones nuevas, soporte CFW anteriores, etc

La diferencia con lo que menciono yo es que constituye lo que se conoce como una "regresión". Una versión nueva deja de funcionar como lo venía haciendo y sin planificarlo.

No se a ciencia cierta si es el FTP_plugin o el test_plugin, pero ambos fueron posteados por MLT y funcionan perfectamente hasta Iris Manager 2.60B. Luego de ahí (2.65 en adelante) no arrancó nunca más. Algo falla...

Saludos
La cuestión no es tanto deliberar si los cambios necesarios son una "regresión" o una "progresión"... sino que requieren tiempo y trabajo. Y ahora mismo entiendo que solo hay un tipo trabajando en ello, Estwald. Y ya hace mucho él solo, la verdad. Y en cualquier caso, tendrás que convencerle a él de la crucial importancia del FTP, yo no administro su tiempo (y soy del bando de USB) :)

Un saludo!
Por supuesto, antes que nada le agradezco a Estwald y no demando nada! Yo contento de quedarme en 2.60B si así fuera! XD

Tampoco es para convencerlo por el FTP, ya que no es solamente ese el problema sino que puede surgir con cualquier otro plugin según lo que comenté unos posts atrás (en resumen, que el Iris no detected Cobra, active Mamba; o si lo detecta que se líe con los plugins que ya están cargados y quiere igualmente cargarlos él mismo... no sé lo que hará!)
Sobre los plugins... lo que es una regresión, es usarlos, tal como los usáis, para empezar.

Lo siento, pero en eso soy inflexible: no quiero plugins rulando en segundo plano con iris Manager y no es culpa mía, si el que los programa, no los diseña de forma que permita desinstalarlos del sistema (el del Cobra ya lo dejó avisado), sin petarlos (que hagan las cosas bien y entonces, a lo mejor considero la posibilidad de lanzarlos cuando salgáis de Iris Manager, incluyendo un pequeño gestor).

¿Por qué rawseciso se desinstala 50 veces y no peta?. Pensadlo un poco...

Sobre el creado de ISOs. En primer lugar, que se hagan splits no es ningún problema, al revés, dudo mucho que metáis en un disco duro un juego grande, sin que se haga algún fragmento que otro de forma interna y sin embargo, partidas, permite meterlas en FAT. El error de extracps3iso ya lo arreglaré en otro momento.. Por lo que veo, hay juegos que leen la parte cifrada (que nosotros no tenemos, obviamente) y a lo mejor os viene bien usar con esos otras herramientas. No se si habrá algún bug, por que a mi, de momento, no me ha dado ninguno y de poco me sirve que digáis que con tal juego tienes tal problema, si yo no tengo el juego y no puedo saber el porqué... esto es open source y cualquiera que pueda colaborar, tiene vía libre, pero no podéis pedir peras al olmo XD .

En todo caso, en consola es lo que hay: la idea de hacerlo en PC, era para tener las herramientas también en consola. El parcheo de versión (error 0x80010009) he dicho como 500 veces que se hace "Comprobando Archivos"

Sobre el nuevo Core, tiene poco que ver con como lo hace MiralaTijera, excepto en que lanza el sm.self.

En primer lugar, este core puede lanzar el sys_init_osd.self original, renombrado como sys_init_osd_orig.self (habría que tener cuidado aquí de no usar el de MiralaTijera) o vsh.self directamente (es lo que hace MiralaTijera y funcionar, funciona). Si no consiguiera cargar estos, intentaría cargar "emergency.self" desde raíz de /dev_usb000 (se supone que sería un self reparador)

Como su objetivo actual es lanzar sm.self, en lugar de hacer como MiralaTijera, que intenta montar el dispositivo /dev_usb000 (y si no está conectado, espera hasta 15 segundos) esto funciona diferente: lanza el sys_init_osd_orig.self o el vsh.self primero y espera un máximo de 12 segundos después, hasta que vsh.self monta el dispositivo usb (que debería ser una pendrive, pues los HDD, son lentos)

¿y que logramos con esto?. Pues... que el mando no se desincroniza y que sin USB conectado, aproximadamente, al poco de cuando el XMB muestra la pantalla de la epilepsia, entra en acción el sm.self

O dicho en plata: el sm.self se lanza mas o menos igual, pues MiralaTijera espera hasta 15 segundos a que haya un dispositivo conectado y yo espero 12 en este caso, pero mientras que nosotros estamos ya funcionando en paralelo con vsh.self, en el core de MiralaTijera aún queda por cargarlo. Así que en general, es más rápido a mi manera y encima, no desincroniza el mando, ni necesita un pendrive conectado para acelerar el arranque, puesto que el lanzado del sm.self es indiferente al arranque del sistema.

Antes de cargar el sm.self, se "escuchan" las flags. Y aquí vienen los cambios:

- Nosotros solo soportamos la instalación del new_core.self (sys_int_osd.self finalmente) y del sm.self y flag relacionados con estos. Esto permite que sea compatible teóricamente con cualquier CFW (que sea soportado por el sm.self, pues el core es, así como está, teóricamente universal)

- El sm.self puede ser cargado en primer lugar, desde /dev_usb000 renombrándolo como sm_external.self y poniéndolo en raíz y si éste no está, como sm.self desde raíz de /dev_flash (o sea, como siempre). Esto permite probarlo desde fuera o cargar cualquier otra cosa en su lugar.

- Las instalaciones no son como con el Core de Miralatijera: en primer lugar, nada de meter los ficheros en raíz y que el core las pille al vuelo, sin saber que está metiendo. Para empezar, los ficheros a instalar (dos, el new_core.self y sm.self) deben estar en la carpeta "core_install" y en "flags" debemos crear un fichero "install" para que la haga caso.

Luego, el proceso de copiado trata de ser lo mas seguro posible: primero, se copian los archivos con nombres temporales, asegurándose de que se han copiado correctamente. Y luego, mediante un sistema de renombrado pasan a tener su nombre definitivo (en el caso del Core, el antiguo sys_init_osd.self, quedaría como sys_init_osd_old.self. En el de sm.self, solo queda el nuevo). Una vez finalizado, renombra la flag como "_install" (o la elimina, si ya existe _install), pero no elimina los ficheros de "core_install" ;)

Las flags que utiliza el core, son:

ignoresm -> Permite ignorar la carga de sm.self (puede ser útil si esta mal y cuelga la consola, por ejemplo)

removesm -> Borra el sm.self de /dev_flash (lo mismo que con el core de MiralaTijera)

install -> instala sm.self y/o new_core.self. Luego, se renombra como _install

verbose -> El core crea un core_log.txt conteniendo alguna información sobre como va actuando. Si no se especifica, solo crea/actualiza el core_log.txt durante el proceso de instalación de ficheros (con la flag 'install' activa). En mi opinión, es mejor que "verbose" no esté activa, salvo qur por alguna razón, la necesitemos (así evitamos escribir en cada arranque sobre el dispositivo USB información redundante y como veis, en el proceso de instalación tampoco hace falta activarla)

Como veis, es un core muy sencillo, sobre todo por que estoy evitando todo aquello que pudiera tener una dependencia de un CFW en particular , aparte de que hay cosas específicas que sin el permiso de MiralaTijera no puedo incluir o trabajar.


El problema, como siempre, es que si vais a tener mierdas de fondo pululando (como plugins), a saber lo que pasa, aparte de que yo no puedo saber de primera mano si hay o no hay problemas en consolas Slim, etc. Así que viendo el cariz que está tomando el asunto, con las "regresiones" y "progresiones" lo mismo al final, no saco nada por que no tengo ganas de que alguien pete su consola por meter cosas que yo no tengo dando por saco y encima, me den un disgusto [decaio] .

Saludos
Oye stewald, yo tengo el cfw 4.46 rogero, y me gustaria saber si funciona bien el mamba
Estwald si deseas un beta tester para consolas Slim, yo me ofrezco, tengo flasher para recuperar la consola por si llega a petar.

Saludos
Estwald y funcionara el nosleep de los discos duros?
Miguel20 escribió:Oye stewald, yo tengo el cfw 4.46 rogero, y me gustaria saber si funciona bien el mamba


Hola Miguel20 yo estoy usando Habib 4.53 1.01 versión sin Cobra. Con con Iris 2.70 con Mamba con mas de 20 ISOS en un HD externo en NTFS. Y estoy encantado la verdad no uso ni un plugin ni nada en la consola, ni juego online y funciona todo perfectamente lo de poner los juegos en iso al disco externo NTFS e ganado en velocidad de transferencia y cargas con las ISOS mucho mas rapido que antes.

Creo que para 4.46 sin cobra funciona perfectamente así que tu mismo.

En fin que estoy muy contento con lo que hay ahora mismo solo falta a ver si nuestro maestro Estwald al cual estoy y estamos muy agradecidos por todo lo que hace, consiga lo de los ventiladores aunque ahora en invierno no hace mucha falta pero para el veranito si convendria..

Saludos.
Estwald escribió:El problema, como siempre, es que si vais a tener mierdas de fondo pululando (como plugins), a saber lo que pasa, aparte de que yo no puedo saber de primera mano si hay o no hay problemas en consolas Slim, etc.


Podrías hace un instalador bien restrictivo, que no acepte CFW de Cobra o de MLT. Así el que quiera instalarlo, que se comprometa antes a prescindir de plugins.

Y también podrías hacer una excepción y no liberar el código del instalador para prevenir problemas; si otros desarrolladores lo quieren de otra forma, que lo hagan enteramente bajo su responsabilidad. Los que hacen CFWs sí podrán incorporar los componentes.

Yo me ofrezco a hacer una traducción bien precisa del readme al inglés, si eso ayuda, para que los requerimientos y riesgos queden meridianamente claros.

R.
El tema de los plugins, la verdad que esta muy raro que les de fallo a la gran mayoría.

Por ahora, solo tengo el test y ntfs_ext. Con esos dos plugins, el Iris Manager versión 265 270 me han trabajado perfectamente.

Creo que a la gente que le ha dado problemas, quizás queden rastros de webman por ahí y esa quizás sea la razón del fallo.

Solo me queda decir, que la scene del ps3 esta en su época dorada [carcajad] , con eso del core Estwald, si funciona en todos los CFW, sera como una luz para los demás CFW y la gran mayoría de ps3 van estar mas que feliz.
Todavía estoy un poco reticiente a usar Iris mánager porque nunca lo he usado (y aprenderse todos los comandos es un trabajo), pero ahora que tiene soporte ntfs (en .iso solo) y un discless 100%, pues me pasaré. El problema es que estoy en 3.55 xDD
rocknard escribió:Todavía estoy un poco reticiente a usar Iris mánager porque nunca lo he usado (y aprenderse todos los comandos es un trabajo), pero ahora que tiene soporte ntfs (en .iso solo) y un discless 100%, pues me pasaré. El problema es que estoy en 3.55 xDD


Pasate a 4.46 MLT o Habib 4.53 Cobra q van de lujo, antes de instalar el CFW instala los QA FLAGS

Un saludo
Una pregunta se puede bajar el update de los juegos desde iris manager sin necesidad de ejecutar el juego? es que algunos como los que tienen el eboot modificado por duplex si ya generaste la iso pues no se puede descargar directamente al ejecutar el juego :S
Rasterian escribió:
Podrías hace un instalador bien restrictivo, que no acepte CFW de Cobra o de MLT.

R.


no creo que haga falta, yo estoy en 4.46 1.03 Habid Cobra y me funcionan todas las isos de PS3 en NTFS disco externo y también en ese mismo disco tengo juegos en el formato de ficheros y también me funcionan todos (concretamente he probado 59 juegos). Eso si, sólo tengo el CFW, el Iris 2.70 y el Multiman para cuándo quiero jugar a isos o carpetas que tengo en el PC.

Saludos,
Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.

un saludo
abufa escribió:Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.

un saludo


Si; y en mi caso no lo reconocio.
Faxtron escribió:
abufa escribió:Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.

un saludo


Si; y en mi caso no lo reconocio.

suena interesante pero estan soportadas tablas de particiones GPT para particiones mayores de 2TB ?

ESTWALD te pido ayuda, quiero modificar el PKG instalador de IRIS para que lleve una pre-configuracion o sea un "manager_setup.bin" preconfigurado por mi

Tambien te daria una sugerencia para el nuevo "System Manager", no se si se te habra ocurrido pero seria interesante que sea el propio IRIS quien instale SM y permita desinstalarlo y tambien reporte su presencia ya sea en activo o no, todo desde el menu de configuracion de IRIS.

GRACIAS por tu atencion.
Faxtron escribió:
abufa escribió:Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.

un saludo


Si; y en mi caso no lo reconocio.


¿Desde Iris Manager tampoco?

En teoría tenemos soporte para sectores de más de 512 bytes... y digo, en teoría, por que no tengo ningún disco duro de esos para probar.

Mis modificaciones del plugin iban en ese sentido e igualmente, en la librería, pero claro, tal vez el problema este en otro lado, si lo hay (lo mismo cambia algo en las particiones). Si no lo has probado con Iris, mira a ver.

alexjrock escribió:Estwald si deseas un beta tester para consolas Slim, yo me ofrezco, tengo flasher para recuperar la consola por si llega a petar.

Saludos


A ver si mañana te puedo enviar un MP con todo, que ando petado de tiempo durante el día.

He cambiado algunas cosas: ahora tenemos dos flags de instalación y otras dos nuevas.

Las flags, para evitar colisiones con el Core de MiralaTijera, se instalarán en "core_flags", mientras que la actualización del Core o del sm.self, si la hubiera, irán en "core_install"

Ahora el Core puede trabajar de la nueva manera (es decir, haciendo las cosas en paralelo con vsh.self) o a la manera de MiralaTijera (haciendo las cosas antes de cargar vsh.self).

Para ello son las dos nuevas flags: "boot_on" instala una flag en "/dev_flash" para indicarle que queremos que haga las cosas antes de cargar vsh.self, mientras que "boot_off" desactiva ese modo. Hasta el momento, yo no he visto problema en actualizar los ficheros en paralelo con vsh.self por ejemplo, pero no es mala idea poder fijar ese modo en un momento dado.

Obviamente, con "boot_on" se producirá desincronización del mando...

Basado en la misma idea, son las dos flags de instalación: "install" activa en /dev_flash una flag temporal, crea "install2" en /dev_usb000 y reinicia la consola para poder hacer la instalación antes de vsh.self (y luego otra vez, para aplicar los cambios). Esto da una idea de como pueden trabajar otras funciones que soporta el Core de MiralaTijera en el futuro, que requieren esta forma de funcionar (hay otras como por ejemplo, el "anotherlv2" que se pueden hacer directamente: yo de hecho, tengo un LV2 modificado para que lance sys_init_osd2.self en lugar del de siempre y una aplicación que carga el new_core.self debidamente en la flash y luego lanza ese LV2, para probar de forma segura el Core XD).

Si solo se especifica "install2" en ese caso, se instalan los ficheros de forma paralela a vsh.self y se reinicia después, para hacer efectivos los cambios.

Las flags como "install" o "install2" se desactivan a posteriori anteponiendo "_". Lo mismo pasa con los ficheros de instalación: si no hay algún error que haya impedido la instalación, sm.self se renombrará como _sm.self y new_core.self como _new_core.self.

Esto está pensado para evitar situaciones cíclicas, reinstalaciones accidentales que puedan causar problemas de semibrick, exponeros al mínimo a ese riesgo (copiado de ficheros de forma segura y renombrado posterior, de forma rápida, para minimizar los riesgos) , pero para conservar los ficheros (MiralaTijera los borra) y también evitar el uso de las flags de forma indebida.

También hay que tener en cuenta que aunque ahora mismo, básicamente, nos limitamos a cargar sm.self y actualizar el Core, en el futuro podrían haber mas funciones y el core tiene que estar preparado para ello.

El código se compila bajo PSL1GHT, tal como está, debería se compatible con todos los CFW en principio, aunque el sm.self solo trabajará para los que esté adaptado, obviamente. También suministrare los fuentes y la liblv2 ya compilada, con lo que se precisa.

De esa forma, los que se dedican a hacer CFW, lo podrán incluir (si quieren).

EDIT:

BillGates escribió:ESTWALD te pido ayuda, quiero modificar el PKG instalador de IRIS para que lleve una pre-configuracion o sea un "manager_setup.bin" preconfigurado por mi

Tambien te daria una sugerencia para el nuevo "System Manager", no se si se te habra ocurrido pero seria interesante que sea el propio IRIS quien instale SM y permita desinstalarlo y tambien reporte su presencia ya sea en activo o no, todo desde el menu de configuracion de IRIS.

GRACIAS por tu atencion.


A lo primero, debes editar el Makefile. Te muestro por ejemplo, el código de "pkg" (sin animación)

pkg: $(BUILD) #$(OUTPUT).pkg
   @$(MAKE) --no-print-directory -C $(CURDIR)/loader -f $(CURDIR)/loader/Makefile npdrm
   $(VERB) echo building pkg ... $(notdir $@)
   $(VERB) mkdir -p $(BUILDDIR)/pkg/USRDIR
   $(VERB) cp $(ICON0) $(BUILDDIR)/pkg/ICON0.PNG
   $(VERB) cp -f $(CURDIR)/loader/EBOOT.BIN $(BUILDDIR)/pkg/USRDIR/EBOOT.BIN
   $(VERB) cp -f $(CURDIR)/$(TARGET).self $(BUILDDIR)/pkg/USRDIR/iris_manager.self
   $(VERB) $(SFO) --title "$(TITLE)" --appid "$(APPID)" -f $(SFOXML) $(BUILDDIR)/pkg/PARAM.SFO
   $(VERB) if [ -n "$(PKGFILES)" -a -d "$(PKGFILES)" ]; then cp -rf $(PKGFILES)/* $(BUILDDIR)/pkg/; fi
   $(VERB) $(PKG) --contentid $(CONTENTID) $(BUILDDIR)/pkg/ $(TARGET).pkg >> /dev/null


Si te fijas, hay varios "cp" $(CURDIR) representa el directorio donde está el Makefile y $(BUILDDIR)/pkg donde se está formando el pkg. Para con animación es lo mismo, pero en ese caso "pkg2".

El parámetro -f lo que hace es forzar el copiado, por cierto.

Sobre lo que dices de instalar sm.self desde Iris... no se exactamente a que te refieres con eso:

- Si te refieres a lanzar el sm.self desde el propio Iris Manager, no se puede, o mejor dicho, si lo lanzas, tienes que salir del sm.self y de Iris Manager para poder hacer otra cosa (de hecho, en mi Core, pretendía mantenerlo en un bucle para ver si podía lanzar otros selfs en segundo plano, más adelante, mediante una treta y se quedaba vsh.self esperando a que saliera de mi Core...).

- Si te refieres a copiar el Core completo, dando una opción en Iris Manager, se puede desde el Archive Manager y si quieres mantener una copia del sys_init_osd original, lo tendrá que hacer manualmente (el problema es que yo no puedo asumir automáticamente esa tarea: si el sys_init_osd.self resulta ser el Core de MiralaTijera, no nos interesa mantener esa copia, por que habrá conflicto), pero la tarea en si de copiar el Core a su sitio la primera vez, lo puede hacer otra herramienta que luego se puede desinstalar, con menos trabajo por mi parte y de forma mas segura.

- Si te refieres a actualizar tanto el Core como el sm.self, para eso tiene el propio Core sus propias flags y es más seguro hacerlo ahí, que desde Iris y en todo caso, DEBE poder hacerse desde el Core.

Mi filosofía de trabajo no es darle a la gente lo que cree que quiere, si no lo que a mi me parece oportuno ofrecer de la forma más segura posible. Ya sabemos todos que los programas no están exentos de la posibilidad de error (que fácil es cagarla...) y lo que es peor, que se pueden interferir unos con otros... por lo que siempre es preferible que las cosas se hagan donde y cómo se tienen que hacer.

Por ejemplo, mi consola se enladrilló por culpa de que si el stage2.bin de Cobra está chungo, no tienes medio de saltártelo. Si yo cargara ese stage2.bin desde el Core, produciría un semibrick (no podrías entrar en Restaurar archivos y cosas así, por que entonces la cagarías, pero si podrías actualizar la consola!). Aún así, me vería obligado, por seguridad, a cargar desde USB o al menos, tratar de hacerlo desde HDD0, si se puede, con checkeo de protección (algo así como que si no puede montar el HDD0, borrara una flag en la flash, que hiciera que no pudieras cargar el stage2.bin), pero mucho mejor usar "Mamba" por que si ahí falla algo, se cuelga la consola, se reinicia y a otra cosa.

Yo nunca jamás metería una lista para lanzar plugins en el arranque, sin posibilidad de borrarla de ninguna manera, si algo falla, que puede fallar por que esté mal formada o por que algún plugin (algunos no respetan la posibilidad de ser desenchufados...) sea incompatible con algo. Es más, tengo cierta prudencia en liberar mi Core, pues lo normal es que funcione perfectamente, pero puede ser que no lo haga bajo ciertas condiciones (plugins rulando que no tenían que estar, por ejemplo). O el "bug" de Cobra (ocasionado según creo, para que funcione netiso) , que hace que sm.self solo pueda funcionar en un solo hilo y sin poder bajar las prioridades, con el perjuicio que ocasiona eso: no es casualidad que con 'Mamba' sí funcione en Multihilo, pues 'Mamba' es cargado DESPUES y no interfiere.

Con esto pretendo explicaros a todos que muchas veces, no es por ser aguafiestas, por lo no que no se hacen las cosas: puede no interesarme, o parecerme demasiado trabajo hacer algo para el poco provecho que le voy a sacar, pero muchas veces, hay otro tipo de razones relacionadas con la seguridad de hacer las cosas y la prudencia, lo que hace que prefiera no hacerlo (por ejemplo, el nuevo sm.self, va a tener por defecto, desactivado lo del "nosleep" y tendrá que activarlo Iris Manager, si vosotros queréis: es mas aconsejable hacerlo así, pese a que no he tenido ningún problema con eso. Pero vosotros no sois yo y os encanta meter otras mier... digo, cosas XD y en principio, se metió esa opción para los que usáis Multiman mas que para otra cosa (la opción por defecto, escanea todos los dispositivos: menos óptimo y más problemático que fijar uno solo como hace Iris Manager, pero si Deank no adapta el método, solo podía ofrecer esa vía que ahora, la quiero dejar desactivada por defecto)

A fin de cuentas, no se trata de que yo me luzca haciendo programas, si no que mis programas sean compartidos con las máximas garantías posibles a mi alcance (sin pretender cubrir lo que hacen otros: ese no es mi problema, mi problema es que las cosas funcionen bien con lo que yo hago y que la gente pueda ver lo que hago, por medio del código fuente, por si ellos tienen que tener en cuenta algo, o a mi me pueden pedir algún cambio que proporcione compatibilidad mutua): me puedo equivocar, como todo el mundo o pueden surgir cosas que no haya previsto, pero lo que sería imperdonable, es que eso ocurriera por dejadez mía, o por estar en una absurda carrera por ser el primero en algo u ofrecer algo distinto sabiendo de sobras que eso puede ocasionar problemas y sin hacer nada para evitarlo (y eso lo hemos visto demasiadas veces en esta scene). Al menos, si surge algo, que quede el consuelo de que ha sido un fallo que se me escapa y que en mis pruebas no ha aparecido, ni me inducían a pensar que ocurriría.

Por algo en todos estos años, solo he tenido un brick (habiendo hecho hasta un CFW: funcionó a la primera y no, no fue suerte, sabía que iba a funcionar y aún así estuve en vilo hasta que me confirmaron que no daba problemas en el resto de máquinas, por que era mi responsabilidad hasta cierto punto y me preocupo más por vuestras consolas que vosotros mismos, que alegremente os lanzáis a hacer de betatesters con fe ciega XD ) fue precisamente, por modificar algo que no cumplía con los márgenes mínimos de seguridad que yo me autoimpongo (y cuanto me he fustigado yo, por haber cometido ese error de tocarlo, sin tener las máximas garantías de que podría recuperarlo y suponer que el de cobra no sería tan corto de miras para no prever algo tan básico... pero en el fondo, la culpa es mía por suponerlo o no estar en ese momento, suficientemente preparado para ello, aunque en el stage2.bin que compilé, básicamente, no había nada mal, que esa es otra XD: el fallo viene por otro lado) y como de los errores se aprende, ahora tenemos 'Mamba' (y yo de cara al usuario, quiero mantener compatibilidad con Cobra que tenemos, pero si me puedo mantener en un CFW que me permita usar 'Mamba', ahí es donde voy a estar yo y no por que sea mi trabajo, si no por que Cobra no me da sensación de seguridad, después de lo que me pasó y creo que los que han pasado a CFW habib 4.53 con Cobra, ya han visto los problemas que se han presentado, todos ellos evitables con el uso de 'Mamba', por mucho que alguno lo pueda considerar un "retroceso" frente a un teórico CFW Cobra "completo".

Yo prefiero pájaro en mano, que ciento volando. Y nadie ha dicho que no se puedan lanzar emuladores desde ese pájaro en un caso hipotético, si no que se ha prescindido de ello por que no compensa (si me compensara y no estuviera con otras cosas, los emuladores estarían funcionando, si no ahora, mañana o pasado. O buscaría un método alternativo para arreglar el problema) y se prefiere apostar por una portabilidad más fácil que asegure ese pájaro, que es entre el 90% y el 100% de los usos que le van a dar la mayoría de los usuarios y tener un método mas seguro.

Por eso que expongo, hay cosas que se pueden hacer, pero no se hacen: no porque no se puedan, si no por que no se deberían hacer de esa manera, sobre todo si sabes que en un caso, puede ocasionar problemas serios...

Saludos
Rasterian escribió:Aquí va un bug report de makeps3iso. He tenido ocasión de seguir probando lo que comenté ayer:

Rasterian escribió:Probado sobre Rebug 4.46.1 REX:
[...]
- Cuelgue en proceso de carga de Demon's souls (BLES00932) convertido a ISO splitfiles desde unidad USB en NTFS (ya sé que es una combinación extraña, es lo que me generó el makeps3iso al ejecutarlo por primera vez). Este título es complicado, porque tiene 12000 ficheros, nunca lo he llegado a pasar al HDD0. Volveré a probar generando una ISO con el makeps3iso sin "splitear" y otra con el isotools de 3k3y y un fichero IRD.


Ahora puedo confirmar que no funciona con la ISO generada por el makeps3iso, spliteada o sin splitear, pero sí funciona con la ISO generada por el isotools de 3k3y (utilizando fichero IRD de su página). Con el makeps3iso, el juego se cuelga en el primer mensaje que sale tras arrancar.

Los ficheros que tengo pasan la verificación de hash del IRD con el isotools, así que el problema parece estar en el proceso de generación de la ISO del makeps3iso. He generado y ejecutado todas las ISOs sobre la misma unidad USB, que no está fragmentada.


Hoy tenía las dos ISOs delante en el PC y las he abierto por curiosidad para ver si observaba el origen del problema. Y efectivamente, la del 3k3y contiene 12721 ficheros (exactamente los mismos que la carpeta del juego) y la del makeps3iso contiene 12694. Los ficheros que están en la primera pero no en la segunda son los siguientes:

PS3_GAME\USRDIR\sound\magicorchestra2.ini
PS3_GAME\USRDIR\sound\magicorchestra2.mgs
PS3_GAME\USRDIR\sound\map00.momd
PS3_GAME\USRDIR\sound\newmixerdata.momd
PS3_UPDATE\PS3UPDAT.PUP
PS3_GAME\USRDIR\sound\rpcsetting.rpc
PS3_GAME\USRDIR\parts\wp_a_1702_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1703.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1703.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1703_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1703_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1704.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1704.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1704_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1704_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1800.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1800.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1800_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1800_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_9999.partsbnd
PS3_GAME\USRDIR\parts\wp_a_9999.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_9999_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_9999_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_c_0201.partsbnd
PS3_GAME\USRDIR\parts\wp_c_0201.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_c_0201_l.partsbnd
PS3_GAME\USRDIR\parts\wp_c_0201_l.partsbnd.dcx

Lo dejo aquí puesto por si es de utilidad para identificar el problema en makeps3iso más adelante (aunque no veo un patrón claro en las rutas y los nombres). De todas formas, ahora mismo me parece mucho más valioso lo del SM para complementar "mamba" :)
Rasterian escribió:
Rasterian escribió:Aquí va un bug report de makeps3iso. He tenido ocasión de seguir probando lo que comenté ayer:

Rasterian escribió:Probado sobre Rebug 4.46.1 REX:
[...]
- Cuelgue en proceso de carga de Demon's souls (BLES00932) convertido a ISO splitfiles desde unidad USB en NTFS (ya sé que es una combinación extraña, es lo que me generó el makeps3iso al ejecutarlo por primera vez). Este título es complicado, porque tiene 12000 ficheros, nunca lo he llegado a pasar al HDD0. Volveré a probar generando una ISO con el makeps3iso sin "splitear" y otra con el isotools de 3k3y y un fichero IRD.


Ahora puedo confirmar que no funciona con la ISO generada por el makeps3iso, spliteada o sin splitear, pero sí funciona con la ISO generada por el isotools de 3k3y (utilizando fichero IRD de su página). Con el makeps3iso, el juego se cuelga en el primer mensaje que sale tras arrancar.

Los ficheros que tengo pasan la verificación de hash del IRD con el isotools, así que el problema parece estar en el proceso de generación de la ISO del makeps3iso. He generado y ejecutado todas las ISOs sobre la misma unidad USB, que no está fragmentada.


Hoy tenía las dos ISOs delante en el PC y las he abierto por curiosidad para ver si observaba el origen del problema. Y efectivamente, la del 3k3y contiene 12721 ficheros (exactamente los mismos que la carpeta del juego) y la del makeps3iso contiene 12694. Los ficheros que están en la primera pero no en la segunda son los siguientes:

PS3_GAME\USRDIR\sound\magicorchestra2.ini
PS3_GAME\USRDIR\sound\magicorchestra2.mgs
PS3_GAME\USRDIR\sound\map00.momd
PS3_GAME\USRDIR\sound\newmixerdata.momd
PS3_UPDATE\PS3UPDAT.PUP
PS3_GAME\USRDIR\sound\rpcsetting.rpc
PS3_GAME\USRDIR\parts\wp_a_1702_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1703.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1703.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1703_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1703_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1704.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1704.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1704_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1704_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1800.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1800.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_1800_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_1800_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_9999.partsbnd
PS3_GAME\USRDIR\parts\wp_a_9999.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_a_9999_l.partsbnd
PS3_GAME\USRDIR\parts\wp_a_9999_l.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_c_0201.partsbnd
PS3_GAME\USRDIR\parts\wp_c_0201.partsbnd.dcx
PS3_GAME\USRDIR\parts\wp_c_0201_l.partsbnd
PS3_GAME\USRDIR\parts\wp_c_0201_l.partsbnd.dcx

Lo dejo aquí puesto por si es de utilidad para identificar el problema en makeps3iso más adelante (aunque no veo un patrón claro en las rutas y los nombres). De todas formas, ahora mismo me parece mucho más valioso lo del SM para complementar "mamba" :)


¿Podrias pasarme solo el árbol de directorios?

Es decir, las carpetas, sin los ficheros, en un comprimido, tal y como lo tienes tu.

Tal vez con eso averigüe donde está el problema (seguramente, en la ordenación de carpetas, pero no es lo mismo tener un ejemplo práctico que suponerlo).

Saludos
Estwald escribió:
Faxtron escribió:
abufa escribió:Alguien ha probado algún disco de 3TB si la PS3 se lo reconoce ahora en NTFS a la hora de cargar juegos??.

un saludo


Si; y en mi caso no lo reconocio.


¿Desde Iris Manager tampoco?

En teoría tenemos soporte para sectores de más de 512 bytes... y digo, en teoría, por que no tengo ningún disco duro de esos para probar.



Acabo de probar uno de 4 TB formateado al completo en NTFS la play no lo reconoce desde el XMB pero el Iris Manager SIIIII :) :) :) :) .

He probado con una ISO de un juego y lo ha cargado perfectamente.

Eres una makina Estwald :)

Un saludo
abufa escribió:Acabo de probar uno de 4 TB formateado al completo en NTFS la play no lo reconoce desde el XMB pero el Iris Manager SIIIII :) :) :) :) .

He probado con una ISO de un juego y lo ha cargado perfectamente.

Eres una makina Estwald :)

Un saludo


Eso es parte del trabajo silencioso que hice: arreglé el método que usaba el de cobra para obtener la lista de sectores para que tuviera en cuenta un tamaño diferente de 512 bytes y lo mismo hice con rawseciso: teóricamente, debería funcionar (yo no tengo un HDD de ese tipo, para hacer pruebas, pero el fuente de la librería NTFS teóricamente, lo tiene en cuenta y solo había que adaptar lo necesario para las ISOS) y ahora confirmas tu que en la práctica lo hace. El código fuente de ambos está disponible (uno en el RAR de Iris Manager y otro en el git), pero adaptarlo a sus programas es cosa de otros.

De hecho, ahora mismo, todas las ISOS van desde rawseciso interno, sean del dispositivo que sean y puedes incluso desenchufar y enchufar el disco duro, que aguanta (eso si, si no lo enchufas, se quedaría la consola esperando a que lo hicieras, en cuanto tratara de leer [+risas] ). Solo la falsa ISO de los juegos en ficheros sueltos y las ISOS de PS2 (en 4.46) van por el método antiguo de Cobra

Saludos
No dejas de sorprenderme Estwald :O :O ...lo acabo de poner a prueba otra vez con un juego con mas caña como el "Beyond Two Souls" que son mas de 30 GB en un único archivo iso y funcionado correctamente.

Igual al compi Faxtron ha dicho que no se lo ha detectado el disco porque en el Iris Manager no le ha marcado la capacidad y espacio libre en disco como lo hace con las unidades en fat32 en la parte superior derecha. En este caso solo marca que es unidad ntfs.

Voy a probar eso que me comentas de desconectar el disco en caliente y volver a conectar para confirmarte que funciona, aunque igual esto si lo has podido comprobar por ti mismo.

un saludo makina ;) y muchas gracias por tu trabajo silencioso :)
Estwald, te lo he dicho varias veces pero no me canso de decirte q es para quitarse el sombrero todo lo q haces por la scene... IMPRESIONANTE

Saludos crack
Estwald hay alguna forma que desde el mismo iris manager puedas bajar los updates de los juegos? es que por ejemplo tengo el iso del GTA V de duplex y es una jodienda corregir y deshacer el iso :S para que deje bajar el update directamente desde el juego. ya que al ejecutarlo con el eboot modificado este hace que se reinicie la consola.
emulation escribió:Estwald hay alguna forma que desde el mismo iris manager puedas bajar los updates de los juegos? es que por ejemplo tengo el iso del GTA V de duplex y es una jodienda corregir y deshacer el iso :S para que deje bajar el update directamente desde el juego. ya que al ejecutarlo con el eboot modificado este hace que se reinicie la consola.


puedes bajar el update desde el pc e instalarlo por usb...

no esperes...

Saludos...
Claro esa es una opción pero al usuario común se le complica el asunto ya que debe ver la id del juego en cuestión luego buscar el programa luego ver si esta disponible bajarlo, ponerlo en un usb e instalarlo.

en cambio desde el mismo programa entras busca el sólito todo. lo bajas y luego vas y lo instalas. el usuario se ahorra muchísimos pasos. Multiman hace eso con los juegos en formato JB pero... dizque en su nuevo método hace lo mismo en juegos con NTFS e isos pero al menos a mi no me funciona y desde webman menos porque el update lo baja desde el mismo juego y con el eboot modificado pues no funciona... por eso y viendo que con iris suele ir bien seria una buena adición al programa.
emulation escribió:Claro esa es una opción pero al usuario común se le complica el asunto ya que debe ver la id del juego en cuestión luego buscar el programa luego ver si esta disponible bajarlo, ponerlo en un usb e instalarlo.

en cambio desde el mismo programa entras busca el sólito todo. lo bajas y luego vas y lo instalas. el usuario se ahorra muchísimos pasos. Multiman hace eso con los juegos en formato JB pero... dizque en su nuevo método hace lo mismo en juegos con NTFS e isos pero al menos a mi no me funciona y desde webman menos porque el update lo baja desde el mismo juego y con el eboot modificado pues no funciona... por eso y viendo que con iris suele ir bien seria una buena adición al programa.


ok, entonces te tocara seguir esperando, o coger los fuentes y a programar, porque el jefe anda en otras cosas de las que no hay otras opciones...

yo tambien ando estudiando los fuentes a ver si adapto esta version a .iso...

Saludos...
Por eso pregunto si lo puede hacer si me dice que no tiene intencion pues ni modo. es solo una preguntita :)
Depués de todo lo dicho Estwald, ¿cuál crees tu que es el CFW óptimo para utilizar IM?, como ya dije más atrás me gustan las funcionalidades que aporta el 4.46 MLT + Cobra, pero si es necesario, por estabilidad, salir de ahí a otro CFW para que se lance mamba en vez de utilizar cobra, no tengo problema en prescindir del emu de PS2.
Gracias Estwald por tus conocimientos y aportaciones!!! Sin ti esta scene estaría muerta!!! [tadoramo]

El fin de semana me pongo a actualizar mi PS3 y a convertir los juegos que tengo a .ISO, solo tengo unas cuantas dudas:

¿Que CFW me recomiendan? Estoy actualmente en MLT 4.50. Quiero usar los backups que tengo de PS3 en ISO, los backups de PS2 no me interesan, pero ¿los PSP remaster siguen funcionando?

En cuanto al particionamiento NTFS, ¿podré usar mi HDD-USB NTFS para almacenar mis rooms de mis emuladores y ejecutarlos desde ahí o los tengo que pasar al HDD interno?

Gracias por su ayuda!!! [tadoramo] [tadoramo]
Estwald escribió:¿Podrias pasarme solo el árbol de directorios?

Es decir, las carpetas, sin los ficheros, en un comprimido, tal y como lo tienes tu.

Tal vez con eso averigüe donde está el problema (seguramente, en la ordenación de carpetas, pero no es lo mismo tener un ejemplo práctico que suponerlo).

Saludos


Estwald, aquí está: https://www.dropbox.com/s/9tqxqhgjuufpog6/BLES00932dir.zip

La prueba definitiva creo que sería el Resident Evil 6, que tiene del orden de 16000 ficheros. :-)

Saludos
emulation escribió:Estwald hay alguna forma que desde el mismo iris manager puedas bajar los updates de los juegos? es que por ejemplo tengo el iso del GTA V de duplex y es una jodienda corregir y deshacer el iso :S para que deje bajar el update directamente desde el juego. ya que al ejecutarlo con el eboot modificado este hace que se reinicie la consola.


Si, YA tenemos manera [beer]

Es decir, he arreglado el código para trabajar con HTTP (luego dirán mis compis sceners que tiro mierda sobre ellos... pero, ¿cuando se enterarán de que nuestros compiladores trabajan con direcciones de 64 bits y los de SONY usan 32 bits?. Por que siempre estamos con los mismos problemas, cojones (se nota que no prueban nada de lo que portan)) y ya soy capaz de bajarme ficheros del servidor (el XML que describe las actualizaciones y un PKG, me he bajado).

Ahora faltaría hacer el intérprete, mirar que actualizaciones tienes instaladas y bajar PKG a partir de ahí, dando las oportunas opciones, etc y alguna cosilla más que habrá que adaptar.

Pero de momento, eso tendrá que esperar un poco XD (no es nada difícil, pero tengo compromisos que me restan tiempo, por que al fin ya al cabo, todo es cuestión de tiempo)

Rasterian, gracias por mandarme los directorios: en realidad, si hay algún fallo es ahí, el número de ficheros no importa, siempre y cuando, no de error la función de listarlos, por algún motivo).

El core lo tengo ya listo desde ayer: voy a ver si se lo mando a alexjrock para que lo testee en Slim y me cuente.

Saludos
Ohhh Gracias Estwald :) Yo puedo esperar, solo te preguntaba si era posible :) ya que en iris no encontre ninguna opcion que hiciera lo de los updates de juegos :p
Estwald, Habib en su reciente actaulización de CFW 4.53+COBRA v1.03 ha incluido el código fuente por si deseas echarle un vistazo.
Más info en la fuente

Saludos [bye]
5412 respuestas