DarthParametric

Location uses degrees. 0 degrees is East. You can also script facing commands to force an NPC to reorient and face in a specific direction: AssignCommand(oNPC, SetFacing(90.0)); You can also use fixed cardinal direction constants: float DIRECTION_EAST = 0.0; float DIRECTION_NORTH = 90.0; float DIRECTION_WEST = 180.0; float DIRECTION_SOUTH = 270.0; Alternatively, you can face them towards another object: AssignCommand(oNPC, SetFacingPoint(GetPosition(oObject))); This can be temperamental though. Often they won't change their facing until they perform an animation, so adding a short anim to a script is something necessary if you are trying to assign facings in a conversation, especially with interjections from companions where the NPC may be changing their facing to look at multiple different speakers.

MDLEdit can't handle animations being declared with no keyframes, of which this model contains several. You'll have to use MDLOps. Be aware that KMax will also crash for the same reason if you try to load the resultant ASCII. I would suggest waiting until SS uploads the updated model, which resolves these issues. Edit: Actually the KMax issue is the OdysseyBase having keyframes in any animation.

It's not real modelling unless you remake the mesh and redo the UVs at least half a dozen times.

Don't say I never did anything for you: DP_Bao-Dur_Armour_and_Robes.7z I haven't even looked at it for about 3 1/2 years though, so you're on your own as far as doing anything with it. The adjusted head to match was already released as a modder's resource. Edit: To clarify for people arriving here in the future, the attached file is a modder's resource. You can use it in your own work with the usual constraints - don't redistribute it by itself, and provide credit in any released work.

It just means unload the current module and load the specified module. If you have been there before then that module's GIT/ARE/IFO is stored in your save file, recording whatever state changes occurred.

That script is global, so you'll find it in scripts.bif (original source included). It has nothing to do with transitions though: #include "k_inc_end" void main() { SetTraskState(TRASK_NOTHING_02); } It just sets a global number: void SetTraskState(int nValue) { // AurPostString("New State" + IntToString(nValue),5,7,2.0); SetGlobalNumber("END_TRASK_DLG",nValue); // AurPostString("Set: " + IntToString(nValue),5,10,3.0); } There are a few modules that utilise global scripts for things that really should be module-specific. Manaan is notorious for doing this. I'd suggest permanently extracting scripts.bif somewhere so you don't need to use KTool. I'd also highly recommend installing Notepad++ along with JC's NWScript language definitions if you haven't already. It makes working with scripts much easier. With the global scripts extracted, you can try doing a Search in Files for examples of a particular function:

Normal maps tend to be pretty anaemic so I'd probably lean towards actual geometry as much as possible. At least for the large details anyway. For example, if you want a crack, model in an actual cavity/split.

If you want the creatures to be hostile straight away then you should probably just set their faction to hostile in the UTC. The standard hostile faction is 1 (2 is friendly, 5 is neutral). You can set up triggers as area transitions. The Taris Undercity has some examples of this. If you want to do it via a script, then the function you need is StartNewModule: // 509: Shut down the currently loaded module and start a new one (moving all // currently-connected players to the starting point. void StartNewModule(string sModuleName, string sWayPoint="", string sMovie1="", string sMovie2="", string sMovie3="", string sMovie4="", string sMovie5="", string sMovie6=""); As per the above, you need to specify the destination module name. You can also specify the tag of a waypoint you want the party to spawn at. If left blank then they will spawn at the Mod_Entry point defined in the module's IFO. You can also specify a movie (or multiple movies) to cover the load sequence. A vanilla example is on Kashyyyk when you side with Chuundar. After finishing in the Shadowlands and returning to him, at the end of the conversation you get kicked out of the village. The script that does that is k_pkas_leavetown in the Chieftain's Hall (kas_m23ad) which sends you to a waypoint right outside the village entrance on the Great Walkway: void main() { StartNewModule("kas_m22ab", "kas23ab_kas22ab"); } If you want to fire it from a DLG, you can put the script on the exit node (i.e. the one that says End Dialogue).

Everything tends to turn to mush in Odyssey, so fine details don't really work well. You're going to have to supersize that sucker, a nice fat inch wide bevel. If you go with metal that will allow you to do some bare metal edge wear and use an envmap to get some edge highlights.

It's a commandline program, not GUI-based. You need to either run it from a command prompt or use a batch file. I posted one previously here. It also requires a copy of nwscript.nss from the game to be placed in the same folder as the exe. Since the two games have differing script functions, you'll need two copies of the program in different folders if you want to compile for both K1 and TSL.

You can spawn multiple instances of the same UTC with different locations, yes. There are a few different ways you can do it in terms of varying efficiency, using loops and so forth, although those tend to work best with waypoints that have tag names set up to be iterated through. If you have a look at some of the vanilla scripts you'll see how this is done. Just be aware though that you probably don't want to attach the DLG directly to the UTC, and that trying to deal with a bunch of different objects all with the same tag in a script can get a bit messy if you need to grab a specific one. As far as module transitions go, again the vanilla game should give you plenty of examples to use as a guide. How you go about it really depends on what sort of transition it is. A doorway or other entrance/exit in a module that the player is manually moving through? Or a forced transition at the end of a cutscene/conversation?

Looks a bit blotchy. Procedural? Is it meant to be metal or stone? I think it needs some edge wear. And the edges themselves could really do with a bevel.

