Leaderboard

For the most of the meeting, Janek just sat silently, listening and observing; he had nothing to add, and on top of that, taking a reading of others was equally if not even more important than getting all possible information out of the conversation. To say the least, this didn’t sound good. When agent Reskos’ hologram appeared, Janek blinked an extra time, crossing his arms, doing his best (athough not completely succeeding) to not break from his neutral appearance. No, this most definitely didn’t sound good. Well, at least there was no telling what to expect, which could be a very bad or a very good thing. Probably both. ”Splendid”, Janek said as casually as possible, despite his growing nervousness, when a suitable moment finally presented itself. ”Let me get this straight. We’re supposed to dance straight into the lair of a Force-using, mind-controlling, dual-wielding, unaccounted entity, who either is or is connected to a missing Jedi master, and who creeps out the most seasoned undercover agents?” He took a quick breath, and continued: ”Don’t get me wrong, I’m not backing off. I simply prefer to know where I stand.”

VP was kind enough to make the new forum for us, thanks again @VarsityPuppet! Though it would be nice if we got some news as to where the other site updates are at.

@ebmar: That's a completely different texture, by the way. I didn't say I'd consider this . . . but . . . drop the attached file in your Override and let me know if shows up. (Pictures would help if it does.) If it works and if people want it, give the first person that posts pictures of this new texture in the game likes or light side points. That's how I'll determine if I need to update the package or not - your like will be vote. (Because the way the site works, this attachment won't last forever.) I'd test it myself but I have my own Ord Mantell textures replacing these. (Those Ord Mantell textures were for this video, which could use some comments and likes on YouTube by the way.) LZA_scre01.tga

Thanks to @eNoodlesand @UnusualCharactersfor working on my Modding Request. From what I hear, it's been submitted for approval.

Hello! First of all, congratulations and thanks for creating this modification. I installed it and I noticed something that perhaps you haven't considered. In the Taris upper cantina, we meet some patrons. One of them has the old male commoner look but his voice is mismatched since it is a young male voice. I wondered how many such situations we may encounter during the game? While I do enjoy the head variety of the former Lite NPCs, I fear the voice not matching the age is a jarring issue. If I am not mistaken, there are 8 Commoner Lite that use one of the "old" heads, while in the original game they are all young.

TYTHON: JEDI COUNCIL CHAMBER "Excuse me, Grandmaster," interjected Master Vek, "but are all of us in this chamber on the task force to find Voleran and the data? Will we all venture into unknown territory?" She looked around, eyes veiled but seeing everything and everyone. "We'll require several ships." "When I said 'task force,' I did not mean 'strike force.'" Shan narrowed her eyes. "Are you volunteering for the latter, Master Vek?" "Yes." Vesi gave a start. The Miraluka had always taught her about caution, patience, weighing assignments before accepting them. Now this? The young Jedi couldn't believe her ears. "As is my apprentice, Vesi Svari, Jedi Consular of the second rank." "Excuse me," Vesi replied, trying not to stammer, "but with all due respect, I am grossly unqualified for such a mission. As my Master said, I've only reached the second rank of Consular training. Against experienced assassins, Dark Jedi or Sith, I doubt I'll achieve victory." A beat. "Besides, I'm equipped with an implant nodule at the base of my skull that could be hacked - exploited - by our attackers. I do not decline such a duty out of insubordination, I assure you, but a desire to protect myself and others from my inexperience." She bowed deeply to Grandmaster Shan, the other Council members, and finally to her own mentor. "I'm sorry." Murmurs from the other Councilors, followed by a firm silencing gaze from the senior Jedi. "May I ask you a question, Knight Svari?" "Of course." Vesi blushed. She sensed that whatever Satele Shan had to say to her next, it would result in disciplinary action. "Was I always this experienced? At your age, with my Force and lightsaber talents, did I hold my current rank?" When Svari shook her head, the Grandmaster continued, "Nevertheless, even in my novice years, I was sent on important missions to serve this Temple - along with my superiors. I did not work alone. Neither shall you. Even if you're assigned to clean battle and reconnaissance droids, will you forsake your chance to serve? Will you fulfill your duty despite your fear? Your Master sees much that you do not, young Jedi." "I...I know." What does she see in me? On a mission of this magnitude, why send someone so weak? However, if I'm needed..." "I accept." "Good." A small smile tweaked the corners of the Grandmaster's lips. "Now, then: My fellow Councilors, I have delegated roles upon the strike force or the task force here at the Temple to each and every one of you. As for the Masters, including you, Canitha Vek, you shall report to your Council superiors each day with the progress you have made on your various assignments. Any other questions?" When silence ensued, Shan said, "Very well. This Council meeting is adjourned, and in the meantime, one by one, come and report to me." As everyone filed into line, Councilors in front, Masters behind them, and apprentices and various attaches in the rear, Vesi asked Vek: "Why?" "Why not?" Seeing as this cryptic reply did not satisfy her apprentice, the Miraluka said: "Trust me, as you always have. Now is the time to put such loyalty and devotion to the test. I'll be with you every step of the way. Let your fear subside, and let courage take its place."

