Leaderboard

Even I have to do a tentative release date from time - if only to convince myself to finish it. Cast list subject to change or expansion.

There is no irradiated skybox in the original M4-78 but I changed the models so that there is now. And yes, it will change once the radiation is cleared. Sure thing. Here's an example. You can also see some more screenshots in other posts I made over the last months or so. As to the questions of why I'm not releasing K1 yet. There's no specific reason for why I want to release them simultaneously, but that's the route I want to go. One reason is that I still need to make screenshots and stuff like that that will take some time and I'd rather focus on getting all skyboxes done first before I go down this rabbithole so that I can then make all screenshots for both games at the same time. Depending on how long finishing TSL takes I might decide to release K1 earlier but not before I've finished the add-ons like BOS:SR and I haven't even started those. With the exception of Taris that I mentioned before, they shouldn't take too long though. I'll keep you guys posted. We'll see how it goes. Rest assured though, it won't be long now (at least compared to the 3+ years this project has been in the work now... )

Milestone reached: All K1 skyboxes, backdrops and models are finished or in short: Everything for vanilla (!) K1 is done Before you get your hopes up though, that does not mean that the release is imminent! The current plan is to release the mods for both games simultaneously, although that might change. However, I want to have the addons for K1 ready at least before I release it. That's mostly BOS:SR support which includes a Taris skybox that will probably take a while to do. The reason for why getting K1 actually done was that I had to do some tweaks to Kashyyyk and the Tatooine buildings, but mostly I iterated through dozens and dozens of iterations of improving Manaan as I wasn't really happy with the old version. The sky was too dark for instance and there were issues with K1s terrible bloom effect. But after several weeks I finally reached a result that I really like. Sadly I don't have a screenshot, so you'll have to wait for closer to the release to see it. Another thing that kept me busy was M4-78 which is now pretty much done. You've seen most of it before so it was mostly busywork of adding backdrops to all modules, tweaking fog, etc. But it also included the irradiated skybox: Certainly looks unhealthy, doesn't it?

Nobody can give you an answer. This is the "how long is a piece of string?" of modding. The time required is entirely contingent on the specifics of what you want to do, your relevant skills/proficiencies, and how much free time you have to devote to it. Maybe you could do it in a week, maybe you'd still be working on it in a decade. If you want collaboration then there is no reason not to lay out what it is you have in mind. Then people might actually be able to give you some informed opinion on how feasible what you want to do is, and what sort of effort would be required. But right off the bat, the fact that you think it requires a team means the likelihood of it ever seeing the light of day is low.

There's still a few decades before that comes out, plenty of time.

Thanks! Work has been continuing with the first TSL skyboxes being rendered in their full glory. As an example, here's one of the Onderon skyboxes including holes in the turret gun barrels: At the same time, I'm also working on the mod skyboxes. So far M4-78 and Coruscant are done designwise but still need to be rendered. That brings me to a question for all of you though. Is there any mod that I should include, i.e. make a skybox for, that is not already part of my plans? So far I want to make skyboxes for: M4-78 EP (TSL) Coruscant Jedi Temple (TSL) BOS:SR (K1) Green Grass for Dantooine (K1) Maybe. I'm not sure about that one yet, so let me know if that's something you're interested in. It wouldn't be a lot of work so I'll probably do it anyway, but knowing what the community actually wants would help. I'm also considering Yavin IV and Ord Mantell for K1. I haven't played either of those, so I can't say how good or popular they are. So please let me know if that's something you're interested in. Are there any other mods that I should include? Please let me know.

Yes, that's the case. It's on my bug list for the Community Patch, although it's been sitting there for a while. There's a similar issue with the dark side ending with only certain party members being lootable. We might've fixed that one already, I forget.

