Sithspecter

After quite a bit of consideration, I don't think we have much to worry about, for several reasons. 1. The largest hosting sites that remain for KotOR modding, DeadlyStream and Nexus, haven't allowed this and will not allow it. It's still the status quo on these sites. 2. The moderators of /r/KotOR agree about this issue, and have graciously promised to remove any links people may post with such mods. 3. Steam Workshop is doomed to mangle the mods that are uploaded (at least for now), and it doesn't even exist at this point for KotOR 1. In addition, I'm sure that the Steam staff will respond positively toward any reported mods uploaded by someone who did not create them. It's my thought that if someone wants to publicly upload a mod, they can try to go to Deadly Stream or Nexus. They'll get shut down. They can try to go to Reddit. They'll get shut down. They can try to go to Steam Workshop. The mod they posted will most likely not work, they'll probably get shut down. Any users who download non-working Steam Workshop mods will probably come here, and we'll steer them in the right direction. I don't think this will be as big of an issue as previously thought, and will hopefully bring more members to this community, which is fine by me. I think that the unveiling of the updated TSL on Steam with the Workshop and the shutting down of KotOR Files within a week was just bad timing. I think it will all smooth out soon.

This one: https://www.reddit.com/r/kotor/comments/3eoc1m/uploading_mods_to_steam_workshop/ Basically it's a large outcry of; "theft of intellectual property is okay if it's old..."

It's kind of surprising that it has taken so long for this sort of thing to happen. I'm really thankful that we have such a respectable community here on Deadly Stream and at Lucas Forums. Though there have been occasional violations, there really hasn't been anything of this scale before. I guess it's the first real discernible rift in the ideologies of the community. Not that I really count Reddit as part of the community, as it's just not set up well for modding. In any case, it may be time that some of us make an appearance there. It's the only way that popular opinion might get swayed. I've gone over and voiced my opinion and supported Darth Insidious, who is seemingly the only voice of reason there. Snigaroo on Reddit said this about Darth Insidious, who in my memory is the longest continuously active modder that I know of. I was pretty appalled by it, and the guy clearly has little respect for the modders or intellectual property.

Can you explain what you mean by this?

Before everyone freaks out, just take a look: http://www.gamefront.com/files/listing/pub2/star-wars-knights-of-the-old-republic http://www.gamefront.com/files/listing/pub2/star-wars-knights-of-the-old-republic-ii-the-sith-lords Seems like most, if not all, files are still there available for download. I've seen one with only 9 downloads still there, so don't get too worked up.

Well the problem is that the rooms are definitely already connected in the VIS file seeing as they are right next to each other. I think Varsity Puppet is correct in his theory that this is due to the rendering engine, and I really don't think you'll be able to do much about it.

Well, my forte is in creating lightmaps, not animating them. I'm surprised that you were able to make heads or tails of the existing ones in KotOR, which seem to be pretty confusing and tightly packed to me. First off, would you be willing to explain the process you used to animate the lightmaps to line up with the flickering lights? Did the lights already flicker? That's a very strange problem that the timing would change. I would think that possibly leaving the specific "room" would maybe cause the animation to stop altogether, but apparently that's not the case. KotOR doesn't have any animated lightmaps already in the game that we could reference, so that's unfortunate for your mod. Maybe the lightmaps don't render when they're not in view of the camera? That's the only explanation that I can think of based on your video. Also, I seriously doubt that lightmaps could be added as invisible placeables, given the nature of lightmaps. I'd like to hear a better explanation of that idea.

File Name: Sithspecter's Boba Fett File Submitter: Sithspecter File Submitted: 03 Jul 2015 File Category: Mods K1R Compatible: Yes This mod adds Boba Fett’s signature helmet, armor, and EE-3 repeater, in addition to two pistols of my own design. The helmet item is a disguise, so Boba Fett’s armor and helmet can be worn “over” any existing armor in the game. The items are fairly powerful, and should allow for a larger use of ranged weapons. This mod is also compatible with K1R. To get the items, use the following codes on cheat or KSE: g_i_mask24 – Boba’s Helmet/Armor g_w_rptnblstr41 – Boba’s EE-3 ss_heavy01 – Frontier AF-44 Pistol Click here to download this file

