xander2077

Members
  • Content Count

    299
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by xander2077

  1. kinda why i gave up on the helmet style mask option with every armor in the game. I guess i could try it, but im leery about making it incompatible with other mods. Dont mind tsl patcher, but the other stuff is too labor intensive on the scripting for me just yet. I think for now it would be just fine to get the helmet versions of a few masks in the game with its own armor or robe, one disguise for each gender. Now for helmets i want to mix and match with armor i would have to use a dummy head replacer like the squashed face one, as long as it doesnt have to be in the head selection menu. i did a mockup of one that i never tested and it basically cuts everything off from the bottom lip up since the rest is hidden anyway. textured it to be like the stormtrooper turtleneck sort of. but then that would take some multiple texture editing in the Uiti i believe as well to match armor colors. Thats kind of why i have so many mods on hold, one reason is to secure permissions, and the other is to think about it for a minute before i proceed and make it too ridiculous.
  2. i really gave that some thought, but i decided to just make them a disguise with either male or female, and it has to be with a suit of armor that matches the helmet, and it will be an add on to the masks later. Of course for that i think i will just make it a new texture completely, and forego the separate helmet, and make it more like a creature body, where the head is attached to the body, so it wont need a new head. If it was more like the canderous mandalorian items, then yes i would go ahead and do that since it is just one suit and helmet, but there are three, and i wanted them to be wearable by any gender, except maybe zaalbar or mission, who will get their own stuff to compensate for not being able to wear the disguises. as tempting as it was, i realized it was convoluted as well, and so it might be better used for another mod later down the road where it is more suitable. Such as one that needs to have different mix and match robes or armor and helmets.
  3. Hmmm, well if he did one years ago was it animated?
  4. I think he is, but he just kind of went off and started working on it and is probably busy doing that. If he is he will post something fairly soon.
  5. WOW that must be a very hi res set of images. downloading now, be done in 2 hours lol.
  6. Yes VP, that is a good primer, which is what I read initially, but the LucasForums threads go into a lot more detail and experimentation, and I am thankful they still exist. I’m still using MDLOPs0.6 and so far some of the issues encountered in max are not present although some are. YMMV. What has been achieved with the masks has taught me a lot about those differences, and some of it has to do with the NeverBlender plug-in interpreting the compiled ASCII. Both NWNMax and NeverBlender have their drawbacks and perks. I think you both are doing a stellar job of ironing out all the kinks in MDLOPs, now I just have to get on board and get it working in Linux. I’m pretty much relying on ndix UR and Purifier for pointers there but that is due to them understanding code more than I. I did stumble on a blog by Floyd who did a tutorial on head editing and his write up about coding opened my eyes a bit on the terminology and functions so I’m going to take the plunge. The above experiment will help a bit but I’m not sure how much of that will be beneficial. It is time consuming to say the least, and might really be covering old ground, but it is a good learning experience. I was also intrigued by the suggestion that another format be used in Kaurora so it is more cross platform friendly, but I am not sure if FBX would be good for that or not, but I do know max and blender fully support the format and it is a popular one, as long as MDLOPs and Kaurora can both compile well enough so that the FBX doesn’t lose any of the data, then I’m interested. I need to take a break, it took me a minute to do some new UV unwrapping and seam editing so now I need to back off for a while and come back to this later.
  7. OK, small update for folks out there working on the MDL issue. I have been really delving into the old LucasArts forums and reading up extensively on some of the issues and techniques, just soaking it all up and finding out there are some perks to using Blender that Max doesn’t have. Basically what I read was that there is no way to edit the models without losing the smoothing info, and/or the other stuff like bump map coding etc. however in my masks mod I did notice one thing consistently so far and I am going to experiment on the others based on some of the discoveries by Darth Sapiens, and RedRob41. When I edited the vanilla trimeshes for masks, I was able to add the smooth rendering back on by selecting all faces and applying "shade smooth" to all faces. This really does improve the appearance of the models in the game, which I learned early on and is very evident in some of the models, some more than others. But what I have not tried is messing around with bump mapping and envmapping just yet, still reading up on that and how to properly get it rendered. It seems I misunderstood the process a bit and reading the LA forum posts is helping me understand it better. So I may yet find a way to make some of the metallic masks reflect and have bump maps like I want. I don’t want to jump the gun here, but it seems like Blender is becoming a much friendlier KotOR modding tool than I had thought previously. Something else I want to add is I have never tried creating a mesh from scratch except for a few models that I have not compiled with MDLOPS yet, and there is a reason why. It seems as if those who have tried that end up with very weird anomalies, so something is present in the mesh data, that resculpting in Blender does not get rid of. This is probably how I was able to make the masks work fairly well, by simply modifying the vanilla meshes, but I also noticed that adding to the model is possible, since for a few of them I did that very thing. The reason for keeping the old vanilla mesh is 1: for reference, and 2: so that your new mesh retains the properties of the old one. How? Well simply by merging or in Blender, joining the new mesh to the old trimesh object. So for instance if I was making a new mesh for a robot, I would not simply rig the new mesh in place of the old one, but join the new parts to their respective vanilla parts, new head merged to old head, new right hand to old right hand, etc...And the new part takes on the properties and behavior of the old vanilla one, which would be selected second of the two and be the active object. Then once the two meshes occupy the same mesh space (in blender this is easily done and opening the edit mesh properties allows you to edit the mesh(es) in the object) then the old one can safely be deleted since the new mesh is technically the same part as the old one. It is kind of like deleting parts you don’t want off an existing mesh and then re-exporting it. Now as far as the weighting goes, I am still not clear on whether the new part adopts the weights of the old for skinned meshes in blender or not, that still has to be discovered, but from what I gather from discussing it, NeverBlender seems to assign default weights to skinned meshes and they work anyway on export, but that is a non issue with trimesh only models. If anyone has any links that have more info about KotOR MDLs, or tutorials that are still available, I’m open to suggestions. Some are still available, and some are long lost to the void of the internet. Anyway, that’s about it for now.
  8. @ DP, i sent a PM because i dont want to clutter the thread any more with unrelated stuff, im kind of going off topic about things that are vaguely related to MDlops, and there are more details in the PM.
  9. Rule of thumb for all things windows update, read the KB notes. If it sounds off, it probably is. It can become a full time job unfortunately. I just never understood why they have to be so sneaky if its really good for you. Both methods work, guess its just whether or not you want to mess around with regedit or let the patch do it for you. I agree windows 7 was the last upgrade i would ever want, and even then i still wish i could go back to XP on this rig, but the drivers were pulled from the public and now cost $50 to reaquire. Talk about milking a product. So dont do like me and lose your driver disk that shipped with the computer. Next rig i put windows on will be 7, and it will be another home built box. more driver flexibility and support. I am also considering isolating it from the web unless aboslutely necessary, but sneakernet works too. One thing modding has taught me is that both linux and windows are absolutely necessary. Im just not impressed with 10 at all. Once you have it, they nag you about using one drive. Give an inch, the whole thing about a mile yaddah yaddah...
  10. i was curious about the droids. I have a couple of new ones, one is based on the protocol droid mesh but just resculpted, and the other one is based on another source i was experimenting with to see how close NWN aurora was to Kaurora for at least the droid trimesh. What you are talking about is a completely new mesh has to be rigged to the HK helpers? how about animations? it has to do with the experiment.
  11. @ fair strides and @ DP: we all kind of figured FS was the keymaster for the code, but with him being busy lately we didnt want to burden him with a lot of things. So each of us has been studying dutifully and hopeing that once FS has some time we can go over all of it and compare notes to improve things. being that a lot of us are Blender users, and Blender handles it differently, as well as neverblender, this is a passionate subject for all of us. Not to bypass anyone, just that things are a bit different from this side than the Max side of things. So while we may be going over things already known or learned, it is still best to learn in spite of that to bring a better understanding to the table so FS wont feel like he is repeating things over and over. Or less so because we all have a better understanding before going onto the discussion. I think this is going to help expand Kotor modding to a new pinnacle, and even help us figure out some things that have been brick walls for a while. Who knows, we may even be able to figure out how to add the correct lines to an mdl so it can do things it could not before with textures. One can dream.
  12. Awesomeness. Purifier and i are also coming at this from other angles as well. Im currently slogging throung comparing samples of NWN1 models for each category to their equivalents in Kotor. Once i produce a list then i will peobably have to pass that on and rely on someone else for comparison of the TSL files since there is a slight difference. I dont have any extracted from my copy of TSL.
  13. Thanks, Xuul! Now my dream has come true to hear you announce this mod! Almost as iconic as the "Let's get ready to rumble" dude.
  14. Maybe a 3d model overlay of both to give the crypt a more stone like appearance, and the outfit to add weathering and character. Both can be done with 3d model superimposed and blended over the frames. Of course that would take a bit of work to mimic the size and positioning, but it is possible. Just a suggestion. It can help with a lot of lighting issues that can be a problem during filming and make things possible that lighting on a budget won’t be able to fix. Tools like blender can do that. Won’t even take a lot of processing power compared to some programs. If the frames for the model are rendered at the correct angles, then they can be turned into an image and pasted over the frames using something like after effects. I’m not sure what your toolset is but I’m sure you guys are familiar with rotoscoping and other things you did in the trailer, same concepts just a different overlay.
  15. Not bad, costuming and effects are pretty good. Maybe add some after effects to the crypt and the robe inside it?
  16. that is a hard nut to crack since it is already out of focus compared to the rest of the shot. But it appears they are glass spines or cylinders and the lights flashing are not really letters or words, but just flashing lights to simulate data moving, or like synapses firing off in the brain. The ones that are dark are either shut off or under routine maintanence. Again using the idea of a server to make the logical leap. Most of the existing jedi library textures are pretty lame. Im looking around for a good example of it that actually pulls it off.
  17. i always thought of them as either being holodisks, or giant databanks like todays server rooms, and the terminals use either one to access the data. In the prequel trilogy that is pretty much how they represented them if i remember right. of all the times they went to the jedi temple, i dont remember them cracking open a holobook once, and usually it was either a holographic librarian, or a terminal they accessed. I think making them look like bookshelves is more or less for aesthetics, or a throwback to actual libraries with books to make them seem more familiar to the viewer, or possibly to impress the visitor, and give it a sense of nostalgia. it would be kind of cool to make them look more like the visuals in the movies, but to pull it off right there almost needs to be a model update as well.
  18. You mean like disco lights? that could go with the dancing Kreia Im not sure what module part that would be but the only two ways i can think of finding that out, is by converting the module with mdlops to see what the texture is. or a whole dump of the texture files and going through them one by one. I would look for that but i cant use Ktool any more to get the files.
  19. One of the experiments I am working on is comparing the NWN1 format to the KotOR format. All the import and export plug-ins we use are based on the NWN1 format. There is no purpose built KotOR model importer and exporter, which would be the more direct approach - but nobody seems to want to go that route. I’m not sure why it was decided to import ASCII instead of the binary format from KotOR but that is what we have to work with. NWN1 models are already ASCII, and in KotOR they switched to the binary for a smaller file size, so what mdlops does is try to approximate the NWN1 format for the NWN importer to blender or max respectively. It is based on that original model format. However the problems creep up probably because of the presence of skinned models in KotOR. since NWN models were all just trimesh objects with no skinning really that I can see (unless for some reason this is hidden from me by the Neverblender importer), I imagine a lot of guess work had to go into mdlops to make it mimic the NWN1 format and fill in the blanks for some of the new model properties such as skinning and hooks not present in the NWN format, but something is not quite right. So what I want to do is compare the output from blender since I used a NWN body and rig as the basis for the new model I want to put in KotOR. Since it is a trimesh body, it has been re-sculpted into a droid body so the data is still present from the original NWN1 model format to help identify things during conversion. Hopefully comparing things will narrow down some of the issues present in KotOR model import and export. Of course there will have to be some editing done to the ASCII or binary to point it to the correct animations instead of the NWN1 animations, but one thing at a time. Comparing this model to the stock droid model from KotOR reveals that they are basically the same thing, a bunch of trimesh body parts that have a bunch of helper objects - which will explain why most trimesh objects are successfully imported and exported using these NWN plug-ins. so this could actually help refine the tools we have been using for KotOR models. It would be a step in the right direction. But the better approach would be to decompile the KotOR model format from scratch and make a set of import/export plug-ins for blender and max that are purpose built for KotOR models, just like there is one specifically for the mdb format of NWN2. I will also be examining a premade NWN2 rig to see if I can convert it to one that can be used for KotOR models. This rig is basically the same as a KotOR rig/skeleton, but the difference is the NWN2 models reference them directly instead of using trimesh objects as go betweens to the animation skeletons. So this could help people create new models that work like they are supposed to if I can figure it out. It would certainly make rigging and skin weighting easier for blender users.
  20. i think we should have a contest to see who can come up with the best dialogue for a fake scenario for an imaginary mod, and then the submissions can be voted on by the community. whoever comes up with the best one gets the job. now i would offer my services, but two things kind of put a dent in that 1: i am pretty busy already, and 2: everything would have to be thoroughly spell checked and edited since i seem to have butter fingers and a really bad spell check. When did spell check and grammar dictionaries go so wrong?
  21. Well, I have some "new" information for KotOR modders. The models for NWN1 are already ASCII, which means when they updated the aurora engine for KotOR, they decided to convert the models to binary to make the files smaller. Now, de-compiling the NWN model may give us some new clues as to the differences between the KotOR ASCII and the NWN ASCII. I can import all nwn1 models without converting them to ASCII with mdlops, they just import with Neverblender. Since KotOR models are binary they have to be converted to the old ASCII format with mdlops first, so the mdlops converter is not quite built to convert everything to the old NWN format. Part of this could be due to the skinned models in KotOR. It could be that one or two bytes on a line are mismatched or that the nwn1 format did not allow for the complexity of KotOR models since the NWN models are all just trimesh objects with helpers, kind of like the KotOR droids. so the issue is not the importer at all, it is reworking mdlops so that the conversion to the ASCII format matches the ASCII data in the old nwn1 models, and that has to be done first before the importer will be successful 100% of the time with all KotOR models. I have a few of the models for NWN1 in my external drive if anyone wants to use them to compare the data between formats so that mdlops can better approximate the format that Neverblender expects. This actually might also benefit users of NWNmax as well, since the importer relies on the models being as close to the original NWN1 model format as possible. The models I have include character, item, and even some areas with walkmeshes, so examining those could really benefit people trying to mod KotOR. Anyone interested in comparing the formats to troubleshoot can PM me for a zip file of the MDL’s.
  22. i think this will also work with TSL by simply dropping it in the override as well. i think the masks are named the exact same thing as far as models and textures go.
  23. I think there is a Revan's mask somewhere, but I cant remember who did it. I think I have a copy. I don't think it is white, but it can be made that way by taking part from the star forge robes. Not sure about screens, I have to use a weird key combo and forget half the time.
  24. No doubt they stripped down and simplified the models a lot. But that’s not what I am talking about. There was a mod that added bracers to the forearms of the KotOR player group characters but I am not sure how they added those hooks to the models. Perhaps studying NWN models helped them to figure it out? I don’t know - but that is as far as I would try to go. using the belt slot might be possible only if the hooks were added after the fact, but that would take some heavy hacking to get them to work, and I would avoid using those for actual belts, but try using them for things like capes, belts would look horrible, and perhaps the only way to really mod them in if at all would be to eliminate belts from the body models so they don’t peek from behind, but it is a very long shot. Still would look bulky I figure. The difference between nwn2 and KotOR models is the NWN models have a lot more pieces. They have the torso, the legs, the lower legs (boots) and also you can swap hair with a helmet. There are belts, over cloaks, armor pieces, and just a whole lot more that can be placed on the body model itself. To mimic that I am sure it would take some doing with the exe limitations of K1 and 2. NWN1 models are so blocky they are ugly, but the system for those is more similar to KotOR models than NWN2 models, even though the quality of KotOR models is on par with nwn2. But all that aside - because it is really a moot point - is that perhaps these people have a larger understanding of the Aurora model structure, what is possible from the exe and 2da perspective, and some of their workarounds may have some validity even in a stripped down Aurora engine of the KotOR series. It might be worth looking in to. NWN used the Aurora engine, an updated version of that was the Odyssey engine, used for K1 and 2. Electron engine was a separate branch of the Aurora engine used for NWN 2. So they all have similarities, but the limitations are in the exe itself. The file systems they all share 2da, erf, uti etc, all are pretty much the same format (there are slight differences though) but they provide the same functions. So I would wager any real changes that would open up new items or model functions need to be patched into the exe, and it is even possible to throw multiplayer in there theoretically. The problem is you have to have the license of the original engine used for the game development to avoid having to reverse engineer it, and that toolset will make it possible to rewrite history so to speak. I’m not sure how much an outdated engine would cost, but it would be interesting to find out. I’m sure they would probably let it go for a song, and probably more readily than Microsoft would. Witcher was based on the Aurora engine too. And that was a more up to date version of it. Wonder how much they paid to license it? I’m sure if the three engines from the time were compared, then a lot of the stripped features can be put back in. But that is just a guess really. I’m really more interested in what each exe can do, and if it would be possible to mimic functions through a player made patch.
  25. This is purely from a study standpoint. I won’t even dare get into using things from their games or mods, probably would not work anyway. But what those modders have done could be mimicked to a degree by studying some of their methods and using that as a springboard for some really cool mods here. The toolsets might be worthy of cracking open the hood to see what can or can’t be duplicated in tools for K1 and 2 but I’m not really sure how far that would go. A lot of custom content and skinned models can be studied and similar things can be done in K1 and 2. For example: Heads created in other programs, bodies, etc. and using belt and other slots for adding parts of clothing on. It’s just interesting to see how similar some of the things are. What has already been proven to work is the Neverblender plug-in. And the fact they are updating it to be more compatible with Kotor needs is very encouraging. Now the tutorials are priceless when it comes to using some of the blender methods they discuss.