Hi I've spent the last month working on a new decompiler for NCS code, and I'm ready to share my work in progress with you all. It works properly on many scripts, but there are still situations where it produces incorrect code (but the issues are usually relatively minor). I started this project both because an updated, open source NCS decompiler would be useful to me, and also to learn more about decompilation theory. It's a fascinating topic - I plan to create a YouTube video series on decompilation, using this code as an example. It's also meant to be a reference for others who want to implement an NCS decompiler for themselves (e.g. in C++ for the xoreos-tools project), or for those who want to learn decompilation in general - although NCS is a relatively simple language to decompile (for many reasons, discussed in the GitHub readme), I use very little in the way of "heuristics" and have based my algorithms mostly on the famous 1994 Cifuentes thesis "Reverse Compilation Techniques". I'll keep you all updated if you're interested in any educational content I produce based on this project. Relative to DeNCS, my code has some new features (some implemented fully, some still in the works), including: - Detecting if-else if-else if-...-else chains and not using nested ifs (done) - Doesn't have any problems with ACTION assignments to global variables (DeNCS fails on this, which is one of the main reasons some K1 scripts don't work in DeNCS) (done) - Handles recursion gracefully using a technique I came up with (which I believe might be novel) (WIP but mostly done) - Detecting includes and using the source code from the game's NSS files rather than the decompiled code (WIP) It works quite well, but it's not perfect yet and there are issues (take a look at the GitHub README for more information). Please be very careful if you want to use this for your mods, and (if possible) decompile scripts with the original DeNCS as well to check for consistency. If in doubt, I'd trust DeNCS over my decompiler for now. You can find the complete source code on GitHub at https://github.com/lachjames/ncs2nss as well as instructions on using the decompiler if you'd like to give it a try. I'd be very grateful for any suggestions or issues anyone would like to raise I'm aware that other decompiler projects are currently in the works, and I'd be more than happy to work with anyone who would like to work with me. I've licensed the code under GPL 3.0; my understanding (I'm not a lawyer) is that you are welcome to use the code for anything as long as you open source that code too. At the very least, this is my intent. This is the same license xoreos-tools uses, so it seems reasonable. This project relies on xoreos-tools for disassembly; Windows binaries are included in the xt/ folder (but I intend to remove this before any official release, or at least work with @DrMcCoy to make this automatically update to the latest version of xoreos-tools).

So I was browsing the TOR subreddit the other day and there was one of those show-off posts where someone posted pics of their various outfits throughout their character's story progression. The thing that really caught me eye was the sword used in one of them. It was new to me, but apparently it was added to the game two years ago - the Ancient Sith Lord's Warblade. I figured it looked pretty cool and might be worth porting, maybe for use as Ajunta Pall's sword, since that is described as having an ebony blade. I did do an initial port of it, but then I realised that the description also mentions that the blade edges are notched. I had a look through the other weapon models to see if they had something like that. There aren't any swords, but the retractable blade from the Zakuulan Exile's blaster (which I made my own version of, back before ports were allowed) looked like it might work. I took that as a starting point, reshaped it into a sword blade and remapped it to fit the Warblade's texture. Then I swiped a hilt and crossguard from one of the other sword models, lopped a few bits off and changed the texture a bit. And here's the result: Still need to do some tweaking of the textures, and of course the envmap is a nightmare as always. Also in hindsight I think I should have duplicated the lower half of the blade instead of stretching it, so that the scallops were more numerous and more pronounced, since it looks more wavy that notched. Not sure if I really want to more or less remake the blade from scratch though.

the work on K1 is going well so far, i did numerous improvements to the different planets & also implemented a new type of reflections: Complex texture based noise reflections. As every texture has its very complex set of layers, shapes, this technique only highlights certain areas of the texture like only certain crystals on a marble tex or the blank spots on a galvanised metal plate. This makes a much more natural, realistic look possible for a wide array of materials. Apart from this a lot of detail work has been done, like for example the metal application at this wooden Dantooine door: The special thing about it is, that its using cubemap for shine and additionally fakes a Self-illum effect of that tiny lights within: Manaan also got a total makeover: Sneak peak at Dantooine: Kashyyyk:

You guys may want to do a test of a larger map in KotOR before proceeding. If I remember correctly, I tried rendering higher resolution maps for some of the Sleheyron areas, but they turned out all wonky in the game, as if the game only uses a set pixel amount for each dimension. There may be additional settings in the GUI files that could be changed to work around this, but I don't know of them.

I'll try a little tutorial: Conversion: With KotOR Tool you extract pmhc07.mdl (from Kotor II -> BIFs -> models.bif -> Aurora Model) and pmhc07.mdx (from Kotor II -> BIFs -> models.bif -> Aurora Model Extension). Now with MDLEdit you load the mdl file, just to see which supermodel you need (it's almost always S_Female02, but still good to check). After loading the file, on the bottom half of the window you see "Header", click that and on the top half of the window you see "Supermodel: S_Female02". This is the supermodel from K1 that you need (the supermodel from the game you are porting to is needed). The mdl and mdx of the supermodel need to be in the same location as the model you're trying to convert. So, in KotOR Tool you need to export those files, Kotor I -> BIFs -> Aurora Model / Aurora Model Extension -> s_female02.mdl/mdx. Preperation for conversion done. Now you open MDLEdit, make sure the KOTOR1/KOTOR2 button below the menu is on KOTOR2, because you're loading a K2 model. Load the mdl file, you might think you can now just switch to K1 and save a binary file, but no. You can now switch the button to KOTOR1, you Save -> ASCII, then you load that ascii file, now you can save as binary (which the game can use). Put the mdl and mdx in K1's override folder. Textures/portraits: K1 has 2 more darkside transition phases and the filenames work slightly different. K2: neutral/light, halfway dark (...d1), full dark (...d2) K1: neutral/light, 1/4 dark (...d1), halfway dark (...d2), 3/4 dark (...d3), full dark (...d) With PMHC07 you're in luck, the portraits all have the same pose, so in an image editor you can combine different images to get the intermediate phases. For example, load the neutral portrait, add the halfway dark portrait in a layer on top, set the opacity of that layer to 50% and you get K1's d1 phase portrait. You do pretty much the same with the head textures. Portraits: Kotor II -> ERFs -> TexturePacks -> swpc_tex_gui.erf -> P -> po_PMHC07/po_PMHC07d1/po_PMHC07d2 Head textures: Kotor II -> ERFs -> TexturePacks -> swpc_tex_tpa.erf -> P -> PMHC07/PMHC07d1/PMHC07d2 2da files: To turn this into a mod you would need to use the TSLPatcher, but that's a bit beyond the scope of this tutorial. You can however study the changes.ini file that come with one of my mods that do something similar, it's mostly just changing P[M/F]H[A/B/C/H] values to PMHC07. There's no PMHC07 in K1 so you can stick to that name. To test things for yourself you need to add lines to portraits.2da, appearance.2da and heads.2da (You can extract those with KotOR Tool to your override if you don't already have these in there. Kotor I -> BIFs -> 2da.bif -> 2D Array). You can add a new line with the * at the bottom of the list and you can copy lines to that new line, so copy another row (for example an existing PMHC one, right click the "button" of an existing line, left from the first column -> Copy Row, similarly you can paste that on the new row). Make sure you change things accordingly. Portraits.2da lists the playable characters and points to lines in appearance.2da, appearance.2da points to a head in heads.2da. In this case I would repeat how things are done for an existing pmhc, for example pmhc05. Good luck and happy experimenting

Wow, this is looking pretty good! I'm interested in including these in my M4-78 Ebon Hawk movies if I do another version.

Welcome! It's great to meet a fellow victim programmer! I'm unfamiliar with NCSDIS, so I read a man page. As far as I can tell, it produces an assembly-like output, DOT output, stack information, and control structures? My binary does all of that, too. 🤣 Not sure how NCSDIS helps here or can be integrated, but I'm interested in looking at it to see what I might have missed. The documentation is accurate. It says the JSR instruction doesn't modify the stack. However, before you even get to the instruction description the section "Calling Subroutines and Engine Routines (ACTIONS)" states that "Invoking subroutines [Amano: that means JSR] or engine routines [Amano: that means ACTION] is done basically in the same manner. Arguments are placed on the stack in reverse order. The call is then made and the callee removes all the arguments from the stack prior to returning." So, somewhere inside the called function is where the arguments are popped. This makes sense given that NCS was patterned after machine code, and the most common calling convention at that time, stdcall, had the callee clean the stack. No worries, this is my thread to discuss the development of whatever this will be named. I'm not on Discord, but I will send you direct messages here if I run into any issues. You can also subscribe to this thread in case anyone else replies, particularly from DP, Salk, or DrMcCoy since they directly work with NCS files. 😊

Hi @DrMcCoy thanks for “@ing” me - I rarely post on forums but this has given me motivation to do so I’ve made the GitHub repo for my implementation of “ncs2nss” public at https://github.com/lachjames/ncs2nss. There are a few things to know: - Firstly, it’s a work in progress and isn’t perfect. However, all the fundamental components are implemented and the code runs most of the time without error (as in runtime error - it may well make decompilation errors) - I would be not just happy but “double plus happy” if this were ported into C++ and included in xoreos-tools - I say in the readme that one of my goals is to demonstrate how this can be done in Python (using tools I’m familiar with such as rply) so others can implement the same (e.g. in xoreos-tools). I haven’t put an official license on it yet but like DrMcCoy I’m a big believer in open source so consider it open with attribution. - My version works with ncsdis and I encourage you to do the same (and include your improvements in xoreos-tools) as one perfect library for disassembly is better than two that work most of the time. This is just my opinion and I don’t mean to diminish the work you’ve done on the disassembler (I’m sure it’s great, just like xoreos-tools is great) - I just feel that if we all merge our efforts we can make a better final product @DrMcCoy feel free to post/copy anything from our conversations if you’d like. I’m an open book; just didn’t want to annoy you on GitHub by cluttering up your inbox with posts on issues In particular, let me copy-paste my latest message to him on Discord below: *** BEGIN QUOTE *** Hey so I've realized that this heuristic analysis is not reliable enough to be used properly, but I came up with another solution which works every time. The problem is that the Skywing documentation is incorrect, and JSR does in fact work just like ACTION in that it modifies the stack pointer by popping off arguments. It doesn't push on a return value though (if there is one, space for that must have been allocated by the caller function before calling the callee). Perhaps what they mean is that the JSR does not do anything "intrinsically", but the function calling convention appears to be that functions pop their own arguments (which is more reasonable than making the caller do it every time; this is something I've actually taught before in computer science classes). In any case, what you can do is the following (after constructing a call graph): For each subroutine in the call-graph, iterating with DFS reverse post-order traversal: 1. If the current subroutine is part of a cycle in the call graph: 1.a. Collect all the subroutines in the cycle 1.b. Trace both the final stack pointer and subroutine calls from every possible path from the start block of each subroutine to a block with no successors. 1.c. For each of these paths, we can form an entry in a system of simultaneous equations, where the final stack pointer is on the RHS and the subroutine calls are on the LHS. For example, if a path through subA calls subB 2 times and subC 2 times, and the final stack pointer is -8, our equation would be "0a + 4b + 2c = 8". 1.d. Solve this (potentially overdetermined) system of linear equations for a, b, c, ... which are the number of arguments for subroutines A, B, C, ... respectively. 2. Otherwise, compute the number of arguments as per usual for non-recursive functions. Can then also determine if there's a return value after finding the number of arguments. One issue with this is the problem of vector/struct arguments. This method will tell you the size of the stack space which is popped from the stack after calling each subroutine; however, it does not tell you the structure of said space. However, this is easy to calculate once you know the number of arguments - when you call the function in another subroutine, you can use the state of the stack at that call to determine the types of the sub's arguments (including how much space they take up). *** END QUOTE *** Don’t mean to take over this thread so I’ll make a new one if you want. I’d also be more than happy to talk to anyone on discord about this - feel free to message me (Lachjames#6269 - if you’re on the DS discord server you should be able to message me).

It's been a while! I hope all is well. First, as you can tell I'm not dead. (But, I may be a zombie.) Most important, I am still working on the decompiler and have been since the last update! Back in May I was preparing a status update, but stopped because I didn't like the code. I couldn't say why, exactly. It worked, it was fast. But, for some reason I wasn't satisfied. So, I scrapped the code and started over. And I finally saw what the problem was: the original code wasn't written to be easily extended. Which was important, since it still needed features. (If I had to guess, I would say it was 5%-10% complete.) Since then, I've made significant progress: To do: Embedding NWScript function declarations into the binary Complete (Yes, all 877! No nwscript.nss needed!!!) Identifying simple expressions (e.g. addition, assignment, bitwise operations, and function calls) Complete Fixed handling of STORE_STATE op code Identifying statements Declarations Complete Assignment Complete Iteration, selection and jump statements Still working Operator associativity and precedence This is irrelevant at the byte code level Type conversions This does not appear to exist in NWScript Byte code conversion to source code Still working Source code conversion to byte code Not started GUI Not started Analysis of NCS file bugs Still working Given what I've learned over the last few months, I would say progress is now 30%. Here's an example of what the decompiler currently does: 02 03 [RSADDI, create a named variable of type int on the stack] 04 03 00000002 [CONSTI, Place a constant (i.e. temporary) value of type int onto the stack] 05 00 0300 01 [Action, Call the function 0x300, popping 1 argument off the stack] 01 01 FFFFFFF8 0004 [CPDOWNSP, Copy the result from the top of the stack to an existing variable] This series of four operations is represented by the following psuedo-NWScript: 02 03 int I0; 04 03 00000002 2; 05 00 0300 01 int GetScriptParameter(int nIndex); [Function 0x300 (768) returns an int onto the top of the stack!!!] 01 01 FFFFFFF8 0004 <some variable -8 bytes from the top of the stack> = <value at top of stack>; Continued evaluation: int I0; I0 = GetScriptParameter(2); We have a variable declaration, and then assignment of the function result to the declared variable. In C terminology, that's a variable definition: int I0 = GetScriptParameter(2); Some of the steps are omitted, but we see the following: Some NCS op codes translate directly to NWScript statements (e.g. RSADDx results in a named variable) Some NCS op codes translate directly to expressions (e.g. CONSTx places a constant, or literal, into the script, ADDxx places addition into the script) Multiple NCS op codes will need to be combined to make complex NWScript statements, as in the example above At the moment, I have partially decompiled scripts. And, the binary does not choke on global variables initialized by functions the way DeNCS does! @Salk and @DarthParametric should be happy, since this means the swoop race scripts from Manaan and Tatooine can finally be decompiled! I'm also tallying errors I've found in scripts. Here's one in pseudo-code: string S1 = "Blah"; string S2 = "Meh"; object(S1) == object(S2); NWScript does not have casts! Casts added to illustrate the problem! What's wrong with this? NWScript is based on C, and C is a strongly-typed language. This means an entity of type string is different from an entity of type object! So, when NWScript is told to test for equality, it needs to compare the entities using their type information. That means strings should be compared byte by byte, up to the length of the shortest string. But, we told NWScript that S1 and S2 are object types, which are pointers! The pointers are compared, but not the strings to which they point! Thus, they will likely never test correctly even when the strings have the same contents! This is a real bug I found, and while I don't think it breaks the script I found it in, it could explain weird issues I've had with the game over the years. (I once tried to leave Peragus, only to find the Ebon Hawk surrounded by 30-40 robots. There're supposed to be two or three!!!) That's all for now. Hopefully, I'll have more progress by next week.

I put that warning against using the Steam Workshop version of TSLRCM for a reason. I suggest you read this on why using Steam Workshop is NOT recommended: This is why I do not use the Steam Workshop, and I will not provide support for Steam Workshop. If you encounter bugs because you are using the Steam Workshop, tweaking a few files does not guarantee you won't encounter any more bugs, so I suggest you just reinstall KotOR 2, use the installer version of TSLRCM instead and reinstall my mod and other mods you want to use. Installing manually may sound like a hassle but that is the best way to avoid bugs and conflicts.

@VeganCannibalism, check this page for how to fix the registry issue.

I assume you're using MDLEdit, if not then that's the easiest way to go. No face animation means you need to have the super model from the game you're porting to be in the same location/folder as the model you're converting. If you load pfhc06.mdl with MDLEdit you can click on Header on the lower half of the screen, then on the top half you see Supermodel: S_Female03, that means you need to extract the mdl+mdx from K1 with that name. In the whole process you load with K2 on, switch to K1, export as ascii, load that ascii and then you can save as binary. I've seen the line in the middle on several models, but that's not something I know how to fix. It's not a problem with the texture but with the model or slight differences between how the 2 games apply the texture to a model. It might also be that it wasn't an issue when KotOR didn't have those wide screen or higher resolution fixes.

v1.5: - Added lightsaber forms to Dark Jedi NPCs in the game; - Fixed Form III: Soresu to give Defence Bonus +4 as stated in the readme; - Fixed description of Form V: Shien/Djem So to state a defence bonus *decrease* of 5; - Fixed Forms III and V to prevent effect stacking; - Corrected Makashi stats by reducing Will saves to +2 and changing Defence Bonus -5 to Damage +3; - Added lightsaber forms to c. 70 Jedi/Sith NPCs in the game; - Incorporated my old "Korriban Academy Workbench" mod; - Restricted lightsaber forms to characters wielding melee weapons.

Hello! I'd like to ask your opinion about this item's restriction. Currently it's restricted to Light Side but not to Jedi. The description speaks specifically of being an item created to celebrate Guun Han Saresh's acceptance into the Order. Do you think it would make more sense if only light sided Jedi could wear it? Thanks.

Hello, ebmar! That is exactly what I had done locally but I wasn't quite sure. Especially considering that the polar opposite item (Tulak Hord's Mask, which also looks identical in the original game) is restricted to Dark Side but not Jedi. I hope others will chime in and give us their opinion as well. Cheers!

I think that's a great idea for consistency's sake. I mean, it does make sense after all. Perhaps adding Jedi Defense to Feat Required field on the item's template/UTI would be the best approach for that.

The mouth issue is due to the facial bones in K1 & K2 being different. If you just port a head without correcting that, then they'll be animated improperly. I've posted a sort of mini-tutorial on it here.

My offer still stands if you're unable to run the CSLU Toolkit. If you can do all the setup work and all I have to do is hit a button, I don't mind hitting the button.

Lip creation requires the audio. Read the tutorial for it and provide everything needed if you want someone else to generate them. You could also consider a Win 7 VM, which would allow you to do it yourself.

Sorry About My Typing, I'm Partially Blind In My Left Eye And Capping The 1st Letter Of Each Word Helps Me Spot The Spaces Between Words, So Again Apologize

It's left over from Neverwinter Nights, in which it makes the user immune from paralysis and movement speed debuffs. Maybe it does the same thing in KOTOR, but it could very well do nothing. It's entirely possible to have armor that doesn't restrict Force powers, though. The restriction is through the base item number. If you make a new base item type that is otherwise a copy of armor with the same appearance and such, it won't have the restriction.

Project delayed until further notice. I have to learn some things in animating scenes myself before moving forward. There's only so much that I could've asked DarthVarkor to do and it's high time for me to step up to the plate and do more. Luckily, I think I have all of the programs that I'm going to need. I have the time - as much as I want, now that the deadline is apparently out the window. (See new video below.) I just need the experience at this point. When I have more information to pass on to you dear reader, I'll be letting you know here in this thread. In the meantime, if there are folks that haven't handed in their reviews, feel free to get in touch with me via PMs. Let's see if we get through this together. Update: That . . . is a very old binder of mine. And that grey package is essential to the documentary. Any guesses on what it is? Update 2: The following video contains a review that can be found through this link: http://loresworn.com/lso-plays-knights-of-the-old-republic-ii-m4-78/ As I did not hear back from the authors, I decided to use TTS to create both the voices of the two reviewers and a additional narrator voice that opens and closes the review. This preview doesn't include any animation. It is however designed to give you an idea of how text reviews of the various EP versions will be handled: synthetic voices with a "droid like" filter placed on top. At the time of this message, reviewers that have send in their own audio will not have the droid filter applied. (Yes, even if they are portrayed as a droid in their animated segments.) This filtering concept is only in the planning stage so it may be subject to change. But for now, enjoy this preview review from folks that are not attached to either DeadlyStream or the KOTOR Subreddit (AFAIK). This is only the beginning.

It's easy enough once you become somewhat familiar with Kotor Tool. You need that to extract the model (.mdl) and model extension (.mdx), as well as the supermodel so that the face animations aren't missing. Then you just need to use MDLedit to port whatever you want. Note however that the editing tool will screw up the smoothing groups. There's some steps involved, so let me know if you want to give it a try.

Hello! It seems that after the Leviathan, Bastila's equipped items are gone with the exception of the weapon. Can someone else confirm this is what actually happens? If that is the case, I find it quite inconsistent. It should either be everything (preferable) or nothing. It doesn't make sense that the only item returned to the player's inventory is her weapon.

It's possible, although it's not so straightforward with the current setup. The masters use the same robe model as the player, so currently the mod simply overwrites that model. They would have to be made to use an unedited copy of the original robe model. I'll keep it in mind for a future update.

BoS:SR has a LOT of data in it, as does the Lehon expansion, though less so in the latter case. Your install order is the best you could do for compatibility, but you're simply trying to throw a whole lot in there, more probably than can rationally be expected to work together. BoS:SR and the K1CP already are, I believe, fundamentally incompatible. Tack onto that other mods like the Lehon expansion and a bunch of Force mods and you're playing with fire. I'm not surprised you're running into issues.

Yeah. Perhaps you could create some sort of parser to autodetect differences or something. At least they were pretty good about flagging changes in comments, prefixed by xxx-OEI. An example of functions with added variables: object CreateItemOnObject(string sItemTemplate, object oTarget=OBJECT_SELF, int nStackSize=1); vs object CreateItemOnObject(string sItemTemplate, object oTarget=OBJECT_SELF, int nStackSize=1, int nHideMessage = 0); And of course they added entirely new functions that don't exist in K1, for example GetScriptStringParameter (which is not a thing in K1).

Took a look there and I did actually find a fix. If you create a .txi file and add the line mipmap 0 downsamplemax 0 the line disappears. There was also another solution that involved the use of an open32.gll file but I play on android mostly so that fix wouldn't work there.

Yeah, I was using MDLEdit but I wasn't doing the intermediary step of exporting as ascii and I hadn't exported the super models either. Thanks for your help, I'll give those a try and see if I can't find some way to fix that line :)

