Leaderboard

It is that time of year again; I need to perform some maintenance to ensure Deadlystream continues on. What this means is during the week of 11/26 (thru 12/1), Deadlystream may be intermittently offline. If there are any extended offline periods, there will be updates to this reddit thread. In terms of other site updates, more to come! Thanks for your continued support! edit: Maintenace complete! -T

You only specify the exact placeables you want to spawn. If you just have that one, then your script would be: void main() { if ((GetEnteringObject() == GetFirstPC())) { if( GetObjectByTag( "PLC_TSLCpnl" ) == OBJECT_INVALID ) { CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_TSLCpnl", Location(Vector(179.16,65.40,0.00), 180.0)); } ExecuteScript("k_ptar_02aa_ORIG", OBJECT_SELF); } } Note that the "180.0" is the rotation, so you will need to set that appropriately. I would start with 0.0 (it's a float, so it must always have a decimal) and adjust as needed. Your new script must be the exact name of the original OnEnter script. If you are editing M02AA then it would be k_ptar_02aa_en and the original would need to be renamed something else, remembering that you do not want to exceed 16 characters in a filename. I have provided a suitable example in the script above. Once your new script is compiled, put it, the renamed original OnEnter script, and your UTP in the Override folder and test it in-game.

In KOTOR Tool, the GIT (dynamic area info) is in the XYZ.rim along with the ARE (static area info) and IFO (module info). A UTP is the GFF template for a placeable, equivalent to a UTC for a creature or UTI for an item. You'll find them in the XYZ_s.rim under Blueprint, Placeables. Regarding the script, yes, PLC_301RefEnt etc are the individual placeable tags (as opposed to the resref - i.e. filename - an important distinction) . Basically what the script is doing is firing when the PC enters the module, checking for the existence of the placeable with the tag PLC_301SignPad. If that placeable exists, it then jumps straight to the ExecuteScript command, which fires the original OnEnter, renamed with the "_ORIG" epithet (this new script is given the original OnEnter name so the module loads it). If the placeable is not found (i.e. the engine returns OBJECT_INVALID) then it will proceed to spawn each of the listed placeables at the specified locations (assuming UTPs exist for them).

Like most things in a module, it will need a GIT entry to actually spawn in the level, along with the UTP that defines it. For testing purposes you are probably better to start with spawning it via script so that you can quickly adjust the position as needs be. For this you will typically want to hijack the module's OnEnter script with a new script that spawns the placeable before loading the original OnEnter. Here is an example of one I used for the Nar Shaddaa landing zone module: void main() { if ((GetEnteringObject() == GetFirstPC())) { if( GetObjectByTag( "PLC_301SignPad" ) == OBJECT_INVALID ) { CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301SignPad", Location(Vector(-85.25,19.45,9.66545), 131.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301SignShp", Location(Vector(-55.5,-6.15,9.722), 90.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301DckEnt", Location(Vector(5.7,41.65,9.66551), 180.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301CanEnt", Location(Vector(38.25,0.00,9.66545), 180.0)); CreateObject(OBJECT_TYPE_PLACEABLE, "PLC_301RefEnt", Location(Vector(0.0,-44.25,10.0), 90.0)); } ExecuteScript("k_301_enter_ORIG", OBJECT_SELF); } } The important difference to note is that scripts specify rotation in degree, but the GIT specifies the bearing of placeables in radians. From memory they also use differing origins, so it can take some trial and error getting it right. As far as actually determining the position values goes, you can either run around in the level in-game and use one of the armband mods that will spit out your current position, or you can load the level up in Max/GMax and derive it that way.

Thanks to @UnusualCharacters for his excellent voice acting! Here's a small update of Lehon Mandalorian Expansion, this is the only Mandalorian character that is not speaking Mando'a, but due to the quality and repeated closure of services by volunteers, I've chosen to keep his voice acting in place and have ceased searching for another. The last Mandalorian character has received her lines and they have been implemented into the game, no external force is holding me back anymore! Overall, as of right now, a few spelling & grammar mishaps exist and a final test to confirm bug fixes are all that's left to do. Currently, I'm working on a gameplay trailer. I'm hoping to release LME before the end of 2018. Star Wars Knights of the Old Republic 18-11-2018 17_15.mp4

It is. Still, you can expect an update for EE soon. Nothing major, just a few tweaks. Haven't testen M4-78EP 1.5, though. So if you experience any problem, report in. 1.8.4./1.8.5. changed nothing that could break EE, plus all post 1.8.3. fixes were already covered by EE.

This is correct. The compatibility patch lies within the EE mod itself. There isn't a standalone patch floating around anywhere. Sorry if I phrased that all weird. I certainly think it does. @danil-ch do you think this could be something that is doable? The patch worked fine with M4-78 1.2 but that's the latest version I got to work. And I looked for you. It still lists TSLRCM version 1.8.3.

Yes. Simply recompile the ASCII against the equivalent K1 supermodel. If you made use of TSL's added bones however, such as for the cloak of a robe, then that won't work in K1, as it lacks those. Fortunately however, @JCarter426 has ported the TSL supermodels to K1 as part of his robes mod, so you can either install his robes mod or just take the supermodels from it (or the modder's resource pack) and compile against those.