DarthParametric

All the party members have Starting Conditional checks to determine if they are available. You should see these being used in most DLGs for party member interjections. For Mira and Hanharr specifically: https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source/blob/master/TSL/Vanilla/Data/Scripts/c_con_mirapm.nss https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source/blob/master/TSL/Vanilla/Data/Scripts/c_con_hanharrpm.nss

So I have been experimenting a bit more with it, making some adjustments. @seedhartha helped by fixing up an issue with the rig of Malak's stunt model to allow the facial animations to work. I have been looking at the original video and comparing it to my in-game capture and looking at the animations in Max to try an sort out the lip sync timing issues. I'm not sure if it's due to the frame rate of the video (29.97fps) or something else, but the individual shot lengths don't match the individual animation lengths (30fps). For example, the first shot's animation is 16.4667 seconds, but the first shot in 09.bik is only 16.383 seconds. Not sure what the best approach to fix it might be, whether I can massage the audio to better match the animation, or if I should try and adjust the animation to match the audio.

Sounds like a pathing problem where she physically can't reach the door. Have you tried manually walking right up to the door until you bump into it before clicking on it?

Yeah I agree that looks the most suitable for a datapad gripped by a mangled arm. Although it does raise the question of how exactly the player would be able to read any info off it.

I doubt it. I'm sure they would have done it in whatever video editor they were using, be it AE or something else. Plus they did all those cross-fades and such in the revelation sequence which would have had to have been done out of engine. If you want to try the in-engine version out yourself, here's the stunt module and the recompiled stunt models. Just open the console and type in "warp stunt_danruins". You'll be in the central room where the overseer droid usually is. Go left or right and interact with one of the terminals. That will launch the cutscene. I noticed the original version's audio really drags out the door opening, so the regular door may have to be swapped out for a custom placeable that uses the stunt animation (tried the character approach, didn't work). Dan_Dream_Stunt_Module.7z

So I created a stunt module for it to test it out. Seems to be some wonkiness going on with the anims. Not sure what's up with that. I'll have to take a look at the models. It also seems like the game doesn't want to apply stunt animations to a door. I guess that will require creating a dummy creature version of it, although possibly the door could just be scripted to open at the right time. Additionally, the star map will need to be scripted to play its opening anim at the end. And that pillar behind it will need to be removed (I think it's just a placeable). Edit: Tweaked the FoV in a few shots to better match the original. Needs further work and the star map timing is possibly a bit off. But obviously resolving the stunt anims is the primary concern. Edit 2: Ahah! It was screwy bone indexes. Should have realised sooner. I assume the models must have changed at some point in development. Recompiling the stunt models against their supermodels fixed it. Now it just needs lip sync and a bit of minor tweaking to align it with the original video's audio track. One option would be to keep it as a purely in-engine scene. The only problem would be replicating the black screen edge "fog" VFX. You can't add any new video effect filters (like the inbuilt security camera blue/scanlines one), but you could potentially cheat it by putting a plane in front of the camera with an animated texture. Not sure how hot it would look though, and it would likely require different versions for different aspect ratios.

It's in the animations, as I mentioned above:

What's the actual file the game is using? A TPC or a TGA and TXI? Whichever it is, attach them.

I think doing it in-engine makes the most sense, just to keep the look consistent with the original. That way the only thing you'd need to add would be the black mist (?) screen overlay and subtitles. Not as such, but here is the module list, which you can use to get the prefixes from.

The Dantooine dream stunt anims exist, although Revan and Malak's positions don't line up with the Ruins layout so they'd need adjustment. The animated camera does line up with the layout though (starts outside the star map chamber). The models are M15aa_c01_cam, M15aa_c01_char02 (Malak), M15aa_c01_char04 (Revan), M15aa_c01_char03 (door). For other stuff like the Bastila/Revan fight and the revelation sequence, most of it should be able to be recreated with mostly generic anims. It would probably need to be done in TSL, just because you can script all anims there, unlike K1. There might need to be the odd custom anim cobbled together. The star map fly-arounds would be simple enough. It's really only the Hawk's take-off/landing sequences, Taris fly-overs/bombardment, and endgame Star Forge battle sequences that would be difficult. They can't really be done in-engine. I did play around with the idea of redoing the take-off/landing videos, but it would be a ton of effort. I had a brief fiddle with the first half of the Manaan take-off before moving off to focus on other things. That would really require a team of people, not just because of the workload but because you'd need people to handle different facets. Like all the missing VFX in this shot for example. Manaan_Take-off_WIP_Render_Test_2b.mp4

Yeah, unless you have a model specifically tailored to your target image/video, it's never going to be perfect. The question is whether the result is better or worse than a simple linear resize. As long as the upscale hasn't turned everything to mush then it's probably a win. By the way, I see you have redone the subtitles in that Dantooine memory. I'm not sure if putting them directly over the image is a great idea. Personally I'd prefer the option of having them in the letterboxing, like the originals. Of course that would require a lot of extra work, so perhaps just leaving them out altogether would be better. Speaking of the Dantooine memory, there are certain cases like that one and the Revan bridge fight where they could probably be recreated in-engine and recaptured at a higher resolution. Then you'd just need to add the VFX on top.