For KotOR 1, you can simply type "whereami" in the cheat console, and it will show the coordinates on screen.

As the title says, what exactly do you need to do to have custom items spawnable as loot?

I've updated the package to include the new versions. I've kept the old versions just in case people might prefer those versions. Just scroll to the top of the page as the information up there has updated with pictures of the new versions of Disciple's dark sided portraits. (And this time, the TXIs are named properly.)

This topic actually came up on the Discord server yesterday. I argued that, much like dark side players look like cancer, Jedi preserve their health and youth better, which would be why the K1 player looks like they're in their twenties. This also lets you imagine Revan's and Malak's age before and during the war as you see fit. Do with that as you will. It would be more fitting to give Carth his unused aged head texture for K2, come to think of it.

You can do it directly in MDLEdit, or decompile it to an ASCII, edit it in a text editor to change the name, then recompile. Alternatively, you can hex edit the model and do an ASCII string find and replace, but you'll want to keep the same number of characters for the filename going that route.

some new skyboxes for Onderon & Dantooine:

I have no complaints about this. I just noticed it. I made a preliminary sketch.

I was actually making a mod which does just that, all I need to do to finish it is to make the TSLPatcher and it'd be ready to go. EDIT: And it's uploaded- https://deadlystream.com/files/file/1376-light-side-ending-masters/

