ebmar

Members
  • Content Count

    1,179
  • Joined

  • Last visited

  • Days Won

    43

ebmar last won the day on December 24 2021

ebmar had the most liked content!

Community Reputation

856 Jedi Grand Master

About ebmar

  • Rank
    Caffeinated Sith Lord

Profile Information

  • Gender
    Male
  • Location
    : Dromund Kaas

Recent Profile Visitors

38,884 profile views
  1. Yeah, I was on a habit applying envmap to the sclera part so there it goes with this one as well.
  2. Quite opposite to what DP suggested -- I'm not encouraging you to use it, but if you know what you're doing--at least locally--it's worth a try. I'm using it along my TSL build, and are comfortable with. I'd enthusiastically use it for K1 as well if only it supports it, which apparently not. Be advised that I'm using GOG version of TSL, so I can't tell if things works the same with others [Steam, retail, etc.]. And to answer your questions -- Yes, you can for TSL but only one level apart, IIRC -- for example; Override \ GUI -- and not Override \ GUI \ Menu Only if you think you need to, or most importantly -- can. From my documentation should only be 2DAs and JRL. Whatever suited you, really. This is how my [TSL] Override's lookin' for reference --
  3. UTI is for Items [weapons, armors etc.], UTC is for Creatures [NPCs, etc.]. No, make it a habit to put back module-specific templates back to their own MODs/modules, such that one you mentioned above. You can use ERFEdit as the external-tool to work on it. As with Holocron Toolset @Cortisol might have better answer as I haven't tried the feature yet.
  4. For this type of change one will have to load/enter the module the first time to have it work. So in this case you'll need to load a [saved] game anywhere before landing on Dantooine. The basic idea is to have the game load the [object] templates before they're spawned into the module, otherwise they still carry the previous data prior to the edited ones. No you don't, and never have to edit the RIM -- ever, at least in K1. The game prioritize MOD over RIM, so any change you make to the MOD will take precedence shortly -- that, if you load it right. One will not need to edit RIMs' 'cause they're critical for rollbacks and/or debugging without having to reinstall the game.
  5. ebmar

    TOOL:tga2tpc

    Yeah, more or less. Basically,--speaking as an end-user of the format--I'm quite certain there are no differences regarding TGA vs TPC colors, pixels' positioning/orientation in such it'd make them details changing shapes or something -- and even if there's one there can only bits of jaggedness/artefacts at parts. However, I guess that's inevitable regarding how compression works -- like almost in general. But again, there are probably edge-cases like you experienced -- which I never had one, and that can be down to many things such as the [conversion] process itself.
  6. ebmar

    TOOL:tga2tpc

    tpcview takes account on rendering alpha-channel with the diffuse/texture, so that black area appear transparent there as it's applied with alpha-mask purposed for envmap in-game, if I call this matter correctly. Therefore, I don't see any issue regarding tga2tpc's TPC end-result -- particularly in this substance.
  7. That's not advisable -- as in your case then the baton will have Vibroblade's soundsets/SFX as defined in the baseitems.2DA [weaponmattype] -- unless you intent on having that. A rather proper route will be by adding new entry for it -- using one of the dual-wield melees as the template and edit the fields where necessary. However, it seems possible to use the current baton's ID and changing the value of weaponwield from 1 to 2 to match the other DW melees. Although I haven't tried to see if it's working [properly] or not. As JC said the game check for the specific lightsaber item types for FJ to function. Granted that your idea should work [like having a sword pointed to the saber item type], but you can't do much about the SFX--and its other specific traits--unless you don't give much concern about them.
  8. Actually I'd suggest you to just edit the OnEnter itself rather than calling/execute it from your script. That way can remove the hassle from having to edit the relevant field on the ARE/IFO. Granted, one can just make a unique name for a script that used for executing the original and placing it to the Override, but I believe that'd do more problems than it solve. Understandable that there are some edge cases which the original can't be decompiled, but if necessary just go with the editing. Not really aside of other members' source, vanilla scripts and once in a while I visit NWN Lexicon for relevant answers that can't be found anywhere. And not to forget asking other members for insights is a great educational resources as well. Though I find the best way to learn is by decompiling any of the binary, and make your way reconstructing them as readable as can be with intelligible constants -- for example [to where they fit into]; int 1 to TRUE, float 0.0 to DIRECTION_EAST, int 5 to ANIMATION_LOOPING_TALK_NORMAL, etc.]. Oh, and comments [started by // then followed with one] can go a long way too -- as our masters @Qui-Gon Glenn once taught me as well --
  9. No worries, the pleasure's mine. Anyway, in case you missed the added comments you should change the filename of the executed script/k_pdan_13_areaold to something less/equal to 16 characters. The script will still compile and the ExecuteScript function will fires -- it's just there's nothing to execute 'cause the game can't read it. Appreciate you think of me like that -- but I know there's more about the [KotOR] scripting world that I didn't understand yet, hahah. But as what I have now wouldn't be possible if not with helping hands from other members in the communities. As for scripting syntax [usage of logical AND && / logical OR || / logical NOT !] I'd suggest you to check on this one -- Introduction to Scripting Syntax - Tutorials: Scripting - The International House of Mojo Forums (mixnmojo.com)
  10. Try this, this one compiles for me -- void main() { int sID_FOUND_BOD1 = GetGlobalBoolean("FOUND_BOD1"); int sID_light_crys2 = GetGlobalBoolean("light_crys2"); // Checks if BOTH quest requirements are met if(sID_FOUND_BOD1 == TRUE && sID_light_crys2 == TRUE) { CreateObject(OBJECT_TYPE_CREATURE, "dan13_jed99", Location(Vector(160.04f, 84.16f, 12.62f), DIRECTION_EAST)); } // Better change the executed-script name as it exceeds the maximum 16 characters the game could read ExecuteScript("k_pdan_13_areaold", OBJECT_SELF); } Your problem was--as the compiler said so -- Error: Variable "check" defined multiple times in the same scope Although to be honest I was surprised looking at your script initially - thinking that'd work and the problem was on something else. Would be cool if the compiler can support that idea, I guess. And yeah, it had something to do with the and function within a script.
  11. Try this to swap Malak's appearance to his jawless one before the final sentences -- [K1]_Jawless_Malak_[End-Game]_BETA.7z Apparently it's fine as it is using the default jawless model/n_darthmalak02 -- as it already refer the regular model/N_DarthMalak as the Supermodel. Granted, the cape will clips with the floor but that to expected as it will require custom animations like Sithspecter's Revan's Flowing Cape mod -- which not something I could tackle. The script will work with a saved game inside the module so one don't have to re-enter looking for its first time. I don't provide the source with the archive but here's one to look at -- Nope, and I didn't plan working on one [said animations] in the meantime.
  12. Yeah it's possible to switch his appearance with the fade-in/out script that's currently available on the cutscene's setup. I think one can try porting the animations from the default model to there [or only change the reference of the supermodel]. I did working on a mod [not much been achieved though other than the appearance - as it stands now] that use the jawless model as well, and had the cape animations working -- Pretty sure it's sufficient with the regular-custom model -- we'll see about it. Edit: My post a bit late than JC, but yeah -- this one's define whether or not stunt model's needed --
  13. Likewise -- much appreciate your effort on this tool as well. 🍻 Anyways, looks like I'm going to keep you busy here with another report, regarding the recent update in particular, hahah -- The editor looks like can read the SSF well, however -- KotOR Tool unable to read the exported file, therefore I assume the exported-edited ones from your tool's broken. Until this moment the only tool I trusted on editing the SSF was K-Tool, so that's something I took into consideration as well. These new features seem to be working properly. Awesome -- thanks for bringing this feature to life -- and working. 👍 Not sure what you mean by this. Is it support external tools now? Because I noticed it's not supported with the former version. Yes, there's a tab to switch between the internal and external but your tool fail to open one. Feedbacks: Likely you'll have to revisit your built-in GFF editor, as it broke the edited file. I was editing a UTI with yours and it's not working in-game while using K-GFF works I see that you try to support MDL decompile, but not sure what the decompiler you have with the tool there. I tried decompiling a model and it broke -- no texture-reference/bitmap node exported with the ASCII and with that alone one can tell it's not working properly. Unless you had it working to its fullest capacity I suggest you to disable that feature in the meantime. Granted, the Extract Textures feature worked though, so that's a good feat to have at least [although you had a typo there -- Textuers, so you might want to fix it on the go 😛 Probably sorting the ResRef ascending-by-name by default should be a feature to have? I think many would like to have that Having external-tools-support working soon sounds like a good option as well before you can have your built-in editor working optimally That's all for now -- and as usual, I'll catch up with you later. Much thanks for considering this -- cheers. 🍻
  14. Greetings, author -- First, congrats for the release -- and an outstanding texture work to top that as well! 👍 Second, just a quick feedback from me that I think you may consider doing MOD/module installation using TSLPatcher [the updated-one bundled with K1CP] to install/patch the UTCs. Dropping them to the Override will likely cause incompatibilities -- not only with other mods, even with the vanilla game itself because the game known for using same UTC among separated modules but having different setup for feats, DLG used for the conversation, scripts, inventories, etc. Granted, you know your mod better than I do -- and if you think it's fine as it is now [that probably you already done a thorough play-test to them], that's your call. Much thanks for considering this -- cheers. 🍻
  15. Greetings, author -- Introduction: First, a good start for allowing the tool to read users'-end Override -- liking that feature already - among any other improvements from the ol' KotOR Tool. Granted, it's far from perfect as there are still bugs around. However, nothing but promising sign one must say. 👍 Report: Second, I'm giving you heads-up about an oversight with the built-in 2DA editor which it mistakenly read-and-write visualeffects.2DA. What your tool does was it reads the row [label] based on index instead of the actual number [int?] each rows has. For example, supposedly [and by using KotOR Tool] VFX_ARD_LIGHT_YELLOW_10 has 5000 with the (Row Label) which also used for scripting constant -- but then your tool read [and write] it as 130 hence breaking the table and obviously the game as well. On top of my head that's the only 2DA I'm aware of that needs attention - there are others probably, but that's the only one I had encounter the issue with. Therefore, along with this report I hope you able to resolve the issue. Feedback: I might be part of the minority that's using subfolder in TSL's Override -- however, I still wish you can make the tool able to read them also. I think that'd be a cool feature to have. 😁 Think that's all for now. I'll get back to you with reports/questions later -- 'cause one thing at a time, I guess. Much thanks for considering this. Cheers.