Project Tamriel

Error report time!

PC_Guard_Stirk_Cuirass has the wrong mesh or texture assigned to it: the cuirass is supposed to show a seagull, but has a wolf (sign of Kvatch) instead. Female version and GND do show the correct insignia.

I guess this is the appropriate thread for model errors since we only have one error thread.

PC_terrain_gc_rock_01 has some problems which cause it to look black when using OpenMW.
There's an extra layer in NiSpecularProperty that is giving the mesh an extra layer, from what it sounds like. OpenMW LINK

PC_Data appears to be no longer compatible with TR_Data. We've done a bit of housekeeping and moved some of our meshes and textures to new locations. Unfortunately, PC_Data has some identical TR meshes/textures in the bsa file that still reference old locations. This causes some items to not display properly in-game (or the CS). Items that we've noticed to be problems are TR_w_glass_ssword.nif, TR_a_steel_helmet_05.nif, and TR_w_imp_saber.nif. There may be more. Sorry for this inconvenience; I was unaware that you had duplicate files when I started this effort. I am still in the process of updating our Data files, and we do have a major relocation effort going on with the textures. Most of this work should be done by the next release. Again, sorry for any trouble this may have caused.

Seneca37 wrote:PC_Data appears to be no longer compatible with TR_Data. We've done a bit of housekeeping and moved some of our meshes and textures to new locations. Unfortunately, PC_Data has some identical TR meshes/textures in the bsa file that still reference old locations. This causes some items to not display properly in-game (or the CS). Items that we've noticed to be problems are TR_w_glass_ssword.nif, TR_a_steel_helmet_05.nif, and TR_w_imp_saber.nif. There may be more. Sorry for this inconvenience; I was unaware that you had duplicate files when I started this effort. I am still in the process of updating our Data files, and we do have a major relocation effort going on with the textures. Most of this work should be done by the next release. Again, sorry for any trouble this may have caused.

Yes, I have seen that on your page and i wanted to carry over the changes, once you are done with all of them. But in the very end, when we create a common data, the TR duplicates in our data files will get removed anyway.

I don't know where it should be posted, so I'm writing there. I think "pc_furn_painting_08_xx" and "pc_furn_painting_09_xx" has wrong specular color. Also, "pc_tx_spriggan.dds" is missing in BSA Archive.

To be honest, most of our paintings are placeholders. I'll look into a full replacement sometime soon.

Couple of things in the new data:

• PC_Ex_Str_Dock is no longer in use and can be removed from data.
• pc_in_galleon_top, pc_in_galleon_top_h, and pc_in_galleon_wall_h aren't linked to statics. I think the meshes have a different name than the data entries, sorry about that.
• PC_In_GalleonLower_01 and PC_In_Galleonupper_01 are no longer in use and can be removed from data.
• pc_ex_str_dock_clm03 has a messed up UV. Fixed version included in attachment.

Also, a couple of personal opinions:

• Statues: I'd much prefer if these were set up as statics, or at least if the names are removed from the activators so it doesn't tell you exactly who you're looking at. The only "named" statues in the main game are the talking Daedric statues. This might sound like a minor thing, but I feel that it would help immersion.
• PC_Misc_Coin, Ancient Imperial Coins: why not rename these to First Empire Coin and Second Empire Coin? Helps ground them better, and gives their dungeons more identity.
• PC_Misc_Col_Barr_Bloodvial: could you rename this to "Colovian Blood Reliquary"? The current name is awkward and doesn't really relate to the Barrows in any way.

Infragris wrote:Couple of things in the new data:

• PC_Ex_Str_Dock is no longer in use and can be removed from data.
• pc_in_galleon_top, pc_in_galleon_top_h, and pc_in_galleon_wall_h aren't linked to statics. I think the meshes have a different name than the data entries, sorry about that.
• PC_In_GalleonLower_01 and PC_In_Galleonupper_01 are no longer in use and can be removed from data.
• pc_ex_str_dock_clm03 has a messed up UV. Fixed version included in attachment.

Also, a couple of personal opinions:

• Statues: I'd much prefer if these were set up as statics, or at least if the names are removed from the activators so it doesn't tell you exactly who you're looking at. The only "named" statues in the main game are the talking Daedric statues. This might sound like a minor thing, but I feel that it would help immersion.
• PC_Misc_Coin, Ancient Imperial Coins: why not rename these to First Empire Coin and Second Empire Coin? Helps ground them better, and gives their dungeons more identity.
• PC_Misc_Col_Barr_Bloodvial: could you rename this to "Colovian Blood Reliquary"? The current name is awkward and doesn't really relate to the Barrows in any way.

Not sure how they're named in PC_Data, but in my plugin I went with Ancient and Antique Coins for the same reason you're saying that the statues shouldn't all display their names, it felt more immersive to me than broadcasting their origin.

