Leaderboard

This is more of an idea than a request. It might be cool to have a mod that adds the Yavin Station to KotOR 2, now that porting is allowed. I did some experiments myself, but there's a bunch of things that I wouldn't know how to fix. - lighting - door scripts, dialogue triggers - the module is referencing to K2 doors which do not fit the door openings m50aa.zip

Hello everyone, I'vee been fiddling with gmax and kotor these days and would like to show you some stuff I've been working on. The idea is to release one or more mods with outfits variants for some companions or secondary characters. I´ve made a version of Mission without her vest, one of Jolee with a hood and an open jacket carth version (Inspired in Kotor Comics and mod by Kha that was never released). Here you can see some pics: There is still some clipping issues to solve with the Jolee hooded model, and I'm having problems exporting the Carth model with the new applied texture , apparently due to a conflict between the "skin" and "unwrap uwv" modifiers. I´m trying to find the error because in the other models I did'nt have the same problem. In any case I tried to export it without the texture to the game and seems to be functional (Here there is an Ingame image). Well, hope someone is interested, on it, I usually have very little free time so I don't expect to finish soon, but anyways I still work on it and hope to finish some day. Opinions, advices or recommendations are welcome since I don't have much experience and still go through trial and error method. Thanks!

With the change in porting rules now firmly in effect and the interest in porting up to and including an entire game's worth of content obvious, I've started poking around to see how things can be done in the long term. As it is now, we have a smattering of individual mods that include ported content, which is all well and good, but this depends on individual modders with the required knowledge producing and releasing mods at their own leisure. As with a lot of things in the modding world, a lot of people are interested, but far fewer know how to do it. So I'm interested in automating the process in order to port content on a much larger scale - for example, making every module in K1 available in K2 - and release this content as mod resources that will be as easy to access as anything you can extract from KOTOR Tool currently, or perhaps even allow for the creation of an automated porting tool that the average end user can run. The latter case would apply even to stuff that was allowed under the old rules, like a lightsaber mod that was done for one game but not another. In general, I'm looking to make things easier and require less manual tinkering. Even before the rules change, I experimented for my own personal use. To make things easier for me, I started extracting files en masse rather than bothering to figure out what I needed for each specific job, given that this was for personal use and not release. Once the rules changed and I was free to distribute these, though, it became clear that this was not ideal. My modified texture packs that included all of K1 and K2's textures amounted to about 800 MB of data. It didn't seem reasonable to include all that in an official upload and put a strain on the servers. Plus, this is the sort of thing I've criticized the Apeiron team over, so I figured I should tread carefully and look for a better method. A more ideal situation would involve a tool that could extract assets from one game and send them to another. I started writing some scripts for this, though I've had mixed results and what I really want involves charting into some unexplored territory. Ideally, this new tool would generate a new BIF or ERF archive - portedmodels.bif or what have you - rather than requiring thousands of files to be placed in Override and all the potential file conflicts that come along with that. Ideally, these will be made as universal resources like the existing models and textures - that way people can still edit them and put their edited files in Override without having to overwrite any files. I've spoken with @VarsityPuppet about developing something like this in the long term, and I'm also interested in seeing whether certain porting processes can be automated with MDLOps or MDLEdit, so I imagine we'll be talking about those eventually. In the meantime, I'll also be posting my own, more hacky results. I've included two such attachments in this post. K1toK2 Texture Conflict Guides K2 has hundreds and hundreds of files that were reused from K1. It's not necessary, and generally not a good idea, to try to copy these over. Not just because they're unneeded, but because files with the same names might not actually be the same textures. There's a very good chance Obsidian altered them and kept the original names. So I've created these guides that list the names of textures that are included in both games. There are three lists: for textures.bif, swpc_tex_gui.erf, and swpc_tex_tpa.erf. (The last list also applies to to _tpb.erf and _tpc.erf.) There are two sets of lists: one that lists conflicts, and one that lists files that are only in K1. K1toK2 Texture Filters These are simple batch scripts that will delete all textures in a folder that are known to be in both games. That way you can extract a game's textures, run the batch files, and filter out the textures that are already in the other game. Extract the contents of textures.bif, swpc_tex_gui.erf, and swpc_tex_tpa.erf from K1 with your preferred method and place them in the same location as the included batch scripts, or you can put them each in their own folders if you prefer. You should have thousands of TPC files and a handful of TGA and TXI files. Run the three batch scripts. These will delete all the conflicting texture files, leaving only the ones that are unique to K1. The batch scripts will delete themselves when finished. Copy the remaining textures to K2. You can put them in Override (or a subfolder in Override) or you can repackage the ERF texture packs to include both the original K2 textures and the extracted K1 assets. Note that if you do want to put them in ERFs, you will have to do _gui and _tpa separately, and you will also have to repeat the process for _tpb and _tpc using the _tpa script if you want to include support for the lower quality texture options. For the first version, I've specifically filtered out every file that has a matching file in K2. Eventually, I want to confirm which (if any) textures Obsidian modified, so we can include both game versions by renaming one copy. If you use my filters and start porting K1 content to K2, you won't run into any missing textures, but they might not necessarily look as they did in K1, at least for now. K1toK2 Texture Conflict Guides v1.zip K1toK2 Texture Filters v1.zip

