DarthParametric

Modders
  • Content Count

    4,399
  • Joined

  • Last visited

  • Days Won

    492

Everything posted by DarthParametric

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. Unfortunately this mod does not include K1CP's fix to GN_RespondToShout to prevent neutral creatures erroneously reacting to combat death shouts (e.g. here and here). This would be much more obvious if the author included the source, although it is apparent when comparing the bytecode of k_ai_master from both. @GearHead: I'd suggest you incorporate this fix in an update to your mod. And please include your script source for better compatibility going forwards.
  8. 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.
  9. Might be an issue with the shadow casting meshes. Not something I ever picked up in testing. I'll have a look at it when I get a chance. Edit: @olegkuz1997 - I have confirmed that this is some sort of issue with both MDLEdit and MDLOps. It also happens simply when recompiling the vanilla SF robes model. I can resolve it via KBlender, at least for the vanilla model. Haven't tested it with my cape/belts models, but it should work there too. I'll look at updating the mod at some point after I finish work on the next release of K1CP, so probably early 2024.
  10. 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.
  11. It's a hardcoded limit. We're stuck with it.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. Yeah, you might want to check here - https://gitlab.com/kotorsge-team/kse
  19. The same thing that usually happens. I got bored and did something else.
  20. 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.
  21. 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?
  22. Yes, this is included in K1CP, as stated in the readme.
  23. 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:
  24. Doesn't difference the lips folder? Seems like a comparison of StreamWaves/StreamVoice folders would be a pretty significant missing element, presumably there is already Python code for that sort of thing to be found on Github.
  25. Hrm, I seem to recall this coming up once before, now that I think about it. Perhaps on one of the Discord channels a year or two ago. It might have been something ebmar was experimenting with. There is a way to forcibly do it via custom head models with incorporated masks, but that's not a particularly desirable approach for more than one or two instances.