Kexikus

Well yeah, that's what I do for the actual skybox textures. Those are done for K1 Dantooine and I have a WIP sky/coloring for K2 Dantooine. What I was talking about here are the actual ingame models/cubes for the skyboxes. I made one of those and now I have to copy that one into every module of both games (yeay...). That's what's up next for K1s Dantooine so that this skybox is fully done except for the final renders. I could show you a comparison but you wouldn't actually see anything on it except for the improved sky, but that's coming from my better knowledge of Terragen and not the new models. But I might be able to explain it: The skyboxes are obviously cubes with five textures assigned to the five visible sides of that cube. The problem with the skybox models in vanilla is that their edges don't always line up properly and that the UVW mapping is also less than perfect. And since that is different for every planet, I prievously had to stretch my textures to fit that so that no pixels are missing and I had to do that individually per skybox/planet. On top of that came the fact that the vanilla skyboxes are not centered vertically, i.e. the horizon is not where it should be which I had to account for by editing the rendered skybox as well. All of that was a lot of individual work for each skybox and lowered the quality due to the stretching. With my new skybox models, I no longer have to do any of that. I can just take the full quality renders straight from Terragen and they form a seamless skybox.

I'll update this thread when I have something to show, no need to ask. I have started working on the skybox models and decided to replace them all with my own model that has a proper UVW mapping. I tested that new model on Manaan, where I rendered all skybox textures in full resolution but not quite full quality. You can see the seamless result here (that's a corner of the skybox model): I also applied these model changes to Korriban and finished that skybox: And as I said before: I'll always post a render of each finished skybox, so here's the one for Korriban: Next up is creating the models for Dantooine and Telos to finish these skyboxes. I'll also work on Tatooine some more to get that one to blend better with the 3d ingame terrain.

Yes, I worked with static cameras for years and never encountered any problems. I don't think I've ever edited existing cameras and only added new ones / made copies of existing cameras but that should make no difference.

Looks really good. The only problem I have with it is that Aurek-Besh lettering and a Rakatan terminal doesn't quite fit together but more importantly: It's only gibberish. I know that most people probably don't care about that but I personally really like those details if they make sense. Apart from that: Outstanding work!

I don't know about -1 actually. 0 seems to be invalid as it just does nothing, but -1 does the same as 1 so I'd guess that the minus sign is just ignored or something as an invalid value would just do nothing.

Seems like I have to go with that workaround. I played around with some more txi parameters, including a mix of the following: mipmap 0 downsamplemax 0 clamp 0 envmap CM_Bright I also tried clamp 1 (and -1^^) as well as the GLOverride. None of that made any improvement compared to having no txi at all. Only clamp 1 (and -1) made things worse.

That would have been my workaround if I can't find another solution. Only that I'd just render at 2046x2046 instead of downscaling.

It's manm26ad with an edited skybox/backdrop model. What you see in that picture above is the hangar ring backdrop texture being screwed up when using clamp 1. There are no changes to the skybox cube itself in that picture though.

I had not but I have now... I would not call that an improvement^^ I also tried GLOverride but that didn't change anything. Guess I'll have to investigate further. Maybe that one is actually a UVW error.

As you might know, I had an issue with my first skybox mod where the edges of the textures would be cut off. Back then I though that this was a model issue, i.e. that the edges of the skybox cube don't line up perfectly. Upon further investigation for version 2, I learned that the model itself has no such issue but it's the UVW map that's causing all of that. You can see an example below. I created a 2048x2048 texture with a 1px black checkerboard pattern and a red 4px checkerboard pattern to represent the pixels of a vanilla 512x512 texture. As you can see, one pixel is outside of the UVW bounds and thus not visible ingame which results in an ugly seam that I'd rather get rid of. There are other examples where more than one pixel is missing, but that doesn't really matter. I figured that this would be easy to fix, so I just scaled the UVW map up until it fit the texture. And that did work in some cases. In other cases I ended up with a black seam between the textures, similar to the black line sometimes seen with face textures. You can see that issue in this screenshot where the two textures for the backdrop meet. I tried the mipmap fix but that did nothing. Any other ideas on how I could fix this?

I think I fixed that by using DelayCommands when equipping her weapon: void main() { object oPC = GetFirstPC(); ChangeToStandardFaction(OBJECT_SELF, 1); DelayCommand(0.4, ActionEquipMostDamagingMelee()); DelayCommand(0.5, ActionAttack(oPC, 0)); } I can't remember if that actually worked but that's what I did^^ And for your second question: I'd go with option 2. While that puts a custom script with a vanilla name in the Override, it has the advantage of not touching dialog files. The reason for why I find that advantageous is that TSLPatcher can easily run into problems with dlg files and I think that's why many people just copy their edited dialog files into the Override instead of using TSLPatcher and then you'd run into incompabilites if you were to edit the dialog for your script. Unless your mod is installed last but I don't think anyone is going to do that with an unofficial patch.