DAN_MTm2

Additionally, his medal was stolen and left at the crime scene by the Sith in an effort to frame him (for a crime he incidentally did commit) so he wouldn't be wearing it. But if you (or anyone) want to make an NPC appearance change mod thing, SpaceAlex released all those assets as a mod resource for anyone to use and finish and there are other available resources as well. The art really isn't the hard part. Partly on account of it's already been done by talented individuals, but mostly because actually putting it into the game is harder and more time consuming and that's the reason SpaceAlex never finished.

So that's a bit different, because it clears the action if the party member happens to be in Solo mode, not in dialog as in our case. But the reason why that part of the code's commented out is because that's probably the old code for the script before it was all moved to k_ai_master and run from there. Fingers crossed!

I can't really say. It depends on the complexity of the scene. Terrain generally has less of an impact than clouds but that also depends strongly on the internal node network that creates the terrain and on the cloud type. Multiple 3D cloud layers have a HUGE impact, 3d objects like buildings on the other hand render extremely fast. So yeah, it really depends. A simple scene like Tatooine renders very quickly, others that have lots of clouds take far longer. The only actual number I can currently give you is that the Coruscant render I posted some days ago took 7 hours. But that's only in Full HD (1920x1080) which is significantly less than 2048x2048. So I'm expecting more than 10 hours for the Coruscant skybox. And that's per texture. So it's somewhere in the 50+ hours region in that case. But that's an extreme case, although I'd say that Telos is going to take the longest (except for Dxun maybe but I can't say for certain as that one is not done yet). But I'm also seriously considering the use of a render farm to speed things up. They aren't really that expensive for only a few renders so that might be worthwhile. We'll see^^

You could do it for the main onDialog script, but that wouldn't eliminate all the cases. Whenever the dialog is fired from any other script, you'd need to either edit the dialog to add the ClearAllActions() script as suggested above or edit the script that fires it. EDIT: But here's another thing that seems to work. I modified the party member heartbeat script to do this: if(GetIsConversationActive() && GetCurrentAction() == ACTION_FOLLOWLEADER) ClearAllActions(); The heartbeat script only fires every 4s or so, so it may not always work immediately, but it is a pretty general solution. k_hen_heartbt01-DialogOrientationFix.zip

