Set changed variables from build instance to placed instance.

I understood, if you build a object in ark:
First you have a instance of this object in build mode(holo).
When you place it, it creates a complete new instance, so all variables are resetted to default.

I have to change variables only at the “holo” instance by a key, that is no problem.
But I have to put them after build, in the new “placed” instance.
I dont know how I can do this.

The only solution to this i know of is a bit “hacky” but it works.
First you need a buff to save the variable that you want to transfer to the placed structure. On the structure bp on begin play you check if it’s a preview structure. If it’s not a preview structure do a trace for players that covers the placement range. Check the resulting players for your buff and grab the variable you need off of it. That’s the bare bones of it. There are a few edge cases that can happen with this solution but it’s the only one that i could come up with, with the access we have.

I had same idea to make a workaround… To save the owner and a “setup index” in arrays in gamemode for example, that the next builded instance has the last selected “setup” for this object, but I never found a solution to identify wheather its preview, I missed the keyword “preview”.

The boolean “isPreviewStructure”, that can be the solution to identify… Cant test at moment, but I will try later!

The “isPreviewStructure” bool will do what you want for identifying. Saving to any of the existing blueprint classes that would first come to mind is possible but you need to override them to create a custom variable. Overriding the default blueprints can be problematic if you want a mod that is fully stackable. Using Buffs can often come in quite handy in these cases.

Sorry Im new in arkmodding+unrealengine(~1week and first mod try) and have no idea what is in the mod when its published.
Isn’t the “Gamemode_MyMod” a part of every simple Mod and works additional to the default Gamemode?
I have read somewhere that it can be used to save static variables, because its a “one instance class” and I used it sometimes for that…
In the editor this works great!
Example of other things I do there:
If this not working finaly: What you mean with buff?

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):

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 :smiley:

Holy ****!
I thought the most difficult is the logic of my mod, seems I was probably wrong.
I’ll go through all this again.
Thank you for your great effort!