Leaderboard
Popular Content
Showing content with the highest reputation on 05/15/2020 in all areas
-
1 pointSo, I've wanted to implement this idea for a while now, but only just recently actually started to do it. A module builder of sorts, that creates semi-unique areas by letting the user piece together areas that already exist in game to create their own layouts. This will allow everyone, including those without the slightest modding experience do design a layout of an area and export it to the game in a matter minutes. There is still a lot of work to be done but the basics of placing rooms, snapping them together and exporting the corresponding MDL/MDX/LYT is implemented. Here is an example of the program in its current state in action: Ultimately the goal would be to have most existing interior areas in both KotOR and TSL to be implemented into this. A list of areas include: Sith Base Black Vulkar and Hidden Bek bases Undercity Sewers Devik's Estate Sandral Estate/Khoonda Dantooine Academy and its Sublevels Korriban Academy/Tombs Endar Spire/Harbinger Leviathan Peragus Telos Residential Area Telos Military Base Telos Academy Nar Shadaa Iziz Palace Trayus Academy Hrakert Station And of course there is always the possibly of custom user-made content. The main issue is that settings up the rooms for use does take time, so depending on interest I might not do all of them. Currently I have been using the Sith Base as you can see from the screenshots above. The biggest issue is none of the rooms in the game follow a specific size convention, so in most cases, if you try set up a module that has a circuit, It probably won't align properly. Features that I plan on implementing include: Exporting with doors. Have each door frame have a door and doors which don't go anywhere should be unselectable. Exporting a minimap. This would include settings up the appropriate values in an .ifo file so there is zero setup required. Export as a MOD file, so no setup required to get them to run in game. Export textures/lightmaps with a custom prefix to allow user's to easily retexture areas that won't interfere with other existing modules. Export any area as K1 or TSL models. Allow the user to set up rooms to transitions to other modules. Some kind of intuitive and simple UI that allows players to configure the VIS file. More as I go a long. This development of course has not gone smoothly, here is a list of frustrations I noted down if you an be bothered to read them: Both the MDL and WOK files contain the walkmesh data, which seems redundant. The MDL walkmesh handles grass and camera-blocking whereas the WOK walkmesh handles actual movement and pathfinding. AFIAK both share identical geometry. I imagine this is because of certain precomputed values stored in it that change when the model shifts? The WOK ignores the position of the room in the LYT. Changing the coordinates in the LYT will shift the MDL but not the WOK. So this means the vertices in the WOK need to be manually shifted. Because of this, bounding boxes on the AABB need to be moved and face normals need to be updated. Some values which im not even sure what they are may need to be changed as well (place distances/most significant plane)? The LYT lacks any rotation property for room entries. The orientation property in the node header for MDLs doesn't do anything, even when controllers aren't present, so I'm not sure why this exists. Maybe a remnant from NWN format or the console version? The root node in MDL doesn't come with any controllers at all, I should probably check if MDLEdit is capable of this if the ascii file is modified correctly. My work around to this is to child a dummy node onto the root and have that node parent everything else. I use this node to rotate the entire model. Rooms either come with a full doorframe, or none at all, meaning I have to edit each room to have half-doorframes to make them universally compatible with all the other rooms of the same door type. More of an inconvenience than anything else really. In order two connect rooms, the geometric edge on both rooms as to 'point' to the other room's index in the LYT file. This means I have to use a combination of KAurora and MDLEdit to figure out the index of the edge that my program has to edit on export. Its an very tiresome task. There is some bug in KotORBlender that if I export an MDL then delete one of the objects, then export it again an error occurs because the object is missing. Sigh. Of course its missing, I deleted it. A quick work around is just to copy all the model into a new .blend file and export that instead. This tool is not intended to be a full fledged module editor but mainly for building an area which can be edited using some other tool. That said it will be incorporated with my All-in-one toolset (WIP) but I will most release a stand alone as well. I'm also open to name suggestions if anyone. I do also want to try create a terrain editor as well. This hypothetical tool (exteriors) would compliment the one I just talked about (interiors). I'd imagine it would have some kind of "cliffs" ability that would mimic the walls that shape modules the same of what you see on the surfaces Dantooine/Dxun/Telos. You would further be able to detail the landscape with objects such as trees/rocks. It would be technical challenge, but I'm definitely going to take a stab at it. For now, that about covers it all.
-
1 pointI would say that even with the default Jedi robe you could get quite close to this. You couldn't have the cloak and probably not all of the leather pouches but apart from that it could work pretty well and would be something I'm also very interested in.
-
1 pointThat's completely understandable. I personally don't feel that a new model is actually required, as there are two quite workable ones I mentioned: The ported TSL robe models that are used in JC's Robe mod, which (I assume) considering it's position in the recommended mod build on r/KOTOR are ubiquitous enough that a disclaimer would likely be all it needs. The Model J robes likely would work as well, although I foresee the need to use a modified one that still displays the player head. I was trying to aim for maximum compatibility, but if you feel a new model is needed, that's completely fine.
-
1 pointThis is quite tricky. The reason the Qel-Droma robes in-game look like any other Jedi robes is because they all share the same 3D body model. There is only a small number of body models that can be used in KOTOR, ranging from Model A (being the underwear model) to Model J (the Star Forge robes model), which are determined in appearance.2da as columns. While it's possible to add appearance rows in appearance.2da, the number of model columns is hardcoded. In practical terms, this implies that if one were to replace the Qel-Droma robe model, they'd end up replacing the entire batch of Jedi robes in the game. Now typically there are two workaround for this: either replacing the Star Forge robes model or introduce a new model as a disguise. The latter is ideal for stuff that also covers the head of the wearer, but when the character's head is meant to be visible, then it gets tricky because you'd have to create a new row in appearance.2da for each of the playable heads. Yikes. Besides, a mere retexture, however well-made it may be, won't cut it if you want to achieve the look on those pictures, simply because the robes models don't quite look like on the pictures. Depending on the direction you'll want to take for this I'd gladly create a new model quite close to the one in your pics. However, as I'm already working on several projects at the time and because of IRL stuff, I won't create the texture for it. Someone else would have to join in and do that.
-
1 pointExcited to announce that I just got accepted to grad school! Not bad for a guy who almost flunked out of college 3 years ago. It's really humbling; I'm truly grateful.
-
1 pointWell for one thing, I don't wish to make the player end up being too overpowered. I mean the crystal alone gives crazy buffs once levelled enough, so combined with the robes it would be even worse. Placing it inside the Exile's container in the Harbinger is too early in my opinion. At the beginning of the game, Kreia observes that the Exile looks like a Jedi, to which your answers basically are that you're a Jedi no more, or even at all. The Exile accepts that it is his/her destiny to use the Force and be a Jedi or a Sith - or whatever Kreia tries to teach the player - later into the game. That's where in my opinion it would make sense to acquire the robes. As for the evolution of the crystal, it is in my intention to mirror the way the crystal works. From what I've found, the crystal can have 9 "levels". Those levels are determined by a simple formula: (Player LVL - 9)/3. So you'll get a level 9 crystal once you reach level 36 which is close to impossible. So I was thinking to dial it down a bit by giving the robes about 5 levels. For example I might look for a dialogue the player has around level 10 that matches the criteria above and determine the robes level by the following: (Player LVL - 5)/5 which would grant you a level 5 robes by player level 30. Just to give you an idea but nothing is set in stone, yet.
-
1 pointSure. I just wanted to give you an idea of the work that would be involved. Thank you, I can hardly take any credit for the original model and texture, which were made by DT85 and Toshi over at JKHub. The female model is the result of some heavy editing on my part though. Now that the cloaked version has been released, here's a sneak peek at what I'm working on next: This is a brand new model that I've created from scratch by using the female underwear model as a reference for the shape and proportions. The basic design is heavily inspired by this artwork by Jan-Wah Li. The idea I had for this mod was to create a set of simple robes that the Jedi Exile would wear once his/her training with Kreia begins and that would evolve with the player just like the way the Exile's Crystal works: the higher the light side (or dark side) stat of the player, the better the buffs. The outfit will also get a new color scheme as the player evolves: as the player tends to the dark side, the robes will get closer to black. Inversely, for light side players the robe will get a more colorful texture. I'm not decided on the colors yet but I might include a few versions as an option to chose from during installation (I'm open to suggestions). All of that will of course involve a bunch of scripting which is really not my thing, but that's a problem for later.
-
0 pointsMan that video got slammed with that. Even at 1080 there are huge compression blocks. But I'm glad you've sorted that skybox though.