Ehhhhh, don't do that, it's garbage. I ported the TOR Kel Dor as part of another mod for K1. The head and hands could be grafted onto one or more of the regular body models (currently it's using JC's TSL-ported knight robes body) if you wanted bounty hunters.

You can use DeNCS which requires Java. However, you can get almost all of K1's scripts and most of TSL's vanilla scripts (no TSLRCM yet) here - https://github.com/KOTORCommunityPatches/Vanilla_KOTOR_Script_Source

Creating completely new conversations and cutscenes is entirely practical. Aside from your own personal skill, the only real limiting factor is generating entirely new custom VO for existing characters like party members. Although that is becoming a far more realistic prospect now with the advent of AI generated audio. As far as more entry-level stuff goes, to start with I'd suggest grabbing DLGEditor. While HT has many laudable features, its inbuilt DLG editor leaves a bit to be desired in my opinion. All conversations and cutscenes in the game are handled by DLG files, so DLGEditor is going to be your primary tool. That said, they are reliant on some external resources like scripts, static and animated cameras, stunt animations, VO, etc., so you will have to use some other tools. Scripting especially will be a major component of anything more complex than very simple conversations where the PC walks up to and clicks on an NPC or placeable (computer interactions are also DLGs). I'd suggest you extract some DLGs to have a look at in DLGEditor so you can get an idea of how their tree structure, the entry/reply system, and the concept of speaker and listener works, plus the general layout of DLGEditor itself. Start with simple ones like those for minor ambient NPCs wandering around modules before getting into the more meaty DLGs of major NPCs and party members. As to actually editing a DLG, it can be a little tricky to wrap your brain around the logic of where new entries and replies have to go, how multiple reply choices for the player work, and wrangling DLGEditor to actually do what you want. A good starting point would be taking a simple DLG, like for one of the aforementioned ambient NPCs, and experimenting with adding new nodes to an existing branch. Find somewhere in the game like Taris or Dantooine where you can easily test out your changes in-game. Once you have managed your first edit of an existing branch, you'll want to learn how multiple branches work, which means understanding starting conditional scripts. These scripts are just a simple true or false check, which tells the DLG whether or not that branch can be accessed. Basically a DLG will always start at the first branch at the top of the file, unless its first entry has a starting conditional requirement it doesn't meet. If that's the case it will fall through to the second branch, and so on. This is how you build large DLG trees which account for multiple different scenarios. For example, some of those aforementioned ambient NPCs reacting with different dialogue depending on the specific point you're at in the game (e.g. reacting to events on Kashyyyk or Manaan). A starting conditional (typically "k_con_talkedto") is often used to have a unique first-time branch with introductory dialogue, which will only be accessed the first time the player speaks to that NPC. Any subsequent conversations will then start on a different, lower branch. Of course you don't always need to have large, complex DLGs housing every conceivable conversation. You can use a script to initiate a specific custom DLG that handles a one-off conversation or cutscene when required. The other major component of conversations is VO. There are two main types, actual unique dialogue, which DLGEditor calls a "VO_ResRef" (e.g. nglobedavi05008_), and generic alien or droid VO, which DLGEditor calls a "Sound" (e.g. n_gendro_sads1). If you are creating custom unique VO then you are also going to have to create matching lip sync files for it. Typically this is done with the CSLU Toolkit and LipSynchEditor, although various people have tried to create replacements. You'll also want SithCodec so you can convert audio to and from the format the game requires. Here's a guide to creating new lip sync files. Edit: I should also mention the other major element of a DLG, which is the actual text. All text in the game is contained within dialog.tlk, so what you'll see in a DLG is a StrRef - the ID of a particular string in dialog.tlk (e.g. 25157 - "Are you threatening me? "). None of the vanilla DLGs will contain any text themselves, just the external StrRefs. The idea is that having all the game's text centralised makes translation easier. You can swap out just one file to translate all text in the game to another language, rather than having to edit thousands of individual files. However, most mods have typically avoided adding new strings to dialog.tlk for custom lines and have instead used what are referred to as "local strings", text stored within a DLG (or other file) directly. To do this, you'll need to change the StrRef for a given entry/reply to -1 first to make the text box editable.

That's far too vague. How you go about creating a mod depends entirely on what sort of mod it is. Detail exactly what it is you want the mod to do.

Odyssey doesn't have emissive textures. Typically it uses the self-illuminated mesh option to achieve a similar result. In a small number of cases - mostly for character models - it uses an envmap (e.g. CM_Bright). For self illum you can use whatever animations are practical on that type of model, typically level models or placeables. For the most part this is usually just keying the self illum value between black and white to darken or lighten it (e.g. blinky lights in the Hawk cockpit). You can also change the colour of the self illum itself this way, but since the colour is multiplied with the texture this generally doesn't work so hot for complex applications. Your other options are the usual position/rotation/scale/mesh alpha. This would require an actual light in the model, which then has the appropriate animation controlling its brightness/colour. You can see this type of thing with certain placeables. The prologue Hawk module in TSL should also have a good number of flickering lights to examine. There's a specific procedural noise "distort" semantic. It's almost exclusively used for water. Here are all the TXIs (bar the lightmap ones) from both games: K1_TXIs.7z TSL_TXIs.7z

