Hey uh, concerning Fairy Fencer F and it's sequel, do you happen to know if any actual models exist of the fairies, specifically Eryn and Karin? The organization of the filesystem is kinda hard to decipher...

(09-30-2017, 02:19 PM)Carpaccio Wrote: Hey uh, concerning Fairy Fencer F and it's sequel, do you happen to know if any actual models exist of the fairies, specifically Eryn and Karin? The organization of the filesystem is kinda hard to decipher...

I don't think so, the only one I found was "303" but that's technically not the "proper" Eryn.

Anyway, I've update my Telltale Games model importer now (finally):
https://mega.nz/#!X9oSlTLC!2-K7JYcGobjrE...-5stmRUyoA
(EDIT: If you downloaded it earlier, please re-download, as I accidentally broke the TWD3 importer!)
(EDIT 2: And if you downloaded it before 10/10/2017, please re-redownload it as I'm a twit and made a stupid mistake.)

And I also updated the texture-converting QuickBMS script to fix the problems with Minecraft: Story Mode Season 2's textures not converting correctly.
https://mega.nz/#!35xByISR!R9ExvMyMqtUfB...HGNBv65HDw

Trying to rip from some of the Sonic 06 stage .XNO files, but getting an error on specific ones, most notably tpj_mapA_roadlm.xno under the Tropical Jungle Area A files, as well as several Kingdom Valley files. The error in question is:

Runtime error: array index must be positive number, got: undefined

Is there a quick way to fix that? Seems to have something to do with the Bone1 array.

How did you make a way to decode the unknown formats what did you use? QuickBMS? And the Luigi's Mansion .mdl files inside the .szp archive can you make a way to open and export those please??

(10-13-2017, 01:54 PM)SniperDude2745 Wrote: How did you make a way to decode the unknown formats what did you use? QuickBMS? And the Luigi's Mansion .mdl files inside the .szp archive can you make a way to open and export those please??

First part is research, trial and error, and countless hours of fiddling with coding. Second part:

(09-10-2016, 10:52 AM)Random Talking Bush Wrote:

(NOTE: THIS TOPIC IS NOT FOR REQUESTS!)

(10-07-2017, 10:40 PM)namine207 Wrote: Trying to rip from some of the Sonic 06 stage .XNO files, but getting an error on specific ones, most notably tpj_mapA_roadlm.xno under the Tropical Jungle Area A files, as well as several Kingdom Valley files. The error in question is:

Runtime error: array index must be positive number, got: undefined

Is there a quick way to fix that? Seems to have something to do with the Bone1 array.

I'm gonna have to do a ton of rewriting for the *NO script later, hopefully I can find and fix that problem then.

Random Talking Bush Wrote: I'm gonna have to do a ton of rewriting for the *NO script later, hopefully I can find and fix that problem then.

Does this mean you're going to add support for .CNO model files as well? Because it's been almost 3 years since it was last updated, and I would very much like it to receive an update.

(10-14-2017, 03:11 PM)MakutaMaster962 Wrote: Does this mean you're going to add support for .CNO model files as well? Because it's been almost 3 years since it was last updated, and I would very much like it to receive an update.

Yeah, I'm gonna try to support all of the various *NO formats (CNO, SNO, INO) in the next update, as well as making it auto-detect the respective formats instead of there being various buttons (since I've got a much better understanding of MaxScripting now).

Similar situation to namine207, I am also having a few quirks with the *no importer script. While fairly reliable in most cases, I too get a few specific files that just will not import. My error comes from the Wii *.gno format where some files will say upon importing:
My use for this is ripping stage geometry from Black Knight and Secret Rings, but some geometries end up missing because not all will import because of the aforementioned error.

Besides the quirks, I have a few question about the script itself. 

First off, does this rip and assign materials? I use Blender for everything, and I don't know if it's my limited experience with 3ds max like not knowing how to add a material in that program, but what I do is import to 3ds max, export fbx and reimport to Blender, and from what I can tell, each object should get its own material, but no materials are present. While still workable because each object needs to only worry about one material, what I end up having to doing is try to recreate and reassign materials after looking back and forth between the game itself and my editor to see what texture goes to what object. It gets to be very tedious and would be much faster with material names at the very least. This isn't really much of a problem with smaller models though because guess-and-check materials usually end up working, but larger files with hundreds of objects end up being time consuming. However, I have to say I don't know jack shit about the file format and for all I know it doesn't even store material IDs. BUT if it does, I think this would be a very useful feature making ripping large stages much easier.

Second, large stage geometries are separated into multiple *.*no files. I think a feature that could be added to the import script is sequential batch importing so it's just a matter of selecting the desired *.gno files and waiting for it to import all the geometries into max. As of now, having to import each *.gno one by one for large stages is very tedious. 

Back to the original problem though, maybe you could help me out in the meantime? I have a few example gno files I can send that give the problem unless you're already fixing everything with the next update.

EDIT: forgot to complete a few sentences...

(10-14-2017, 09:46 PM)adeljalqadi Wrote: Similar situation to namine207, I am also having a few quirks with the *no importer script. While fairly reliable in most cases, I too get a few specific files that just will not import. My error comes from the Wii *.gno format where some files will say upon importing:

Code:

...
-- MAXScript Rollout Handler Exception:
-- Unable to convert: undefined to type: Integer64
-- MAXScript callstack:
-- thread data: threadID:13076
...

My use for this is ripping stage geometry from Black Knight and Secret Rings, but some geometries end up missing because not all will import because of the aforementioned error.

