multiplayer

[solar stirrup]

Yeah was just a random thought

It'd be dumb to try heh

[fathom aspen]

Yeah that's the hard part

I would assume that what they would do in case they make subsystems net supported

Yeah, I would just have a proxy actor for the net shiz

I would assume they should be relevant if the location was updated on the server

IsNetRelevantFor debugging ftw

[livid sluice]

Ooh ill look into this. Thank you

is there a blueprint equivalent to this function?

[fathom aspen]

Nope

BP barely has 10% of the net tools

[steel fractal]

Hi everyone, im having this weird issue where when i call restart player, if im in multiplayer, the PlayerController comes up as null. It works fine tho in single player. what am i doing wrong? I tried to run restart on client as well, but no luck

actually nevermind it happens even if i dont restart player

now i have no idea lol

[fathom aspen]

Apart from what your goal is

You're doing things wrong there

BeginPlay is called on both server and client

GetGameMode is valid only on server

So that's one error

Before that you call a server RPC which is assumed to be called from client

And those are different paths

Have you read the compendium?

[steel fractal]

yes ive read it, i still get kind of confused

[fathom aspen]

Also BeginPlay is called before you can even call RPCs

The first point where it's safe to call RPCs is OnPostLogin, which iirc happens after BeginPlay

[steel fractal]

that can only be run from gamemode tho right

[fathom aspen]

Correct

[steel fractal]

gotcha

i think i messed up some c++ cuz regular spawning doesnt even work, the pawns dont attach to the controller in multiplayer

[fathom aspen]

In SP you don't have all these gotchas, you're always authority there (no two sides) so things are run locally seamlessly with no issues whatsoever

[fathom aspen]

Then figure out why that's happening first. It should be as easy as to call Possess function with a reference to the pawn

Don't feel afraid to look how it's done in source

It's done in HandleStartingNewPlayer

[steel fractal]

hm ya i actually have it overridden, so ill take a look, but im pretty sure im just running the super and i took out any custom code

im pretty sure nativley on a fresh game mode, the controller attaches in multiplayer too, so i did something

[fathom aspen]

Ofc, so trace down your setup

[woven otter]

Hello, im using a level for the login of players so i can check a db for their info before joining the server, my problem is i cant figure out how to pass the player name from this "offline scene" to the online lobby and from that lobby they can go to different minigames, each of those games run as a different instance on other servers, any idea haw can i make the player keep its name between all this?

[cloud halo]

How can I get the information that the current user is Server or Client?

[worthy magnet]

