DarthParametric

Modders
  • Content Count

    4,626
  • Joined

  • Last visited

  • Days Won

    523

Everything posted by DarthParametric

  1. You might want to consider some sort of version control-based backup system (e.g. Git, SVN, etc.). You could do it locally, or via somewhere like Github using a private (i.e. non-public) repo.
  2. The log file indicates that you are trying to install the mod over the top of an existing K1CP installation. DO NOT EVER DO THIS. You must always start with a completely clean fresh installation. Since you are obviously using the Steam version, go into the game's folder (C:\Steam\steamapps\common\swkotor in your case) and delete the Override and Modules folders. Then in Steam, right-click on the game's entry in your library, select Properties, Local Files, and click the "Verify integrity of game files" button. Then start the entire mod installation process from scratch, including replacing the exe and patching it for widescreen, assuming you were doing that (in which case you probably just want to save a backup of the patched exe first).
  3. Can't say I can recall seeing that error before. Attach the whole log file.
  4. There are shirtless underwear models (and fully nude models) on Nexus. There's also redrob's player and party underwear models for TSL. You'd probably have to kit bash some of those to get exactly what you want.
  5. Zip up your save/s and attach the file. This is why the game explicitly tells you: "Save often, and in more than one slot".
  6. Sounds like a recurrence of this issue here, which neither I nor the original author were able to reproduce in subsequent testing. Based on other similar cases elsewhere in the game, I believe this is caused by excessive clicking when a script is trying to execute, causing it to terminate prematurely. You can download a revised copy of the script and put it in your Override folder. Note that this won't help you fix an existing sequence break, but hopefully it should prevent it reoccurring if you load an earlier save and try again.
  7. I've heard of this problem once before. Are you using the K1 Community Patch?
  8. https://deadlystream.com/topic/6218-k1-community-patch/?do=findComment&comment=86783
  9. DarthParametric

    mcNyG5mgbbY

    Malak is about to bombard New York?
  10. Of course. It's not like K1CP/K2CP claims any ownership of it. Ideally @Fair Strides will edit the TSLPatcher mod page and switch it to that exe so that broken version drops out of circulation. One thing to note, however, is that the "fixed" version still requires the presence of dialog.tlk, so that will presumably break Workshop compatibility for TSL.
  11. TXI data is stored in the TPC itself. Don't use KTool to convert TPCs. Fully extract the texture archives (leaving them as TPCs) to a folder. Download TPCView and run it. Go to where you extracted all the TPCs. Select them all, left-click drag them over the TPCView window, hold down the ALT key, release. TPCView will convert them to TGAs plus TXIs.
  12. Are you using a TXI? As I said above, both the normal map itself and the diffuse texture require the appropriate TXI data. Here's the vanilla TXI: LTS_Bwall04B.txi
  13. You need to differentiate between a bump map and a normal map. A bump map is greyscale and only provides detail for a single axis (height). A normal map is RGB and provides detail for all three axes (X, Y, Z) - one channel (i.e. one greyscale map) for each axis. These typically look blue, what is known as a tangent-space normal (as you can see in my earlier posts). Unfortunately, Odyssey refers to both types as bump maps which is technically correct, albeit extremely unhelpful. The error you are getting only occurs with normal maps. Normal maps are used in conjunction with the tangentspace flag in the model. If the model has the tangentspace flag enabled then you must supply an appropriate tangent-space normal map. For Odyssey, these must be RGBA, having a white alpha channel, and saved as a DXT5 TPC. As far as TXI data goes, both types use the same semantics. The diffuse map requires: bumpmaptexture xyz where XYZ is the name of the associated bump/normal map. The bump/normal map requires: isbumpmap 1 at a minimum. It can also optionally have any of the following: isdiffusebumpmap 1 isspecularbumpmap 1 bumpmapscaling 3 The first two are set to either 0 or 1 (false or true, respectively). A diffuse bump applies to the diffuse texture, a specular bump applies to the envmap (when used in conjunction with bumpyshinytexture in the diffuse). Typically you'll want to specify both of these and set them to 1 (I believe otherwise diffuse defaults to 0). The scaling value is an integer from 1 to an unknown maximum, but I'd suggest 10 would be the upper bound. This controls the intensity of the bump. Since Odyssey's implementation is pretty poor, you can try adjusting this number to values above 1 to get more noticeable results.
  14. Note that you typically don't need to create UTW files. You can just add the entry to the GIT using the global TemplateResRef (sw_waypoint001) and change the tag, etc. in the GIT struct. Most vanilla waypoint entries do this.
  15. Interestingly I am not seeing anything like the second picture. The "chunks" sparks FX are working, but the base explosion is not a reddish colour like in the pic. It seems to be more or less the same overpowering white as the vanilla explosion. Edit: Seems like the frag grenade FX model - v_grnfrag_fnf - doesn't actually use the fx_Explode_01 texture. The droid explosion FX models do though, so maybe it was one of those?
  16. Per the Endar Spire include: void PlayExplosion(string sWP = "end_explode01", int bWithShake = TRUE, int bWithRumble = TRUE) { location lExplode = GetLocation(GetNearestObjectByTag(sWP)); effect eExplode = EffectVisualEffect(VFX_FNF_GRENADE_FRAGMENTATION); effect eShake = EffectVisualEffect(VFX_IMP_SCREEN_SHAKE); ApplyEffectAtLocation(DURATION_TYPE_INSTANT,eExplode,lExplode); if(bWithShake) { ApplyEffectToObject(DURATION_TYPE_INSTANT,eShake,GetFirstPC()); } if(bWithRumble) { PlayRumblePattern(14); } } VFX_FNF_GRENADE_FRAGMENTATION being the item of interest.
  17. @Dark Hope: This might be of use to you to add to the description Edit: Removed embed since DH added it to the description.
  18. // 285: Determine whether oCreature has nFeat, and nFeat is useable. // - nFeat: FEAT_* // - oCreature int GetHasFeat(int nFeat, object oCreature=OBJECT_SELF);
  19. You'd have to evaluate that yourself on a case-by-case basis. But it's certainly possible, especially with older games.
  20. I would suggest setting scaling to 100% to at least test its impact, certainly.
  21. It should be noted that the adjusted main menu UI won't exactly match the vanilla menu background. I'd suggest the addition of this: And this:
  22. Note that the rules only allow porting from K1, TSL, and TOR. Unless something has changed recently, any other porting is still no bueno. Otherwise we'd be porting over stuff from Battlefront and the like.
  23. They compile fine directly on my end, as long as you use the version of the first script you posted originally. You left out the leading Location the second time you posted it - i.e. it should be location lLoc = Location(GetPosition(oOwner) + AngleToVector(GetFacing(oOwner)) * 2.0, GetFacing(oOwner)-180.0); not location lLoc = (GetPosition(oOwner) + AngleToVector(GetFacing(oOwner)) * 2.0, GetFacing(oOwner)-180.0);
  24. The include function itself is fine, although you don't need the main. Post the other script. Edit: I thought the first script was an include. My mistake.