I was getting annoyed by not being able to get things to work, so I decided to do tests to figure out how exactly the system works. Here is what I've learned so far. Maybe it can help someone, or someone has something else to add to this. My testing continues (in orientation, what happens if there is an enemy, or a closed door between the first speaker and listener when conversation starts, ...), after it's done I will update this text and then it should probably go into the tutorial section. ------------------------------------------------------------------------------------------------------ Everything below is about TSL. When the dialog starts, these roles need to be determined: - DEFAULT_SPEAKER or OWNER - DEFAULT_LISTENER - PLAYER The terms OWNER and PLAYER may actually be used in the Listener (but not Speaker) field in the dialog editor (and also for dialog animations). In scripts fired through the dialog, OBJECT_SELF refers to OWNER. To explain how they are determined we also need to define oStarter and oOwner. They are defined by the script that fires the dialog: AssignCommand(oStarter, ActionStartConversation(oOwner, "some_dialog")); PLAYER always represents the first PC (GetFirstPC() in scripts). DEFAULT_LISTENER is generally oStarter. RULE 1: This is always true if oStarter is PLAYER. RULE 2: If oOwner is PLAYER, then DEFAULT_LISTENER is always PLAYER (green and purple). If oStarter is a party member, then control is given to PLAYER after the dialog (green). RULE 3: If oStarter is a party member and oOwner is a creature, then DEFAULT_LISTENER is PLAYER (red). In addition to that, before the dialog, PLAYER and oStarter exchange locations and control is given to PLAYER. After the dialog, control over the original party member is regained. RULE 4: If oStarter is not a party member and oOwner is a party member, then DEFAULT_LISTENER is oOwner, the party member (blue). OWNER is generally oOwner. RULE 1: If oOwner is PLAYER, then OWNER is oStarter (green and purple). RULE 2: If oOwner is a party member and oStarter is not a party member, OWNER is oStarter (blue). All of this is summarized in the following table: 1 Controlled character changes to PLAYER after dialog. 2 Controlled character changes to PLAYER before dialog, but changes back afterwards. Notes: STARTER in this table refers to DEFAULT_LISTENER. Shaded cells represent combinations where the roles of oStarter and oOwner may be reversed with the same effect. More attention should be paid to the white cells, especially a combination of a party member with another party member or creature. Bold font weight indicates that OWNER is oOwner or STARTER is oStarter, that is, no special rules have applied. A node in this text means every entry and every instance of the player choosing a reply. Every node has the following roles, which need to be determined: - SPEAKER - LISTENER In determining them, we need to make use of OWNER, DEFAULT_LISTENER and PLAYER (defined above). SPEAKER is the object with the tag in the Speaker field of the current entry. If the Speaker field is empty, SPEAKER is OWNER. If the field is not empty, but no object with that tag exists, the entry is skipped; if after that no other entries are available, the dialog ends. In replies, SPEAKER is automatically PLAYER. The keywords 'OWNER' and 'PLAYER' may NOT be used in the Speaker field. Doing this will end the conversation. LISTENER is the object with the tag in the Listener field of the current node. If the field is empty, it is the object with the tag in the Speaker field of the previous node. If that object is invalid or the same as SPEAKER, or if this is the first node, then LISTENER is DEFAULT_LISTENER. The keywords 'OWNER' and 'PLAYER' may be used in the Listener field. At the beginning of every node, SPEAKER and LISTENER reorient on each other, unless SetLockOrientationInDialog() is TRUE. In that case the creature for which it is TRUE does not reorient. There are two ways of reorienting in dialog. One is head-tracking, where the head is turned towards the target, and the body only turns as much as it needs to for the head to face the target. The creatures that do not use head-tracking instead turn entirely to face the target. For head-tracking to work, it must be enabled in appearance.2da under column 'headtrack'. The creatures that use head-tracking can turn it off by setting SetLockHeadFollowInDialog() to TRUE. However, if 'headtrack' is 0 in appearance.2da, then SetLockHeadFollowInDialog() cannot be used to enable head-tracking; these creatures will always turn entirely to face the target.

Another piece of information, discovered as a result of Salk's question. When outside of dialog, party members follow the PC and reorient on them at any time. When you enter dialog in K1 this behavior persists, and causes them to reorient on the PC whenever they speak, ignoring the Speaker/Listener functionality. Calling ClearAllActions() on the party member will remove this behavior. This issue will also not arise in Solo mode, because in that case the party members are not following and reorienting on the PC.

