Multicast function didn't actually update the property on the client side
I have a multicast function in a BlueprintSCSHook actor component:
And the logs show that it was executed on both the server and the client side.
Solution:Jump to solution
I mean when you are playing in the game client and someone joins you (no dedicated server involved) this table (unrelated to the issue) shows the "types" of multiplayer
12 Replies
But the belt's max length didn't get changed in multiplayer mode, could somebody please be so kind helping me out?
Much appreciated.
But the belt's max length didn't get changed in multiplayer modewhat happens when you try host and play multiplayer, does it work for the host only? can you check after the fact what
belt->mMaxSplineLength
is on the client side - is it actually the value you changed it to, or did it somehow get changed back?
what is the specific actor your component is being attached to via the SCS hook?It worked in single-player mode.
I don't understand wdym by "host" tho, set up a dedi server and login as an admin?
No I haven't, I thought that since the assignment is executed right after the log, so it should naturally be executed as well, but I'll check it tomorrow.
But how should I check tho, log right before and after the assignment? Or write another hook to check the value constantly, probably on the Tick?
Spline holograms, plus Wires and Lifts.
Solution
I mean when you are playing in the game client and someone joins you (no dedicated server involved) this table (unrelated to the issue) shows the "types" of multiplayer
Oh, I don't know you can do this, let me try, thank you very much.
@Robb (Busy) I fixed it. After I saw the table, I moved the assignment functions to the modsubsystem and marked it SpawnOnClient and it worked, no need for replications or SCS hooks or anything.
Now I don't know how that will affect the "big picture", but I see that the dedi server is actually "just a host" and did not share any data with the clients, so I don't think it'll affect anything.
Thank you very much for your help.
glad that worked out! here is the docs page that table is from for future reference: https://docs-dev.ficsit.app/satisfactory-modding/latest/Development/ModLoader/Subsystems.html#_replication_policy
Mod Subsystems :: Satisfactory Modding Documentation
If youβre looking for the subsystems that SML provides by default, check out the Registry page. Subsystems are actors that exist...
OK, thanks! π
@Robb Turns out that I didn't actually fix it, it's just an "illusion".
I checked the logs more carefully this time and noticed that there is
LogNet: Warning: UActorChannel::ProcessBunch: ReadContentBlockPayload failed to find/create object. RepObj: NULL, Channel: 24
before the assignment, I went look it up and found out it means the component is not synced, I can't figure out why, I did mark the component SetIsReplicatedByDefault(true);
and replicate every property, even marked the functions Reliable, WithValidation
and all that stuff, but somehow it failed to sync with each other, could you share some insight, please?hmm, are you getting the desired behavior on the client and server sides despite that message?
since it is an actor component, there might be something more you have to do to make it replicate, I have no idea what to check next though
It's really weird and funny, when I use the replicated actor component, the value is changed but not the visual, still gives me "belt too long" warning but it's actually within the new length limit, and when I use the independent subsystem, the visual is changed but not the value, I can drag the belt infinitely long, but when I confirm it, nothing is built, sometimes even crash the game with "belt too long" error.
I end up cheesed it by use them both, one takes care of the actual value and one takes care of the visual. π
I know I'm not supposed to do stuff like this, but I can't figure out why and how to fix it, and many people are waiting for it to be fixed, so I have no choice but to cheese it for now. π«