I agree with this statement. The texture in itself looks quite nice, but the perspective is off. A good rule for landscape painting is to use thirds, and never halves. What this means is that two thirds should be devoted to the sky or the ground, never one half. In this case, I figure you've used half for the ground. I know KotOR is a bit different and has many exceptions to this rule, but I think your perspective will benefit a lot from a lower horizon. Still looks amazing though.

Looks nothing short of incredible. I'm usually not one for texture packs but I will give this a download when it's done.

Well, it would help if you answered my previous question.

The skybox looks good, I want to see what it looks like in the game.

New area creation is something of an experiment and hasn't been discussed thoroughly. The purpose of this thread is to serve as a knowledge collective of new area knowledge, and discuss what we know and don't know, and what we can and cannot do with areas at this point. I hope this thread will allow us to share our techniques and eventually allow me to write a comprehensive tutorial on new area creation. For the purposes of this thread, "new area creation" refers to modeling a brand new area, not simply a module reskin. Additionally, this thread does not serve as a tutorial on how to use 3DSMax or GMax, though various techniques and functions may be discussed. We've been able to create new areas for a while, ever since Magnus II released KAurora, which enabled us to compile new walkmeshes. KAurora has added several functions, including adding emitters and lightmaps. 1. We can create newly modeled areas This one is fairly obvious, but I felt the need to include it anyways. As several members on here have already done, newly modeled areas are entirely possible. However, a new area isn't something that happens overnight. A new area takes careful planning, consideration, and a lot of hard work. Making a new area on par with existing KotOR areas will take several months of work. Area creation also entails a good amount of troubleshooting, most of which will have to be done on your own. 2. We can create emitters for our areas KAurora also has the ability to export new emitters, for use in areas and other applications. To add an emitter, you can start by creating one from the helpers tab in Max. I have found that the best way is to base your emitter off one from the game. Pull a model with a similar emitter up in KAurora, and fill in the fields as closely as possible, changing only what you need. Additionally, not all of the fields are visible in Max, so you'll have to work on your emitters in KAurora as well. I have found that creating a model for each emitter and including them in the layout and .vis is the most hassle free. Additionally, I've had trouble getting the orientation fields set correctly. The ones that export from Max seem to screw it up when they are set at angles. For instance, when I create the steam emitters that come from the bottom of the Ebon Hawk, I always copy the orientation from the landing module of an existing planet, and everything is good. Emitters take some fine tuning, but can add a lot of detail to an area. 3. We can add lightmaps to new areas I'd say that given the difference between lightmapped and non-lightmapped areas, it's almost not even worth it to create an area if you don't intend to lightmap it. In my opinion, lightmapping accounts for about 60-80% of how good an area looks. Quanon's created an excellent tutorial on lightmapping, and it covers most everything pretty well. Quanon and I have exchanged quite a bit of discussion on lightmaps, and we've each found different techniques that work. Quanon has found that it's best for him to do one massive lightmap of his whole area. I have found that ti's best to split my areas up into small sections before lightmapping, and doing multiple lightmaps. I've also found that lightmaps are a tricky and buggy portion of the process. They take a long time to get right, and sometimes you have to start over it it's not applying correctly in the game. When finished, they are spectacular. 4. We can add lights to new areas We've known since the beginning that AuroraDLights were possible in KAurora, though there is some confusion surrounding them. Hopefully I can help clear some of that up. In the days before lightmaps, ignorant people such as myself thought that all the lighting came from AuroraDLights and Aurora Lights. It was thought, at least by myself, that AuroraDLights and Aurora Lights were 2 different things. AuroraDLights were possible to create through NWMax, but imported areas from the game through the old MDLOps 0.5 showed mostly blank dummies called Aurora Lights. New evidence from areas run through MDLOps 0.6a shows that all of these are actually AuroraDLights. So yes, AuroraDLights are possible. Aurora Lights aren't real things. Lightmaps provide the lighting for an area. AuroraDLights are meant to create shadows and give light to dynamic objects such as creatures, placeables, doors, etc. Quanon seems to be correct in that only 3 can light up at a time. However, you can have far more than 3 AuroraDLights in any given area. I think a common misconception used to be that there could only be 3 AuroraDLights. This is false. Use as many as you want. A much more in depth explanation of AuroraDLights can be found here. 5. We can create minimaps for our areas This one is a minor addition, and doesn't really have to do with KAurora. But, with some trial and error and a top-down render of the area, it's entirely possible to create a minimap for your area. It's a nice touch to finish up your area, even though it's not entirely necessary. Here is a quick synopsis of my findings with K1 minimaps: I was dreading working on the minimaps. I did one for the main street a while back, and it was a 4-6 hour trial and error process that was annoying as all get out. So, I pulled up another module, rendered the top down view, and took it to Photoshop. Opened up the .are, and got ready to begin the process again. I knew that the fields in the .are were based on knowing the precise pixel coordinates on the 512 by 256 TGA of the map, and referencing actual meter coordinates of the area. However, last time I tried this, something didn't add up. So I have 8 different values I have to figure out in the .are to get the map and the scaling right, based on 2 (x,y) points on the TGA and the coordinates of the area. MapPt1X (TGA reference of X coordinate #1) MapPt1Y (TGA reference of Y coordinate #1) MapPt2X (TGA reference of X coordinate #2) MapPt2Y (TGA reference of Y coordinate #2) And WorldPt1X (Meter value of X coordinate #1) WorldPt1Y (Meter value of Y coordinate #1) WorldPt2X (Meter value of X coordinate #2) WorldPt2Y (Meter value of Y coordinate #2) I picked out two references I could see visually on the TGA of the map, and got their meter coordinates in MAX. Filled in the WorldPt values, which was the easy part. So I had figured out that the MapPt values were decimals based on how far from the top left corner the pixel representing the coordinates I just found was. For example, if the pixel was halfway to the bottom, the MapPtY for that pixel would be .5. That seemed to work fine for the Y-axis. I would figure out how many pixels from the top the pixel was, divide by 256, then I'd have the right MapPtY. The weird thing was the X-axis. This was off for the X-axis for some inexplicable reason. However, I finally discovered that while the textures are all 512 by 256, the game only uses ~435 by 256 of the texture. By diving the X pixel values by 435 instead of 512, the map worked perfectly!! I did several maps right in a row, making up for the sustained time loss fighting the Great Walkmesh War of 2016. 6. We can use walkmeshes that are divided into multiple parts Quanon probably has more to say about this, as he's done it and I haven't. But it appears that when you divide the walkmesh into multiple parts, you can rig it to work by including a doorhook line in the layout file with the coordinates of the seam between the two. This should enable us to create areas that utilize the full functionality of the vis file and multiple AuroraDLights. 7. We can block line of sight and blaster fire with walkmeshes When I looked at the existing walkmeshes in the game, I discovered that they had "walls". By extruding the edges of the walkmesh, and raising them up, you can create walkmesh "barriers" that block line of sight and blaster fire. The polygons of these walls need to be assigned the Non-Walk material. There's not much else to say about this, but it works well. I guess the main lesson is to use the existing KotOR and TSL models as your guide. 8. We CAN block camera movement by using the walkmesh injector! This one has plagued us from the beginning, and I'm not sure we can do it with the tools we have. I have determined that the camera is blocked not by the walkmesh, but by the model itself. This makes sense, as things such as characters still block the camera even though they don't have walkmeshes. I'm very open for any discussion into this, as it's one of the last features that existing areas have that we can't duplicate. We can block the camera movement through walls by using Dastardly's Walkmesh Injector!! 9. We cannot create area animations through KAurora KAurora currently can't handle animations, but there are several ways around it. Placeables can still be animated through MDLOps, and included in the area. Additionally, it's possible that you could use a faux character model in the same manner. I haven't found the need to experiment much with this yet, but others may want to use it in their areas.

We will decide that when the time comes.

There are several options for rescaling UV maps, though most are fairly tedious. First, if a texture is scaled badly, you can obviously enlarge the texture by a factor of 4, which would fix the badly scaled portion. But, this unnecessarily makes the regularly scaled portion a bit too fine of a resolution. You could find the object names of the portions that are scaled badly in 3DSMax and hex edit those portions to use the larger tiled texture. This process is going to be pretty tedious, but it would seem to have the best results. You could also pull the whole model into 3DSMax and adjust the UV maps, and use the Replacer function to change only the maps and preserve other qualities like animations and lightmaps. I'm not 100% sure that would work though. Once again, this would be somewhat tedious, but probably a bit easier than hex editing.

Davik's estate looks really clean, I like it!!

I'll attempt to help what I can, but unfortunately all I've done is animate bones for a model that was already skinned and weighed. First question though, is this something that you've modeled all on your own, or is it from another game?

The outdoor sand texture looks good, I think just easing up on the darks will make it look excellent. The indoor sand I think should appear to be more packed, which is a small gripe considering that the texture in itself already looks good, it just seems a bit out of place. After seeing the Anchorhead street with that texture I take it back. Looks fantastic out there.

My guess is that it's your graphics card. I had an Intel graphics card for years and never knew what the shaders were, because they never appeared.

Looks very interesting with the larger hills and peaks in the distance. Overall, it looks good though perhaps the grass could use just a slight bit less saturation (5-10%), or that same percentage shift toward yellow.

The plot stays under wraps, and we don't really plan to reveal much more of the areas either. We're in this to deliver a finished product, not to get a few comments by posting every little thing we've worked on for Sleheyron. We chose to reveal the street and the arena because we wanted to show that we've been able to replicate Bioware's Sleheyron almost exactly, and that we've been able to restore those bits of Sleheyron that are in KotOR's files. The docking bay was an added bonus that doesn't reveal too much. Anything that we do show will be in a complete state, not something that we've spent 10 minutes on and want to get a little attention for.

Sleheyron Update Work on Sleheyron continues, not at the fastest pace, but at a steady sustainable pace, which is as good as we can hope for at this point. The bulk of the work is still on the area models, but they are coming along quite nicely. Not to reveal too much, but soon we hope the planet will be structured enough to begin placing content. You may have noticed that I've been saying "we" a lot, and that is another important portion of this mod that I'd like to share. Fair Strides and I have struck up a partnership, and we have accomplished much together. We form a real working team, with complementary skill sets. Fair Strides takes on the more technical side of things, while I focus on the more artistic elements. We can talk intelligently about each others' skills, and we've both learned a lot in the process. Fair Strides' enthusiasm has helped me greatly to keep this mod going, and his scripting knowledge is more than up to the task. Additionally, we have worked very hard together hammering out the plot, and filling in the holes from what we know was intended to be on Sleheyron. This isn't a plot we've come up with in 10 minutes, but rather a plot that we've spent months discussing, rewriting, and evaluating. We've stuck to what we know from David Gaider's original plot for Sleheyron, and we've come up with a number of creative elements to fill in the gaps. Expect some fairly unique quests, and remember that the Gladiator fights will only end up being about 1/3 of the entire Sleheyron plot. In any case, I just wanted to make Fair Strides' involvement in this project more widely known. He doesn't seek much publicity, but he is definitely an equal partner in this mod who is helping make a lot of things happen behind the scenes. And for those worried about K1R Compatibility, rest assured that Fair Strides will make it happen. So three cheers for Fair Strides!! Huzzah, Huzzah, Huzzah!!