DarthParametric

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.

I've never played the game on mobile, so I can't really speak to what the normal experience is supposed to be. As to support for other languages, K1CP is currently only made for the English version of the game because that's the version the major contributors use. We'd be happy to support other languages, but that would require native speakers to offer help in terms of translations and beta testing on non-English versions.

It's a hardcoded limit. We're stuck with it.

You've presumably hit the placeables.2da row limit bug. You've installed too many mods that add new rows to placeables.2da, which the engine can't handle. It's rolling over and counting from the top (hence why you get the wrong ones showing). Your install is effectively broken. Nuke and start from scratch. Stop using so many mods.

You've still got the same problem. You're asking for basic "how do I use this program" information. I can't give you a one or two sentence solution. Go watch some tutorials on Youtube about the program's basic functionality and how to skin a model.

Like I said, this is all basic "how do I use Blender" stuff. You need to watch some tutorials. I can't help you, I don't use Blender unless absolutely necessary.

You're asking about basic character skinning/rigging. That's the sort of thing you'll need to watch some tutorial videos on Youtube about. Especially for Blender. I only use it for level model stuff. I know nothing about how the character side of stuff works.

You can either tone down the intensity of the alpha channel, or switch the envmap to a different one. I assume you are using CM_Baremetal? You could try mycube instead. That tends to be a little less intense.

FS created a repo for the update of KSE here - https://github.com/Fair-Strides/KotOR-Save-Editor - although I'm not sure how far along it is.

Yeah, you might want to check here - https://gitlab.com/kotorsge-team/kse

The same thing that usually happens. I got bored and did something else.

Because TSL only uses medium models, so there were no source anims. You can of course get around this via scene scaling in Max, but presumably JC either decided not to do this or maybe just forgot. It should be noted that this is a large part of the point of supermodels, so that you can have a single animation source and models of arbitrary scales using them. Edit: I should point out that the major reason for having a per-model anim is to prevent issues like clipping with custom tweaks. Is that actually happening here? It has been a while since I looked at it.

Looking at the regular cloaked robes (that also have the glitch), only the medium model has the anims anyway. The large and small models are already using the supermodel anims. Is there any reason to keep the custom model anims rather than pushing all of them to use the supermodel?

Presumably it means it can't find it, which is odd if it can find everything else. You can try checking the hash of chitin.key in the game's base directory to make sure it isn't corrupted. The SHA-512 hash of mine is: F51CB6038F897CF6281FB3E64294E8EA7AF0A9ED2C4C47F138CBFD84250763B4DEEF62DF03C852C88B8592AF9D096ED011F507285FE4E8C84508BF0AD1E9F123 If you don't already have a means to generate file hashes, you can try this online tool - https://emn178.github.io/online-tools/sha512_file_hash.html. Simply drag and drop chitin.key onto the page to generate the hash for it and compare it to the one I posted above (note that tool produces lowercase hashes while mine is uppercase, but that doesn't matter). Alternatively, this is the option I use myself - https://github.com/namazso/OpenHashTab/releases/latest Per the name, it adds a new tab to the Properties window in Explorer that will list hashes of the selected file, like so: