DarthParametric

Members
  • Content Count

    3,494
  • Joined

  • Days Won

    342

Posts posted by DarthParametric


  1. In future, you shouldn't use K1R and K1CP together. Versions of K1CP after 1.7 aren't compatible.

    If you are getting crashes with the fade, try Disable Vertex Buffer Objects=1 in the [Graphics Options] of swkotor.ini if you don't already have that added. That's the only thing I can think of with that. It shouldn't be related to the script itself. As I said before, fading is the default behaviour that a lot of vanilla scripts use, so if you are encountering crashing elsewhere then that could be the cause.

    • Like 1

  2. A conversation is initiated between two objects. One is the owner of the dialogue (and all scripts attached to it) and the other is the listener. This is typically the player, but not always. The owner of a DLG is considered the default speaker of entry nodes unless someone else's tag is specified in the Speaker field for that node. All scripts attached to the DLG are executed by the owner. In practical terms, this means you don't need to use a tag for the owner, you can use OBJECT_SELF. You also don't need to assign commands to the owner - any command that isn't assigned to someone else defaults to the owner. But, as I said, a script (and the DLG itself) will immediately terminate when their owner is destroyed. This can create problems if you need a scene to continue on past a creature being destroyed and it was the owner.

    In essence, whoever you assign an ActionStartConversation to is the owner of that DLG and its scripts. If you assigned it to a placeable then the placeable is the owner. The game uses a lot of invisible placeables as owners for cutscenes, because it frees the designer up to do whatever they want to the NPC participants.

    As to your crashes, that is not normal behaviour. Not for a simple fade. That is the default behaviour anyway, so you'd be getting that all the time during the vanilla game. If you are using an EndConversation/EndConverAbort script then yes, I'd expect that could be the issue, since you are presumably destroying the owner of the DLG just as it tries to fire another script due to the delay.

    • Like 2

  3. Is the NPC the owner of the DLG/script? That can sometimes cause problems, since a script will immediately terminate as soon as its owner is destroyed. You can still destroy the owner as the final function in an exit node script, but this will usually happen in plain sight of the player unless you jump them somewhere else first. You can also command them to walk somewhere, like the module exit, first before destroying themselves. In general though, it's pretty straightforward:

    DestroyObject(oNPC, 0.0, TRUE, 0.0);

    The variables here are the creature to destroy, the delay in seconds before destroying them, not fading them out (so FALSE if you do want them to fade), and the delay in seconds before they start fading (which only matters if the previous term was set to FALSE). If the creature is the script owner then you can swap the object reference to OBJECT_SELF. But in that case I would delay calling the function until everything else in the script has finished executing, like so:

    DelayCommand(2.5, DestroyObject(oNPC, 0.0, TRUE, 0.0));

    This will delay calling the function by 2.5 seconds, the value of which you can adjust as needed.

    If you want a creature to destroy itself after walking somewhere first, you can add the command to its action stack. This is commonly seen when an NPC "exits" an area. Often this can be part of the creature's UserDefine script, the case for which can be called at the end of the conversation. For example:

    ActionMoveToObject(GetObjectByTag("k_exit", 0), FALSE);
    ActionDoCommand(DestroyObject(OBJECT_SELF));
    SetCommandable(FALSE);

    To issue those commands from a script owned by a different creature/object, you'd need to use AssignCommand to assign them to the NPC of interest.

    If you want more specific details, you need to provide more info about the circumstances of your scene and how it is currently set up.

    • Thanks 1

  4. They also work on triggers as well. It's common practice to set a local on a trigger the first time it fires. Gives more flexibility than outright destroying it for cases where you might want to reuse it.

    All of K1's random loot placeables use locals in their heartbeat scripts to stop them respawning (although Obsidian added a new function for TSL to just remove the script altogether after firing, to cut down on overhead on the Xbox).

    K1 makes extensive use of module locals for various quest states via the module includes.

    • Thanks 1

  5. If you are going to get into scripting, you'll be spending lots of time rewriting stuff. Comes with the territory. If you are making something for you self, by all means hack it together however you want. If you are planning on releasing something publicly though then you should be willing to refine it to make sure you don't do anything that isn't strictly necessary. It will make your life easier in the long run anyway when you come to setting up a TSLPatcher config.

    TalkedTo isn't anything special or unique. It's just local boolean constant 10. They added an extra utility function for it, but under the hood it's still just Get/SetLocalBoolean. If you want to use the strings and the functions for them outside generic scripts, you'll need to set k_inc_utility as an include.

    • Like 2

  6. By default, mapnotes (like pretty much every other string in a GFF) use a StrRef - i.e. a line from dialog.tlk. If you want to use a local string, in KGFF right click on the Mapnote node in the GIT and choose Add String. That will add a local string child node that will let you type in your description. Make sure the StrRef field in the parent node is set to -1.

    • Light Side Points 1

  7. You're using Workshop mods? Or a combination of Workshop TSLRCM and regular mods?

    And yes, by doing a verify integrity you pretty much 100% destroyed your install. Some people have a nasty habit of recommending this, but you should NEVER DO THIS for TSL unless you are exclusively using Workshop mods (which you should also never do).

    Your terminator guy could be either a texture issue or an appearance.2da issue. Impossible to say without knowing the full extent of your installation. Regardless, it suggests an incorrect/incompatible/broken set of mods.


  8. Sure, go ahead. Just warn people that there will be a hard incompatibility with any other mod that edits that file. It can only be resolved with manual merging, since TSLPatcher doesn't allow for dynamic patching of VIS files (or LYTs).

    • Like 1

  9. You can't run nwnnsscomp by double clicking it. It's a commandline program. You need to run it from a DOS prompt.

    • Open a command window Start -> Run -> cmd and navigate to the location of nwnnsscomp (you'll have to Google how to do that)
    • Alternatively, on Windows 10 go here and download one of the REG files to enable a context menu "Open command window here" in any folder
    • Run your command.
    • Alternatively to all that, create a batch file that will compile all NSS files in the current directory:
    @echo off
    
    rem CHANGE THIS TO YOUR LOCAL NWNNSSCOMP FOLDER:
    set nwnsscompdir=F:\Star Wars Knights of the Old Republic\-=TOOLS=-\NWNSSCOMP\K1
    
    rem NOTE THAT YOU NEED SEPARATE VERSIONS FOR K1 AND TSL, EACH WITH
    rem THEIR OWN GAME-SPECIFIC VERSION OF NWSCRIPT.NSS
    
    for %%F in (*.nss) do (
      if not "%%~nF"=="nwscript" (
        "%nwnsscompdir%\nwnnsscomp.exe" -c "%~dp0%%~nF.nss" -o "%~dp0%%~nF.ncs"
      ) else (
        echo Skipping: %%F
      )
    )
    
    pause

    Just copy and paste it into a text file and save as xxx.bat (note that you will need specific K1 and TSL versions, as described).

    As far as the other question, TRUE is 1 and FALSE is 0. So whatever statements you set to 0 will be set to FALSE.

    • Like 1

  10. It's not a texture issue, it's a module VIS issue, i.e. the file that dictates what rooms are visible from each other. The engine doesn't render any rooms not listed as visible from the current room you are in to save on memory (since the game was designed for the original Xbox with 64MB of RAM). The fix is pretty simple, since a VIS is just a text file.

    Edit: Here @todevuch, try putting this in your Override. It should fix the pictured issues I think.

    m12aa.vis

    • Thanks 1

  11. If you are getting dumped out of the conversation then your DLG tree is broken. Whatever nodes you added or changed are likely not linked back to the rest of the tree, so they just exit.

    You have to manually click to advance when there is no voice over for the line.


  12. If you are using the Reddit mod build then do not use any other mod unless you know what you are doing. You'll probably break things. If you absolutely must use a mod, ask over on Reddit whether or not it is compatible with the build, or you can flag @Snigaroo (AKA Sniggles) directly here on DS. Generally speaking though you should avoid mods from Nexus, again unless you know what you are doing, since a lot of the mods found there are ancient and will cause problems with TSLRCM. Especially ones that use manual hard overwrites.

    TSLPatcher integration is a per-mod thing. It's not a generic mod manager that works with all mods. The author needs to create a custom setup for their mod on their end. Some loose file mods don't need it, like basic texture mods and so forth, but some that do either pre-date the existence of TSLPatcher, or the author was lazy and didn't create a setup for it. Avoid any mod that tells you to drop 2DAs and the like in the Override.

    • Like 1