Leaderboard

recently I have downloaded and installed yavin IV mod on my android device and try to play it. at first everything was according to the mod story but after the conversation with suvam tan, I try to go to the planet surface by clicking on panel access door and after that suvam tan ask me whether I want to go to the planet surface with his ship then I said yes and the screen loading but then the screen is clash blank for a while and the game shut down automatically means it kick out off the game. I tried to restart the game, talked with suvam tan and accessing the panel door once more to go to the planet surface but then the same problem happened. How to fix this bug issue? I tried to find the solution by accessing thru google, go to every star wars kotor 1 forum but still didn't found any solution. Hopefully anyone can help me with this bug problem. Thanks

It's been an eventful week. I have more discoveries to report, on another case of me breaking something and then everybody putting it back together again. Only this time, it broke because I was doing things the right way! It was only when I screwed up that I got the results I wanted.... So, I've been porting areas for a while. During the MDLEdit beta testing, once editing areas became a thing, I got some of Dantooine ported to K2 quite nicely: But for every attempt after that, something went wrong, like the latest one on Taris here: Some of the rooms don't render. When I got to Taris, this was after a handful of failed modules like this, and I finally realized the rooms that aren't rendering are only those without any real walkmesh data (no aabb node on the model and an empty WOK file). Even though the layout and visibility files were set up correctly (they're the original ones from K1) and all the textures were there, and so on, these rooms would not render. On Taris, all the walkable parts of the area would show, but the skybox and background buildings would not. I'd noticed before that K2 rooms have a tendency to include walkmeshes even when they shouldn't need them. Skyboxes were immediately obvious and suspect. You're not supposed to walk in the sky. Yet they were there, and though I didn't understand why, I tried adding a walkmesh to one of my problematic rooms on Taris and got it to render: After deleting the unneeded WOK file but leaving the MDL & MDX intact, I was able to confirm that K2 does not actually require a WOK file. Also, copying the original (empty) WOK files from K1 did not help with the rendering. It seemed only the presence of the aabb node was needed to get it to show. But the Dantooine skybox has no such node. The game was rendering it even without one. It couldn't be that K2 requires an aabb node for rooms. I had a working Dantooine to point to. I kept saying "This works! Why does this work?!" Well, lots of thanks to @bead-v for troubleshooting, and also @ndix UR for providing some suggestions. It took days of thinking and testing to figure out, but now the answer is clear: room models without an aabb node might not be visible in K2. Because obviously it was that. Of course K2 has different requirements from K1 that nobody predicted. The reason Dantooine was working for me was because when I set up the module, a year ago, I forgot to include the VIS file. Apparently, the lack of any visibility list forces the game to render every room all the time... even when it would have trouble rendering them otherwise. The counter-intuitive consequence of this was that when my module was set up incorrectly, everything that was supposed to be there would be there; when the module was set up correctly, stuff would fail to render. Naturally, I only forgot the VIS file the one time, and included it in every subsequent porting attempt, and therefore got unsatisfactory results. Every time I set things up correctly, the game would not behave, because apparently K2 has a higher standard for what qualifies as an area model than K1 does. So the upshot is that areas ported from K1 to K2 will have problems because of rooms lacking aabb nodes (probably every skybox, and more). Also, all rooms created for K2 must meet the same requirements, or else they won't render; everything needs an aabb node even if it doesn't require a walkmesh. bead is working on an update to MDLEdit to address this issue - an option to add a dummy aabb node when needed. The specifics are still being debated because of a complication in detecting whether a model is an area model. Apparently, the only way to do that is to check for an aabb node or the presence of a WOK file, since those are things that only areas have. I suspect the complication in solving this problem may in fact be the cause of it - that at some point in development for whatever reason, Obsidian introduced an aabb node requirement because it was the only viable way to check if the model was an area model and should be rendered... and then that meant every model required them. Given that K1 rooms can lack aabb nodes (that's the whole problem) the only other option is to check for a WOK file. Therefore, areas should be compiled with their original WOK files present, when applicable - in the same way that character models require supermodels. The part of this that I can't get over is I happened to misplace one file one time, and that mistake is what made KOTOR behave. If I hadn't screwed up, there wouldn't have been a working example for us to look at. We wouldn't have identified the problem without that, or at least we would've had a harder time of it. So the moral of the story is you can't look at how things work and use logic and reason to plan your modding course of action, because the game won't accept that. You have to approach KOTOR like a blunt instrument. Make mistakes that work.