PC_Data Error Reporting Thread

Report any errors from the P:C public files here
Post Reply
User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

PC_Data Error Reporting Thread

Post by Infragris »

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.

User avatar
Tes96
PT Modder
Posts: 107
Joined: Mon Jan 19, 2015 8:13 pm
Location: Tamriel

Post by Tes96 »

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
"If one is to understand the arcane arts, one must study all its aspects, not just the dogmatic narrow view of the Mages Guild."

Seneca37
PT Modder
Posts: 1
Joined: Thu Feb 05, 2015 6:16 pm

Post by Seneca37 »

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.

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
Moritius
PT Modder
Posts: 224
Joined: Sat Aug 08, 2015 3:30 pm
Location: Poland

Post by Moritius »

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.
<ThomasRuz> A cleansing potion, with a nasty side-effect
<rotouns> Drain Spear 50 / 3600s
<ThomasRuz> We shall call it... the potion of impotency!

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.
Attachments
pc_ex_str_dock_clm03.nif
(1.66 KiB) Downloaded 312 times

User avatar
Saint_Jiub
P:C Council Member
Posts: 448
Joined: Sun Jan 18, 2015 5:44 pm

Post by Saint_Jiub »

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.

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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?

User avatar
Moritius
PT Modder
Posts: 224
Joined: Sat Aug 08, 2015 3:30 pm
Location: Poland

Post by Moritius »

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).
<ThomasRuz> A cleansing potion, with a nasty side-effect
<rotouns> Drain Spear 50 / 3600s
<ThomasRuz> We shall call it... the potion of impotency!

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.

User avatar
Moritius
PT Modder
Posts: 224
Joined: Sat Aug 08, 2015 3:30 pm
Location: Poland

Post by Moritius »

I've forgotten about this function (I'm not using it when scripting). Yeah, using invisible collision box should do the trick.
<ThomasRuz> A cleansing potion, with a nasty side-effect
<rotouns> Drain Spear 50 / 3600s
<ThomasRuz> We shall call it... the potion of impotency!

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
berry
PT Modder
Posts: 670
Joined: Fri Jan 16, 2015 4:16 pm

Post by berry »

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.

User avatar
berry
PT Modder
Posts: 670
Joined: Fri Jan 16, 2015 4:16 pm

Post by berry »

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. :P

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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):

Code: Select all

Begin PC_Ayl_Door_Double
;if you want this door to have a key, create a copy of this script and add lines that manually unlock the door when the key is in the players inventory

float timer
; a variable to prevent the door from frequently getting opened and closed by npcs all the time

short state
;0 = initial state
;1 = being opened
;2 = closed

set timer to ( timer + getSecondsPassed )

if ( onActivate == 1 )
	;here you can add a line in your custom script checking if the player doesn't have the right key in inventory before the locked state is checked
	if ( getLocked > 0 )
		if (timer >= 1)
			set timer to 0
			playSound3D "LockedDoor"
		endif
	elseif ( state != 1 )
		if (timer >= 1)
			set state to 1
			set timer to 0
			playSound3D "Door Metal Open"
			playGroup, idle2, 0
		endif
	elseif ( state == 1 )
		if ( getCollidingActor == 0 ) ; to prevent the closing while an npc collides with the door
			if (timer >= 1)
				set state to 2
				set timer to 0
				playSound3D "Door Metal Close"
				playGroup, idle3, 0
			endif
		endif
	endif
endif

if ( state == 0 )
	set state to 2
	playGroup, Idle, 0
endif

End PC_Ayl_Door_Double
Attachments
newdoor.7z
(9.46 KiB) Downloaded 273 times

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
worsas
Project Administrator
Posts: 2678
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas »

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.

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.
Attachments
tr_w_imp_saber.dds
(170.82 KiB) Downloaded 368 times

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.

User avatar
Infragris
Project Administrator
Posts: 1396
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris »

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.

User avatar
Iskuss1418
PT Reviewer
Posts: 221
Joined: Tue Nov 29, 2016 1:57 am

Post by Iskuss1418 »

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

Post Reply

Return to “P:C Playtesting & Error Reporting”