chore: Update render component and delete unused code

[jadebenn]

A few minor changes I'm exporting from my entity/component refactor branch. I've also deleted the explicit destructors here, as they're (now) unnecessary and can prevent the implicit generation of move constructors.

[EmosewaMC]

I wouldn't replace the pointer with a unique ptr, instead consider just removing the ptr altogether and storing the struct as a non ptr in a vector instead.

[jadebenn]

In the remaining case I do think it makes sense to use unique ptrs. There needs to be a "null" case, I think.

[EmosewaMC]

In the remaining case I do think it makes sense to use unique ptrs. There needs to be a "null" case, I think.

Where is this null check done? Can there not be an alternative check if it exists? I do not believe Effect needs to be a ptr as the only case where we return one we always assume its non-null, therefore this pointer can be safely removed.

[jadebenn]

There is a null check in the serialization. I'm not 100% sure of its purpose, but I was reluctant to touch it.

[EmosewaMC]

There is a null check in the serialization. I'm not 100% sure of its purpose, but I was reluctant to touch it.

That is simply a good practice when accessing pointers. The member does not need to be a pointer

[EmosewaMC]

There are cases when you don't need to check (like when there is a strong guarantee the pointer will be valid, like the parent of a component), but for a container like this someone may mindlessly delete the ptr but not remove it from the container. In this context it was just added as a backup.

[EmosewaMC]

one final question

[jadebenn]

I still haven't gotten around to checking the specific red blocks case but I didn't notice anything out of the ordinary running around VE and AG when I last tested. I'll try and confirm your specific example tonight.

[EmosewaMC]

Ah, some context that may be helpful is red blocks is the only place in the whole game where this component is serialized, hence this test case

[jadebenn]

Tried it in-game. I don't think this is normal... is it?

[jadebenn]

Oddly, it's only the speaker that seems to have issues

[jadebenn]

Marking as draft until this is solved.

[EmosewaMC]

Tried it in-game. I don't think this is normal... is it?

Normal and live accurate behavior. The live game used the wrong fx for that speaker (crux prime meteor instead of the intended one.)

[EmosewaMC]

Check the client logs for the word unserialize and if you see any let me know.

[jadebenn]

Checked, no issues in the logs. Should recompile fine if you rerun the workflow.

[EmosewaMC]

Pending ci