Can anyone send a link or file of that pdf that explains networking rly well? I lost it and cant find it :(

[steel fractal]

i think what i did is fubar i stripped out all my custom code and the issue is still happening

[fathom aspen]

https://wizardcell.com/unreal/persistent-data/

TLDR use subsystems

[fathom aspen]

#multiplayer message

It's in 📌 btw

[fathom aspen]

What do you mean? Host vs. hosted player?

[cloud halo]

Yes, if the current user is the Host, I will do a different action if the client is a different action.

[fathom aspen]

The listen-server player has his local controller on the server

So checking IsLocalController on PC in GameMode will yield true for host

[cloud halo]

we are trying to do this

[fathom aspen]

Ok?

[cloud halo]

I have no idea which node I should use to distinguish between two users.

[fathom aspen]

I already told you though. For example you want to know if the host is overlapping this box you have

You do SwtichHasAuthority, use Authority pin, check IsLocallyControlled

For host it's true

For clients it's false

[high lotus]

Probably the biggest thing you can do is make a tiny demo project and test the network functions with lots of debug messages until you understand what's going on. This is probably going to be more helpful than asking for help, because you'll gain an understanding from the ground up

@fathom aspen I like your website 🙂

[fathom aspen]

And anywhere else you can do a combination check of IsServer && IsLocallyControlled/IsLocalController (depending on where you are, Pawn/PlayerController) @cloud halo

[fathom aspen]

Glad you find it helpful 🙂

[cloud halo]

How can the text be fixed in this way for both server and client.

[fathom aspen]

You are using SwitchHasAuthority and IsServer

That's not a combination I pointed for

[cloud halo]

i don't understand how to do it

[cloud halo]

Thanks,
how do i make an actor to spawn only on client users

If there is a tutorial on these topics, I wouldn't bother you.

[fathom aspen]

This one is the best

[fathom aspen]

There is no such an answer to such question

It depends who is spawning

Where you are

[quasi tide]

If you want an actor to spawn only on the client...just spawn it

[fathom aspen]

But if it's a function like BeginPlay that is called for both server and client then you want to check IsServer

[fathom aspen]

You can go the Role path like I did here, but it should be taken carefully

[quasi tide]

Read and re-read the networking bible multiple times.

[fathom aspen]

3 times isn't even close to be enough

[cloud halo]

Thank you very much, I will try to do it.

[steel fractal]

@fathom aspen I think I figure out the issue, if I override anything in bp, it breaks the player controller spawning. The game mode only works on a fresh copy, even if I delete the override the issue will persist

So I guess as work around, I should just not make a blueprint child of it

Idk if that’s a bug or something

[candid escarp]

Hello people! I implemented the VOIP talker into my project and it works fine like it is.

However, I want to add a walkie talkie funtionality, but this would require multiple components to attach the talker reference to.

Or how would I implement a walkie talkie system?

[sour relic]

Any suggestions on this please

[fathom aspen]

Yes just have a static camera actor placed in the level and run SetViewTargetWithBlend with to with the target camera and PC

You can unspecify the PlayerCameraManager in PC, though it will always spawn default one iirc

Doesn't matter much

Ah you use it too?

It's amazing 💜

Drop me your blog

MM ftw

Where are my colors + dark mode though

[quasi tide]

It's the best template 😅. I use it too. But I haven't done a post yet 😅

[fathom aspen]

We started writing around the same time and you already have 7 posts 🥲

[quasi tide]

Get your write on foo!

[fathom aspen]

We need one on the net addressable stuff

[quasi tide]

It's just so much work to write stuff 😅

[high lotus]

write tiny stuff

better 1 tiny thing than 0 49 minute reads 😛

[fathom aspen]

The plan is always tiny... but you know how it ends up

[quasi tide]

Then showing code examples...bleh

[fathom aspen]

That one is a compendium xD

Well it's still a semi-compendium but you know we want them clicks

It's going to get bigger though

[radiant cypress]

Hey ! Widget Component "Owner No See" seems to apply only if "Space" is set on "World", and not if it is set on "Screen".
Is there a way to have the same result with a "screen" widget component ?

[high lotus]

why would you put a widget on a screen that the owner can't see?

can you just not put it there?

[radiant cypress]

@high lotus Well, it's a lifebar that i want other to see 🙂

[high lotus]

network or splitscreen mp?

[radiant cypress]

network

[high lotus]

can you just check if it's connected to the locally controlled player, and hide it if that's the case?

[radiant cypress]

so i start with node "Get owner player", and then ?

And Local Viewing Player OCntroller

[high lotus]

well, how does the health bar connect with the pawn?

[radiant cypress]

thing is i also tried hide it with a custom event

that is a normal one (not server)

But it hides it for everyone

its a widget component

[high lotus]

if referenced pawn's controller = player controller (0) hide the widget?

[radiant cypress]

"hide the widget" hides it for everyone no matter what

[high lotus]

you'd have to run that code locally on each machine, not on the server

[radiant cypress]

yes

thats what ive done i guess

because i fired it on beginPlay

without ServerEvent

just normal CustomEvent

[high lotus]

on begin play, you might not have control set to each pawn

[radiant cypress]

on begin play of pawn

wouldnt it work ?

[high lotus]

control may not be immediately assumed on pawn start

[radiant cypress]

but then i dont understand

on game mode then ? on PostLogin Event ?

[high lotus]

you can check if it's locally controlled after you've spawned it and see if any pawns have local control

[radiant cypress]

after i spawned it but not in its beginplay ?

[high lotus]

a pawn might not be immediately possessed by a player controller, so you can't check who owns a pawn on begin play

[radiant cypress]

let me check then

well thing is

when i switched the widget to "world"

insted of screen

and let the "owner no see" ticked

it was working

(widget was two sided to be sure its not because of onesided)

[high lotus]

I think every widget in screen space is owned by the player who's screen it's displayed on

[radiant cypress]

then how do you explain that it was working as I imagined ?

when set to "world"

owners couldnt see their own healthbar above their head

[fathom aspen]

That's a bug: https://issues.unrealengine.com/issue/UE-48546

The 52 votes though...

[radiant cypress]

oh

[fathom aspen]

Can't you just SetHiddenInGame?

For owner

[radiant cypress]

52 votes mean what ?

it wont be looked at ?

[fathom aspen]

For Epic?

[radiant cypress]

^^

[fathom aspen]

Nothing

[radiant cypress]

yeah

i see

too few ppl

Probvlem is

using "set hidden in game"

hides it for everyone

event if i trigger it locally

its like

its visibility is replicated by default

[fathom aspen]

There are two functions

SetHiddenInGame and SetVisibilty

AFAIR the latter is replicated but the former isn't

Try the latter

[radiant cypress]

let me check

so set hiddenin game

lets go

Hides it for everyone ^^

this is such a basic feature, how do people bypass this ?

[fathom aspen]

Did you try the latter

I could be wrong

[radiant cypress]

yes let me re-check

doesnt work

should i spawn a widget "attached"

so its not a widget component xD

would be a widget Bp whos eventtick makes him follow the owner ?

[fathom aspen]

I mean the other approach is a runtime component, but don't go that route

[radiant cypress]

this is such a horrible way

but i dont think of anything better

[fathom aspen]

Well it's working for me

[radiant cypress]

really ? !

[fathom aspen]

I'm not sure what your check was

So could be that

[radiant cypress]

well my apologies

didnt use this check

but i dont understand

how this checks affects what's after it

for network

like

for me its just a check and a branch

i struggle to understand

[fathom aspen]

This means if I'm the connection controlling this pawn -> do this

BeginPlay fires on all proxies

[radiant cypress]

Yeah so thats what was suggesting @high lotus

[fathom aspen]

Autonomous and simulated

[radiant cypress]

i see

[high lotus]

The only issue is that it might not be locally controlled yet on begin play

[fathom aspen]

Right ^

The pawn could be not possessed in BeginPlay

[radiant cypress]

Is there a node that fires once controlled ?

[fathom aspen]

Well Possessed is one candidate though it fires only on server

[radiant cypress]

i can just put this hide event apart

[fathom aspen]

Which doesn't help you much

[radiant cypress]

and fire it after i possess the pawn

its ok, i spawn the pawn from gameMode and possess it

i'll just add something next to possess

[fathom aspen]

Still you're on the server, and that check will always yield false on server

Unless you're a listen-server player

[radiant cypress]

cant i fire a "Owning Client" event ?

[obtuse field]

When unreal builds code for client, does it include server code as well(e.g. the one that is enclosed in IsRunningDedicatedServer() branch/if statement) and vice-versa?

[radiant cypress]

from game mode

[fathom aspen]

Nope

GameMode isn't replicated

You can't fire RPCs from actors that aren't replicated

[radiant cypress]

then am i stuck ?

what's the right order

[fathom aspen]

Well you can try to fire an RPC from Possessed event

[radiant cypress]

mhhh

[obtuse field]

GameState is replicated if I remember well

[fathom aspen]

But not owned by client

So you can only fire multicast RPCs there

[radiant cypress]

Gosh this is so deep, just to bypass a known bug ...

[fathom aspen]

AcknowledgePossession is called client-side iirc

But that one is cpp only

[radiant cypress]

tempted to add a .5 delay and be done with it

or when controller fires first action

👀

I mean i dont want to

[fathom aspen]

If you're doing BP only I would go this route

[radiant cypress]

never used Remote Procedure Calls

i'll try to dig in

[fathom aspen]

But I would still check for IsLocallyControlled before firing the RPC so it works for listen-server too

[radiant cypress]

got it

in any case, thx for the help 🙂

[fathom aspen]

They are pretty damn useful. You can't ignore them for long

See the compendium if you haven't yet

Found in 📌

[radiant cypress]

oh no wait i thought it was something else

rpc are events with Server/Multicast/OC ?

[fathom aspen]

Yes

[radiant cypress]

well then i'm familiar with them, yes

So, a Multicast from possessed, then ?

It works on server, but not on clients

[high lotus]

you're asking if the game mode is locally controlled on the server?

you'd need to do the locally controlled call on the pawn in question on client side after the multi cast

[radiant cypress]

@high lotus screenshot is thirdpersoncharacter ^^

But "Event Possessed" fires on server by default

so i thought a Multicast wxould do it

but it hides only the widget on the server pawn

[high lotus]

if you multicast in the game mode, and it's only running on the server, it won't run the multicast to any clients

[radiant cypress]

im not using the game mode

[radiant cypress]

I'm using the "Event Possess" inside the ThirdPersonCharacter BP

[sinful tree]

Event possessed only ever runs on the server. checking if the character is locally controlled there means it'll only work if it's the server's character being checked. Put your islocallycontrolled branch on the multicast.

[radiant cypress]

I tried, before, same result ^^

[sinful tree]

That's likely because you're also multicasting before the objects exist on other clients. Fact remains, you don't check if locally controlled on the server unless you only want it to work for the server.

You'll need to do the same check on begin play most likely.

[radiant cypress]

well thing is, it works fine when firing on begin play

but puzzabug and wizardcell told me that the pawn might not be locally controlled yet on begin play

[sinful tree]

Begin Play fires on both client and the server.

By the time that happens, locally controlled should be set for the owning client.

[radiant cypress]

So according to you, i dont even need the Event Possessed

[high lotus]

try the check before and after a delay on begin play and see what happens

[radiant cypress]

oh, so a double stuff

whynot

[thin stratus]

Ehhhhhhhhhhhhhhhhh

[sinful tree]

If you care if it shows or not based on possession.

[radiant cypress]

in my case, its currently the begin play part that does the job

[thin stratus]

BeginPlay can't handle possessed pawns theoretically

Cause the pawn is simply not possessed

It's more or less redundant to do it there

At that point you can just do a ClientRPC on Possessed

[sinful tree]

What about relevancy?

[thin stratus]

Well you are targeting the owner

So it's relevant

[radiant cypress]

looks like I started a topic 👀

[thin stratus]

Also at that point you can just try if the "OwnerNoSee" boolean works

[sinful tree]

Truuue.

[radiant cypress]

🍿

[radiant cypress]

nah, we're all here because this one has a bug ^^

[thin stratus]

Which is?

[radiant cypress]

when in screen mode

owner no see doesnt work

i've tried it, and there is an official bug report

[thin stratus]

Yeah cause they never address that situation

The OwnerNoSee is for the MeshComponent

Which is of course not used in screenmode

[radiant cypress]

yes

thats why it was working when widget was in world mode

[thin stratus]

You could also go into the Widget itself

[radiant cypress]

but i dont want it to be so

[thin stratus]

But that would be polling

So a CLientRPC on Possessed should work just fine

And if you have C++, then it's even easier with OnRep_Controller

[radiant cypress]

im full bp

but like

[thin stratus]

RIP

[radiant cypress]

see that

hahah

see, this

doesnt work

oh

owning client ?

[thin stratus]

ClientRPC

There is no need for a Multicast with IsLocallyControlled

Just do a ClientRPC

[radiant cypress]

so, Owning Client event

right ?

[thin stratus]

Yeah

[radiant cypress]

it doenst work either

[thin stratus]

Why not?

[high lotus]

like that?

[thin stratus]

A Reliable ClientRPC should work just fine there

Yeah, I'm sure i've done that before

[radiant cypress]

oookay

it works when reliable

you've got to help me on understanding

when using reliable

[thin stratus]

Yeah which you also want, otherwise it's dropped

[radiant cypress]

:/

[thin stratus]

Well, reliable probably tries to resent if it fails

[radiant cypress]

i see

its like

not a one shot one life

[thin stratus]

Not sure, I always expected Possessed to be the point at which one can use an RPC

Otherwise you are f'd in BPs

[radiant cypress]

i saw somewhere that you dont want to use only reliable

would be too much

[thin stratus]

Yeah

But this one is important

Otherwise it's not always hidden

[radiant cypress]

yep

well thx 🙂

[sour relic]

I have tried it but it needs a player controller and the game multiplayer so it only works for a single player

[fathom aspen]

Yes if you're using GetPlayerController(0) then that's not good

On server ofc

[sour relic]

Ya

[fathom aspen]

The compendium addresses that btw

But you can do it for each controller

Are you doing it in the level BP?

[sour relic]

Just run loop?

Yes level bp

Either that or place a static actor in the middle and attach the camera to it

Player actor ofc

Also I tried removing the player camera manager and it still spawns itself and cameras for every player spawn

From the pc and game mode base

I miss the simple unity camera lol

[fathom aspen]

Well I won't do it in the level BP tbh

I mean if you are doing it in BeginPlay, there is a possibility the PC hasn't loaded yet

The timings are not working to your side there

Also say you SetViewTarget and the PC gets possesed

[sour relic]

I see

[fathom aspen]

There could be an issue where the camera moves

I would do it in Possessed

Call SetViewTarget there with the NewController reference

You would still need the reference for your camera

[sour relic]

Ohk

[fathom aspen]

I would have an actor like GameMode/GameState hold a referene to it

[sour relic]

Ohk got it will try it thanx

Idk if this server has it or not but still thanks @fathom aspen

+1 respect (guess not)

[fathom aspen]

Ah the compendium?

It's in 📌

[dark edge]

Use Reliable if it MUST happen.

If it's on tick, the next tick is coming 15 or so milliseconds later. Doesn't need to be reliable.
If it's something cosmetic and not that important, doesn't need to be reliable.

Reliable is like certified mail. Unreliable is like spam.

[cloud halo]

I'm spawning an actor but it only appears on the server side how do I make it visible to everyone?

[quasi tide]

Make sure the actor is replicated

In the BP - go to the details panel and search for replication

If "Replicated" is not checked - it won't replicate

[cloud halo]

Thanks very very much

[obtuse field]

I have a foliage spawning system that just spawns hell lot of instances that are later propagated to the client. That can cause "package overflow"(the error that pops then too much data is send). Can I somehow prevent it, e.g. force unreal to send particular data with delay if it needs to?

[cloud halo]

The changes are only visible on the server side, how can I fix this?

[fathom aspen]

What do you mean by propagated? Replicated? Spawned locally thorough an RPC?

[fathom aspen]

What is this dot? A widget component?

[obtuse field]

Yes, by rpc

its already unreliable

[fathom aspen]

And you are passing them through an RPC param?

I mean you should be able to spawn them locally just fine

I would have them net addressable and not replicated

[obtuse field]

I'm passing item/instance id(String) + its location. Nothing else

There are just a lot of them

[fathom aspen]

A lot of RPCs?

[obtuse field]

y

[fathom aspen]

I would assume each RPC has its overhead

[fathom aspen]

So I would have less RPCs with more payload in each @obtuse field

[cloud halo]

Its color changes when it enters the trigger box.

[fathom aspen]

That doesn't have to replicate

Just keep it part of the CDO

And change it locally

So instead I would have FColor property that is replicated

Tied to an OnRep

Inside the OnRep I would set the TextRenederComponent color to the repped down color from server

The FColor propert gets set when someone overlaps the box

Ofc it has to be set on the server, so guard it with a HasAuthority check

[cloud halo]

Everything was working in the code I wrote before, then I wrote this code, what should I fix now, sorry my english is very poor

[fathom aspen]

I'm not supposed to fix your code.

I can tell you how things work correctly

It's up to you to do them like I said

Have you checked the compendium yet?

[cloud halo]

sorry i asked for help as i need to raise this, i think i figured out how to fix the problem, thanks.

[fathom aspen]

Client-side prediction

ShooterGame already does it, you can take a look

The less data the better, and as long as things are synced/correct then yes

[lucid socket]

Hey guys, i'm working on a spectator system and having issues with spectators 'Set View Target with Blend' not getting the pitch from the player they are spectating. I spawn a spectator through the gamemode which a controller posses, then within that spectator, get the next available player to spectate and set the view target on the server. Any ideas?

[fathom aspen]

SetViewTargetWithBlend should mirror the view (apart from ADSing) just fine, like 1:1

I recall having similar issue a while back but I wasn't using the built in spectator system

Can't recall the specifics but I wrote a post on it

https://wizardcell.com/unreal/spectating-system/

[lucid socket]

Oo thanks, I did come across this post a couple of days ago and had the same result after implementation unfortunately. Must just be missing a checkbox somewhere, it works fine in my third person camera but not in first person

[fathom aspen]

Ah ok then that explains it

It was made to work for TPS

I would assume you want to set the ViewTarget to your FirstPersonMesh

Which you might have already done it

But I would have to look deep into it to figure out the pitch issue

Can't think of anything of the top off my head

[lucid socket]

I set the ViewTarget to just the characters reference, which pulls the active camera (currently first person) all works smoothly but just the pitch issue. I am using a true first person setup too

appreciate the help, i'll be sure to reply to my original if I find a fix

[fathom aspen]

Yeah right the ViewTarget is just the pawn, not the mesh sorry.

[stable patrol]

i dont think im understanding the replication correct since it spawn on server but not show on the client computer enve tho i set it to run on server then plug in a event that is set to muticast. this only spawn on server but not anywhere else

[fathom aspen]

You can't fire RPCs in GameMode

It's not a replicated actor

Read the compendium found in 📌

[stable patrol]

whoops and thanks ill take a look

[pastel escarp]

How can I mark an actor not to be persistant in seamless travel ? for example I don't want my PlayerState to be persistant in seamless travel

[fathom aspen]

https://wizardcell.com/unreal/persistent-data/

TLDR override AGameModeBase::GetSeamlessTravelActorList and make it not

PlayerArray is what you're looking for

[pastel escarp]

Thanks a lot ❤️

[twin juniper]

what's a smart way to handle drag and drop with client/server architecture

[strong vapor]

basically you're going to have to have functions in your pawn or player controller that reach up to the server.. the server doesn't know about your widgets.. so widgets are going to have to talk to the pawn or something.. someone who can talk to the server

[cloud halo]

character(client) can interact with 1st triggerbox but not 2nd triggerbox(spawned)
how can i solve the problem

[hoary spear]

compendium whispers

[cloud halo]

It works if I connect a normal node, but it doesn't work when I connect a node used in the previously used "switch has authority".

[sinful tree]

The bind from here is only happening on the server. Your function "Character Action" has a boolean "ServerSide" which you are setting to false when calling it on the bound event. That means when it reaches the branch it's going to the false path, and then it's checking Has Authority which would be "Authority" (as it's only running on the server) and that's not connected so it does nothing.

[cloud halo]

How can I fix it, can you help

[sinful tree]

There's no easy way to fix the issue with what you have here in any sort of a clean proper way.
You should let actors handle what they need to handle rather than having the level blueprint do it all.

[mental nest]

Character does not move when change Movement mode to Custom Movement mode

I am working on a project with many different movement modes like Wall running, sliding etc. In my** customCharacterMovement** Component I added these custom modes but when I switch my movement mode to slide character stops moving immediately and functions like set velocity or add force or add impulse nothing work.

I tested this in both SP and Multiplayer Modes.
How can I fix this?

[hoary spear]

dont crosspost. #rules #7

[halcyon ore]

Moving my post here from #cpp, since I just missed this chat because of me being blind I guess. lol
Hey all, a tiny bit stuck, and not sure why.
I've tried looking up stuff, but I'm either using the wrong words, or finding the wrong things.
and, anything I have found doesn't help.
I'm trying to do a replicated function.
I have this in my .h file:

        void Update_Aim_Direction(FRotator Direction);```
I have these in my .cpp file:
```void ADino_SurvivalCharacter::Update_Aim_Direction_Implementation(FRotator Direction)
{
    CameraBoom->SetWorldRotation(Direction);
}

and called with this under tick
Update_Aim_Direction_Implementation(CameraBoom->GetRelativeRotation());
The functions fires, and adding a print string has it print, but only on server.
and said value its meant to replicate and change, doesn't change for others.

[hexed juniper]

is there any tutorials or tools to make online or lan vr game?

need some help 😦

[twilit radish]

You need to just call the regular method. You don't directly call the _Implementation method. So:

Update_Aim_Direction(CameraBoom->GetRelativeRotation());
```instead of 
```cpp
Update_Aim_Direction_Implementation(CameraBoom->GetRelativeRotation());

[twilit radish]

I would say start by learning how regular multiplayer works, all VR changes is the way inputs work honestly. It changes nothing about how Unreal's multiplayer framework fundamentally works 🙂

[halcyon ore]

Damn, that simple.
😦
Thanks. 🙂
I am new to it, and initially not having _Implementation in my function definition broke like crazy with no super logical error result, so my brain just assumed I should call it with _Implementation added.

[fathom aspen]

Calling it with _Implementation will just call it locally

It was probably breaking because you can't send more than two unreliable multicast RPC calls per net update

Additional ones will be dropped

Whatever you're doing there is done the wrong the way

[stable patrol]

is there a way for the client to inherit the same camera as the cameera is not set on the client side and is in wrong position when playing i was finally able to get the actor to spawn on both server and clienttho but the view is weird

[fathom aspen]

It's as simple as running SetViewTargetWithBlend on the server

[stable patrol]

okay.

[fathom aspen]

Is this the level BP?

[stable patrol]

yes. as there not a character for tic tac toe

[fathom aspen]

That still doesn't say it's legitimate to but the logic in the level BP

[stable patrol]

yes it in the level bp

[fathom aspen]

#multiplayer message

[spark fractal]

Hi im just starting to learn about RPCs and trying to call an actor's skeletal mesh to animate on all clients, i use UFUCNTION(NetMulticast, Reliable) so it is deffo called on the clients but when i do call it, it only appears to be getting called on the server any ideas where i might be going wrong?

[fathom aspen]

We need more context. What class and function is it being called from, how does the RPC look like, etc.

Also you don't call it with _Implementation

[stable patrol]

figure it out it was also due to the default pawn being in scene as it was possessing that for some reason thanks wizard for the help

[spark fractal]

i call it with its standard function name, the class is Hand and the function is called AnimateHand() inside AnimateHand_Implementation it just has the PlayAnim() function and is called from gamemode as Hand->HandMesh->AnimateHand()

Ive sort of understand it works on the server due it being called from there but thought NetMulticast is to call on all clients also, is it possibly cause it has to be called in a class all the clients have access to like playercontroller?

[fathom aspen]

What is this Hand class?

Pawn?

What is HandMesh? a SkeletalMeshComponent?

Cause you are contradicting yourself

You are saying the RPC is called from a class called Hand while in fact it seems to be called from HandMesh which sounds to be an ActorComponent

So it's a guessing game

Either share code, or elaborate

[spark fractal]

hand is an actor, and hand mesh is a skeletalmeshcomponent

i spawn the actor in gamemode and then call the mesh attached to animate

[fathom aspen]

Ok but the RPC doesn't reside in the hand actor

It's in the skeletal mesh component

So:

1. That hand actor needs to be replicated
2. SkeletalMeshComponent that the RPC is being called from need to be replicated too

[spark fractal]

okay can you just set that up in the constructor of the hand actor?

[fathom aspen]

Yes that's done at the ctor level

SetIsReplicated(true) for the component

And bReplicates = true for the actor

[spark fractal]

found it thank you way to test

[fathom aspen]

And if you have a BP child, just double check you have the replication checkboxes ticked in both places

For the actor and the component

[pastel escarp]

calling AGameStateBase::RemovePlayerState from Server only Removes the player state from the player array on server , dsnt happen on clients, any idea why ?

[fathom aspen]

Yes, because PlayerArray is not replicated

It's synced instead by the engine code

So you have to look through source at how they remove it client-side

[spark fractal]

double checked these and tested updated stuff and sadly still only animating on the server side

https://pastebin.com/z4HGmYZt

here's relevant code

[fathom aspen]

The RPC is in the actor and not in the component as you said, so you don't need to replicate the component

Apart from that the RPC should be firing just fine

[spark fractal]

could it possibly be due to it being called from gamemode or should that not affect it?

[fathom aspen]

Nah

GameMode is server only and that says it's being called from the right side (server-side)

Breakpoint it and see where it's being called

It could be called client-side just not acting like you want

Ah wait. You are spawning the actor on the server and calling the RPC right after

If the actor hasn't replicate to client yet then there is no chance for the RPC to be acked client-side

You don't spawn a replicated actor and call an RPC on it right after it

Though you marked it as Reliable so it can be executed in the end, but I would just debug and figure things out

[spark fractal]

so should i try spawn then wait next frame to animate?

fixed it just called it to animate on begin play

replicates then

[hoary spear]

Sounds like repnotify could be used

[candid gale]

I'm trying to wrap my head around this.
In an actor component I have this Client RPC:

// InventoryComponent.h
UFUNCTION(Client, Reliable)
void SetupInitialInventoryClient();

// InventoryComponent.cpp
void UInventoryComponent::SetupInitialInventoryClient_Implementation()
{
    if (GetOwnerRole() == ROLE_Authority) {
        int i = 10;
    } else {
        int i = 20;
    }
}

I just oversimplified it to prove a point. So I call it from the server and it fires the breakpoint where int i = 10 for some reason, so like, this RPC is still executing on server. I don't get why though and it's just happening after I made a couple changes where I removed replication on some properties.
Am I missing something?

[sinful marlin]

Are you on a Listen Server?

[candid gale]

no

playing as client

[solar stirrup]

How do you call the RPC

[candid gale]

void UInventoryComponent::BeginPlay()
{
    Super::BeginPlay();

    if (GetOwnerRole() == ROLE_Authority) {
        // Stuff

        SetupInitialInventoryClient();
    }
}

it's so weird, I've gone through this so many times but now it's doing that

[candid gale]

so anyone knows why? am I missing something?

[fathom aspen]

Did you remove replication on the component itself?

Cause the component has to be replicated

[candid gale]

In the character is set

[fathom aspen]

The only thing that might seem sus to me is that the Owner hasn't been possessed yet, thus not owned by a client-owned actor

The component is attached to pawn right?

Ah yeah you said character

[candid gale]

yeah I'm still using the default 3rd person character

[shut gyro]

Does the latest AWS Gamelift SDK work fine for version 4.27?

It 'says' it only supports 4.26, but I think its fine for 4.27? Just want to know if anything is using it for that or even UE5

[candid gale]

I'll set up a timer and see what happens

[candid gale]

well, you were right, set up a random timer for 3 seconds and it was finally called on client, but that begs the question where can I call this safely to execute on client if not on BeginPlay?

another issue I'm facing is that in the real function I'm sending an UObject which contains a UPROPERTY, an array of other type of UObject, it's coming as empty in this function when in the server it has data for sure

[fathom aspen]

The character can safely call client RPCs when a function like Possessed is called. Also the component should have replicated to the client if a function like PostNetInit is called.

[candid gale]

I'll assume it's because it's an array of pointers and since that info isn't replicated it's pointing to nothing, client doesn't know about it right?

[fathom aspen]

Yeah the UObjects have to be net addressable

One way is to replicate them

[candid gale]

I want to avoid that

[fathom aspen]

Also the array has to be replicated too

Well even if you used actors you somehow want to replicate them

[candid gale]

I already tried a full replicated approach but I found so many flaws that I'm trying a pure RPC approach now

[fathom aspen]

Unless you like the idea of deterministically naming them on all machines

Replicating actors is easier than replicating uobjects, but the latter sends less bandwith

Well if the thing you're doing is state then you're screwed

For state use property replication

[candid gale]

what I would want is just to send raw data through RPC's and I'd just make the functions work on both server then the clients involved

[fathom aspen]

For transient events use RPCs

[candid gale]

don't really need for the clients to know about another player's inventory at all times

[fathom aspen]

The data don't need to be replicated for sure, but they need to be net addressable

[winged badger]

I prefer a reliable RPC to replicated variable for important messages, even when both can do just fine

[fathom aspen]

Well that's why you have OwnerOnly

But in that case it's owner only

[fathom aspen]

Because replicated properties can still be lost right?

They don't have the retry mechanism reliable RPCs have I guess

[winged badger]

I really dont want some fluke to make my players miss an event like match started ir ended

[candid gale]

• I'm not familiar with net addressable.
• Also what's owneronly. I tried to find ways to execute repnotify functions in just the client data that was changed, replicate the data on everyone but only call the replicatedUsing function on that specific client, didn't find anything

[fathom aspen]

What's the first point in time it's safe to call client RPCs in actor components @winged badger

I suppose by the time Possessed is called it's safe right?

[winged badger]

Depends whats the owner

[fathom aspen]

The component is replicated ofc

Pawn

Character

[winged badger]

Yeah, that will work

[fathom aspen]

I mean by the time PostNetInit is called the component should have replicated

And I supposed it's called before Possessed is called

[winged badger]

In postnetinit i start sending server rpcs

[fathom aspen]

This whole actor chain cycle creation is called before Possessed is called

Right

Yeah I feel Possessed is safe to call client RPCs on actor components

[winged badger]

But no owner unless its set as the actor is spawned

[fathom aspen]

Yeah ofc

[fathom aspen]

1. It means that objects can be referenced over the network

2. It's a replication condition

https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/Networking/Actors/Properties/Conditions/

For what you want you don't want to be using RPCs at all

Inventory is a state

[candid gale]

COND_OwnerOnly?

[fathom aspen]

Yes

Unless you're doing something client-side and you fire a server RPC

Which can happen frequently

[candid gale]

it says 'This property will only send to the actor's owner' so both the value and the function

I would like the value at least to be replicated on all the clients

[fathom aspen]

Well then don't set conditions

You can't have it both

[candid gale]

damn

[fathom aspen]

I guess you can change its condition at runtime but there is no reason to do such a thing

Also read this

https://jambax.co.uk/replicating-uobjects/

[candid gale]

read millions of times at this point haha

other people tell me this approach is inefficient

[fathom aspen]

Whattt???

[candid gale]

that inventory data should be Structs instead

[fathom aspen]

That doesn't really matter.

[candid gale]

my first approach was basically based off this

[fathom aspen]

Lyra's approach which is good in the sense of inventories is based off this

I don't really care if it's an array of structs or uobjects as long as you're replicating and NOT RPCing

[candid gale]

Let me lay down the issues that I encountered using this approach:

• I used repnotify to update the UI on a property change, so whenever an item was updated in quantities, or a shirt received an item, etc. The problem is since this function is called on all the clients, and I have no apparent way to tell to only call the UI update on the client that matters, then other clients ended up with weird stuff while for example dragging an item in the middle of it, etc

• The amount of repnotify calls was insane, because it did it per property change and such, so for example I swap an item between my inventory and a chest inventory, that involves swapping item slots, owners, subcontainer and the swap between the 2 different array of items, each one represented a repnotify call instead of just one consolidated call at the end of it all

• The above issue I tried to solve with a RPC call to force an update from the server after all's done, but the issue is that the replication stuff happens not in order but first comes first served, so pretty much I ended up in situations where the RPC call happened before the whole replication changes took place on my client and that led to a bunch of it's own issues

so I contacted some people and that's where the Replication approach with UObjects being inefficient came from

stuff like there shouldn't be arrays of UObjects, that items should just be raw data and not an object with a bunch of unnecessary boilerplate attached to them, etc

[fathom aspen]

1. That's because you don't check IsLocallyControllled inside the OnRep.
2. That's the beauty of property replication that each can replicate at its rate, and not sending too much data in one RPC.
3. You shouldn't really have property dependencies at all, and there always way to go around this. If you need them to replicate all at the same time then put them in a struct, implement NetSerialize for them and make them replicate atomically.

[fathom aspen]

People can have opinions that doesn't make them true. This inventory approach is used in too many games fyi

And it's UObjects because they are less resource heavy than AActors

[candid gale]

1 and 3 you spoke like in japanese to me hehe, I have no knowledge about these concepts.
Except for the part of putting them in a struct. Like in the example I provided, I manipulate a bunch of UItem properties, then I manipulate the array of an UStorageItem object, which extends from UItem, and ofc the array holds a bunch of UItems. how could I put it all in a struct?

And, wouldn't that struct have their properties replicated as well, with their repnotify defeating the purpose of a single call, or you mean to take out the ReplicatedUsing from these properties?

[fathom aspen]

Just have the struct contain the properties that define an inventory item, so something like FInventoryItem.
You don't need to have each property bind to an OnRep, but they need to be replicated for sure. The array will ideally be tied to an OnRep and when that OnRep is called you can check for the entries in the array that replicated, and more specifically the properties

Structs be default only send the properties that replicated, unless you make them send them all

But note that if you have a pointer to a non-POD type you can't guarantee it has replicated in time with others, so it still need to be tied to an OnRep

[candid gale]

a non-POD type?

[fluid summit]

Hi! does anyone know how i can quickly get the Player controller from a Remote actor? (not a pawn)

Actor -> Remote -> Get Player Controller basically

i want to check if "Input key is down"

[fathom aspen]

Yeah, say a pointer to an actor

As each actor has its own net priority

[fathom aspen]

What do you mean by remote? simulated proxy?

[plush otter]

hello, I have a multiplayer mobile project. Find if strange when previewing 2 clients in PIE, simulated proxy doesn't have smooth movement interpolation.
More obvious with larger lag value.

I haven't changed anything in character movement component.

[fluid summit]

Yeah

[fathom aspen]

You can't.

Client-side you only have access to your controller

GetPlayerController(0) client-side returns your controller

Though it's not as safe as GetFirstLocalPlayerController in GameInstance

[candid gale]

yeah that's pretty much what I faced here.
I have a replicated (non repnotify) property called InventoryOwner which points to the InventoryComponent that holds the item, then that's important to have it updated because I get the owner actor to do some stuff, I swapped owners between 2 items before swapping them on both arrays, but the inventory owner change happened AFTER the item array swap which holds the repnotify, so the UI update happened with items still having their old inventory owners.

I still don't see how holding this on a struct may change anything

Although the conditional of owner only gives me an idea

like I said, I don't need other players to know about other actor's inventories, only when they search them

so maybe have a replicated InventoryComponent property that points to that secondary inventory before opening the UI? since that property is replicated and points to another replicated inventory the changes will be reflected on both my client and that other player's inventory?

[fluid summit]

That's what i wanted, i forgot about that one, thanks!

[fathom aspen]

Then it sounds like you want to ping-pong. The owner has replicated, OnRep is called, fire a server RPC telling the server it did, do the other stuff that should come after

[candid gale]

isn't that highly inefficient though?

[fathom aspen]

That's how you guarantee order at a very basic level

Don't get worried too much about efficiency if you have nothing working yet

We can keep talking about this till tomorrow but you won't have anything done then. Start doing, optimize later

Ah yeah forgot about the 🐞

[candid gale]

I had this with the old approach
https://imgur.com/WMpHIZr

you can see the issue I just talked about

[quasi tide]

Faster bugs mean faster bug detection 🧠

[fluid summit]

Why don't you do
Inventory -->Content (OnRep)

OnRepContent --> Update UI (OnClient)

?

i'm confused with the way you are approaching it

[fathom aspen]

Those are two inventories open. It's as easy as calling server RPCs to notify the server of the drag and then updating things on the server

[candid gale]

yeah, those moves are done through RPC

[fathom aspen]

Inventories have been done/discussed so many times in this server. You can use the search tool to get a basic understanding of how they work

[candid gale]

but then the RPC function does all the changes for these replicated properties

[candid gale]

Because of order of replication
I expected the red stuff to happen before the blue stuff

[fathom aspen]

Right, and UI listen to OnReps

[candid gale]

it almost never happened

[twin juniper]

if I have something like this called on the client, can the client edit the bools when calling it? I am calling from a widget because of drag and drop, but is it even possible to incorporate bools into the input safely or should I just think of another method?

[sinful tree]

Yes. Anything client side can potentially be modified by the client.

[twin juniper]

Okay, thanks!

[sinful tree]

i've been working a lot on drag & drop mechanics, and normally you probably shouldn't care too much on client side if they are attempting to do something because at some point you'll probably want to call it to do something on the server anyway. It's good to validate on the client before attempting to call the server, but if it's important or game changing in some way, you want the server to validate the request.

[twin juniper]

alright, I get it, so I should validate at the endpoint such as when dragging to like an equipment slot

[quasi tide]

I pretty much always validate on client side (and server). Just to potentially save some RPC/replication work.

Don't need the server to tell the client they can't reload because they have no ammo when the client has that information locally.

But if the client does try to reload, still verify on the server that it is legal.

[fluid summit]

Also it's good to check on both (Client-Server) so you don't get glitchy behaviors

[twin juniper]

alright I'll try both

thanks

[dark edge]

What do you mean I can't just drag and drop my HP bar onto my head slot?

[sinful tree]

Drag and drop all the UI

Attach the whole HUD to your head.

[dark edge]

Users be like

IDK how most people do it but IMO you should just start with the request/transaction, then just have UI call that. Drag and drop inventory should just be calling PleaseEquipThisItemInThisSlotPlease(Item, Slot)

[fluid summit]

I'm not sure if sarcasm or real question xD

All UI --> OnRep or "Bind value on tick"

[dark edge]

Hey if it's changing a lot and you're not making WoW or EVE, have at it.

prolly fast enough

If it's just a shooter HUD that's probably fine.

[sinful tree]

I think it was along the lines of 300 or 400 binds that it ends up being more performant to update by an event vs. using a bind.

Authaer did some testing on that some time ago.

[dark edge]

I wonder why there isn't some sort of an inverse bind

some sort of OnPropertyChanged delegate you can automagically subscribe to

[fluid summit]

So if less than 400 binds, Binds > Event?

[dark edge]

You'd think that'd be a handy UPROPERTY thing

[sinful tree]

Well binds are technically just easier is all, not so much that they are greater. Also function binds don't count as those could be terrible XD

GetTotalHPOfAllActors() which calls "GetAllActorsOfClass <Actor>" loops through them, calling an interface on each and adding up their returned values for example. I don't think that would be a good bind.

[stable patrol]

sorry reading documents and still trying to figure things out. trying to run a rpc for the client to spawn thing on a server. i am using a run on server to blueprint interface and then the interface calls the interface to spawn item. run on server does not spawn anything but when i set to multicast it only spawn on client.

this is being called from the player controller to the actor that need to be spawn in

i get no error and the interfaces all fire off.

[sinful tree]

You need to mark the actor as replicated if you want the server to spawn it and appear on all clients.

[stable patrol]

it is

should i enable component replicate?

[sinful tree]

Is there already a BP O spawned in the level?

[stable patrol]

yes

i have 2 actor spawn off camera so i can get references to them

[sinful tree]

This is also a problem. If you're executing on the server, it's taking the server's Player Controller for the location.

[stable patrol]

i thought all controller should be at 0 or should i change it

[sinful tree]

You shouldn't use get player controller at all when running on the server.

Instead, you should be passing the location/hit result through the RPC you called earlier.

Better yet, just pass the hit actor. That should give you your location too.

[stable patrol]

so where i started the interface plug the actor through that and then in the actor pass the info from interface to through the calll event of it?

[sinful tree]

It should flow something like this - add in any additional checks you need.

[stable patrol]

ah ok

will give that a go thanks.

nice that work didnt think i would need to call the trace off the server. that was my issue smh

appreciate it. thanks

[torpid whale]

One question, how does the closed multiplayer system work? the famous cooperatives like devour

in the devour the rooms are for 4 people, how does that work? in which service can it be stored? It is expensive?

[sinful tree]

It's done through a player acting as the host of the game aka Listen Server. The lobbies are managed through #online-subsystems.

[hollow eagle]

Or via a dedicated server just like non-cooperative games. Being "closed" doesn't inherently mean the server model needs to change.

[fluid summit]

Hi! I have a endless procedurally generated world

i'm running into some troubles with the navmesh stuff

I was thinking on attach the navmesh volume to the player and update it every once in a while (or when entering a new sector)

does anyone know of a better way?

Another option is to have a really huge navmesh volumen (25.000, 25.000, 500) of scale and just let it be.
But i'm not sure if this is only needs to be built once or also when playing and if there's big performance costs to having a bounds that big

[pseudo spoke]

I know few people have experience with beacons, but does anyone know why my beacon works locally (URL 127.0.0.1) but doesn't work from outside my network (URL <my public IP>)?

[pseudo spoke]

Turns out beacons require port-forwarding or a subsystem with nat punchthrough

[fossil veldt]

Anybody know if there's a reason why clients pawns wouldn't get spawned after a seamless travel, I'm on UE5, super weird
Clients travel with the server and just get stuck as default pawn

Just gotta do HandleStartNewPlayer in virtual void HandleSeamlessTravelPlayer(AController*& C); ig?

[hollow eagle]

pawns not marked for seamless travel maybe? idk didn't see you said spawned, was thinking you meant they were deleted from a previous level after travel

[fathom aspen]

They should be spawning just fine. They are spawned in the function you mentioned

https://wizardcell.com/unreal/persistent-data/#gameframework-actors-creation-cycle

You can take a look here too ^

[fossil veldt]

Yeah it's weird, I think there's just some general fuckery going on with seamless travel in UE5

https://issues.unrealengine.com/issue/UE-151220

[hollow eagle]

that's without seamless travel though

[fathom aspen]

Heck that's a new bug

[hollow eagle]

fixed in 5.1 apparently, but also not relevant

[fossil veldt]

Hmmm

[fathom aspen]

Are you sure you haven't touched engine code

[fossil veldt]

ye

Everything should be working fine, this is out the box

Super weird honestly

[fathom aspen]

What happens if you hard travel. Have a feeling that hasn't to do with the travel

[fossil veldt]

Hard travel doesn't work at all lolz

just doesn't even do anything

¯_(ツ)_/¯

[fathom aspen]

Lol

[fossil veldt]

Bout to try this turbo hack and just ship it

void AVTGameModeBase::HandleSeamlessTravelPlayer(AController*& C)
{
    // Default behavior is to spawn new controllers and copy data
    APlayerController* PC = Cast<APlayerController>(C);
    if (PC && PC->Player)
    {
        // We need to spawn a new PlayerController to replace the old one
        UClass* PCClassToSpawn = GetPlayerControllerClassToSpawnForSeamlessTravel(PC);
        APlayerController* const NewPC = SpawnPlayerControllerCommon(PC->IsLocalPlayerController() ? ROLE_SimulatedProxy : ROLE_AutonomousProxy, PC->GetFocalLocation(), PC->GetControlRotation(), PCClassToSpawn);
        if (NewPC)
        {
            PC->SeamlessTravelTo(NewPC);
            NewPC->SeamlessTravelFrom(PC);
            SwapPlayerControllers(PC, NewPC);
            PC = NewPC;
            C = NewPC;
        }
        else
        {
            UE_LOG(LogGameMode, Warning, TEXT("HandleSeamlessTravelPlayer: Failed to spawn new PlayerController for %s (old class %s)"), *PC->GetHumanReadableName(), *PC->GetClass()->GetName());
            PC->Destroy();
            return;
        }
    }

    InitSeamlessTravelPlayer(C);

    // Initialize hud and other player details, shared with PostLogin
    GenericPlayerInitialization(C);

    // Spawn Player
    GetWorld()->GetTimerManager().SetTimerForNextTick(FTimerDelegate::CreateUObject(this, &ThisClass::FinishSeamlessTravelPlayer, PC));
}

void AVTGameModeBase::FinishSeamlessTravelPlayer(APlayerController* PC)
{
    if (PC && PlayerCanRestart(PC))
    {
        // This may spawn the player pawn if the game is in progress
        HandleStartingNewPlayer(PC);
    }
    else
    {
        GetWorld()->GetTimerManager().SetTimerForNextTick(FTimerDelegate::CreateUObject(this, &ThisClass::FinishSeamlessTravelPlayer, PC));
    }
}

Modern Problems require Modern Solutions

[fathom aspen]

I like the end part

[fossil veldt]

[fossil veldt]

https://forums.unrealengine.com/t/ue5-seamless-travel-bug-found-we-found-the-cause-and-also-have-a-workaround/583652

:D

I wasn't going crazy

[fossil veldt]

@fathom aspen @hollow eagle ^ Incase you care

Fix does indeed work also, even if it is a crap one

[thin stratus]

That will probably only be addressed if someone posts it on UDN :(

[quasi tide]

Be the hero Cedric

(or James)

[thin stratus]

I can't. We are only linked to clients. Can't post in their name (or rather shouldn't)

[solar stirrup]

Just PR the bandaid fix

Which'll never be merged, not because it's a bandaid fix, but because it's a PR

[somber jasper]

Can someone help me in understanding how to use these two variables :- **bServerAcceptClientAuthoritativePosition **& **bIgnoreClientMovementErrorChecksAndCorrection **

I am trying to solve a problem where the character is free falling and proxies movement on clients are stuttering.

[uncut schooner]

Hi

[split siren]

If I remember correctly bServerAcceptClientAuthoritativePosition accepts the position sent by client in SavedMove if the error (delta between sent final client position and server position) is bellow threshold. I think by defaults it is 3.
bIgnoreClientMovementErrorChecksAndCorrection basically removes the threshold and whatever client said is the position, will be the final position. This basically means anyone can cheat their movement (teleport, have any speed/velocity etc) without any issues.

[split siren]

Hi

[split siren]

I am trying to solve a problem where the character is free falling and proxies movement on clients are stuttering. - Sounds like these two variables are not what you are looking for. Check if the movement mode is the same and if all non-default variables are present on clients.

[somber jasper]

Will this work on SetActorLocation also ? Means Client is using SetActorLocation to move and wants to make that authoritative

[split siren]

Haven't tested that, but it should.

[split siren]

If you are unsure, just check the FSavedMove that is client sending to server in CMC

[uncut schooner]

Where do you guys recon I should handle my chat system, simple messaging system that just gets the sends a message by multicast

I have been trying in the game mode, game instance and player state

Maybe a subsytem?

Although I am new to subsystems

[split siren]

Subsystem could work, but the code base is already in GameMode, so I would probably just use the game state/game mode combo and tried to re-use whatever is already in the engine.

[uncut schooner]

Thanks

[rocky kestrel]

This replicated actor and Any damage Event. When health is >= 1 I want to call interface function to player to add item to chest. But target is not right player how should I do that?

Damage cause is server

But how I take the actual player ref?

[split siren]

There is a OnDamageTaken (OnTakeDamage or something similar) which executes on the player that was damaged. Then you can just get self reference

[thick scroll]

What is a nice compact way of sharing unique id's across the network? i.e, server creates a 10 structs and gives them unique id's, they are then replicated to all clients and allows, for example, clients to identify which struct an event was raised on.

[worn wagon]

Anyone got a good way of making players auto spectate a player when they begin spectating instead of defaulting to freecam? I'm tried so many thing and the best I can get is a solution that works 50% of the time. In BeginSpectatingState I've tried setting viewtarget on the server as well as calling ServerViewNextPlayer on the client. The latter works most of the time, but sometimes it just doesn't. I'm not sure why this would be, since it should be called on the client after everything is setup on the server and the spectator pawn has been created and possessed.

I might just have some incorrect assumptions with how viewtargets work also. As I understand it ClientSetViewTarget is what forces the client to swap viewtarget, and I've made sure to set bClientSimulatingViewTarget to false.

[winged badger]

spectator controller and spectator pawn

then slap a camera to spectator pawn and attach it to a player

[stuck gorge]

Hi, when I try to move pawn on clients it jerks when moving. How can I fix that?

[worn wagon]

Maybe I was unclear, I have a spectator system that works fine. The issue I'm having is making the player instantly swap to another player when they enter the spectating state, ideally I don't want there to be a single tick where they are in freecam.

[winged badger]

what makes you enter spectating state?

[worn wagon]

bPlayerIsWaiting = true;
ChangeState(NAME_Spectating);
ClientGotoState(NAME_Spectating);```

In the player controller

[winged badger]

thats the code that switches you to it

what triggers it?

[worn wagon]

PC->SetPlayState(NAME_Spectating);```
When the player dies

SetPlayState runs the code above

This is before the player pawn gets destroyed, it needs to hang around and show the body

[winged badger]

you running everything from the same trigger?

if you're depending on your pawn replicating its health being zero and the playerstate replicating that you should go to spectator mode

those 2 things might not happen at the same time

if you're changing the controller and pawn for spectating, those also need to replicate (as actors) before client can use them

if you replace the playerstate object, its even worse, as those have low net priority by default and can take a while to arrive

[worn wagon]

The spectator pawn is clientside only though

I'm not replacing the controller & playerstate either, unless I'm misunderstanding you

[winged badger]

ok, that simplifies things

[worn wagon]

I just set the state to NAME_Spectating using ChangeState, which is run on server and client. From inside of there it calls BeginSpectatingState, which runs this code

    {
        UnPossess();
    }

    DestroySpectatorPawn();
    SetSpectatorPawn(SpawnSpectatorPawn());```

[winged badger]

so you're not possessing the spectator pawn either? just setting it as viewtarget and funneling next player inputs to it?

[worn wagon]

No I'm pretty sure it gets possessed

This is the default spectating system, I'm not doing anything fancy

[winged badger]

whats the client side entry point?

[worn wagon]

ClientGotoState calls ChangeState on the client, it's a client RPC

[winged badger]

i'd probably run it from OnRep_Pawn if the Pawn is null

[worn wagon]

The pawn won't be null it gets created in BeginSpectatingState

[winged badger]

server doesn't consult a client before doing the Unpossess?

[worn wagon]

I'm not sure what you mean by consult. In fact looking at the source the manual UnPossess I call is unnecessary because it is called anyway in BeginSpectatingState

Not that it should make any difference

[winged badger]

the way i understood you you occasionally have short intervals of free cam before you start spectating proper, yes?

which means that client side its controller has no pawn and no view target

[worn wagon]

Execution path looks like this. I call SetPlayState(NAME_Spectating)

Changestate calls EndPlayingState then BeginSpectatingState

[winged badger]

i don't think thats the issue

[worn wagon]

BeginSpectatingState unpossesses pawn on server, then creates and possesses spectator pawn. this code is all run on the client independently

[worn wagon]

This shouldn't be the case, it goes straight to the spectator pawn.

I'm not sure though, clearly something i'm doing is incorrect

[winged badger]

well, you have 2 roughly parallel executions

server will at some point UnPossess and Destroy the PlayPawn

and client will at some point create a SpectatorPawn

you also potentially have few replications competing

like PlayPawn's destruction and the RPC (or whatever it is) that triggers client to create a Spectator

there is no real way to consistently guarantee what comes first

[worn wagon]

The play pawn isn't destroyed, it just gets unpossessed

[winged badger]

and how does the client know when to go spectating?

[worn wagon]

But either way, if override BeginSpectatingState and execute code on the client, at that point everything should be settled

[worn wagon]

It's like I showed above

[winged badger]

what replication callback or RPC is the entry point?

i saw none of those

imo, simplest way is to let server unpossess the PlayPawn whenever it pleases

and then when you get an OnRep_Pawn in the Controller, run the creating the Spectator logic from there

[worn wagon]

What would be being replicated though

[winged badger]

as it is fairly straightforward

[worn wagon]

the spectator pawn is clientside only

[fathom aspen]

This one: ClientGotoState(NAME_Spectating);

I know what @worn wagon is talking about but I agree with Zlo

I had this nasty behavior where you can't have it move automatically to a player unless you do this with an input click

[winged badger]

the Pawn pointer in the PlayerController would change from PlayPawn to nullptr, and that would trigger the OnRep

[worn wagon]

Yeah that's exactly the issue i'm having

[fathom aspen]

Though that was the way our system was designed so it worked perfectly for me

[worn wagon]

Ah okay

[quasi tide]

Zlo is usually right. And when they're not, Unreal changes so they are.

[fathom aspen]

What Zlo suggested sounds promising, try it @worn wagon , tell us if it works

[worn wagon]

Is there no way for me to set the viewtarget on the server and have it replicated to the client? Do I have to wait for the client to recieve the unpossess before calling a server RPC to spectate the next player?

[winged badger]

that is fine

up until the Tick your OnRep_Pawn fires

as far as client is concerned, its still possessing and viewing the PlayPawn

from there you spawn the Spectator and SetViewTarget to it sychronously

and should have no gaps

potential problems with locally spawned spectator: ServerUpdateCamera might require tweaking to work in spectator mode

without that working, server won't be able to determine the center of your relevancy radius correctly

[worn wagon]

I guess I'm just unsure how the viewtarget is handled. Currently I swap viewtarget with the ServerViewNextPlayer RPC.

Is it okay to do it all clientside? I thought the server had to handle the viewtarget

[winged badger]

it doesn't

and it is

[worn wagon]

I just don't understand this part then

[winged badger]

you really don't want to wait for server to swap out your camera's target 99% of the time

[worn wagon]

I was told this should be set to false

Do I need to change this to true if I am going to go with the approach you mentioned?

[winged badger]

i never saw that boolean 😄

or at least it wasn't memorable enough

[fathom aspen]

void APlayerController::ClientSetViewTarget_Implementation( AActor* A, FViewTargetTransitionParams TransitionParams )
{
    if (PlayerCameraManager && !PlayerCameraManager->bClientSimulatingViewTarget)
    {
        if( A == NULL )
        {
            ServerVerifyViewTarget();
            return;
        }
        // don't force view to self while unpossessed (since server may be doing it having destroyed the pawn)
        if ( IsInState(NAME_Inactive) && A == this )
        {
            return;
        }
        SetViewTarget(A, TransitionParams);
    }
}

It just makes the client full authoritative of spectating

Not told by the server what to spectate

[winged badger]

which is fine, unless you have competative team vs. team

and don't want them to spectate enemy team

[worn wagon]

This is what I have, but still

[winged badger]

but even then doesn't matter

[worn wagon]

It seems like it should be fine if bClientSimulatingViewTarget is false though, since it only updates if called explicitly if I'm understanding correctly

[winged badger]

if you don't provide NextPlayer() PreviousPlayer() for the enemy team

[worn wagon]

It's not really replicated it is kept in sync with rpcs

[quasi tide]

Just check if the next pawn is bTeamA or not

[winged badger]

they still have to hack the game to spectate enemies

and if they are doing that, that boolean sure won't stop them

[worn wagon]

Yeah

I'll try setting the viewtarget on the client in the pawn onrep then

[worn wagon]

So yeah seems like the pawn is consistently replicated after the spectating state. Setting viewtarget on the client only didn't work, did some weird stuff. But sending a server rpc to change viewtarget after the pawn is repped seems to work quite well and consistently

Not ideal because of the roundtrip delay but it's something

I wonder if there's a race condition possible there though, I don't see why the pawn couldn't be repped before the spectating state in some scenarios.

I might need to look into these too

[fathom aspen]

Well the pawn is a replicated property and an independent actor

So that's expected

The RPC will fire way before that reps down

[worn wagon]

Is that always guaranteed? Regardless of netupdaterate?

[fathom aspen]

RPCs don't care for net update

Unless they are unreliable multicasts

[worn wagon]

Yeah I mean for the replicated pawn

could it ever replicate as fast as the rpc is sent?

[fathom aspen]

There are no guarantees

So it doesn't really matter if there are cases that it does

[worn wagon]

It would here

Ideally I make the spectating all clientside only

[fathom aspen]

Yeah that was what Zlo suggested which is fine

I managed at the time to do it with UnFreeze timer

Which is like a 1 sec timer by default

But that's unreliable

[fathom aspen]

You can try, but that needs some good amount of modifications to the built in spectator system I guess

[worn wagon]

Yeah seems like a hassle

I guess I just don't really understand if the viewtarget is "replicated" like that comment in playecameramanager says, why can't I just set the viewtarget on the server after entering spectating.

That would be the easiest

But it doesn't work that way

[fathom aspen]

Well if you rely on docs then good luck

I've found that AcknowledgePossession doc is the best so far

[worn wagon]

Wouldn't work for spectator pawn though right, since it's client only

It doesn't get possessed on the server

Or is it called from the client?

[fathom aspen]

Well Possess is a server only function, by default

That's why they call PossessedBy

So they kinda possess it but locally

SpectatorPawn isn't always client-sided

Take for example a listen-server

That's another example to how misleading the docs can be 😉

[fathom aspen]

client-side only™️

[worn wagon]

Ah i see lmao

[open quail]

guys what was the function that got called on the server to accept/reject a connection attempt? trying to make a hard limit for user amount (e.g. dont allow players joining if there are already 6 in the server)

[fathom aspen]

AGameModeBase::PreLogin

https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/Networking/Server/#connectionprocess

[dire dagger]

Why couldn‘t you just limit the players when creating the Session?

[split siren]

Is it possible to force-push a replicated variable even if it did not change? (Because it might have changed on client)

[sinful tree]

Are you making it so the replicated variable gets changed on the client?

[fathom aspen]

You mean have the OnRep get called?

REPNOTIFY_Always that is

[split siren]

And have the client "invalid" value cleared with the server version.
Trying to do very simple form of client-side prediction

1. Client and Server have X = 1
2. Client RPCs server that function "PlusOne" is being executed on client
3. Client does X = X +1
   4a) Server says Yep, X = 2 (Which sends update to client, because rep variable X has changed)
   4b) Server says NOPE, X = 1 (Nothing changes, but I need to inform client that X remained 1)

[fathom aspen]

Yeah that is used a lot for prediction

GAS uses it a lot

The server will always overwrite the client's version, at least when an update comes from the server

[split siren]

Oh cool, thanks. While on the topic can I have a quick question about prediction in GAS if you don't mind?

[fathom aspen]

I don't think I will be able to answer as I barely started to dig through that

Your best chances is #gameplay-ability-system

[split siren]

Thanks, I have tried that but my questions just hanged there today. I guess I need to re-phrase them and do more code digging.

[vivid seal]

one way to handle prediction like this is to have an id of some kind associated with the prediction, and then have your X value be a struct that includes both the value and the last confirmed ID

the server would then update the ID whether the value goes to 2 or stays at 1, and OnRep would get called

i use that for stuff like predicting ability charges, since the client saves off predictions of charges spent tied to IDs, and the server replicates the actual value as of a certain ID, allowing the client to clear any predictions up to and including that ID and continue to have any further predictions in effect

of course, you're also replicating the ID all the time so if you have to attach it to a lot of plain old data variables you're doubling the amount of information you're replicating. In my case, the charges/cooldown struct is already a number of different fields so adding a single int32 to it doesn't change much

alternatively, in the case of the server saying NOPE, you can just RPC the predicting client to undo the prediction

[twin juniper]

Is there a way to check that my property is being replicated by push params if i'm using it?

[fathom aspen]

I don't think you can. You should call GetLifetimeReplicatedProps() to get the replicated properties and I'm fairly sure you shouldn't be calling that function

I don't see the point in knowing that too

[worthy magnet]

Can someone explain to me why GetPlayerController is giving me trouble in multiplayer?

[fathom aspen]

Yes because that function likes troubles

Using it on server will give the first player controller (not yours if you're the 2nd player)

On client it's safe to some extent

There are always other ways to get your controller

[worthy magnet]

Ahh hmm okok I see

[twin juniper]

Monitoring ? I got some cases a few months ago where push replicated properties were replicated with the default way

[fathom aspen]

Breakpoint engine code then

Trace it, and see what are being done with those properties

For example breakpoint this beast: FRepLayout::InitFromClass

[clear island]

for me to send an actor pointer in a client rpc, is it required that actor be a replicated property?

[fathom aspen]

It can be, it doesn't have to

It has to be net addressable

[clear island]

hmm what does that mean?

net addressable

[fathom aspen]

For an actor to be net addressable it has to be either replicated, or loaded from package, or deterministically named the same on all machines

[clear island]

ok I guess there is some gap in my knowledge here then, here's my code:

that wep would be null on the client

because from what I've read so far " the actor probably hasn’t fully replicated yet"

[fathom aspen]

Why won't you have it replicated though

[clear island]

but I dont understand, this is a local variable, local variables are replicated too ?

[fathom aspen]

The weapon actor should be replicated

[clear island]

the weapon class?

[fathom aspen]

Yes

And yes you can't fire an RPC right after, the actor could have not been created yet on client

[clear island]

yep, it is

[fathom aspen]

You want an OnRep instead

[clear island]

ok this is what I dont understand here, can you clarify this part? I know it wont exist on the client, this is a local variable I'm creating on the server, thats what I'm sending it in a client rpc

[fathom aspen]

This local variable isn't a POD type

This is not an int32

[clear island]

or are you saying that the class itself "AWeapon" hasn't been replicated to the client yet

[fathom aspen]

When you send that actor to client, the client resolves it's NetGUID into a replicated actor

And if it can't, because the actor hasn't replicated yet then you get null

[fathom aspen]

The actor instance

You're telling the client hey get this net guid and resolve it into a replicated actor

The client is telling you I can't because I don't have one

[clear island]

so the net guid is kinda like a pointer to the variable I created on the server

[fathom aspen]

It's a unique identifier

to objects

[clear island]

which identifies that variable

right?

[fathom aspen]

The object

Right

Over the network

[clear island]

ok so does that mean that all actors I spawn on the server, will eventually be replicated to all clients? even local variables like on my example?

[fathom aspen]

If the actor is marked as replicated then yes

Replicating the pointer to an actor is just an easy means of getting it client-side

Otherwise you have to find it

[clear island]

uh, well that I would have never guessed, I thought the only things that are automatically replicated are object properties that I explicitly mark with UPROPERTY(Replicated) but even local variables are replicated, that is interesting

[fathom aspen]

I'm not sure what you mean by local variables

[clear island]

well in this case, that "Wep" is a local variable

local object/instance of AWeapon class

[fathom aspen]

Any property you want it replicated it needs to marked as a Replicated UPROPERTY

[clear island]

yea that I understand

but in my example "Wep" is not a property just a local variable

[fathom aspen]

Yeah but say you have an int32 local variable that doesn't replicate

It will die as soon as the function gets out of range

[clear island]

yea because that is passed by value I suppose

pointer is to pass by reference so it makes sense

[fathom aspen]

Nah even that pointer will die, it's still local

The actor will be replicated though

local variables has nothing to do with replication

[clear island]

I see

well, time to change this to use OnRep_ instead

[dark edge]

Pretty good rule of thumb

[pure trellis]

Could this be a potential data race when the server executes this on a replicated actor?

Or is the RPC guaranteed to arrive & execute before the destroy packet?