KaPks8

If I run into troubles like that, I usually try to load a save were I've never been in the affected cell before, and then go / coc into the cell where I placed the new object. That way, I am trying to make sure, that the game never instantiated any of these objects before, but pulls 'fresh' data from the records, instead of using what it may find in the save from a previous visit to the cell.

I gave up fiddling and searching, bit the bullet, and am now using a (self stopping) quest script setting a global, if the player has the trait. I then check the global in the perk condition instead of using "hasPerk". If there's trickery available as asked for in my original post, I'm still very interested in learning about it.

Hi there. I created a new perk and a new trait. Both work as intended. The perk and the trait are exclusive, meaning, that players chosing the trait during character creation will not be able to later on choose the perk. Players not choosing the trait will be able to pick the perk. This also works as intended. There's only one thing left, which will confuse players (and it sticks out like a sore thumb to me), so I'd like to get rid of that. I am using "hasPerk" as a condition in the perk for checking, if the player already has the trait -- and as a result, the game displays the trait as being required for the perk in the perk selection screen, while of course it isn't. I have several workarounds in mind, but would like to know, if there's some trickery possible right in the perk conditions in the GECK as to stop the game from displaying a requirement the moment it sees "hasPerk" in a perk's conditions.

I've never used More Perks, and looking at the posts, the issues seem to mostly stem from clashes with other mods. Apart from having an actual look at what the new perks are supposed to do in the GECK, I'd probably have a look at the entry points used, formlists relied on, quest scripts running in the background, etc. With players having mods installed by the dozen, I'd not even try to maintain compatibility patches. I'd rather try to catch some of the stuff in code (e.g. formlists added, etc), if at all possible.

After trying to wrap my head around this for a while now, I simply tried GMST records with different values. It looks like the initial value of the IHUDMaxCompassNPCTicks GMST record quite literally defines both, the maximum number of ticks initially visible and the upper limit of ticks the game engine will display, regardless of what IHUDMaxCompassNPCTicks is set to during the session. Which means, that I'll need to overwrite IHUDMaxCompassNPCTicks with its maximum default value (10), and only after this I'm able to freely vary the number of displayed ticks between 0 and 10. Does this sound about right ?

Hi there. I'm fiddling with IHUDMaxCompassNPCTicks, which I'd like to occassionally (not situationally) change during gameplay. IHUDMaxCompassNPCTicks works as described in the docs, as long as I don't set it to zero using a GMST record in a plug-in. If I set IHUDMaxCompassNPCTicks to zero in a GMST record, trying to modify it with SetGameSetting or con_SetGameSetting shows no effect on the compass, despite GetGameSetting showing the new value. I'd be fine with the game throwing out this part of the mechanics, if it's told to not use the ticks in a GMST on startup -- but I'd be glad, if someone else could verify this, before I start implementing my workaround. Any pointers / experiences ? FNV version is 1.4.0.525, NVSE 0.5.1.4.