That's really strange because my mod just doesn't have any file that could cause this. The only thing that could have happened is that my mod accidently replaced galaxymap_p.gui in the Override. Could you check the backup folder that was created when installing my mod and put the galaxymap_p.gui from there back into your Override folder (make sure to keep a copy of the one in the Override). If that fixes it, then I need to figure out what my mod did wrong. If it doesn't, then it's another mod.

Did you have that same issue before installing my mod?

AFAIK isbumpmap just tells the game that this is a bump map just like cube tells it that this is a cubemap. I also suggest that you post this in the tutorial section or that it's moved there. Thanks for collecting this information.

That issue happens when you don't have the Coruscant and M4-78 compability patch installed. Re-read the installation instructions of my mod and make sure you followed them exactly.

It's been almost exactly one year since I declared the first version of this mod as finished and started testing it. Well, I just fixed the last known bug! That means it's time for the next round of testing to make sure that I didn't screw anything up with the rather extensive bug-fixing after the first round. Once those tests are done, I obviously need to fix all bugs that were discovered and then I can finally get to the voice overs. It's been taking a long time but the mod is slowly getting to where I want it and that's where you come in: I need you guys to help me test this mod. This requires that you do a full playthrough of the game with some specific choices I need you to make. You cannot use other mods in this playthrough (except for texture mods) and I need you to report every issue you find. Keep in mind that the mod is not completed so there are probably several bugs and it will generally not be a polished experience. Also, playing through the game takes time and while I understand this, I don't want to wait a year for you to complete the game or maybe not complete it at all. If none of that discourages you, please send me a PM and I'll let you know what exactly I need. If you don't feel like playing through the game just for this but would still like to help, I could use someone to read through Juhani's party member dialog for me to check for inconsistencies and other errors. If you're interested to do this, send me a PM. Thanks for the interest in my mod, I'll keep you updated on the progress

I don't know about that but I've always been able to use the quaternions I get from the orientation armband directly and got what I wanted. I'm still investigating this current issue. At the moment it seems like I always get one of two possible outcomes (facing directly north or facing directly south) when I enter anything that I don't copy from another camera. That includes simple values like 0°,90°, etc. I have absolutely no idea why that's happening though... Edit: Instead of editing the already existing cameras, I deleted those and created two copies of another camera. Now I get better results, i.e. there are now more than two possible directions. But the cameras are still oriented wrong. In fact they're oriented 90° clockwise from what I was expecting... Edit 2: Manually adding a counter-clockwise rotation of 90° to compensate rotates the camera by 180° so it's still facing the wrong direction. Edit 3: Okay. Doing a counter-clockwise rotation of 45° from my original orientation resulted in the needed 90° rotation. I guess I solved the issue, but something seems to be seriously wrong with the camera orientation in this module.

Well, in my case there actually is a reason for that. The cameras are used in the Xor cutscene that's present across three different modules and each of them uses static cameras with the same IDs. I only edited that one instance and I'd rather not make it a special case by using animated cameras and thus requiring a unique dlg and thus requiring a unique trigger script. But you say that in a way that leads me to believe that it's always better to use animated cameras. Would you mind clarifying why that is? I always though that they'd be much more work. Yeah, waypoints work as well. I'll check the other static cameras in the area. Maybe I can find a reason for what's going on.

The module is tat_m17ab, the Tatooine docking area. I've attached the files to this post in case anyone wants to have a look. You need the three .utcs and the .git. You can then load the provided savegame (I hope it won't crash) and if you leave the Ebon Hawk with Juhani in your party (she won't have a portrait but is selectable), you should get the second Xor encounter after you talk to the customs officer. The cameras in question are the first two cameras in that scene with the ID 444 and 445. In the provided .git they should face Xor and his lackeys (direction of 180°), but instead they face the underside of the Ebon Hawk. I also added a file called m17ab_90.git where I changed the orientation of the 444 camera to 90°. That one works fine and faces straight away from the Ebon Hawk. camera.zip Any help with this would be really appreciated. Thanks.

Yeah, it's a static camera in the .git. And the problem is not where 0° is facing. As I said, I got the rotation from the orientation armband, so I know that I want 180°. The problem is that for some reason 90° and 180° face in opposite directions and that makes no sense at all. camera.zip

No. Force Jump is hardcoded to be only available with the vanilla lightsaber baseitem. And you can't equip those in a hidden slot.

So, I'm currently trying to rotate two cameras. I never had problems with that but these two just don't do what I want them to do. I got the rotation by using an orientation armband which gave me an orientation of about 180° and thus quaternions of approximately -1 and 0. But when I enter those, the camera will face in the direction of what would be 270°. It's not an issue with the armband though, as using that to get the rotation for some waypoints worked perfectly fine. So I tried to enter the quaternions for 90° (0 and 1) which should result in the desired 180° if the camera is rotated by another 90° as it seemed. But that worked perfectly, the camera was rotated just as it should be. Now I'm really out of ideas on what could be going on here. The cameras just don't do what they're told. Any ideas on why that could be?

It does sound like a more serious issue, but I can't really tell you what's going on exactly.

Oh, then I remembered that incorrectly. The part about only having to edit the .git is still correct though.