Search the Community
Showing results for tags 'triggers'.
Found 2 results
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.
I decided to dig deep into this map editor thing and can confirm the editor works. It allows you to input creatures, doors, encounters, merchants, placeables, sounds, triggers, and waypoints. I was able to tweak the module lighting different colors. and select day or night cycle option or both not sure if that works. Now for the interesting part the map files themselves 1st I look at how the names were structured in the map folder of existing maps 2nd I i created a simple blue 512x512 image saved it as jpg, then gave it a name of a module that didn't have a map. 3rd I opened up the jpg image in a text editor the re saved it in the .map extension and put it into the module folder. 4th Opened up the module editor selected open module project and pointed it to the newely created blue image i made. Results the map loaded the editor accepted the map and i was allowed to use all functions...So the map extension wasn't a mystery after all it just took some determination to figure out. Now new maps can be created for all the levels... Id appreciate all who can help with this. Important. you must use th K-Tool to extract the module you want to edit into a folder FIRST as the module editor needs it to load all the dump files into the map editor. This is so everything already in the level can be in its positon. Solved invisible issues thanks to the suggestion by Sithpecter about Z coordinates.. What i did was take a z coordinate from a model that was on the map like this one 10.19682...then i simply change the the last number 2 to a 5 i realized it was important for every model to have its own Z coordinates. Now all models show up where ever placed Now all there is to do is create maps for the Levels http://www.mediafire.com/view/c1ie1c...K2_00009_1.png