PC_Data Error Reporting Thread

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

PC_Data Error Reporting Thread

Post by Infragris » Sat Jan 24, 2015 10:49 pm

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: Isle of Artaeum, Summerset archipelago

Post by Tes96 » Fri Jun 05, 2015 12:58 am

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."

User avatar
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Fri Oct 02, 2015 9:47 am

"PC_Terrain_GC_rock_33" has no collision.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by Seneca37 » Sat Oct 10, 2015 11:57 pm

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: 2101
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas » Wed Oct 14, 2015 1:49 pm

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
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Fri Oct 23, 2015 1:09 pm

"PC_In_Ar_Entrance01"
When entering the interior, the player will immediately get stuck due to low ceiling.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

User avatar
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Mon Feb 22, 2016 1:35 pm

"PC_In_GC_trans_00" has the wrong texture.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by Moritius » Sat Mar 12, 2016 4:00 pm

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.







Leon edit: Post moved to this thread.
<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: 1294
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris » Sun Mar 13, 2016 10:22 am

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

User avatar
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Sun Apr 10, 2016 8:56 pm

"PC_Ex_Str_Gate" has some collision problems.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by Infragris » Tue Jun 21, 2016 9:25 pm

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 116 times

User avatar
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Wed Jun 22, 2016 11:28 am

The new Ayleid iron gates: once they are opened they can not be closed.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by Saint_Jiub » Wed Jun 22, 2016 2:39 pm

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: 1294
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris » Wed Jun 22, 2016 3:17 pm

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: 2101
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas » Wed Jun 22, 2016 4:22 pm

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
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Sun Jun 26, 2016 2:58 pm

worsas wrote:It is supposed to prevent cheating by locking off npcs and creatures.
I was thinking; who are we to prevent players from cheating? If the player wants to lock everything and kill everything, let them do so? I think that's one of Morrowind greatest strength; that the player can do whatever he/she wants.

Also, just a scenario: The player is heavily wounded and a creature is following the player while the player runs away, then the player can close a door to give the player not only a bit more time, but also to increase the chance of survival.

If you really want the doors to be open and not able to be closed, then maybe a message should appear: "This door is permanently broken."
Or something like that.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by worsas » Sun Jun 26, 2016 9:23 pm

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: 1294
Joined: Fri Jan 02, 2015 7:51 pm

Post by Infragris » Sun Jun 26, 2016 10:01 pm

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: 218
Joined: Sat Aug 08, 2015 3:30 pm
Location: Poland

Post by Moritius » Sun Jun 26, 2016 10:16 pm

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
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Sun Jun 26, 2016 10:22 pm

worsas wrote: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.
For every door that the player tries to close? Sorry Worsas, but I'm not convinced on this idea.
Besides, the vanilla game is full of exploitation, yet only a small amount of people will make use of it.
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by Infragris » Sun Jun 26, 2016 10:44 pm

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: 218
Joined: Sat Aug 08, 2015 3:30 pm
Location: Poland

Post by Moritius » Sun Jun 26, 2016 11:05 pm

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: 2101
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas » Mon Jun 27, 2016 9:40 am

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 » Mon Jun 27, 2016 12:23 pm

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
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Mon Jun 27, 2016 1:15 pm

berry wrote: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.
What about this:

Code: Select all

Begin PC_TEST_DOOR

Short State
GetCollidingActor
GetCollidingPC

if ( state == 1 )
	return
endif

if ( GetCollidingActor == 1 )
	if ( GetCollidingPC == 0 )
		if ( getLocked > 0 )
			return
		else
			set state to 1
			PlaySound "Door Metal Open"
		endif
	endif
endif

if ( onActivate == 1 )
	if ( getLocked > 0 )
		PlaySound "LockedDoor"
	else
		set state to 1
		PlaySound "Door Metal Open"
	endif
endif

if ( state == 0 )
	playGroup, Idle, 0
else
	playGroup, idle2, 0
endif

End PC_TEST_DOOR
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by berry » Mon Jun 27, 2016 1:44 pm

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: 2101
Joined: Wed Dec 31, 2014 1:23 am

Post by worsas » Mon Jun 27, 2016 2:11 pm

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 97 times

User avatar
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Mon Jul 18, 2016 3:10 pm

The "PC_In_Ar_Door_01" doesn't fit into the frame; there is a gap at the top.
Attachments
AyleidDoorFix.png
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

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

Post by worsas » Mon Jul 18, 2016 3:32 pm

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
Leon
PT Modder
Posts: 603
Joined: Tue Jul 28, 2015 11:25 am
Location: The Netherlands

Post by Leon » Mon Jul 18, 2016 3:45 pm

lol, how stupid of me, thanks Worsas :P
Lead Interior Designer & Quality Assurance at Province: Cyrodiil

Post Reply

Return to “P:C Playtesting & Error Reporting”