Search the Community

Big preservation win for the KotOR modding community today. Several long-dormant classic tools are officially no longer abandonware and will now be maintained under the OpenKotOR umbrella. These utilities have been part of the foundation of KotOR modding for years, and having active stewardship again means bug fixes, modernization, long-term preservation, and future quality-of-life improvements are finally back on the table. Huge thanks to @Fair Strides for helping make this possible and for entrusting the community with the source and continued maintenance. Official new repository homes: TSLPatcher ← (yes you are reading this correctly) ChangeEdit ← (yes, your eyes are NOT deceiving you!) ERFEdit JRLEditor TalkEd SSFEdit This is one of those moments that quietly changes the future of the ecosystem. More information: - OpenKotOR is dedicated to keeping source code and legacy applications maintained to allow anyone and everyone to start building and creating quickly. A lot of the old communities are fragmented and much of the information is difficult to find/understand without a community. Many of us are frustrated with this, and have created a community where we can just get stuff done without a plethora of outdated archaic rules making it seem like the average subreddit arguing with various Reddit mods. If you head over to https://discord.gg/jxR7hzHmsD, you’ll find an active hub of modern KotOR tooling and development. The community is building full replacements for many of the classic utilities -- including a brand‑new 3D map builder, an opinionated MDL viewer/animator/extractor, and even a complete game engine rewrite capable of running KotOR directly in your browser. On the modding side, major projects like Sleheyron, Rhen Var, and expanded work on M4‑78EP are deep in testing, iteration, and refinement. The server is a great place to follow progress, report issues, and see what the next generation of KotOR modding looks like as it takes shape. There’s a lot happening, and it’s all moving fast. New people are joining every day, many doing things that could only be *dreamed* of in previous years. Imagine if we beat Disney to a remake, or if our community non-profit passion turns out BETTER than what the game developers intended. All of this work lives under the broader OpenKotOR community, which you can join here: https://openkotor.com/ Everyone has a say in this community, regardless of how long you've been around, who you are, or what your current understanding is. This is a completely decentralized community. Please feel free to openly share your creativity and curiosity or just grab some popcorn and watch some agentic engineers poop out some ai spaghetti. It's all quite fun. If you’re curious, want to contribute, or just enjoy seeing the game pushed into new territory, you’ll fit right in.

Hi. So the speedrunning community is trying to figure out how a glitch works that we call a "Displaced Loading Zone" (aka DLZ). And I've come here for some help solving this mystery. What is a DLZ? A DLZ is when you're just walking along in the game and suddenly, for no apparent reason, the game loads a different module - as if you had walked into a Loading Zone. Examples: Endar Spire Taris - Sith Base Dantooine Enclave Speedrunner DLZ info doc: What We Know This used to be a very rare occurrence and getting footage of it was even rarer. But as more people streamed the game, we got more and more examples. We eventually got enough info to start some early speculation on how this glitch was occurring. Long story short, we have a basic understanding of the circumstances needed for this glitch to fire. How does a DLZ work? What's Confirmed: A DLZ always occurs when the player is "below" or "south" of the Loading Zone on the map (in the negative Y direction). A DLZ can occur at any Y position below the loading zone, so long as it coincides with the trigger. Z position does not matter Camera facing does not matter Player facing does not matter? Which character is party leader doesn't matter A DLZ can trigger dialogue cutscenes as well as Loading Zones. Some maps in game are turned 90 degrees from the way they are actually oriented in the Toolset (example: Endar Spire - Command Module). If a party member is too far away from the party leader, a "Gather Your Party" dialogue occurs instead of the module transition and the player is placed outside the door at the transabort point. If there are 2 valid destinations above the player when a DLZ is triggered, it will not always go to the nearest one What's Theorized: A DLZ occurs when the player is within range of some sort of trigger or encounter, etc. A DLZ occurs when the player is "East" or "West" of any trigger on the map (in any X direction - not just when inside the trigger) A DLZ is caused because the game checks if the player position matches the Y coordinate of the trigger and the X coordinate of the loading zone. A DLZ cannot cause a player to reach a loading zone that is "East" or "West" of them (in the positive or negative X direction). A DLZ cannot cause a player to reach a loading zone that is "South" of them (in the negative Y direction) If there are 2 valid destinations above the player when a DLZ is triggered, it will always go to the farthest one (highest Y coord) A DLZ only fires when you're aligned at the very edge of the door's loading zone with your X value. Here's an example DLZ from the Endar Spire: Conceptual Semantics: There are various ways of conceptualizing this phenomenon and we often use them interchangeably. Expressing it in these different ways can cause confusion. All of these are conceptually more or less the same, even if it's not exactly how the glitch works. The Loading Zone is brought down to the player - (hence, "Displaced Loading Zone") The player is brought up to the Loading Zone Move along the Y-axis Move up/down from this X point Aligned at this X value Vertical DLZ Matching X coordinate of the Loading Zone and the Y coordinate of the Trigger. Consistent Results - Performing the Glitch at Will We just recently discovered a way to consistently perform the glitch. Up until now, we have been unable to perform the glitch at will. This made studying how it works next to impossible. The method involves continuously walking into a wall while angling left and right to continually pass over the X position where we know the glitch can occur. The Consistency varies wildly. But it's something. In fact, the new Endar Spire DLZ method is so consistent that anyone can do it in, at most, about 10 seconds. It's basically free. Consistent Endar Spire DLZ Finding Various DLZ coordinates - (X position is what matters) So, after trying this method on various DLZ locations, we set about determining precisely what X value needed to be achieved for it to fire. Some DLZ locations were harder to get to work than others. And some seemed to need extremely precise positioning to work. We suspect that there is something to this that we are missing. It appears that sometimes if we are moving too fast or too slow in the X direction, it doesn't happen. So, our current method is to pass over the X point as many times as we can to just hope it fires. Typical DLZ attempt by our most practiced DLZer WHY does a DLZ happen? Seeking the answer to this question is what led me here to make this post. I started combing through the source SCRIPTS of the game to try to understand how triggers and loading zones are handled by the game. It's a big pool to dive into. I can read the scripts well enough. It's all VERY thoroughly commented, which helps a lot. But I can't seem to find the scripts I'm looking for, even when going down an #include rabbit trail. The closest I've come to finding what I'm looking for is coming across the GetEnteringObject() function being used. But I have yet to find the NSS file where it's defined. What I'm looking for: How does the game track player position? How does the game know a player entered a trigger zone? How does the game know a player entered a loading zone? How could the player/loading zone coordinates be getting confused? My theory is something like: in the script, the programmer assumes the Y coordinate for the player is known and only checks to see that the X coord matches. Something like that. If you've read this far, thank you for your time. Any help or insights you could give would be greatly appreciated.