Added my own touchups: Could still use a little bit of touchup around the beard. Oh, and the UV map. Revan_Head_d_v3.7z TOR_Revan_Head_UV_Map.7z

Really looking forward to the Wiki inclusion for basic modding tutorials! Thanks for letting us know what's going on!

Hey all, first off I just want to say how inspiring and important everything in this thread has been. Big shout out to DarthSapiens and OldTimeRadio for their work on this in the worlds of KotOR and NWN. Also to DarthParametric and Dastardly, whose posts I wish I would have read roughly one day sooner than I did Also sorry about this seriously massive wall of text. TLDR I figured out the numbers, I'm working on this actively, still a *couple* kinks causing K2 to crash on certain newly-bump-mapped models, K1 yet to see any success, going to take a bit of further study it seems. Some numbers are still coming out pretty far from vanilla, but how much they are affecting things visually is TBD, I have been recompiling vanillas that originally did and didn't have bumpmapping without seeing any crashing for about a day now (6 models "tested", half originally non-bumpmapped). The Good I can tell you what the 9-float vertex Tangent Space is and the algorithm to calculate the 3 vectors per vertex in 95+% of cases. As DarthParametric theorized, they are the 3 components of a Tangent Space, to figure this out I used the info here: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-13-normal-mapping/ Because I used that info, I call the 'binormal' vector a 'bitangent', but either way, let's just call them T, B, and N for Tangent, Bitangent, and Normal (all are 3-space vectors). So, the 9 floats in order are [ Bx By Bz Tx Ty Tz Nx Ny Nz ]. These are vertex vectors, distinct from face vectors, with the distinction being that vertex vectors are 'averaged' with all of their adjacent face vectors. I'm not going to go into details that are covered in the opengl-tutorial article, and mdlops already contains the vertex normal calculations, but I do want to write out the oddities of calculating the vertex BT vectors etc. In many ways it works just like calculating the vertex normals. Here is the abbreviated algorithm: Put it into BTN order, and there's your data. For skinned models like c_malbeast in k2, this produces a high number of nearly exact matches compared with the vanilla numbers. I tried a number of other things that don't seem to be right (although I might try some of them again now that I have it working), such as orthogonalizing, deriving B as TxN, not normalizing everywhere, and of course making the system right handed. It all kind of makes sense in hind-sight but damned if it wasn't tricky to figure out. Fun note: comparing the skinned results to the trimesh results, there seems to be a crease angle test that the vanilla compiler did, but only for non-skin. The Bad All of the droid models I have attempted this on have at least one mesh that has overlapping texture vertices in a face, which makes the r factor in the tutorial's vector calculations into a divide by zero. I have not yet figured out if/what dummy data to use in this case that will produce models that don't crash the game on load. Luckily this is true of vanilla bump-mapped models such as g0t0. But... there is definitely some kind of crease angle calculation that comes into play in a big way on droid models (sigh ... it's def not smooth group data), meaning that the vanilla normals are coming out different, and the vanilla BT vectors ... makes it tougher to track this down. This is what I am kind of side-tracked with at the moment. Also, all of my testing has been in K2, the one test I attempted in K1 crashed the game on load. The Ugly The bump-mapping doesn't render (none of it, no vanilla, none of people's experiments etc.) when the game is running in wine on a mac, so I can't see whether it looks right at all. The only ways I can tell that "it's working" are: the game doesn't crash (anymore) when my model loads the game doesn't give me the error message about invalid bumpmap (anymore) since I know from redrob's g0t0 bump research on LF that low alpha on the main texture is necessary, I have done that on my test textures, and the meshes that have working tangent space numbers turn 'solid' or 'alpha 1.0' while the non tangent space meshes remain (mostly) transparent. if the models don't have their tangent space numbers on a node, the node also loses its bumpyshinytexture, which I *can* see in k2 (but not k1). So yeah, I don't have the software to actually see normal maps working, I can just sort of tell. sort of. Crap. After trying every every other option ... I just realized I might have to try the steam version. ALSO - Color Normal Maps as TGAs in Override I didn't see it here, which could be a 'me' problem, but I just read this last night on OldTimeRadio's NWN thread (on forums.bioware, not here) and "tested" (see The Ugly above) it today. It seems like we can use custom (8-bit) color normal maps in KotOR! I don't know if people are largely aware of this or not, but the impression I was left with from this thread was that we were stuck with grayscale height maps rather than actual color normal maps. In case you're wondering why that's a big deal and don't want to look it up, color normal maps encode a full 3-dimensional vector at each pixel, whereas grayscale height/bump maps basically just alter the apparent height of a surface. The visual differences can be kind of subtle, definitely, but when done well and in the right gfx engine, a normal map is a much more powerful tool. For anyone that wants to try this extra easily and has (kind of old but hopefully basically the same) photoshop, open a full color normal map of whatever format. Go to Image > Mode > Indexed Color. I like Local (Adaptive) for Palette, 256 color, Forced None, Dither None (when possible ... if it is creating weird banding you will have to dither) for settings. Save it as a TGA, pop it in your override (rename it to an existing bump map texture ... such as twilek_m01b like the one used in this thread), go look at a twilek (or whatever you chose to replace). The thing I have no idea about is whether you need to reverse the blue & red channels (swizzle it) in these for them to work correctly (as they appear when exported by Kotor Tool). I found this technique to do the color switch in photoshop before I realized that none of it was working for me for a lot of reasons: http://i.imgur.com/nNHu7yf.jpg Testing? I am thinking I could post a vanilla-recompiled model or two for people that can see the bumps to test with. Suggestions? Something that's going to show the normal mapping in a potentially good way and is known to compile easily would be ideal. I have used DarthParametric's Test Pyramid a little bit to calculate on, but I'm too noob (and busy) to attempt to get it in-game. FYI, the values he posted above are definitely for the non accumulated face vectors. Here are the numbers I get from my calculations for it (for anyone else trying to implement the calculations): Anyway ... unless the normal mapping on the new models turn out to look all messed up ... newly normal-mapped models (and compiler support) might be coming sooner rather than later.

