Keep player instantiated objects in game when player leaves room
Options
First off, I realise there is PhotonNetwork.InstantiateSceneObject which will instantiate objects to a scene, however only the master host can instantiate objects this way and all other players will not be able to so i guess this is out of the question.
Im trying to work around this and looking for a way to keep player instantiated objects ingame after leaving the room. I know that setting m_autoCleanUpPlayerObjects to true or false will automatically clean up player objects on leaving
I thought setting autocleanup to false would fix this, but then the player and his camera stays in the game and messes everything up for the other players, thought about trying to delete it by setting it to destroy itself if the detected player id leaving the scene is identical but due the ownership is instantly transferred to the next player preventing it from deleting
thoughts on how to fix? is there any way to stop the player objects from changing ownership, or maybe make the blocks you place change ownership to the next player to stop them deleting with autocleanup, is there any way around this to let all players PhotonNetwork.InstantiateSceneObject and not just the server master?
Im trying to work around this and looking for a way to keep player instantiated objects ingame after leaving the room. I know that setting m_autoCleanUpPlayerObjects to true or false will automatically clean up player objects on leaving
I thought setting autocleanup to false would fix this, but then the player and his camera stays in the game and messes everything up for the other players, thought about trying to delete it by setting it to destroy itself if the detected player id leaving the scene is identical but due the ownership is instantly transferred to the next player preventing it from deleting
thoughts on how to fix? is there any way to stop the player objects from changing ownership, or maybe make the blocks you place change ownership to the next player to stop them deleting with autocleanup, is there any way around this to let all players PhotonNetwork.InstantiateSceneObject and not just the server master?
0
Comments
-
The simplest way would be creating objects via PhotonNetwork.InstantiateSceneObject on master. Just send RPC to master asking him to create scene object. Or you really need the object to be owned by one of the players?0
-
I was also interested in this issue. But if we send RPC every time you create an object that will go beyond 500 messages. For example, if a lot of things! I'm in the game, each player rastavlyaet many items (PhotonSceneObject) How to do it the best way? And how to make the new players have seen, what subjects you were put on a map to it.(How to make items to display for new players?)vadim said:The simplest way would be creating objects via PhotonNetwork.InstantiateSceneObject on master. Just send RPC to master asking him to create scene object. Or you really need the object to be owned by one of the players?
0 -
Not sure what limit are you talking about. Only one RPC required per object.
Objects instantiated with PhotonNetwork.InstantiateSceneObject will be created automatically on all new clients.
0 -
"what limit you're talking about".... nice, indeed... So short view of things. Coder.... eh....
Few things about spawning sceneobjects via RPC.
YOU HAVE TO SEND VIA INSTANTIATING DATA ALMOST EVERYTHING IN RPG GAMES. Where the NPC "lives", is he at home, or outside of building, which tools he have in use at the moment, owner of
the NPC, player group where NPC belongs etcetcetc......
IF WE CAN, AND I DON*T REALLY KNOW WHY WE CAN'T!!!! We could instantiate scene objects from
ANY clients. Then they stays in game, when player goes and other client(s) have a decision what to do for that players NPCs. Turn them under AI or delete or or or or or.... And finally we have to find a way to get that masterclient instantiated gameobject handle for client use. NPC objects are NOT just a balloons or
some stupid demo cubes. They usually have a huge script with huge amount of data glued in it. And all of those data have to rebuild WHEN using RPC instantiating method. I gladly can show to you some scripts from my code if you want. Just install Teamviewer, send email to me to get ID and pass and after a moment you know EXACTLY what I'm talking about.
INCREDIBLE STUPID WAY to instantiate via RPC calls. I will change to another Network system
instantly, when working one (all target devices + lobby & room) came available. But, while waiting
that day I'm stuck with photon's Limited behaviour.0 -
Hi,
easy, easy
PUN is sitting on top of the Photon SDK, so maybe you need to go one level down and skip PUN and its strategies and paradigms. With the barbone sdk you simply send messages the way you want ( within rooms, that restriction still applies, but the chat sdk can be combined to paliate this).
also, I am not sure what's the problem with giving responsibility to the MasterClient for instantiating sceneObject. Can you explain why you don't think this is a good idea? typically, if a Player can detect in its logic that a new NPC has to be instantiated, so can the masterClient, simply because all players have an instance, and so even if a player instance is not "Mine" it can know it's on the masterClient and locally call a manager to instantiate an NPC, no rpc involved here.
Can you consider this? I can explain further if you want.
The size and complexity of your npc have very little to do with the process of instantiating and managing them as entities. If however you want to organize a teamviewer session, we can setup a time, I seem to have spotted your are russian right? I am also in Russia, so it could be good for falling into descent hours for a call. though I prefer join.me over teamviewer lately it's better for zooming into big screens.
Bye,
Jean1 -
Just burned my brain, when other coders are stuck with RPC / Master scene instantiating. Maybe I'm too old or something (50+) Nothing more :-)
No. I'm not from Russia. I'm from Finland.
And yes. I'm not using scene instantiating at all. I just force clients to left their game objects to game before joining to room with: PhotonNetwork.autoCleanUpPlayerObjects = false; My game is really very complex when talking NPCs. It will be overkill to even try instantiating via RPC calls.
And another annoying thing with pun. I have few hundreds NPCs on my game. With original photonview... whoa just ridiculous. Inbuffer overflow even with 35 npcs easily. So I made this:
http://www.thecolonizers.com/forum/index.php?topic=15.0
Works great with few hundred NPCs.
From here: http://www.thecolonizers.com you can see, what I'm doing in my spare time. There is also a couple very old and Limited test versions. Dev-pictures seems to are only ones, what I remember update :-)0 -
Hi,
Finland, ok I saw " player rastavlyaet " in your message, it sounded a lot like cyrillic!
Going brute force with one photon view per npc with hundredth of them in a room is definitly not recommended. let alone indeed each npc sending rpcs...
Have you considered regrouping npc around a single manager that would have a photon view and would then be the middle man for synchronizing them across the network. you can do a routines to synch npc in turn, few at time, and similar tricks.
I would consider indeed an MMO type of networking strategy. I hardly imagine a gameplay having to fight 100th of npc at once on screen, that just doesn't make sense other than being in an mmo network structure.
have you considered https://www.assetstore.unity3d.com/en/#!/content/13867
or have you check albion game, they use Photon server and built on top their own layer for mmo, these direction would make sense for you at this point.
Bye,
Jean
0 -
Eh. Exactly what I've done already. Didn't check the link what I put my previous message?jeanfabre said:Hi,
Have you considered regrouping npc around a single manager that would have a photon view and would then be the middle man for synchronizing them across the network. you can do a routines to synch npc in turn, few at time, and similar tricks.
Currently my idea is:
Each player have a pre-set of soldiers, buildings, tools, resources and workers. All of those NPCs are burned to original game scene level. So, they have already their homes and everything else ok. When game starts, main load routine on each player on game, will collect all of those NPCs, buildings etc and create a photon-instantiated copy of their OWN objects. Then the original object will be deleted. The original keeped all necessary data for photon instantiated object. So, no unwanted RPC or stream transfers. Only photon's intantiate command for others.
When player creates a new building with workers or soldier or..., just photon intanstiate and everyone sees that same object instantly. No unwanted RPC/Master instantiatings, since no-one else haven't any chance to do anything with that object anyway... oh, destroy or kill, ofcourse... :-)
Only data, what is transferred constantly is "statuslist" data via Photon stream. It is List for each soldier & building & worker. The owners (=each player in scene) sends it's own "List" to others. Then they have all required data what they ever need to know about neighbour.
Movements, game objects on/off, rigidbody data etc are sended only via my own databurster, when there is a new data available.
Why I made all like this?
First of all. I can use EXACTLY same levels for local stand alone play as Network multiplaying. I don't need to change anything on them. photon<->mymainloader<->scene levels take care everything.
This seems to work superb...0 -
Hi,
re grouping. I did check the link, and you are not regrouping since you require a photonView per BurstClient, only your burstMaster should have a PhotonView, and that would then mean regrouping and cutting down on network overload.
Else, can you explain further your technic, maybe your npc don not have this burstClient component attached?
Seeking reusability is noble and should always be a very high priority, but I think this case with 100th of npc is likely too much for finding a common denominator between offline and online for your code base without seriously affecting network performances if you stick with one photonView per npc.
also, can you explain the relation between a player and "its" NPC? I am not too sure I understand the use case for having each player responsible for some npcs. I hear you when you say that each players have a number of workers, soldiers, buildings, but there is nothing preventing the masterClient to handle this on behalf of each Players. Maybe the missing link is a proper online database back end to support this.
It's often a misuse of Photon network protocol to send all meta data about the game, instead Photon communication and buffer should be kept to the very realtime essence of your game, only the data that change right now should be required. I wrote on another forum post about Player configurable characters, typically, character setup ( color, gender what kind of trousers, even weapons, etc) should not be passed across the photon network, but instead saved in an online database that every other running instances will connect to and get all metadata needed for properly showing a particular remote player as well as its own player.
does that make sense and could this be a direction for your game implementation?
Bye,
Jean
0 -
Photonview on my npc's are only for indentifying purposes. When creating master burst list, all of npcs are identified with their photon id's. Look a little bit closer about my scripts!
--------- and ---------
Eh. What you're talking about.... My game uses exactly ie. common data(base). where other clients sends their data about soldiers, buildings etc.... to one common big List [t] what is available for every client on their own scenes.
You looked my code? Ok, and it's clear, you didn't get anything from it. That is more than clear. Yep. Maybe you should look twice to get idea!
Maybe I really need steel wire for bending to explain what I mean, but... who the f*ck is interested about that. Are you engineer? Software engineer maybe? Forgotten the fun of coding?
Yes. I'm tired. 14 hours at work with coding c# and then this (my hobby). what should be clear for every REAL CODERs!
Whatsoever... I will exit from stage to right (if you know, what that (even) means).... Bye...
0 -
Hi,
Indeed 14 hours shift is not cool at all... It's totally understandable to get edgy after that, so no worries
Bye,
Jean0 -
Thanks! No hard feelings... I could be a quite rude when tired...0
-
btw. If i like to go to HiFi (high fidelity) I will compress my outgoing bytes on bursters to MIDI (musical instument digital information) format. Then I will have 7 from 8 compression easily, since MIDI uses 7 bit / "midibytes" for transfer. Easy to do, but my codes are written over 25 years ago with turbo Pascal for my midi sequencer software, what I needed those days for my musical interests, I have those disks safe, but I haven't any 3.5" stations for them anymore to get sources and recode them to c# ;-) Maybe some hard googling will help to get those routines allready written for c# but I haven't time for that...0
