Updating Uproperties in the editor afte they are modified prodeducarlly.

Hi.

I finally have the class UNewtonCollisionPrimitive : public UDynamicMeshComponent
working more or less as I want it. however still has some problems that I can’t find a solution for.

the video bellow show what I mean

as you can see, the Mesh works in the editor, I can change the size of all of the Uproperties.
The problem is that I do not knwo how to make the editor recognize the changes made in the c++ code.

This is very important for us, because as you can see, trying to match the size for the shape by editing the primitive size to the staticMeshComponent is not an eassy thing, specially when staticMeshComponent do not provides editor info about size.

I tried do do it on initialization but at that time not all info is ready, basically a UClass can not have other UClass dependent default values, which seems reasonable to me.
So, I figured I can add a bottom, that the user can click, and in code, It used the parent mesh bounds to calculate matching Uproperties.
This gives the user a better starting point for further tweaks.

In the video you can see that this works fine, expect that the Uproperties do not get refresh to the new values, as a long as I never modify the Uproperties proceduratly.
As soon as I apply the best fit option, for some reason, the new Uproperties are stored in component or in some database, and not matter what the component can not be edited from that point on, even if I quit the map and reload it.
The only way to edit is by deleting the components and starting over.
I have debugged this for several days, also rewrote the code several times, but it is the same problem problem or worse.

Does anyone knows what do I need to do to make teh editor award that some UProperties where
modifies procedurally?
the code that implement that Bound calculation is quite simple, it is just this.

void UNewtonCollisionPrimitiveBox::ApplyPropertyChanges()
{
	if (BestFit)
	{
		for (USceneComponent* parent = GetAttachParent(); parent; parent = parent->GetAttachParent())
		{
			UStaticMeshComponent* const meshComp = Cast<UStaticMeshComponent>(parent);
			if (meshComp && meshComp->GetStaticMesh())
			{
				FBoxSphereBounds bounds(meshComp->CalcBounds(FTransform()));
				SizeX = ndMax(float(bounds.BoxExtent.X * 2.0f), 2.0f);
				SizeY = ndMax(float(bounds.BoxExtent.Y * 2.0f), 2.0f);
				SizeZ = ndMax(float(bounds.BoxExtent.Z * 2.0f), 2.0f);

				SetRelativeTransform(FTransform());
				break;
			}
		}
	}
	BuildNewtonShape();

	Super::ApplyPropertyChanges();
}

Thanks.

To summarized the question.

It seems that Uproperties can be changed by the editor or blue print, but changing them in C++ code, causes some internal incorrect state, that is not given any feedback of what was wrong, yet all the properties feel like the are locked.

I figured that the have to be a way to send a editor message, so that I made the requested change as if the change was made by the user changing the variables.

but for teh light of me, I can’t figure out hwo to do that.

Usually to trigger a function when a UPROPERTY changes in the editor you override:

virtual void PostEditChangeProperty(struct FPropertyChangedEvent& propertyChangedEvent) override;

Does that not work if the properties are changed by code rather than in the editor details panel?

yes, that’s the feedback the class get when the property is changed in the editor by the UI.
or when is changed in a blue print which is also a UI thing.

what I mean is a change in code, while is the editor. and get the refresh widged updated in the editor.

People do that in game mode all the type. but Game does no need to refresh the editor.

I looked a the code base, and they onle place I see something like tha is the Chaos cloth system. but is seem a ought fully complicated code for such a trivial operation.

well, I have debugged this for days, and the ability to do this become more important as I made more progress.

After some more re-search, it seems the only way to do this, is by making the C++ class, then go to blue print and subclass it in a blue print new Node, them has blue print do the setting of the component variables.
I am still not clear if doing that will allow to chnge the component variables while teh use is in the editor.

It is too bad that we do not have anyone from Unreal answering these kind of questions with some level of authority to prevent people from going into these wild guesses that take so much dev time, that in most cases a small dev that can’t afford to invest.

Epic, is a several billions dollars company now, things like that does not seems like too much to ask.
Instead what we get, is anecdotes from well intentioned users experiences, but that in the large majority of the cases are not totally correct.

Unreal is not a friendly environment to dev C++ code for, It has almost 30 years of legacy, with many ways to do the same thing that are not clear to the user, the documentation is sloppy and scattered all over the place. And now we have these “Generative AI” answers in all the major browsers, that in more than 90% of the cases provide wrong information.
We get answers like this.

**AI Overview**

To send messages to the Unreal Editor, you can <mark>use the Simulation 3D Message Get and Simulation 3D Message Set blocks in Simulink</mark>. These blocks can send and receive data types like double, int8, uint8, int16, uint16, int32, uint32, and Boolean.

Here are some steps you can take to communicate with the Unreal Editor:

1. Create a level blueprint in the Unreal Editor and connect the Get and Set actors.
2. Set the actor tag values.
3. Set the parent class.
4. Configure the Simulation 3D Message Get and Simulation 3D Message Set blocks in Simulink.
5. Use the Simulation 3D Message Get block to receive data from the Unreal Engine environment C++ actor class.
6. Use the Simulation 3D Message Set block to send data to the Unreal Engine C++ actor class.

Which is just wrong at every step. but despite that, these bogus answers becomes the go to links for any other search. This is very frustrating.

Anyway, here I am going on another, experiment with zero expectation that I will work.

Julio