You need the version for the game you're porting to, so in this case K1. Everything else seems fine, so if that's still not working, it's possible MDLEdit requires you to convert to ASCII, then load the ASCII before compiling. I usually do manual adjustments with KOTORMax rather than a straight port so I don't remember the specifics on that. And if that is the case, then you would likely have to do manual adjustments as well, because MDLEdit & MDLOps don't always get the smoothing groups right when converting.

The bug commonly referred to as the "Juhani Quest Glitch" has officially been fixed. With the help of LiliArch, Kexikus, and several other people, I've managed to fix this long-standing bug in the game, and here's the bug, how the bug is caused, how to fix it, and how we found it: The Bug: Whenever you follow Juhani's personal dialog far enough along, you will be approached by a Twilek named Xor. He will take an interest in Juhani, but is forced to leave disappointed and angry. Later, he ambushes you outside your ship if Juhani is present, and will be dead when all is said and done. From that first moment when you get approached by Xor, you will no longer be able to be approached by any more messengers, effectively stopping the advance of others' personal quests and blocking you off from a shop later in the game. Because of the loss of this store, most players have learned to hold of on delving too deep into Juhani's past until later on, after the store is open. The Cause: The bug is caused simply because the game checks that the value of the global number K_XOR_AMBUSH is either 0 or greater than 2 when determining whether to have any messengers approach you. K_XOR_AMBUSH is set to 1 after Xor talks to you and takes an interest in Juhani. It is set to 2 after he attacks you later on. But it is never set to 3 after the attack is done! The Fix: You guessed it: you need to set the global number K_XOR_AMBUSH to 3 after Xor dies. This will allow other messengers to approach you and allow you access to a store later on. The Discovery: While looking into this bug, I went searching through the game's files for how the messengers were spawned and determined. I found out that each planet had one or two scripts for this, but not all could be decompiled. By examining the ones that could be decompiled, I was able to track the code that handles everything to k_inc_utility.nss in KotOR 1's scripts.bif. The relevant code from that file: Of importance is the following sample: int nXor = GetGlobalNumber("K_XOR_AMBUSH"); //Do not fire any messenger plots on Kashyyyk if Chuundar is dead if(GetGlobalNumber("K_CURRENT_PLANET") == 20) { bConditional = GetGlobalBoolean("kas_ChuundarDead"); } if(bConditional == FALSE) { if(nXor == 0 || nXor > 2) { This led me to investigate the K_XOR_AMBUSH global number and how and where it was changed. I discovered that it was set to 2 just before he attacked you, but that it was never set to 3 when he is dying. From there, I gathered saves from Kexikus and others and tested setting the K_XOR_AMBUSH to 3 after Xor dies. And everything works! This script is used by the game to launch Xor's death scene, but I've edited it to set the K_XOR_AMBUSH to 3 at that time as well. Simply drop it into your override folder and you're good to go! k_hxor_state03.7z