Besides the quirks, I have a few question about the script itself. 

First off, does this rip and assign materials? I don't know if it's my limited experience with 3ds max, but what I do is import to 3ds max, export fbx and reimport to Blender, and from what I can tell, each object should get its own material, but no materials are present. While still workable because each object needs to only worry about one material, what I end up having to doing is try to recreate and reassign materials after looking back and forth between the game itself and my editor to see what texture goes to what object. It gets to be very tedious and would be much faster with material names at the very least. This isn't really much of a problem with smaller models though because guess-and-check materials usually end up working, but larger files with hundreds of objects end up being time consuming. However, I have to say I don't know jack shit about the file format and for all I know it doesn't even store material IDs. BUT if it does, I think this would be a very useful feature making ripping large stages much easier.

Second, large stage geometries are separated into multiple *.*no files. I think a feature that could be added to the import script is sequential batch importing so it's just a matter of selecting the desired *.gno files and waiting for it to import all the geometries into max. As of now, having to import each *.gno one by one for large stages is very tedious. 

Back to the original problem though, maybe you could help me out in the meantime? I have a few example gno files I can send that give the problem unless you're already fixing everything with the next update.

EDIT: forgot to complete a few sentences...

Yeah, the fact that stage models from the Wii games can't be read (plus some from Sonic '06) is definitely one of the primary reasons I'm gonna be revising the script. It's either due to something that's not filled in entirely, or some kinda flag that determines how data should be read. As for the material stuff, I can't recall the reason why I didn't do so for the GNO stuff in particular, but that's also something I'll be implementing (as well as batch-importing while I'm at it, too).

Alright awesome. Looking forward to the revision(s)

(10-14-2017, 03:17 PM)Random Talking Bush Wrote:

(10-14-2017, 03:11 PM)MakutaMaster962 Wrote: Does this mean you're going to add support for .CNO model files as well? Because it's been almost 3 years since it was last updated, and I would very much like it to receive an update.

Yeah, I'm gonna try to support all of the various *NO formats (CNO, SNO, INO) in the next update, as well as making it auto-detect the respective formats instead of there being various buttons (since I've got a much better understanding of MaxScripting now).

That's excellent news, RTB! When can we expect this update to the *NO script? Not trying to rush you or anything.

(10-16-2017, 05:08 PM)MakutaMaster962 Wrote: That's excellent news, RTB! When can we expect this update to the *NO script? Not trying to rush you or anything.

I'm hoping before the end of the month, but it certainly is an undertaking since I have to research and support 9 different formats overall for the new version (CNO/PS3, ENO/360, GNO/Wii, INO/Mobile SD, LNO/Mobile HD, SNO/PS2, UNO/PSP, XNO/360/PS3 and ZNO/PC). But just recently I found the respective flags that determine the types of information in vertex buffers, so I just need to parse all of that correctly and then everything should work out much better (so no more UV mapping or rigging problems, for example).

At least the CNO format seems to be a close variation of ENO, so once I've got the latter redone I can use the coding from that and fix whatever necessary. Sonic 4's a good testing subject for all of this since there's a ton of versions of that game.

Hi RTB, I'm using your script for some Breath of the Wild models and am running into the following problem.  Older versions of your script work with the models but I keep encountering this.  I was using it in 3DSMax 2017 if that makes any difference.  Do you have any idea what could be the problem? Ohh, I have the LOD set to yes but it also happens when set to no.

(10-17-2017, 10:24 PM)Random Talking Bush Wrote:

(10-16-2017, 05:08 PM)MakutaMaster962 Wrote: That's excellent news, RTB! When can we expect this update to the *NO script? Not trying to rush you or anything.

I'm hoping before the end of the month, but it certainly is an undertaking since I have to research and support 9 different formats overall for the new version (CNO/PS3, ENO/360, GNO/Wii, INO/Mobile SD, LNO/Mobile HD, SNO/PS2, UNO/PSP, XNO/360/PS3 and ZNO/PC). But just recently I found the respective flags that determine the types of information in vertex buffers, so I just need to parse all of that correctly and then everything should work out much better (so no more UV mapping or rigging problems, for example).

At least the CNO format seems to be a close variation of ENO, so once I've got the latter redone I can use the coding from that and fix whatever necessary. Sonic 4's a good testing subject for all of this since there's a ton of versions of that game.

On the topic of that, any word on figuring out an extractor for those of Sonic Riders: Zero Gravity? I really want to get the SCR-HD and Master Core ABIS models.

(10-17-2017, 10:24 PM)Random Talking Bush Wrote: I'm hoping before the end of the month, but it certainly is an undertaking since I have to research and support 9 different formats overall for the new version (CNO/PS3, ENO/360, GNO/Wii, INO/Mobile SD, LNO/Mobile HD, SNO/PS2, UNO/PSP, XNO/360/PS3 and ZNO/PC). But just recently I found the respective flags that determine the types of information in vertex buffers, so I just need to parse all of that correctly and then everything should work out much better (so no more UV mapping or rigging problems, for example).

At least the CNO format seems to be a close variation of ENO, so once I've got the latter redone I can use the coding from that and fix whatever necessary. Sonic 4's a good testing subject for all of this since there's a ton of versions of that game.

@RTB,
What progress have you made on updating the *NO Importer Script? Because it's been a month since I last posted on here, and you said you'd "hopefully" have it done before the end of October. I'm sorry for sounding impatient, but I really need that script for some models I'm trying to [correctly] rip and submit to tMR.