You can use the GameMode but it has some caveats: Only the GameMode of the first mod in the load order will get used(there can only be one). A lot of tutorials will tell you to include a custom GameMode file by default. That’s what a lot of us did for a long time because we didn’t know any better. I now advise people to not include it and leave the Default GameMode in the PrimalGameData at “TestGameMode”(the default one). In general there is not much harm to include a GameMode even if you don’t use it, it will just get ignored if your mod isn’t the first in order and if it’s first your GameMode is a unmodified child of the default one so you won’t see a difference. There are a few cases where overriding it becomes a problem, one example is maps overriding the GameMode. If a map overrides the GameMode(TheCenter did in the beginning for example, i think WC changed that after a while) your mods GameMode override will break the settings of the maps GameMode or worse. If you actually rely on changes in the GameMode it NEEDS to be the first in order though. Another thing about the GameMode specifically: it isn’t replicated, there is only a server side version of it(replication in itself is another huge topic). So while it might seem to work for you now, if you haven’t taken replication into account yet it won’t work in a multiplayer game.
So summarizing: if you want “full stackability” you should not touch any settings in the PrimalGameData that aren’t declared stackable(the list on the wiki is probably missing a few of the newer additions, check the Patchnotes for that): https://wiki.arkmodding.net/index.php/What_can_stack
To take your case as an example: You need to save a variable “somewhere” temporarily to transfer it to the placed instance of the structure. Usually(if you aren’t modding) it would be relatively easy. Pretty much like you did it: create a variable on the Pawn, PlayerState, GameState or GameMode and save to that. All of these classes would need you to override unstackable settings in the PrimalGameData when you make a mod for ARK.
That’s where buffs or a custom global actor can come in handy. Both methods have it’s pros and cons. The main problem with both solutions is “how” and “when” to spawn the global actor or buff.
One way to handle the spawning for a global actor can be a map extension that just deals with that on its level graph.
By buffs i mean the PrimalBuff class specifically. They are in essence just actors that get attached to the pawn temporarily or permanently(which has perks in terms of replication). The neat thing about using the Buff Class is that it comes with a lot of useful functionality built in that makes your life easier when handling them.
Coming back to your specific case with a structure in preview mode: it’s going to be very tricky to pull this off without the user having to do additional steps or having a logic in place(again map extension can be useful for this) to apply a buff to all players automatically because of replication.
The preview structure only exists on the client side so you will have problems doing anything server side before placement from the structures graph which is basically needed to spawn a buff/save a variable that you can use after placement. You can’t use RunOnServer events to replicate anything because there simply is no server side version of the actor to run on until final placement. Even if you would use a replicated global actor you are going to run into problems saving anything to it because your wouldn’t be allowed to run a RPC on it.
With additional steps involved you could attach a (possibly permanent)buff to the player that can handle all the RPCs for you. You structure in placement mode would look for the buff on the player, save the variable on server side through a RunOnServer event and then grab it again from the buff after placement.
This has gotten a bit long but there’s just so much involved in this seemingly “simple” thing that you have to be aware of and i haven’t gone into much detail yet