It would follow the nomenclature of the base game's Dwarven coins and our own Ayleid coins, just as the statues would follow the way the Vivec stuff is portrayed. In this case, I think it better to give them semi-specific names in order to ground the dungeons where they are found (Colovian Barrows, Reman fortress ruins) in their backstory.

The new Ayleid iron gates: once they are opened they can not be closed.

This is because npcs and creatures cannot use these doors, even when they are actual doors in the door tab. It is supposed to prevent cheating by locking off npcs and creatures.

Sorry for disregarding some esps that were contributed in the internal section. That is partly because I was not expecting these objects to be in before the data merge and I already had the asset files copied into another place. I will fix all things that were objected to here.

I would really prefer not to hand a means of exploitation to the player and, in my opinion, the minimum loss of freedom associated with not being able to close these doors, is totally acceptable. The situation you describe is nothing but exploitation, as you don't even have to use a lock-spell to keep the enemy from following you. Instead you will have the npc running against the door in a stupid way. More an immersion breaker than anything.

That messagebox you mention could be displayed as soon as the player tries to close the door, so the player knows it's an intended thing.

That message would be way more immersion-breaking than not being able to lock the doors, I think. Is it possible to script the doors to automatically open if an NPC or creature comes near them?

Probably not without MWSE - I think it would need "GetDistance" for every possible NPC/Creature which would make this script very heavy (or impossible to making).

Moritius wrote:Probably not without MWSE - I think it would need "GetDistance" for every possible NPC/Creature which would make this script very heavy (or impossible to making).

How about GetStandingActor? That's used for pitfalls and the like. We could add an invisible block to the door's base, on floor level. I you use GetStandingPC in addition, you could exclude the door from auto-activating near the PC.

I've forgotten about this function (I'm not using it when scripting). Yeah, using invisible collision box should do the trick.

I'll try out, if it is possible to add this collisionelement directly to the door itself and incorporate this call in the script of the door including a second GetStandingPC-check to verify its not the npc but someone else approaching.

The problem is, if we went with that solution, we'd run into the same blind alley we were in with Direnni doors - we'd need unique references (gate and the collision box) for each instance of the doors.

Wouldn't GetCollidingActor (with another condition, using GetCollidingPC == 0, to make sure it's not the player touching the door) work here instead? Monsters or npcs would run into closed doors, but would that trigger the collision check? Anyhow, I'll have some time to try to get this scripted next week, so I can give it a go.

Edit: actually that additional condition check would be unnecessary, to quote MWSFD on that:

GetCollidingActor works the same as the PC version of the function but will return 1 if any Actor (other than the PC) is colliding with the object.

As I added in an edit to my previous post, according to MWSFD we wouldn't need the GetCollidingPC check. Unless I'm mistaken, there's still no way to close the doors with this script, too?

Apart from that, it looks good I think. That is, if that works in-game.

So, first off, I wrote some nonsense above: Npcs actually activate this scripted door. My claim was based on the tests i had made with the direnni grate doors before which npcs seemingly cannot deal with(its not a solid mesh, but many small grate elements that are seemingly difficult to hit).

I was testing with this collision test and wondering all the time why the door got closed and opened all the time again while the npc was handling it, even though the collision was only able to open the door. I had added an invisible collision below the door model itself btw. So that additional collision box wouldn't have been needed anyway.

Here is the script that seems to work now (if used together with the updated door model, which was missing a closing animation previously):

Sorry to say, but this is a pseudo-bug report. The door fits just fine if you only shift it up sufficiently. The door is a little bit thicker than the doorframe to ensure that all gaps get closed.

Those collision issues with the ayleid tiles have always been a mystery to me. Weird stuff. I might be going to tweak the uv-mapping of those rocks aswell, but no promise.

The new tapestry textures are very nice, but the alpha on some of them is a bit too pronounced: they look like they're no longer connected to the hangers.

Parts of the Imperial saber texture somehow got erased: the top and bottom half are completely alpha's. Correct texture from the previous .bsa included below.

Weird (possibly unimportant?) texture issue: the main Gold Coast stone texture is duplicated in data: ground textures use pc_tx_gc_rock.dds, static terrain rocks use pc_terrain_gc_rock01.dds. Both textures are identical. Also, both textures have pretty bad mipmaps. I don't know if this is worth correcting, but it should be kep in mind if we want to replace this texture at any point.

Leveled lists use the original wooden crossbow (T_Com_Wood_Crossbow_01) instead of T_Com_Wood_CrossbowFix_01, which is a fixed version. I don't actually understand why the unfixed version is still in data, tbh.

EDIT: I've talked to sirrah at TR, apparently they only have one instance of the fixed version being used. Might be best to replace the mesh on the original with the fixed version and deprecate the latter.

Openmw Error (Doesn't seem to cause any problems): can't find emitter node, wrong node order? in meshes/pc/f/pc_furn_imp_incense_01.nif