• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by DarthParametric

  1. It does, but it's the one used for the placeable sitters. So it's in the super models, but not accessible via the regular human animset.
  2. I assume you're referring to the "disabled" animation. No, that was only added in TSL. Fortunately though HK uses standard human animation names, so that means you could go with the old standby hack of adding the anim to his model renamed to "dance" or "dance1" (or one of the other anims he doesn't use).
  3. No. Some warnings are expected due to MOD files already existing, but not that many. And errors are always bad. Post your install log.
  4. Unfortunately no. The wiki on the PyKotor repo is pretty barebones and only has a few bits and pieces regarding HoloPatcher. K1CP is probably the only mod currently that uses the feature. You can see some discussion about it in the "HoloPatcher migration" issue on the repo as the feature was initially being developed/implemented. There's more on the DS Discord as it was being refined/implemented/tested, between October and December 2023 (I'd have to go digging to find specific links). Probably more useful (and less confusing) would be to just look at the K1CP changes.ini's [TLKList] section. The gist is that you can now specify a TLK in the tslpatchdata folder to be used for overwriting vanilla strings. In this case, K1CP uses the regular append.tlk for double duty, both overwrites and the typical appends. Any appended strings follow the same format they always did. Overwrite strings get listed in a sub-section under the heading of their filename specified at the start of the block. The vanilla StrRef ID is then linked to source TLK ID (i.e. basically the same way the append list works). So in this example, vanilla StrRef 25859 (one of Mission's lines after breaking Zaalbar out of his Gamorrean cell) is being overwritten by string 27 in append.tlk, etc.
  5. All the animations come from SS's Revan model. There's nothing I can do about it.
  6. Just use HoloPatcher and edit the TLK string directly. Far less effort and it's less intrusive.
  7. Since it works fine for everyone else, it's something on your end. Almost certainly an incompatible mod. List all the mods you have installed.
  8. At what point? If it's during the Malak fight then it doesn't have anything to do with this mod as it doesn't touch the hangar module.
  9. The only way that sounds feasible is if you're buffing a skill via script. For example: ApplyEffectToObject(DURATION_TYPE_TEMPORARY, EffectSkillIncrease(SKILL_xxxxx, nBuffAmt), oTarget, fDuration);
  10. You sure you're not thinking of redrob's Player and Party Underwear mod for TSL? https://deadlystream.com/files/file/344-player-party-underwear/
  11. I believe there's some discussion of it in this thread. Physically adding additional room models is pretty trivial. It's mostly a question of what you do to flesh them out with actual content.
  12. Check your Override folder for the presence of PMHA05 textures - PMHA05/PMHA05d/PMHA05d1/PMHA05d2/PMHA05d3 - either TGA or TPC. If the former, see if there are any TXIs of the same name. Also, make sure when using KTool that you have enabled the option to read 2DAs from the Override folder. You could just be looking at the vanilla 2DA.
  13. As ebmar said, you need to edit appearance.2da and change the values in the envmap column for that player's rows: 148 P_MAL_A_SML_05 149 P_MAL_A_MED_05 150 P_MAL_A_LRG_05 from CM_Baremetal (or whatever it is) to DEFAULT, like the other player rows. Search for a tutorial on how to edit 2DAs. Note that this is likely going to introduce transparency issues with armours that will need to have TXIs added to fix.
  14. I don't use Gimp. You'll have to Google how to edit/delete an alpha channel with it.
  15. It's not a fix, it's an error as was pointed out. The original string using "leave" is already correct.
  16. Ah, I see what the problem is. The Rakata mooks are marked for cleanup. They get destroyed on the second module entry by the module OnEnter. Edit: Actually no, they are just getting straight up destroyed by the module OnExit script. Easy enough to fix. Just add an additional GetGlobalNumber("G_FinalChoice") > 0 to the if check. Or just null it out completely. Should be no real need for it.
  17. The trigger's OnEnter only does a check on whether the entering object is a PC and if it has had the SW_PLOT_HAS_TALKED_TO local boolean flag set. There's nothing that should prevent it firing on subsequent entries to the module past the first, and I can't see any other script that applies the flag externally or destroys the trigger.
  18. Just add some new dedicated upgrade vendor NPCs? Doesn't seem like it should be a big deal.
  19. Yes, those are still in my "cannot decompile" folder, comprising 3 of the last 11 remaining scripts. Not sure if @JCarter426's recent TSL successes would allow for any headway on these or not. Although I do have some that @th3w1zard1 produced for me a while back. Probably need to take a look at those. You'd have to compile the NSS in question, then disassemble it and compare the bytecode to the vanilla script's to see what the disparity is. Nothing obvious in the source stands out, although I wouldn't be surprised if it was the format of the tunnel struct. Edit: Looks like SWMG_SetPlayerTunnelPos([0.0,0.0,20.0]); should instead be SWMG_SetPlayerTunnelPos([20.0,0.0,0.0]); A brief perusal of a couple of the onfire scripts looks like it is defining performance values for each individual gear, given that it is referencing the global for gear selection. Seems like it would be pretty easy to add in some checks for upgrades being installed to adjust those. Just add in some multiplier variables that default to 1.0, then do a check for upgrades and adjust the multipliers based on that.
  20. Depends on what the upgrades do. I'd expect multiple scripts would need to be edited. You could probably use some TOR icons as a starting point. They have hundreds to choose from. There's probably something appropriate amongst those used for ship/weapon/armour upgrades. I extracted some for ebmar a couple of years back, but no doubt there have been a bunch of new ones added since.
  21. The base is pretty much exactly what it sounds like. It's what is often known as the "root" in other game models, the base object that everything else is a child of. Here's the hierarchy of the Mando (in Max, since it's a bit clearer than the way Blender displays it): The "OdysseyBase" is what determines the internal name (i.e. stored in the model data not the filename) of the model. N_Mandalorian04 in your case. In terms of KMax/KBlender, it's also where you define the major properties of the model, like the model classification (Character, in this instance), whether it has a supermodel (an external model it pulls animations from), what (if any) animations it has directly on the model and what their names are, etc. Everything else in the model - the bones, the rendered meshes, the hooks, etc. - will all be children of the base. For hex editing, it's typically not a thing you should really need to resort to these days now that the model format is properly supported and Blender is available for free. There are other threads for years gone by that you can search for if you want to get some examples of how it works, but the gist is that you do search and replace operations on ASCII strings. In your case the base (N_Mandalorian02 -> N_Mandalorian04) and the two textures (Mand02_Body -> Mand04_Body and Mand02_Helmet -> Mand04_Helmet). What you might need to change would vary depending on the model, but like I said you should rarely ever need to hex edit now outside of some large batch operation perhaps.
  22. Yeah you can basically do the reverse of the vanilla link and link to a regular head + body row.
  23. Here's your first problem: You're assigning an override texture that doesn't exist (N_Mand0401). Your second problem, the Mando model you're using (taken from someone else's mod) uses two textures. You can't use an override texture with it, even if it was named properly. Also, you just renamed the N_Mandalorian02 model to N_Mandalorian04 without editing it. That by itself is a problem, since internally the model is still named N_Mandalorian02 (and you'll have an error text file about it in your game folder). The correct approach is to rename the OdysseyBase and rename the texture assignments to point to your new textures. You could do that either via a hex editor, or by opening it with KBlender. Although in this case since the model is so old, it's partially broken, or at least non-conformant, so KBlender doesn't recognise the base name properly. But it's any easy fix. I've attached the fixed model for you. Just null out that texture field in your 2DA and it should work as intended. Fixed_Mando_Model.7z
  24. There are script functions that set the bike's speed/max speed/acceleration, presumably used with the boost pads. You could probably just set some globals for having mods installed and then add a multiplier to the speed/acceleration based on a check of those. Edit: For example, when you hit a boost pad it checks the global for what gear you're in (MIN_RACE_GEAR) and, if you aren't in 5th gear, applies: SWMG_SetPlayerAccelerationPerSecond(SWMG_GetPlayerAccelerationPerSecond() * 1.1); SWMG_SetPlayerSpeed(SWMG_GetPlayerSpeed() * 1.05); Similarly, if you hit an obstacle, it applies: SWMG_SetPlayerSpeed(SWMG_GetPlayerSpeed() * 0.7); For the purposes of mods, you wouldn't want to directly affect the current speed, so you'd likely stick to starting with: SWMG_SetPlayerMinSpeed SWMG_SetPlayerMaxSpeed at the beginning of a race. Additionally you might also want to increase the performance of boost pads and/or reduce the effect of obstacles, depending on the mods installed. Or you could even do the opposite, decrease the effectiveness of boosts and increase the penalty of hitting obstacles, if you wanted certain mods to have drawbacks as well as bonuses. Or some combination thereof (e.g. a "Heavy Plating" mod that reduces max speed and the benefits of boost pads, but lets you plow through obstacles with a minimal reduction in speed).