Added note about AttributeSet being Transient.

zompi2 commented

2021-10-28 07:19:47 +00:00

(Migrated from github.com)

This is something me and my team encounter lately. When someone was playing a game in the editor - values inside AttributeSet changed. Then, when a character blueprint was duplicated - these changed values were moved to a new character blueprint (but as a default values).
This was leading us to some very strange and difficult to track issues.
Creating objects, that are not components inside of actor's constructor is very risky and unsafe anyway, just like binding delegates inside the constructor. The best way to mitigate such issues is to set these properties to be Transient, so they won't serialize themselves during gameplay.

I'm not sure if the written note is descriptive enough, but I think it is a good idea to note about this problem, as designers usually love to copy-paste blueprints ;)

This is something me and my team encounter lately. When someone was playing a game in the editor - values inside AttributeSet changed. Then, when a character blueprint was duplicated - these changed values were moved to a new character blueprint (but as a default values). This was leading us to some very strange and difficult to track issues. Creating objects, that are not components inside of actor's constructor is very risky and unsafe anyway, just like binding delegates inside the constructor. The best way to mitigate such issues is to set these properties to be Transient, so they won't serialize themselves during gameplay. I'm not sure if the written note is descriptive enough, but I think it is a good idea to note about this problem, as designers usually love to copy-paste blueprints ;)

tranek commented

2021-12-03 21:04:58 +00:00

(Migrated from github.com)

I don't think I'm following what you're saying.

You played your game in PIE and made changes to Attribute values in an AttributeSet
You stopped playing in PIE
You duplicated the character BP
The new duplicated character BP had default values for those Attributes
I'm assuming that the default values were the values before the changes that were applied in PIE

That sounds like it's working as intended since any changes to Attributes shouldn't be saved to the CDO BP when PIE stops. I'm reading this as:

Played in PIE, character took 50 damage
Stopped playing in PIE
Duplicated character BP
Played in PIE again and character had full health instead of starting with missing 50 health

I don't think I'm following what you're saying. - You played your game in PIE and made changes to Attribute values in an AttributeSet - You stopped playing in PIE - You duplicated the character BP - The new duplicated character BP had default values for those Attributes - I'm assuming that the default values were the values before the changes that were applied in PIE That sounds like it's working as intended since any changes to Attributes shouldn't be saved to the CDO BP when PIE stops. I'm reading this as: - Played in PIE, character took 50 damage - Stopped playing in PIE - Duplicated character BP - Played in PIE again and character had full health instead of starting with missing 50 health

zompi2 commented

2021-12-06 08:33:15 +00:00

(Migrated from github.com)

I had to remind myself what issue I had have in a first place, because it was some time ago.

I made a description unnecessary overcomplicated. The issue is actually more trivial. This is how it was:

I had a Character with AttributeSet
AttributeSet had a value called Health
Inside of ACharacter::BeginPlay() I was reading AttributeSet->GetHealth(); (in c++ - it's important)
Inside of the Editor I created a Character_BP from my Character and put it in the level.

And now the magic happens

Duplicate Character_BP (let's call it Character2_BP)
Put Character2_BP in the level
When game starts - there is a read access violation on FGameplayAttributeData::GetCurrentValue() when the GetHealth() in BeginPlay is called.

Making AttributeSet Transient fixes this crash.

I'm trying to figure out how to describe this in the document.

I had to remind myself what issue I had have in a first place, because it was some time ago. I made a description unnecessary overcomplicated. The issue is actually more trivial. This is how it was: * I had a Character with AttributeSet * AttributeSet had a value called `Health` * Inside of `ACharacter::BeginPlay()` I was reading `AttributeSet->GetHealth();` (in c++ - it's important) * Inside of the Editor I created a Character_BP from my Character and put it in the level. And now the magic happens * Duplicate Character_BP (let's call it Character2_BP) * Put Character2_BP in the level * When game starts - there is a **read access violation** on `FGameplayAttributeData::GetCurrentValue()` when the `GetHealth()` in BeginPlay is called. Making AttributeSet Transient fixes this crash. I'm trying to figure out how to describe this in the document.

tranek commented

2021-12-07 02:29:47 +00:00

(Migrated from github.com)

That sounds like the duplicating BP Actor bug https://github.com/tranek/GASDocumentation#troubleshooting-duplicatingblueprintactors and the UE Issue https://issues.unrealengine.com/issue/UE-81109. Does that sound like what you're describing?

zompi2 commented

2021-12-07 07:23:00 +00:00

(Migrated from github.com)

Oh... It looks like this is it, actually. I haven't noticed this section for some reason. Ok, so the issue is already covered :D

Anyway, making AttributeSet Transient seems to fix the problem too. I haven't noticed any problems that could be caused by Transient in my project so far.

May I write about it in the section 9.4?

Oh... It looks like this is it, actually. I haven't noticed this section for some reason. Ok, so the issue is already covered :D Anyway, making AttributeSet Transient seems to fix the problem too. I haven't noticed any problems that could be caused by Transient in my project so far. May I write about it in the section 9.4?

SalahAdDin commented

2023-06-02 18:35:25 +00:00

(Migrated from github.com)

@zompi2 yes, please!

zompi2 commented

2023-06-08 11:31:24 +00:00

(Migrated from github.com)

Reviving the dead pull request :D

@tranek @SalahAdDin - I modified the notes that should better fit the document. I divided the 9.4 section into 9.4.1 and 9.4.2 where I present two possible workarounds for this issue.

Reviving the dead pull request :D @tranek @SalahAdDin - I modified the notes that should better fit the document. I divided the 9.4 section into 9.4.1 and 9.4.2 where I present two possible workarounds for this issue.

👍 1