


Ill give you samples if you please consider updating MakeH2OBen10UA and plz make MakeH2OBen10AF vilgax attacks xbox. It work like cahrm i love, it has some issus that i really want you to look at i hope you wont get madeįirst l_romd_d.ps3 boss cant get extracted properlyįile starts with i_xxx_d.ps3 has more then 100 plz remove the limet I admaier your work i tried useing your MakeH2O-bins-Ben10UA Dlls from the post of 20th Dec, 3:19 pm, required) (A +/- 1 correction of the vertex count might be required because sometimes the value in the ps3 file Also fixed the last submesh (quick fix only, may fail). Yeah, see, there was a problem with the H2O-Maker. TexList.append(NoeTexture(rapi.getInputName(), imgWidth, imgHeight, data, texFmt))īigchillghost wrote:Also another successful test of g_wh.ps3: #check if it's this type based on the dataĭata = rapi.imageUntile360DXT(rapi.swapEndianArray(data, 2), imgWidth, imgHeight, 8)ĭata = rapi.imageUntile360DXT(rapi.swapEndianArray(data, 2), imgWidth, imgHeight, 16) Handle = noesis.register("Vicious Engine 2 Ben 10 Series Games Textures", ".v2t") v2t:Ĭode: Select all #Supports Ben 10 Omniverse, Ben 10 Omniverse 2 and Ben 10 Galactic Racing for XBox360 Here is the improved script changing the extension to. But those exceptions that method doesn't support are all environment, vfx or scene maps, which are not so important. Maybe there're more dxt formats represented by the values greater than 0. Good news is that this method works for 99% textures from Ben 10 Omniverse, Ben 10 Omniverse 2, and Ben 10 Galactic Racing for XBox360, which have the same archive format. And I've worked it out: if the four bytes at 0x4C equals 0x 00 00 00 00, then it uses dxt1 format, if it's larger than 0 (currently known values include 0x1, 0x2 and 0x5), than it is dxt5 format. So I guess there must be a field inside the header of those files for identifing which format each texture uses.


Also, there're a lot of other textures that have no _d or _n postfix. For example, some textures named with _d are dxt5 format instead, while some named with _n are dxt1. When I split other textures from different archives, their names and the solutions of the script are actually contrary. Seems this script works perfectly only with those samples.
