VarsityPuppet

Looks like my Malachor Sith Marauder armor skin is pretty popular.

Hate to nitpick, but is the banding and compression (in the purple-sky part, not the cloud) from the screenshot or does it look like that in-game? Also, come to think of it, I think Korriban could use a little change of ambient fog. I notice as the mountains get further out they look washed out.

Well, if we have any tools you might find useful (or if you have any suggestions for tools) feel free to post here. Keep in mind though it might be awhile until we get to things like... models

Go crazy with it! For my purposes, just to add a row to the bottom. Preferably, something that can read a text file and generate a row (or several rows) based on that input.

lol we should elevate his name to the status of "not to be spoken"

Yep. GFF files were all little endian too. Good to know. GFFs did this with labels, but not with any field values. I'm sure they were just too disparate of values to really even bother. Most of the values that would have mattered anyways fit into 4 bytes anyways I will most certainly take a look at that! Thank you! Any chance you've written any code to add rows and then write the new file? I'd be real grateful if you could mock up something like that. Looking for just a really "ragtag" way to finish up my Saber mod without any more tedious work - well, tedious file editing, anyhow.

Gonna play the sh*t out of TSL when you're done with this!

Into Form Application phase! woop woop!

My bad. Only issue I could see with changing the hex to all decimals is that you'll probably get some strange numbers every once in a while since some of them, for instance, could be float/double representations. Heck, even some of them are boolean flags.

I don't know if KAurora will work, so you can certainly give it a try. My guess as to why your method may not be working may be because of the way the model is being recompiled. It's possible (and all too likely) that some offsets are being rearranged upon mdlops compiling (at least in comparison to the original mdl). Best bet might be to just play with mdl_info (Fair Strides first provided link) and just start trying to puzzle together the file format.

Could be. I mean, I don't think managed to do anything particularly fast, clever or efficient with my code. In my research, I read that Hashes aren't necessarily the fastest in terms of writing things with indexes (indices?) involved, which may or may not be the case with .tlk files. Turned out it was useful for GFFs. I haven't had the chance to test any module files, but I've been testing the "basic" gff templates along the way to ensure I was reading/building correctly. My tests: Saber UTI file (5 kb) 131 ms to read GFF 36 ms to write XML 32 ms to write GFF 2 ms to format XML Area GIT file (14 kb) 146 ms to read GFF 37 ms to write XML 44 ms to write GFF 3 ms to formatKreia DLG file (1.4 MB) (Biggest DLG file I could find in the override) 4362 ms to read GFF 1257 ms to write XML 2052 ms to write GFF 499 ms to format

Update: Well, after implementing what I thought would be a faster alternative to Lists, I found out that the main cause of the terrible performance was with one particular chunk of terrible code. After fixing that, performance was pretty damn fast. From my console output: 651 ms to read GFF 288 ms to write XML 190 ms to write GFF I'll have to try a bigger file later.

I know it's been a couple of days, but I'll take a look at your TLK write up in a bit. In the meantime, I've managed to code up the read/write to XML/write to GFF code for GFF files! It works with the 3 I've tested so far :/, although, it's not incredibly fast with larger files... ... but it works! It's cool though, I have some ideas for optimizing all that. Like probably not using Lists to build up byte arrays lol. But it was fun and convenient to use at the time.

Maybe just post the code and explain the crap out of it lol. Alternatively, if you want to just post the file structure, that'd be cool. Or, I think you should join me in my quest and learn C# and we can work off of eachother. It's very similar to java in terms of syntax.

Hmmm... care to share the knowledge and/or code when you're done? I could use something along the lines of a .tlk strref retrieval. It's going to be in Perl isn't it? I fixed the reader so that it reads dlg files (turns out I made a silly mistake when I read the structs from a List). I'm working on rebuilding the files back into GFF/Binary. So far I've just outputting test information like the number of structs, fields, etc. Writing an XML and writing back to a GFF should result in a net change of 0 in the overall size of the file. I'm.... uh... basically not there yet.

So my XML formatting is a little weird, but should it be necessary to edit with an XML editor, I wanted it to be as easy to read as possible. XML formatting is a little weird, but as long as it's able to read and merge changes in a git repo, then I should be good. Should be able to read pretty much any GFF file, although I'll have to make a few changes so it can read .dlg files. Imagine merging dlg files finally!

That texture would replace both textures used on the head, unfortunately. The only way you could pull it off is if you remapped the head and put both of the textures into one file. It stinks, but that's how it is...

I know the code isn't actually that complicated, but I feel dumb for not actually knowing any C++...

WOW So I've been coding all day. A lot of it was spent refactoring. Needless to say, my mind feels like mush. I'm pretty damn close to having the file format laid out perfectly so I can just write a few nested loops that will build it into an xml file. So close!

Yeah, I thought about it, but that would sort of make all the work I just did irrelevant.... :'( Isn't hindsight great? But on the plus side of things, I know how the GFF file works and I've had practice writing code that parses files! Not to mention I want to know how to work with writing files to XML format. If it came down to me not being able to figure out how to read or parse anything, then that would have likely been my course of action. If I for instance, wanted to pack/unpack Rim files or compile source scripts (aka, eventual plans), then I may take that route...

Sounds worth looking in to for sure! For now though, I just want to have the experience of reading/parsing files on my own. It's one thing to understand the code, but it's another to write it yourself. Of course it would be much easier to use the existing code considering xml files are far easier to merge than GFF files (for which all intents and purposes of Git, may as well be binary files). Merge the xml file and then generate the GFF file from the code. Might not be a bad idea to consider writing down everything as an XML and then converting to the preferred format. Anyways, I managed to get some of the complex data types read (things like resrefs and cexostrings). Wasn't really hard, but coming back to the code after a couple of days was a little confusing. Won't be long until I can build a GFF hierarchy and then rewrite the file with new information.

Well, this means I can play through the new Cathalan mod! Hilarity and facepalms will ensue.

Update: I've gotten more of the file decoded. It can read the Struct Array and Field Array. Keep in mind reading these arrays is still quite a ways from actually putting together some working version of a GFF file, but I'm still getting there. I actually ran into a bit of an issue with reading the Label Array. According to the file format PDF, they should be the next item referenced in the Header, but something tells me that it's out of order. Whenever I read the Labels, I get junk data. Ah well, anyways. Continue on.. EDIT: Ah, well nevermind that. I figured out the issues I was having with labels. Forgot to reference an actual array index, not just the variable I was incrementing. How stupid.

Well, I've got it parsing the Header perfectly! The code is nice and concise, although the code to write it to the console is somewhat lengthy... not that it'll be there in the long run.. eh, maybe I could leave it there. Next up is reading the other data structures in the file. I'd look at them now, but it's pretty late and I'm sleepy.

By all means, input away! This is what the thread is about. Man, that Perl still looks confusing. Anywho, managed to get a C# IDE running on Mac (sweet!). I had to install some frameworks and I can't build any Windows Forms, but I think I can create a repository on my Mac and my Desktop, thus using the Desktop to make my forms. Most of the parsing code is separate anyways, so it should be a breeze. As I always tend to forget, I had to look up the code to read the binary of a file and store it in a byte array. Might not be the best way to pull this off in the end, but for the sake of experimenting, this is how I'll do it. I'd much rather, as I read the file, keep track of all of the offsets and where everything is located, but I suppose I need to be able to generally map out the header and go from there.