Your setup still looks unnecessarily convoluted. For instance, this picture can be simplified using blueprint classes or data assets. Notice how each macro has the same variables, the only difference being that the values change. This is what data-only blueprint classes & data assets are for; when you use them, they are treated as though they are part of the blueprint itself (because they essentially are). Think about it like the “Set Static Mesh” or “Set Material” nodes: instead of creating an enum for each new mesh or material, it is automatically added to the list, and all you have to do is select it; those assets have their own settings, which also come with other settings, and so on. None of them, however, need to be manually coded in; it’s all automatic. The way you have it now, you will have to manage all this yourself; what if you wanted to add new types, new variables, or bulk change multiple values for multiple types? Using a class or data asset will simplify this tremendously (and is actually how things like this are supposed to be done). Unless I’m missing something, I think you should use blueprint classes or data blueprints instead.
When it comes to syncing with the first placed trigger, you could just grab the variables directly from the first trigger (i.e. “pull” the settings) instead of having the first trigger set all other triggers (i.e. “push” the settings). You could also just make a child blueprint of the trigger. That way, you don’t have to do anything in the construction script because the settings will sync from inheritance.