The TPC texture format contains a floating point number in its header that we refer to as 'alpha blending'. It appears to be critical when used with DXT5 compression. This tutorial will try to help you use this feature properly. What is alpha blending? Alpha blending is not a direct 'opacity' or 'transparency' factor. It is only relevant for non-environment mapped textures that contain alpha-channel image-based transparency. For example, semi-transparent signage, mostly transparent windows, ghosts, etc. The best description I can give you for what alpha blending is: TLDR: alpha blending is not object opacity. It hides any mesh behind the textured object that has opacity less than tpc alpha blending number. Set it to 0.0 when using texture alpha channel as transparency. The meshes that will be hidden include any mesh that may be using alpha channel solely for environment mapping. Let's see how this plays out in practice with some visual aids. Each figure uses a TPC encoded version of the K1 Manaan Overhaul semi-transparent texture for the Sith Embassy signage. Transparency of the sign is right around 50%. Figure 1. TPC with alphaBlending set to 1.0 With alphaBlending set to 1.0 the only thing that shows through the sign is the skybox itself. This may be some kind of depth buffer test to make sure that something always blends through, which, in the 1.0 case, leaves just the most distant mesh, the skybox. Figure 2. TPC with alphaBlending set to 0.9 This seems to be the critical shot. With alphaBlending set to 0.9, lma_wall11 is showing, while lma_wall09 is hidden. lma_wall11 is 100% opaque, 0% transparent. lma_wall09 is 85% opaque, 15% transparent. So because lma_wall11 opacity > alphaBlending, it is shown, while, for lma_wall09, opacity < alphaBlending, so it is hidden. Figure 3. TPC with alphaBlending set to 0.5 In figure 3 we can see that both lma_wall09 and lma_wall11 are showing because their opacities are both greater than 50%. Figure 4. TPC with alphaBlending set to 0.0 This looks exactly the same as figure 3. Wait, isn't that weird though? Why can't we see the other sign through the first sign? It's opacity is 50%, which is greater than 0.0... Figure 5. TPC with alphaBlending set to 0.5, reverse viewing angle Just by looking through the sign in the opposite direction, the signs in the background now are blended through. This is showing a couple things. First, it seems that alphaBlending doesn't actually control instances where the same texture is behind itself. Instead, it appears that there is some kind of directionality at play. I haven't figured out what determines the direction of blending. I investigated whether it was the faces that appear earlier or later, but that didn't necessarily seem true. Using alpha blending The game's vanilla textures use all kinds of different values from 0.0 - 1.0 here. I do not fully understand why or how they have come up with a lot of their alpha blending values. In my testing, it seems like if you have a semi-transparent object, you set this to a low value, 0.0 or 0.1, and if you have a non-transparent object, you set this to 1.0. The important thing is that you do not think of alpha blending as the transparency or opacity of the object itself. If anyone comes up with better guidelines for setting this value through scientific testing, I will be happy to update this post to reflect the improved guidance.

Someone should mount a rescue attempt.

I gave it to Quanon to texture. Then he was eaten by a space slug. The end.

You didn't mention whether or not it could be posted on the Nexus.