Ah, I see what you mean. In any case, this doesn't seem like an issue with the Speaker/Listener functionality, but an issue with the party members trying to reorient on the PC even during dialog. If you turn on solo mode for example, the issue goes away. I also removed the function that makes the PC move, but that made no difference. I'm gonna do some more tests, because it seems like sometimes it does work. However, you could probably use the solo mode trick to fix the issue. You'd make two scripts: a_disablesolo: void main(){ SetLocalBoolean(GetArea(OBJECT_SELF), 10, GetSoloMode()); SetSoloMode(TRUE); } a_reenablesolo: void main(){ SetSoloMode(GetLocalBoolean(GetArea(OBJECT_SELF), 10)); } Then you'd just need to add these two scripts to all the dialogs where it happens. And just a disclaimer, I'm not 100% sure this would work, but it could. EDIT: Well, I checked the script that fires the banter dialog, and all it seems to do is ClearAllActions() on all the party members. I checked that with the Matale cutscene and it worked. So you can package this up as a script like this: a_clearactparty: void main(){ int n = 0; for(n = 0; n < 3; n++){ AssignCommand(GetPartyMemberByIndex(n), ClearAllActions()); } } And just make sure it fires somewhere in the dialog before the lines with the party members.

The current plan is to release them simultaneously or very close to each other. I haven't started rendering any of the finished textures and I don't intend to do that until all skyboxes from both games are done. Then I might decide to do one game first and release that one as soon as it's ready or I might wait a little longer and release both at the same time.

How this whole Speaker/Listener business works isn't simple, I once did extensive testing and wrote a guide about it. A lot depends on the exact syntax of how the conversation was started in the script. This was for TSL only though, K1 may be and probably is a little different. If you give me a specific example I may be able to tell you why it's not working.

Today I have two finished skyboxes for you. Though, to be honest, both were very close to completion already. Let's start with Korriban. Not much has changed since I last showed that skybox. I just did my ususal model changes and then also some changes to the ingame lightmap so that the statues are more in the shadow and blend better with the skybox. On top of that, I removed the fog. But the most important change is probably the new ground color that looks absolutely ridiculous with normal lighting and atmosphere but matches the ingame terrain when lit properly: With that out of the way, here's a render and two screenshots. The first one shows the new terrain color blending with the area model and the second one shows the new lightmaps and the disabled fog. The second skybox that is now finished is Coruscant. The only thing that was missing here is the fixed model. I also finished the model edits for Telos so that skybox is also fully done now. But you've seen those screenshots before, so I won't show them again.

Here's my folder and its contents so far. Now it's time to convert this file with MDLOps. Load your edited ASCII file, then read and write. MDLOps will generate a new MDL and MDX. Run the Head Fixer on the MDL. The Head Fixer creates a new, fixed MDL file to put the animations back. Rename the fixed MDL and the MDX file from the previous step to whatever you want. However, the file name must have the same number of characters as the original (in this case 8). You could get around this by renaming before you export, but it requires more setup work, so I resign to keeping it the same. Once you've chosen your name, open the MDL in a hex editor. Find and replace the original name (mine was P_AttonH) with your new name (mine is JC_DuH01). Be careful to only replace characters, not delete them; that would break the model and cause your game to crash, most likely. There are 5 Duros textures in the game, so at this stage I use the same process to create duplicate models for each texture variation. After some 2DA editing to get the head in the game, or in my case simply keeping it as P_AttonH for a quick test, we can see our final result: Behold, a new head that can go on any body. You can use roughly the same process to create new full body models if you like, mixing heads and bodies from different models. That's what I did for the Handmaiden Sisters and I've made a tutorial here. So, go make new heads, and good luck!

Kexikus, I am curious about the rendering process. How long do you expect your computer will take to render one skybox, considering you have significantly increased the resolution?