XeNTaX

Batch ripping is like downloading an entire game just for a few samples
Lol couldn't you just toss in a simple GUI that allows users to select what they want to actually extract.

could someone show me how to rip zack from the original ff7? I'm feeling nostalgic, and i want the cutscene buster too...

i've read in this forum that noesis can use txt files. i have a textureinfo.txt. how can i get noesis to read from it so it can map the textures? is there an option for it? or maybe a version of noesis that's need to use the txt file?

When I said it can read txt files, I meant you can write a script to parse the txt file for your specific case.

The reason why I didn't do it was because it doesn't make sense to have to keep reloading the same texture info file for models from the same game.

The C++ API is shitty in a lot of ways, I think I've spent pages in this thread lamenting on that already. It was also a horrible decision to include actual component modules into the plugin project(s), that's something that's a pain in the ass to fix retroactively. Most things are a pain in the ass to fix retroactively and they secretly tie into or need to explicitly match things engine-side that they shouldn't, that's why it's still shitty. On the other hand it's extremely flexible despite all of this and allows you to do anything you could really reasonably want to do within the confines of Noesis, case in point being that Python support was added as an external plugin. The renderer is also abstracted out and I've been considering adding that to the SDK, but I don't think anyone would make use of it, and I need to revise the API again before making it public anyway.

So I was reading up on transform matrices but all that math is just...math. I mean now I can do matrix algebra but so what

I'm working with a format that has all of the meshes positioned at the origin and uses mesh transforms to correctly position and orient them.

It seems like I don't have 16 floats laid out nicely for me to just read in. Apparently it just stores each vector individually, so like you have scale xyz, followed by stuff, followed by position xyz, etc.

How would I take this information and build the correct matrix?

I would probably have to swap rows to get it in XYZ at the end, but which component goes where? lol

I've seen how 3x3 identity matrices have like the x,y,z scale along the diagonal, but I'm not sure why that's the case.

Should I be aiming for a 4x4 or a 4x3 matrix?

4x3 matrix is the best because that is what noesis wants for most operations.
4 x 4 is the same as 4 x 3 but has data that is not used kept on it for example

1 0 0 0
0 1 0 0
0 0 1 0
X Y Z 1

that is a 4 x 4 matrix to make a 4 x 3 you just remove the end that is not used

1 0 0
0 1 0
0 0 1
X Y Z

when crating a matrix i find it easiest to create the matrix from a quat or angles first then
just swap out row 4 for the position data.

Hi MrAdults.

i have one stupid question.
Noesis python really supports XML?

When i import ElementTree and use XML function, Noesis error log is
"ImportError: No module named expat; use SimpleXMLTreeBuilder instead"

if it's possible, please teach me how to use XML format reading in Noesis python.

Thank you.

i tried to import external xml readers before in noeis but i could not find any useful ones that worked with python 3.2
the best bet is most likely to make an xml plugin that gives you the features you want.
but the native python 3.2 xml functions should work no problem.

Would be great if I could use xpath or xquery in python when dealing with those xml files.

chrrox:
Thanks for attached a sample file.
Surely native python supports xml format.
But if Noesis supports xml directly, it's very handy importing game resource of xml.

finale00:
Thanks info.
But i don't know how to use external library in Noesis python.

I think python should support xpath/xquery natively as well. I mean, it seems like a pretty natural way to parse XML files.

lol immediate mode woes

Here's a model built using the rpg interface with normals



Here's the same model, using the imm interface, without normals



And now I added normals in



Here's the code:
Not sure what's causing it, or how to fix it. Or whether I'm supposed to be making a couple extra calls to clean up any previous stuff. I tried clearBufferBind before each immBegin but the results weren't any different.

It uses the same vertex, normal, and index buffers as I would do it using rpgBind
Here's how it looks with rpg calls
I'm using immediate mode here cause the UV's are stored per-face and there's a separate index list into the UV buffer.

I'm trying to parse a Prototype 2 model file, but it's 10MB large and after looking at it in 010 editor it seems it's chunk based, but it has 36k chunks.

When trying to parse the chunks Noesis locks up, I can't do a file search for the chunk header number because it just happens to have the same number in other places but not as a chunk header.

I was thinking of cutting the file up in smaller parts, but I don't know after what chunk I should.

It's really annoying because the armature chunk is like 143360 and the bones for that armature are 143361, but instead of nesting the chunks the armature one only holds the name and numbones and then come all the bones as seperate chunks, so I can't "skip" large chunks because they're all small (30-80 byte range ...) with an occasional large one.

What would be my best bet to deal with this?
I'm currently leaning towards an extra python .pyd module that just parses parts of this file, but that's only because I don't know any better/anything else.

I can't really debug the .py script because Noesis locks up. I already got rid of the memory error when I was loading each different struct into memory.

10 MB file with 36,000 chunks... that's not a lot and shouldn't be cause any memory errors or crashing. Even with heavy nesting of the chunks python should be able to manhandle that. go ahead and write that extra module and see if it still crashes... then you know it's not Noesis. unless you feel like posting source... (I doubt anyone would steal your code). since a chunkfile is a type of tree, there may be something wrong with traversal code causing it to get stuck. using this extra module, you could also save the data into an intermediate format that Noesis can read without crashing.

i'm also sure there's something you can do, like keep count of how many times a chunk id is visited, to see if a chunk is being visited too many times, errr.... an infinite number of times, etc.

you can also create a debug file that prints the chunk tree in the following format (along with the chunksizes too)... to see where it's going crazy.