here's something interesting. I opened twilek_m01b.tpc and twilek_m01b.tga with a hex editor. The tpc had a bunch of empty bytes (is that correct term? they all say 00) for the first eight lines. Then at the end of the file came the isbumpmap 1 bumpmapscaling 1 xbox_downsample 128. The tga (converted by MDLOPs) only had one line of mostly 00 at the beginning, while at the end it had isbumpmap etc... then 76 hex digits, then it repeated isbumpmap etc... The result is that the tga had 18 extra hex digits over the tcp version. Then, I opened the tga with Photoshop, and saved it as a copy tga. When I checked it with a hex editor, this version had 87534 fewer characters than the original version. I have no idea what any of that means . If you need some pixels or vertices pushed around, I'm your guy. If there is eldritch languages, call Robert Langdon to figure out the DaVinci Code I honestly wish I was more help

The torso and arm meshes in the supermodel use completely different names, had their trimesh alpha values set to 0.5, had their render flags set to 0, and had all their alphakey nodes removed. I don't think the cause can be pinned on them. The problem for me is, is this something I am doing/not doing, some sort of bug, or just the game being a dick. Edit: Maybe it is the game being a dick. I edited the DLG and pointed that line of the LS cutscene to the (different) animation used in the equivalent line of the DS cutscene. Despite there being no problems in the DS cutscene, that animation in the LS cutscene also suffered the same torso and arms going full opaque issue. Edit 2: And I also tried switching the (off-screen) animation used in the previous line to the DS scene equivalent. Again, still does it. I don't know what the hell is going on. Edit 3: OK, I solved the LS Dodonna problem, but uncovered some weirdness in the process. The previous animation switch I tried still had a fade in from alpha 0.0 to alpha 0.5 (even though by the time the camera actually switches to Dodonna she is already fully visible). This time I switched to an animation where she was already fully visible and the problem went away. So I tried an experiment with Vandar to see what would happen. I switched his reveal animation from the original with a fade in to one where he was visible the whole time. For some reason, everything except his eyes was completely invisible. And not just for the duration of that animation. His body remained invisible for the rest of the cutscene (which is comprised of a further 8 separate animations). The eyes in this case had animations switching between visible and invisible, because of the aforementioned blinking trick where it swaps visibility between two different sets of eyeball meshes. This is really doing my head in. Edit 4: Oh FFS. I found the problem, and I should have realised sooner. The DLG references stunt models for the animations. In this case, it's the unique hologram models for both Dodonna and Vandar. But for some reason it seems the game reads animations from both the stunt model and the scene model, and in this case even the scene model's supermodel. So I see now why I could never get Vandar to go transparent. My model was using the same mesh names, so clearly it was pulling the 1.0 alphakeys from the stunt model. The stunt model field for Dodonna is blank in the DS cutscene DLG, which is why she worked without a hitch in that one. I guess this is what happens when you try to get fancy and use custom names. Although to be fair to myself, I only really did that because of the MDLEdit crash issue. So, really, it's all @bead-v's fault.