Well for starters, you can specify a location much more neatly as a single variable, like so: location lLoc = Location(Vector(25.0,81.0,-1.27), 0.0); Then your CreateObject call would be: CreateObject(OBJECT_TYPE_CREATURE, "trig_test", lLoc); As to the double spawn, this is presumably the trigger's OnEnter? I would guess that it is firing multiple times before the DestroyObject kicks in, either by party members entering the trigger after the player, or perhaps the spawned creature itself. There are a few things you can do to limit that. One is to put the entire function inside an If check for the object entering being only the player specifically, or only a party member (including the player). That way no random NPCs or the spawned creature itself will initiate the trigger. Like so: void main() { object oPC = GetFirstPC(); object oEntering = GetEnteringObject(); location lLoc = Location(Vector(25.0,81.0,-1.27), 0.0); if (oEntering == oPC) { CreateObject(OBJECT_TYPE_CREATURE, "trig_test", lLoc); DestroyObject(OBJECT_SELF); } } For a check of any player controlled character instead, you can leave out the oPC declaration and change the If statement to: if (GetIsPC(oEntering)) The other thing you can do is to check for and set a boolean. Have the initial If check make sure that a boolean is set to FALSE, then set it to TRUE when the trigger fires. This will ensure the trigger only fires a single time, regardless of who enters it subsequently. Doing that means you don't need to destroy it, but you can do that as well if you want. Keeping the trigger around may be beneficial for some cases where you want to reuse it later. void main() { object oEntering = GetEnteringObject(); int SW_PLOT_HAS_TALKED_TO = 10; location lLoc = Location(Vector(25.0,81.0,-1.27), 0.0); if (GetIsPC(oEntering) && !GetLocalBoolean(OBJECT_SELF, SW_PLOT_HAS_TALKED_TO)) { SetLocalBoolean(OBJECT_SELF, SW_PLOT_HAS_TALKED_TO, TRUE); CreateObject(OBJECT_TYPE_CREATURE, "trig_test", lLoc); //Uncomment the line below if you also wish to destroy the trigger. //DelayCommand(1.0, DestroyObject(OBJECT_SELF)); } } The exclamation mark in front of a function means you are checking for the return value to be FALSE (well technically not TRUE, which is an important distinction per the below). Alternatively, you can also write it as: GetLocalBoolean(OBJECT_SELF, SW_PLOT_HAS_TALKED_TO) == FALSE Both are valid, but the second way can sometimes prove to be a little flaky with uninitialised booleans in my experience (even though that's the method Bioware most commonly used in vanilla scripts). Note that I have declared SW_PLOT_HAS_TALKED_TO here just so you can see what I was doing. You could just cut that out and use 10 directly, or indeed use any of the plot flag locals from 0 to 10.

Well that's entirely down to the walkmeshes. If you are trying to cobble together existing room models in a completely original manner then you are going to need custom walkmeshes. Typically, but not always, each room will have its own walkmesh. Points where you need to cross from one walkmesh to an adjoining one in the next room are defined in the walkmeshes themselves, by which edge/s link to which other rooms. If you looked at the AABB node in the ASCII model of a room, you'd see something like: roomlinks 4 186 8 255 3 298 6 301 6 Here there are three adjoining rooms, 3, 6, and 8 (determined by the LYT hierarchy). Room 6 has two edges for its link because of the nature of the room's triangulation. If your LYT points to vanilla room models then their walkmeshes will be linked corresponding to their original LYT positions. The only solution is loading up the entire LYT of your level and reassigning the room links. As far as I know, currently this can only be done in KOTORMax (so Max/GMax required). I don't believe the equivalent functionality has been implemented in KOTORBlender yet. Note that this will mean you will have to change all the model names to custom ones, if you haven't already.

You are confusing the division of labour in a module, the difference between static elements and dynamic elements. The LYT handles the static elements, i.e. the room models. The door hooks in the LYT aren't used at all. All the dynamic elements - doors, placeables, creatures, triggers, transitions, etc. - are handled by the GIT. The hooks do have one use though. They provide the intended door position, so you can just plug those co-ords into the GIT.

What's the specific droid and in which module? From what I recall those repair DLGs should all use the same generic global script, but it's always possible one doesn't and has an error. Edit: Might be helpful if you zip up a save and attach it.

That is no doubt true, but there are known thieves on there. "2CRI" for example. Anything of mine you see there is outright stolen, not authorised by me.

Going back to your original post, this is actually something KTool can do. Look for the blueprint, items sub-section of templates.bif.

Presumably it's hard capped at 100%. If that's the case you are out of luck as far as scripting goes. You'd need to change all the base item prices in the global UTIs (item templates). That's what Bioware did for the stimpaks, except they created a second set. There are the regular ones you get at the beginning of the game, then if you nuke the giant fish they swap to the other set that cost more.

There's little point. Pretty much all of them have already been told, and Valve doesn't care.

Yes, lots of mods on the Workshop are stolen by retards/assholes and reuploaded there without permission. There's an existing thread about it from about a year ago.

Yeah there are a number of Russian (and other non-English) sites that host stolen mods. I'm sure some of them would try to excuse it by saying they are doing translations or something, but they never ask for permission. Best not to link to them, lest they get traffic they don't deserve.