• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ebmar

  1. For the diffuse/LMA_ floor01s.TXI, you can leave out both envmaptexture and wateralpha [unless you needed that, but I don't see why], and use only these two -- bumpyshinytexture CM_asith bumpmaptexture LMA_floor01sB as well as the normal-map/LMA_ floor01sB.TXI, just leave it like this -- isbumpmap 1 bumpmapscaling 2 See if that changes anything. Though more importantly is how you setup the normal-map. You'd be better export it as 24/32bpp uncompressed-TPC format using tga2tpc, that's the only way the game would read it - far as I can recall. Edit: I haven't really practiced using the uncompressed version, so I'm not quite sure about it working or not. That information I got from the tool's page. In the past I was using mostly 24bpp/DXT1 -- it works, but the result could have been better when using the uncompressed one I'd gather.
  2. ebmar


    Wallpaper I used recently, that were made from pnl_mainmenu -- an GUI asset extracted from TSL's game files. The resolution is in x768, pretty fit for a notebook.
  3. Thank you for the heads-up! As I get far enough on -preferably, finished- my playthrough I'd love to be involved in this.
  4. For voice-overs, it's also good practice [at least for these games] to always export the files first as 32000Hz's mono-MP3 at 48kbps with max of 16 characters [it also is necessary to remove any metadata embedded with the files], and then add the WAV header as instructed here. To quote a point from the post -- Though I'll recommend to only put VOs to StreamWaves\ [K1] or StreamVoice\ [TSL] - no other than that. You're good to go then!
  5. That with the attachment I posted above or using your own like you said -- By theory the INI I have posted wouldn't end a failure because I did have success with it on my test. Edit: also -- That one looks like from your system, not something that caused from a mod.
  6. Sorry, not to bump this thread but I think this post better be separated from that one above. Here's the readjusted changes.INI of the BoS:SR mod, both the main installation [bos_sr_1.0] and v1.1 patch [bossr_patch_1.1] -- [K1]_BoSSR_INI_Update_[BETA].7z Edit: this one did not setup Saves installation - so you'll have to put the provided ones manually. You can rename the [Saves] folder as you see fit, just make sure it's unique as it can be. Attached also the installlog.txts which shows from my test, they're working 100% intended - at the very least, from installation process POV. Please be sure not to be switched between the INIs - they have been placed at their dedicated folder to easen the process. Also I noticed a UTI had been installed eight nine times -to one Override folder- yeah, which was unnecessary, and also an MP3 three times. They're all now only installed once. Hope that could at least reduces the number of times people experiencing troubles, not that from playing the mod but only from installing itself. This great mod deserves love greater than itself surely. And may the 4th be with y'all.
  7. It was because the changes.INI of this mod incorrectly use / instead of \ for GFF patching - basically with all modules [which I assume they could've been broken in some ways]. If you're able and/or have enough patience you can try change them to the latter [\]. Edit: or use Notepad++'s Find-Replace All feature. Find an instance of Modules/ and then batch-replace with Modules\ - that should do it. For example: Before !Destination=Modules/ship.mod After !Destination=Modules\ship.mod Granted, when I was started playing and/or trying to mod this game I know there's a "workaround" [which I'm not sure if it's actually working or not, as I've never been able to reach that part of the game this mod does] to bypass the installation - that you can execute the installer from the game's main directory. But please, don't do that as you know how to do it properly now, hahah.
  8. Yeah, @BarnzyBobble were right about the GOG's stretching. And if there's one specific file be consider to restore is mipc28x6.gui. I replaced the v4.0's one with the former/v3.0[?], and it's back to how it should. Though, I left the equip screen [and rest of others except the said one earlier] that changed by the latter version because it works for me. The "zoomed-in" UI for the item's icon shown bit more details - granted, it noticeably stretched. Nevertheless, much thanks for the improvement this mod brings. Can't imagine myself for not using this. Edit: just noticed that there are gaps that should connect the UI with the frame using v4.0 [for GOG users]. So a rollback option would be much appreciated here. Edit2: disregard. There's an option to download the earlier version just above the Changelog section. Pardon my peon-incompetency, hahah. Edit3: apparently a rollback to v3.0 doesn't help much if v4.0 had already installed. What [GOG] users need to do is to DL clonegizka's mod [as attached a post earlier] and then overwrite changes made by this version.
  9. Yeah, it resets only with nodes that gets modified, whichever the fields are. It doesn't with those that were not, even when they had int > 15 [if they were added previously with K-GFF], which is the max limit the Editor can read.
  10. Row 18 only works with default anims that previously assigned in the DLG. Everytime I add and/or modify the anims either via DLG or script, it resets to int/row 0, in specifics node that calls the anim. Update: You were right about this, @DarthParametric -- > Are you editing it in KGFF afterwards to change it back? Apparently the value resets to 0 if the DLG loaded with the Editor, and it needs to be readjusted again with K-GFF. Dang, didn't thought of that possibility earlier. Said and done, many thanks for the assistance. Much appreciated. Update2: Wait, but why it does not resets with default anims setup? Nah, I don't know then. At least there's a setup to overcomes that.
  11. Ah, that kind of make sense - like row limits and such. But how about it's working with default animations - that was previously assigned in the DLG [the NOD_NO one for example], and without having to force the VidFX with a script? Interesting, I'll get an update for that later. Thank you for the input on that.
  12. It resets in-game, and as a workaround it had to be forced by using EnableVideoEffect. The value inside the DLG refers to the custom one, which is why I asked if that's how it is in TSL [modding]. 🤔
  13. I added a new row to videoeffects.2da for a custom CamVidEffect that I intend to use I edited a DLG/medoff.DLG to add and/or modify participant animations using script With the relevant DLG I also change the CamVidEffect from N/A to 18, and could only be changed with K-GFF as the custom one can't make it to DLGEditor's CamVidEffect list With every nodes that calls the animations -nothing fancy as it was just ANIMATION_LOOPING_USE_COMPUTER and ANIMATION_LOOPING_TALK_NORMAL for example- the VidFX resets to int 0 [not even N/A which is by default], which should have been int 18 [as specified in the 2DA] But with default animations setup [or at least untouched in my attempt] the custom VidFX works and not get overridden I hope the information provided was specific enough - thanks for considering.
  14. Greetings, fellow Jedi. Hope everyone's fine. Can anyone confirm in TSL that adding animations [using tk102's DLGEditor] overrides the currently applied [custom] VideoFX/CamVidEffect? In another case it doesn't happen with already existing animations in the relevant DLG. Not there's no workaround for that as we can call EnableVideoEffect with a script together with the added animations, but I'm just curious about this rather bizarre setup [either I did wrong with the DLG or it's one of new things that Obsidian added] in the first place. Much thanks for considering this.
  15. Lol yeah you're right, this is how it looks -- Try this -- lbl_mapm46aa.tpc I wonder if the black bar should be an alpha in the first place but I didn't bother trying that, and just paint it white instead.
  16. Greetings, mod's author. Hope you're doing fine. I use this mod with my playthrough, and apparently there's a missing animations for dodging with a single-blaster. I play female PC and when she [supposedly] dodge the incoming lasers - she'd just freeze in place. Anyway, was the animation supposed to be g5g1 - as referenced by this documentation? Or was it something else. Much thanks for considering this, and may the Force be with you.
  17. Didn't know that the forum had/support this feature --


    [MemberName] linked to your content in a personal conversation: [Subject]

    I got a notification for that, which is cool! :thumbsup:

    1. DarthParametric


      What terrible things were they saying about you?

      Edit: Oh, just a notification of a link, no juicy gossip. Disregard.

    2. ebmar



      What terrible things were they saying about you?


      Your mod replaced all my MOD files with JPEG like wtf?!

      -- kidding, it's good things, hahah.

  18. Entry#15: TSL's Hologram Apparently the hologram in TSL was a build-in blending additive. Guessing that by stripping off the alpha-channel from Holotex - texture used by the hologram as an overlay. The alpha-masking that were used by the texture was designed to reduce the blending effect [aside of to create scan-line overlays] from the additive, the same as why in lightsaber's blade-texture its alpha was always in solid-white state. Any darker than that then the glowing effect will be reduced.
  19. Hahah, ez of course I won't do that. It was only for testing purpose of lightsabers from this thread, and while at it I saw the duck-lips. 😛 With proper runs I'll take it off surely. Update: You were right, @DarthParametric - but it's about the single-saber ready animations/g2r1 missing some nodes. The supermodel S_Female03 were missing several of it for g2r1 - all the way from f_um_g to f_rns_g. Copy-pasting the animations from dual-saber wield/g4r1 make the duck-lips' gone now, though fine tuning would still be needed because there's a visible sketchy facial transition from idle to ready stance [it might be the flourish animations that controls it]. Many thanks to @JCarter426 for his documentation of Analysis of the Combat Animations -- finding the alphanumeric code for the relevant animations saved me from hard-troubles, hahah. Perhaps JC can spark some light if he get the chance because I'm sure he know better than I do, like maybe there's limit about how many nodes an animations can have or anything.
  20. Thank you for the insights! There's light at the end of the tunnel here. I'll see if I can bear with it in an hour or two, and if not -- - seems more like it, hahah.
  21. Exactly before it was cool, lol. Yeah, I have JC's Supermodel Fix for K2 installed, and while having it removed - the duck lips game still going strong here. So it's vanilla.
  22. Haven't done that earlier, but have now with PFHC05, and -- - apparently it looks OK. Dang, now that strikes me, hahah. Hah, now I wonder why, as you've said that -- P.S. also there's no PFHH01 model in my Override so that's vanilla
  23. Greetings, fellow Jedi! In current TSL playthrough I'm looking forwards to use PFHH01 head model as the PC's head appearance. Everything looks right not until I saw her facial animation particularly with single-wield ready stance for melee weapon, as seen in the screenshot below -- It's with the mouth if anyone's wondering. Also don't mind the small dot on her forehead, it's just something on the texture I added, hahah. - while it also appear on the character-menu there. But apparently it looks differently with dual-wield; it's looking pretty normal, and I suspect [or wish] that's how it should have looked in the first place. Therefore, if I'm about to fix that, where should I start? I thought it was about the animations in the head model and were thinking about copy-pasting the dual-wield to single-wield but apparently that's not the case. Much thanks for considering this, and may the Force be with you.
  24. Cool findings, @Crazy34! Probably the best stuffs happened yet in 2020. 😛 I have tested your lightsabers, and they look great. You nailed the radiuskey value of the light [with the animations] quite seamlessly, and I really liked what I saw. I'm very grateful to that knowledge and had to thank you for that, really. While at it I also wanted to share what I could, particularly this one's with RGB value of the AuroraLight, especially for anyone that uses JC's Lightsaber Visual Effects for K2, for the ambient light to match the blade color -- Hope that helps with anything.
  25. Thank you for fixing it rather quickly. Actually there's a thing that I forgot to report in the first place, and I'm not sure if you already changed it with the update. In initial release the HKs' texture are missing their alpha masks, hence the TXI parameters/shader's information [that included with the setup] will not working, therefore, the HKs will not have reflections [as they should]. Much thanks for considering this.