Leaderboard

No real updates to speak of at the moment, but I'm busy busy in the background fiddling with 'under the hood' stuff which isn't very visual. I'm going to hold off on doing any more with my Mandalorian recruitment for now, as an opportunity to collaborate with an 'old-school' modder from back in the day has come up, so I'd like to see what comes of it. They're finishing up another project right now, so I'm just getting some of the prep-work done. On a totally different subject, you know that empty landing pad on Taris outside the Military Base? The one with no walkmesh? You'll never guess who I found down there!

When talking about normal maps for 3D models like weapons, armour, placeables, etc., generally the "correct" way to do it would be to generate the map from a high poly version of the model. This is what is known as baking. In modern texture generation, this is often as much for creating the diffuse texture itself in the first place as it is for use with the final game model. Here's an example from some of my own experiments with recreating the Ebon Hawk textures from scratch. Take LEH_grwall01. This is the vanilla texture on the left, and my recreated texture on the right (lacking a grime pass): I started by creating a 3D model of the original texture, like so: This was the high poly model. The low poly model was a simple flat plane of two triangles. When baked out, this was the resultant normal map: Obviously this approach is not always practical. Sometimes you'll want to generate a normal map directly from a diffuse image, which I gather is what you are primarily interested in. The simplest route is to create a greyscale height map. At its most simplistic, this would entail desaturating the source image and then running through any number of programs or PS filters to generate the normal map. For example CrazyBump, AwesomeBump, xNormal, etc. There are also some online tools to do this, for example NormalMap Online. Results through this approach will vary wildly depending on the quality of your source image. As an example, let's take one of the texture sources from Sithspecter's "High Quality Blasters for Modders" modder's resource. We'll take w_blstrpstl_001 and simply desaturate it to create a pseudo-height map. Then we'll feed this into NormalMap Online: This is only about 30 seconds of effort, but the result isn't too bad considering. However if you have a look at the attached normal in closer detail, you'll see a lot of noise. This is typically very bad in a normal map, and in this case is somewhat exacerbated by NormalMap Online's lack of sufficient adjustment parameters to mitigate it. But really the root of the problem is that a diffuse is an extremely poor input source, especially in traditional textures that include baked/fake shadowing and highlights/specular. You can see in SS's source image that there are some highlights across the top of the main body, on the top of the sight back piece (bottom left corner), and along most curved edges. There is also a lot of noise in the flat areas from what I gather is the use of PS's Clouds filter, particularly noticeable in the trigger guard and surrounding area. Fortunately in this case we have some ability to quickly and easily tweak the height map, since SS's source is a layered PSD. Turning off a few of the noisy layers to create a new height map input, the revised generated normal looks like this: Looking at the attached revised normal, you'll see there is now far less noise, giving a mostly crisp map. There's still a little bit of wonkiness due to the highlights - notably at the top edges of the grip/handle, the lens of the sight (top left), and the screw heads and scallops - but that's part and parcel of using this sort of image as a source. Those particular issues could be reduced or resolved with some manual adjustment of the height map. Just imagine it as a gradient where white is the highest point and black is the lowest point. The thing to keep in mind with Odyssey is that its normal map implementation is pretty terrible. It's rarely worth the effort to create normal maps. I certainly wouldn't bother for anything small, like weapons or the like. Large floor and wall panels is probably where it will be the most notable, and these have the added benefit of typically being fairly simplistic in terms of the height details, meaning they are easy to create height maps for. Armour and bodies (like droids) can also make use of them, although this is best reserved for large details rather than lots of noisy fine detail. If you are thinking of trying it for stuff like monitor panels and the like I'd suggest you don't waste your time. Especially if it is going to be in a dark area (like the Hawk's cockpit). Stick with faked details in the diffuse for that sort of thing. Edit: Still far from perfect, but here's a further quick adjustment of the height map to address some of the highlighted (no pun intended) problems: You'd actually want to vary the height of the straight panel lines I think, make them a dark grey rather than black like the scallops. And the top edge of the handle needs to be a gradient to get a nice smooth curve. Same thing for the scope lenses (see the screw heads). w_blstrpstl_001_Generated_Normal.7z w_blstrpstl_001_Generated_Normal2.7z w_blstrpstl_001_Generated_Normal3.7z

The way to do it in K1 is to call SuppressStatusSummaryEntry before the creation or destruction. // 763. SuppressStatusSummaryEntry // This will prevent the next n entries that should have shown up in the status summary // from being added // This will not add on to any existing summary suppressions, but rather replace it. So // to clear the supression system pass 0 as the entry value void SuppressStatusSummaryEntry(int nNumEntries = 1); For example: SuppressStatusSummaryEntry(); CreateItemOnObject("g_w_lghtsbr01");

I believe it's been a while since I've made a request. I'll make this brief as I think the title pretty much covers it. Might anyone be interested in making a tutorial for making bump maps - specifically with the novice in mind? Granted as most of you use PhotoShop, it'll be of significantly less use to me. However I'm sure it would make those making new texture mods with PhotoShop pop quite a bit.

View File Yavin Station Hangar In the vanilla game, Yavin Station is the only location that does not have a proper hangar where the player can walk to and from the Ebon Hawk. This mod adds one that generally matches the original landing/takeoff videos, although I have taken a few artistic liberties. You may notice that, as with the original videos, it looks remarkably similar to the Ahto City hangar on Manaan. I can only assume that the same architect worked on both projects. The hangar comes in two variants: with and without a visible forcefield effect over the hangar entrance. By default, the forcefield is invisible. To change between the visible and invisible forcefields, see the INSTALLATION instructions below. Aside from adding the new hangar, I have also made a few additional edits to the station: - Changed the stars to use a different, less-repetitive vanilla star texture. - Fixed some questionable geometry at the main observation window. - Edited the walkmesh by the observation window to correct a glitch where the player could teleport into space, originally documented by the KOTOR 1 Community Patch (K1CP). Please note that I have not reused any K1CP material for these edits. IMPORTANT: For everything to work right, you will need a save from before visiting Yavin Station for the first time. Thank you for downloading, and I hope you enjoy this mod! ------------------------------------------------------------------- INSTALLATION Run INSTALL.exe, and select the option "Main Installation" when prompted. If you are using "High Quality Cockpit Skyboxes" by Sithspecter, see below for additional instructions. By default, the forcefield at the hangar entrance is invisible. To add a visible forcefield effect, run INSTALL.exe again after finishing the main installation, and select "Optional: Add Visible Forcefield". If you change your mind and prefer the invisible forcefield, run INSTALL.exe a third time, and select "Optional: Revert to Invisible Forcefield". ------------------------------------------------------------------- COMPATIBILITY This mod is incompatible with any mods that alter the area geometry of Yavin Station. Reskins are technically compatible, but they might look strange with a few new textures that I have added. If you are using a reskin of the Ebon Hawk's exterior, see the instructions below. This mod has not been tested with the KOTOR 1 Community Patch (K1CP), the KOTOR 1 Restoration (K1R), or the K1 Yavin IV Planet Mod, but I do not expect any significant issues. For best results, install this mod after K1CP or K1R and before any other mods that alter Yavin Station. ------------------------------------------------------------------- HIGH QUALITY COCKPIT SKYBOXES If you are using "High Quality Cockpit Skyboxes" by Sithspecter (which I highly recommend), I have included compatible skybox textures matching my new hangar. After installing the cockpit skyboxes, perform the following steps: 1. Go to the folder "HQ Cockpit Skybox Textures". 2. Copy the TPC files corresponding to the desired quality into your Override folder. 3. If present, delete the following files from Override: - ebo_yab.tga - ebo_yaf.tga - ebo_yal.tga - ebo_yar.tga - ebo_yat.tga "High Quality Cockpit Skyboxes" may be found at https://deadlystream.com/files/file/938-high-quality-cockpit-skyboxes/ ------------------------------------------------------------------- EBON HAWK RESKINS To use a reskin of the Ebon Hawk's exterior with the new hangar, perform the following steps: 1. Make extra copies of "LSF_EHawk01.tga" and "LSF_EHawk01.txi" (if present) from the reskin, and rename them as "yvh_ehawk.tga" and "yvh_ehawk.txi", respectively. 2. If present, open the new "yvh_ehawk.txi" with a text editor, and change the entry after "envmaptexture" or "bumpyshinytexture" to "CM_WK_YAVHGR". 3. Copy both files into your Override folder. 4. Delete "yvh_ehawk.tpc" from your Override folder. ------------------------------------------------------------------- POTENTIAL BUGS During testing, I occasionally ran into issues of teleporting into space while walking between the hangar and the connecting corridor. I believe I have corrected the walkmesh issues causing this, but I recommend saving often just in case. ------------------------------------------------------------------- CREDITS MDLedit and KOTORmax by bead-v KotorBlender by seedhartha tpcview and tga2tpc by ndix UR NWNSSCOMP by Torlack, stoffe, and tk102 DeNCS by JdNoa and Dashus K-GFF by tk102 TSL Patcher by stoffe ERFEdit by stoffe and Fair Strides Kotor Tool by Fred Tetra Thanks to DarthParametric for suggesting the visible forcefield effect and providing an example from K1CP. ------------------------------------------------------------------- VERSION HISTORY 1.0 - Initial Release 1.1 - Added an option for a visible forcefield effect 1.2 - Added particle emitters at the ends of the visible forcefield ------------------------------------------------------------------- DISCLAIMER AND PERMISSIONS This modification is provided as-is and is not supported by Disney, Lucasarts, or Bioware. Use at your own risk. The author shall not be held responsible for damage to your game installation, computer, or saved games resulting from the use of this mod. This mod shall not be reposted, in whole or in part, on any sites other than Deadly Stream without the author's permission. Assets from this mod shall not be redistributed in other modifications without the author's permission. Submitter WildKarrde Submitted 05/07/2022 Category Mods K1R Compatible Yes  

Don't call it a comeback, but here's 2 more new feats: Rationing Technique and Intimidation Factor. Doing K1 first this time, TSL can catch up later. Special thanks to JCarter426 for letting me know about suppressing inventory messages, which I previously thought was impossible. Opens a lot of doors.

Agreed. I come from the FLOSS side of things, for me it's natural to release sources. And while in the FLOSS space, we disagree on different licenses, we agree that source releases, with a proper license attached to allow for re-use, is important. And "release early, release often" is also a common mantra: things might happen, so while we wait for a drop of perfectly finished and cleaned up sources, maybe you get hit by a bus. Or, less crass, your HDD dies and you don't have any backups. Or something else catches your interest or your RL gets bogged down or a global panini hits and your headspace is just weird as all f. It happens, that's okay. Don't get me wrong, good documentation and detailed documented specs of file format is also important. Ideally, there's both docs and code. With code, though, if you can get it to run, you can immediately see if it's correct. This isn't meant as an attack or rant or anything, just for an explanation of where I'm coming from here.

@Masamune753 Yes, it was caused by the attempt to limit the forms to melee wielders. I'm about to upload an update that should fix it. UPDATE: v1.6: -Fixed bug which was causing stats to stack unpredictably (NB: restriction of the lightsaber form to melee wielders is now only checked when the form is first applied); -Corrected inconsistent spelling in the description of Makashi; -Corrected Makashi description to reflect actual bonuses; -Corrected Makashi to give +2 to Will saves.

Star Wars: Obi-Wan Kenobi trailer:

One other fan had an idea. How about a mod that alters Calo Nord's appearance on Leviathan and one of the Star Map planets? Maybe include some cybernetics or wounds? There's no way Calo would survive a pile of metal unharmed.

View File PROTOCOL DROID HD This mod will replace and update DrdProt texture files. To Install 1. Download: DrdProtHD 2. Copy all files to the Knights of the Old republic's Override folder. (Example location - C:\Program Files (x86)\Steam\steamapps\common\swkotor\Override) 3. When/if prompted to overwrite files, press okay. 4. If you like the mod; leave a comment or endorse! (It would be much appreciated) Made with love. Submitter Dark Hope Submitted 04/22/2022 Category Skins K1R Compatible Yes  

Having lurked around the forums a fair bit as of late following a lengthy absence from the community, I've decided to dip my toe back into the waters of KotOR modding. Seeing all of the innovations and changes over the past few years in terms of what we're able to achieve has really given me the itch again! For my first contribution, i've decided to publish this tutorial which I wrote more years ago than i'd care to admit which focusses on the correct way to recruit a new party member and build your own custom dialog tree and quest line for them. I did publish a tutorial soley on the dialog tree aspect of this on LucasForums many moons ago, but I later wrote this more fully fleshed out tutorial and fell off the map before I got around to publishing it. I've gone back to polish this off and tweaked/refined it a little to make things more readable and easier to follow, so hopefully it should be easily understood. I've tried to keep my naming conventions for things as close to the existing ones in the vanilla game files for consistency and so that game files can be easily examined whilst following along if need be. Admittiedly this will mostly be useful to people who are not so familiar with modding the KotOR games and possibly people who are experienced in other areas of modding but haven't dabbled in scripting or anything yet, so if you're already a reasonably well rounded modder in terms of breadth of experience across different areas, this may not be for you. That's enough waffling anyway. Enjoy! Step 1 - Preparing your NPC template: The most logical place to start in my opinion is by creating the template file which contains all of the vital information which the game needs to know about our new party member. Personally, I would start off with the .UTC file from an existing party member and modify it to suit. I personally like to go old school and use K-GFF to modify template files, so the field names I use here may not match whatever is in KotOR Tool, but they'll be similar enough for you to work out which is which. The vast majority of the fields in KotOR Tool or whichever editor you are using are completely self explanatory, so i'll just go over a few of the ones you may not be too familiar with. Here we go: IMPORTANT: When it comes to editing the new party member's scripts, you will need to ensure that the below fields match the values I have given. When it comes to setting your new party member's tag, you need to remember to use the tag of the vanilla party member you are replacing. DO NOT use a custom tag. The vanilla tags are as follows: The TemplateResRef is the unique identifier we assign to the party member's template so that the game can refer to it. In my case, I set it to "p_yuthura" and named the file "p_yuthura.utc" to match. Step 2 - globalcat.2da entries: For this step, all you'll need to do is add a couple of lines to globalcat.2da so that the game can track your progress through your new dialog tree/quest. For my example, I added two new rows: The K_SWG_YUTHURA global will essentially track which stage of the quest you have reached whilst the K_SWG_YUTHURA_LEVEL one will keep track of your PC's level as you progress through the quest. Their values will both be checked and modified by scripts whenver you reach a new stage in the tree, but more on that in the next step! Step 3 - Recruitment: This stage will cover the process of actually recruiting your new NPC and adding them to your party. This tutorial assumes that you will speak to Yuthura Ban in the Dantooine Courtyard before you recruit her. In order to have the conversation end and have Yuthura immediately available for selection, you would use this script: //recruit.nss void main() { RemoveAvailableNPC(5); AddAvailableNPCByTemplate(5, "p_yuthura"); DelayCommand(1.5, ShowPartySelectionGUI()); } If you follow it line by line, it's very simple to follow. It removes whichever NPC is currently occupying slot 5 in your party selection screen. It then adds a new party member to that slot based on the template you have specified. In this case, we have gone with p_yuthura because that's the template we created in Step 1. There will then be a short delay of 1.5 seconds before the party selection screen appears, just like when you recruit a new party member in the vanilla game. This line can be left out if it doesn't suit what you're trying to do. Obviously the number for the party member slot will change depending on which party member you are replacing, so here the different values for each slot in the game: Simply attach this script to an appropriate conversation node in your dialog file and you're good to go. In this case, since we are recruiting an NPC which we have physically encountered, there will now be a duplicate of your NPC still in the location you met them, even if you have recruited them already. This is very easily solved with another simple script attached to the final node in the recruitment dialog: // destroy.nss void main() { object oYuthura = GetObjectByTag("dan13_yuthura"); SetGlobalFadeOut(1.0, 0.5); DelayCommand(1.0, DestroyObject(oYuthura)); DelayCommand(1.0, SetGlobalFadeIn(0.7, 0.0)); } Again, very easy to understand if you go through it line by line. The SetGlobalFadeIn() and SetGlobalFadeOut() commands are used here to fade the screen to black and back to normal again with the disappearance of the NPC taking place in between the two. This adds a nice polished appearance to the affect. For a barebones recruitment mod, you could just stop there. If you've followed everything so far, you'll have a new party member join you and they'll work exactly as any other party member would, just without any sort of quest to follow. Step 3 - Dialog Tree: This is the step where you really flesh out your mod and give your NPC some life. Adding a new quest line based around your new NPC is a great way to not only add exciting new content to the game, but also to bring your new content more in line with the experiences players have with the vanilla party members. This is nowhere near as difficult as you might think when you start out. I'm certainly no programmer, but with a little common sense and applied logic, this who process becomes very simple. The first script we create here is the one which checks whether or not Yuthura's quest line has started yet: //k_swg_yuthura01.nss #include "k_inc_debug" int StartingConditional() { int nResult = GetGlobalNumber("K_SWG_YUTHURA") == 0; return nResult; } As you can see, this script checks that the currently set value of the K_SWG_YUTHURA global we created earlier is 0. If the current value of K_SWG_YUTHURA is indeed 0, then the value of nResult will be positive and the dialog node which this conditional script is attached to will be available. If the value of K_SWG_YUTHURA is anything other than 0, the node will be ignored and the game will move on to the next note in the tree. Once the initial conversation has been completed, we'll need to increase the value of K_SWG_YUTHURA so that a different conversation option becomes available next time. We achieve this by attaching the following script to the final node in the conversation tree: //k_swg_yuthura20.nss #include "k_inc_debug" void main() { int nPlot = GetGlobalNumber("K_SWG_YUTHURA"); int nLevel = GetHitDice(GetFirstPC()); SetGlobalNumber("K_SWG_YUTHURA", (nPlot + 1)); SetGlobalNumber("K_SWG_YUTHURA_LEVEL", nLevel); } Once again, this is simple to follow. We start by assigning values to nPlot and nLevel so that we can reference them later in the script. nPlot is assigned a value equal to the current value of our K_SWG_YUTHURA global and nLevel is assigned a value equal to the PCs current level. K_SWG_YUTHURA then has its value increased by 1 and K_SWG_YUTHURA_LEVEL has its value set to the PC's current level. Moving on to the second stage in the quest/conversation is really simple. All we do is attach this script to the relevant node in the dialog file: //k_swg_yuthura02.nss #include "k_inc_debug" int StartingConditional() { int nResult = GetGlobalNumber("K_SWG_YUTHURA"); int nLevel = GetHitDice(GetFirstPC()); int nLastLevel = GetGlobalNumber("K_SWG_YUTHURA_LEVEL"); if ((nResult == 1) && (nLevel > nLastLevel)) { return TRUE; } return FALSE; } A little more going on here at first glance, so let's break it down. We start by assigning values to nResult, nLevel and nLastLevel. Here, nResult is the current value of K_SWG_YUTHURA, nLevel is the PC's current level and nLastLevel is the current value of K_SWG_YUTHURA_LEVEL. If the value of K_SWG_YUTHURA is 1 and the players current level is greater than the stored value, then the conversation node will be available. You can basically copy and paste this script to cover the rest of the quest line, just by altering the nResult value which the script checks for. Every time you advance a stage in the quest, you increase it by 1. Summary: All in all, this is a fairly simple process to go through and doesn't take too long at all when you consider that the majority of the conditional scripts for your quest are going to end up being copies of eachother with just that one value changed. I've attached my example scripts to save you needing to copy/paste them if you want to use them as a basis for your own. Of course, there's still so much more you could do with your mod to make the experience even more immersive. In terms of dialog, you can make certain conversation options available only if other conditions are met, like needing to have collected a certain number of Star Maps to have been collected or needing to have reached a certain point in another quest. There are so many possibilities and the vast majority of them can be implemented using the same principles outlined in the tutorial above. Get creative with it! mf_recruitment_scripts.zip

If you like this mod, you may also be interested in another mod that reuses DarthSapiens' T3-M4 texture. Refurbished Astromech Droids uses the same T3-M4 skin to upgrade the 3 other reskins of the Astromech droids found in both games. The coloring of the texture remains pretty darn faithful to the original color schemes as well. (I may be biased though.) Edit: I just noticed that N-DReW25 already linked the mod in the description. That's it - I'm going to bed! LOL

Nice mod! I have long used Darth_Sapiens' texture after properly renaming the file and was very happy with it but now I will check out SH's recolored version as well. Thanks!

Thanks to advice from both TamerBill and DarthParametric, I finalized Mission's unique feat (tested and working): Survival Instinct Unique Ability: Mission Mission grew up on the streets of Taris where she learned self-preservation. She gains a +1 bonus to dodging and saving throws when she is the last one standing in combat.

View File K1 NPC Immersive Feats K1 NPC Immersive Feats by Sdub Version: 1.0 Description: In TSL certain items can be limited to certain characters, In K1 however that is not possible... until now. I sought to create a workaround to limit certain items to certain characters. Especially for when modders create items. The solution I came up with was creating unique feats for the NPC's that do not have one. Four NPC's already have a unique feat with. Bastila - Battle Meditation Juhani - Force Camouflage T3M4 - Blaster Integration Zaalbar - Wookiee Toughness I created one for each: Carth - Decorated Pilot Mission - Streetwise Canderous - Regenerative Healing Implants Jolee - Hermit HK-47 - Assassin Droid One important thing to note. These feats are for immersion only. They do not have any active effects attached to them unless the active effect already exists for the characters, like Canderous and his regen. This mod is intended to be used as a resource. I'm planning on releasing a few mods that will require this as a base. Feel free to use it as well, all I ask is that proper credit is given. A huge thanks to @Effix for helping me get the mod properly setup with the TSL patcher. Please let me know if you have any issues. Installation: Run TSLPatcher.exe and locate your swkotor folder Uninstallation: Delete UTC Files for characters, icon images, and replace the dialog.tlk with the one in backup from patcher installation Compatibility: This mod should be compatible with all mods K1R Compatible: Yes Tools Used: TSL Patcher ChangeEdit TLKEdit KOTOR Tool Holocron Toolset Big thanks to the KOTOR Modding Discord, Deadlystream, and @Effix Submitter Sdub Submitted 05/05/2022 Category Mods K1R Compatible Yes  

Have you tested that? Editing an include file will not, on its own, do anything. You'd need to recompile the scripts that use the include.

Update: As suggested by DarthParametric (and reinforced by Sdub), I have added an option for a visible forcefield at the entrance to the hangar. If you've already installed version 1.0 and want to try the new effect, you can proceed straight to the "Add Visible Forcefield" part of the installation. Thanks a ton to Darth Parametric for providing an example forcefield that I could emulate!

The remake is in UE4. There won't be any NWScript in it. It doesn't even use UnrealScript any more, just Blueprints. If you are giving up, then please at least make the current source code available. DS now has its own Github repo for various tool projects. If you'd like to create a repo for it there, jump on the DS Discord - https://discord.gg/h68Z9Ds2 - or send me a PM.

I'd say treat a mod trailer like a videogame teaser rather than a (now defunct) E3 trailer. Show the best examples of what you've added and really use the opportunity to introduce the viewer to some of your characters or themes. Don't hype the viewer up with amazing music and pre-rendered videos when the final product won't look or sound anything like either. Don't show how you wish the mod will look, just show what it actually is.

I directly tried this with Mission for my companion rewards mod. It didn't work.

It's not really. Feats are hardcoded. Potentially some scripting could replicate feat features, but almost certainly not something like stealth run.

Salk, Like everyone here, I am here to learn how to mod Kotor 1 and 2. I am happy to help when I can. And don't mind getting corrected when I am wrong

I was trying to figure out why Bastila was dying so quickly to sand people even tho I gave her Brejik's armband and belt (supposedly effective vs melee attacks). The 2da reference thread had nothing useful, but it wasn't hard to figure out. Damage types: The game has 13 damage types and each weapon can have one or more of these types. baseitems.2da has a column called damageflags. It's a bitfield that says which type of damage a weapon deals by default. In order of least significant bit to most significant (right to left) it goes like this: 0 1 Bludgeoning 1 2 Piercing 2 4 Slashing 3 8 Universal 4 16 Acid 5 32 Cold 6 64 Light side 7 128 Electrical 8 256 Fire 9 512 Dark side 10 1024 Sonic 11 2048 Ion 12 4096 Energy The value itself is stored as a simple decimal integer (tho some other columns use hex - bioware just being inconsistent). The values in the second column are what you'd find in baseitems.damageflags - to have multiple damage types, add those numbers together and put the resulting sum in that column. These types are used anywhere where damage comes in play - for example in all item properties related to damage, including damage bonus, damage immunity, damage penalty, damage resistance and so forth. Weapons by damage type: Disclaimer: This is using the weapon rebalance mod which changes disruptors from 7 (Bludgeoning+Piercing+Slashing) to 8 (Universal damage). It's a change that makes sense. Highly recommended. Quarter_Staff Bludgeoning Stun_Baton Bludgeoning Long_Sword Slashing Vibro_Sword Slashing Short_Sword Piercing Vibro_Blade Piercing Double_Bladed_Sword Slashing Vibro_Double_Blade Slashing Lightsaber Energy Double_Bladed_Lightsaber Energy Short_Lightsaber Energy Blaster_Pistol Energy Heavy_Blaster Energy Hold_Out_Blaster Energy Ion_Blaster Ion Disrupter_Pistol Universal Sonic_Pistol Sonic Ion_Rifle Ion Bowcaster Energy Blaster_Carbine Energy Disrupter_Rifle Universal Sonic_Rifle Sonic Repeating_Blaster Energy Heavy_Repeating_Blaster Energy Blaster_Rifle Energy Ghaffi_Stick Piercing Wookie_Warblade Slashing Gammorean_Battleaxe Slashing Creature_Item_Slash Slashing Creature_Item_Pierce Piercing Creature_Weapon_Sl_Prc Piercing Or transposed: 0 Bludgeoning Quarter_Staff, Stun_Baton 1 Piercing Short_Sword, Vibro_Blade, Ghaffi_Stick, Creature_Item_Pierce, Creature_Weapon_Sl_Prc 2 Slashing Long_Sword, Vibro_Sword, Double_Bladed_Sword, Vibro_Double_Blade, Wookie_Warblade, Gammorean_Battleaxe, Creature_Item_Slash 3 Universal Disrupter_Pistol, Disrupter_Rifle 4 Acid 5 Cold 6 Light side 7 Electrical 8 Fire 9 Dark side 10 Sonic Sonic_Pistol, Sonic_Rifle 11 Ion Ion_Blaster, Ion_Rifle 12 Energy Lightsaber, Double_Bladed_Lightsaber, Short_Lightsaber, Blaster_Pistol, Heavy_Blaster, Hold_Out_Blaster, Bowcaster, Blaster_Carbine, Repeating_Blaster, Heavy_Repeating_Blaster, Blaster_Rifle (Who TF decided a tab size of 8 is a good idea? Also this forum needs a table feature.) So I have my answer now. Gaffi sticks are Piercing damage, and Brejik's stuff protects only v Bludgeoning/Slashing. I feel like this is false advertising. I've been bamboozled. Also, if you have Damage resistance Universal 5/-, it doesn't mean you resist 5 points of any kind of damage, it means you resist 5 points of the damage type "Universal", which is semantically just confusing as heck.

Glad to see this released! Nice job! 😁

May the fourth be with you all!!

With the help of Cortisol over on the discord, we did some sleuthing as to how force powers being restricted by armors work. spells.2da has 2 columns called "requireitemmask" and "forbiditemmask" (these names are hopefully self-explanatory) These are 16-wide bitfields. Some testing confirmed that the 7 least significant bits (right-most) correspond in order from MSB > LSB to: LightSaber, AC9, AC8, AC7, AC6, AC5, AC4 class armors or more specifically they correspond to the following itemtypes in baseitems.2da Bit itemtype 0 31 1 32 2 33 3 34 4 35 5 36 6 39,40,41 I did not find any 2da that creates this mapping. Might be hardcoded in the engine. Have not tested other bits. They may or may not function. Testing that would require pairing every remaining bit with every item type found in baseitems. That's 9*itemtypes (minus the ones we already know about). If someone wants to bother with that be my guest (tho the work could probably efficiently be subdivided if people decide to bother).