The thing you have to accept with a flipbook is that you are going to have a small number of frames. That's why you need to keep the animation simple, so it will still look decent with a small number of frames and a low framerate.

An 8x8 array flipbook at a resolution of 512x512 would only be 64x64 per frame. Not really ideal even on an object that small given the apparent complexity of the image. You'd have to drop the frame count down to something like a 4x4 array to make that work.

So make your TXI: proceduretype cycle defaultwidth 2048 defaultheight 2048 numx 8 numy 8 fps 10 Btw 2K is complete overkill for an animated texture on an object that tiny. I would drop it down to 1K at most.

Flipbook animation order is always left to right, top to bottom: Are your numx/y values actually representative of the number of tiles/frames your image has?

An OnSpawn can't change a creature's type, it simply sets some of its basic AI parameters. All that type of thing has to be pre-defined in a UTC, stored either in the module or globally. The game doesn't have any provision for dynamically creating creatures from scratch. And aside from basic buffs like those above, K1 is extremely limited in what aspects of a creature it can alter via script. Something Obsidian improved on for TSL, adding a number of new script functions. For completely different numbers and/or types of creatures to be spawned based on player level would generally require a module OnEnter or trigger OnEnter, depending on how/when they need to appear. Possibly also a script fired by a DLG or a door/placeable in some cases. Actual module OnEnters that do it should be pretty limited. I know the constant respawns for the Wraids on Tatooine do this (see here), but I can't remember any other examples off-hand. There are also encounters (UTEs), but I think they only have the ability to randomly spawn from a predefined list, not do anything based on player level.

I'm not aware of any universal scaling across all creatures, but there is the k_def_buff script that gets called in 51 OnSpawn scripts across the game for various significant fights (for example, Dark Jedi, Terentateks, etc.). Over half of those are on Korriban, the rest primarily on Kashyyyk and Tatooine. From the script's comment block: Buffs the target object based on the level of the main PC. Jedi (class) will get the following: Player Level 12+: +4 to Wisdom, +4 to Charisma, +50 Force Points, +50 Vitality Points. Player Level 15+: +6 to Wisdom, +6 to Charisma, +100 Force Points, +100 Vitality Points. Beasts (subrace) will get the following: Player Level 12+: +6 strength, +60 Vitality points. Player Level 15+: +10 strength, +120 Vitality points. Droids (race) will get the following: Player Level 12+: +6 Dexterity, +60 Vitality points. Player Level 15+: +10 Dexterity, +100 Vitality points. Scoundrel, Soldier, Scout (class): Player Level 12+: +4 Dexterity, +4 Strength, +50 Vitality points. Player Level 15+: +6 Dexterity, +6 Strength, +100 Vitality points. Since those instances all call the script externally via ExecuteScript, modifying it would affect all those cases without needing to edit the individual OnSpawns. The script does a GetHitDice check on the PC to determine their level, then applies the appropriate effects to the target creature. It could be changed so that rather than checking if the PC is between levels 12 and 14 or level 15+ and then applying one of two static buffs it could dynamically scale the buffs incrementally for each PC level. Since K1CP makes a minor edit to this script, I'd suggest using that as the starting point. There are possibly other OnSpawns (or other scripts) that apply buffs directly. If so those would need to be dealt with on a case-by-case basis. For example, there's the k_inc_generic function GN_ActivateResistances, which is used in OnSpawns with the spawn-in condition SW_FLAG_RESISTANCES_APPLIED. That makes a creature activate the Resist Elements and Resist Force abilities if the PC is level 15+ (or if they are using the Boss AI). Those would require recompiling the individual OnSpawns with a modified k_inc_generic if you wanted to change that. Edit: So this is the vanilla k_def_buff behaviour: Since it applies the first set of buffs in a 3 level block, I was thinking you could follow that same pattern to expand the buffs, something like this: Here levels 12-14 and 15-17 keep their vanilla values. New values have been added for 3-5, 6-8, 9-11, and 18-20. Level 1 remains unbuffed and level 2 is mostly as well aside from a minor HP increase for beasts and droids. I kind of just made the numbers up as I went, so I have no idea if they are any good or not. And I used the existing buffs as a baseline, so if those aren't considered difficult enough then you'd need to scale them all according to taste. Regardless of what the actual values you wanted are, it would be pretty easy to adjust k_def_buff to add them in for all levels. You could also consider editing any OnSpawns to add the use of the buff script that don't already do so. Here's a list of all the existing OnSpawns that use it that I am aware of, as I noted above. You can find decompiled versions on the Community Patch Vanilla Script Source Github repository.