I have a set of agents who should be parking at 4 attractors. I use the moveTo block.
I followed the method suggested in this thread AnyLogic how to set attractor choice to both free and random. The snapshot is below.
My agents disappeared on reaching the attractors. But when I chose "is placed (jumps) to" the agents stayed put but I couldn't proceed to the next state (I'm using statechart to control the movement of the agent).
Is there additional step that I should do to either keep the agent in place or get it to move out of the flowchart?
moveTo
Author found the answer herself:
I found the issue why the agents disappeared. It was caused by the service block that receives the agent in the next flowchart.
I have a project where I am using NavMesh Agent and Obstacles as a core mechanics of the game. I have baked a NavMeshSurface to the ground so the Agents can find their way to the End point. The player is placing Obstacles in front of the Agents to block their path. I am struggling to make the Agents do damage to the Obstacles if they are fully blocked and there is no available path to the end point. Note: (By fully blocked I mean that they are just standing at one place and do nothing. If this happens I want the Agents to start attacking the Obstacles in order to make their own way to the End point) Any suggestions of how to check if there is available path are deeply appreciated! Thank you in advance
Welcome to the community Svetoslav.
Doing quick search on NavMeshAgent check if endpoint is reachable yielded the answer right away (https://answers.unity.com/questions/1254520/how-to-check-if-agent-destination-can-be-reached.html
(answer by Arcana96))
There's a method called CalculatePath which allows you check whether a position is reachable before you move the agent. Here's the documentation:
https://docs.unity3d.com/ScriptReference/NavMeshAgent.CalculatePath.html
Using CalculatePath method returns NavMeshPath object. It can be used to check if endpoint is reachable (check the documentation). After getting positive results, you can set that path to NavMeshAgent's path property.
I have managed to sync my ridigbodies real good but I just noticed that when a client (that's not the master) collides with one it doesn't move, it's locked, while reading on the net I had an idea when the object collides with a rigidbody I just transfer the ownership of that object to that client for the moment for this client to process the collision (I have tested this and it works really good, both clients sync perfectly)
is this recommended? performance-wise and security/cheating wise?
Thanks!
Short answer:
Transferring ownership of a GameObject to a client, when that client needs to control and update the object data, is fine. In cases of detecting cheating possibilities, always have one client (typically the master client or a dedicated server) validate, correct and sync the data to all clients.
I will not make any assumptions. Based on your explanation of the issue, it seems your GameObject Rigidbody IsKinematic was not being synced, causing the collisions having different effects at each client end. But in case that might not be the issue, I have a longer answer hoping it might help for this or other scenarios.
Longer version:
Sync Rigidibody data over the network where it is fundamentally required to be present on the client GameObject. The rest of the Rigidbody data can be created / calculated / simulated on each client individually:
This way, you will make sure all parameters of that Rigidbody are correct (e.g. isKinematic is correctly enabled/disabled on all clients)
Your games will always have the minimum required data to create/simulate the rest of the events and effects properly, reducing network lags and improving performance.
Where data validation is required, the master client will always validate the non-master client data, makes the crucial adjustments and decisions and updates the room data for all clients where necessary. This reduces the chances of players cheating.
Developers will find bugs easier when the events that are supposed to take place on each client, do not align with what is expected. This shows itself more often in scenarios where several events should take place at the same time and on each client.
Much longer version:
When I use PUN2 on GameObjects in my games, I only sync Rigidbody where those GameObjects require Rigidbody values to be present on the clients during collisions to perform specific tasks (e.g. using the velocity or direction for dynamic sound/visual effects), or when the master is validating and correcting the data needed for the non-master clients (as a result of network delay or cheat/hack tampering the data on client side).
When using PUN2 (up to this date), I update its class internal code to my needs. For example, PhotonRigidbodyView does not sync the kinematic state of a Rigidbody yet. When I need this in my games, I could override the class with my CustomPhotonRigidbodyView class (and/or updating the PhotonRigidbodyView a bit).
Does it effect the performance when using PhotonRigidbodyView? Yes, when not used with care, it does decrease it when there are too many objects syncing over the network at the same time. The clients will see jagged movements.
Does it allow cheaters to take advantage of this data, manipulate it and send it over to the clients? Yes, if the game is vulnerable to basic cheats. Then again, the topic of security/cheat detection is quite vast, so for each game definition of "basic" cheats are different.
Is it a good idea to transfer ownership momentarily to be processed on client side? Yes in some cases, other cases no:
If doing this momentary transfer is the only place you do this and it solves all your problems (except cheating), then use it so you won't spend too much time fixing this one part in a different way.
If the Rigidbody or Transform data is being validated and/or synced, either constantly or in periodic intervals by one client (to prevent cheating or to sync client data properly at crucial times), then it is fine to transfer momentarily too.
I typically transfer ownership, when the object data must be changed by the client (e.g. grabbing / dragging around / shooting / throwing) and once the action is performed, ownership will be back to the master to be validated and synced for all clients (including the one that just transferred the ownership). This results in more time spent on testing, catching unwanted (possibly unseen) bugs, and reduced cheating possibilities.
In case a developer working on your game has not properly optimized the Collider and/or Rigidbody components for each GameObject yet, please make sure you have done so before syncing their data over the network. This page in Unity doc may be a good reference to check whether your GameObjects need to be static colliders or dynamic colliders:
https://docs.unity3d.com/Manual/class-Rigidbody.html
https://docs.unity3d.com/Manual/CollidersOverview.html
Once the GameObjects that need a Rigidbody component are identified, then you can decide which ones need to be fully synced over the network or partially synced and/or their ownership transferred when required.
I hope my answer does not confuse any of the readers. If there is anything not clear, please mention in the comment and I will improve my answer for you.
Update: 2019-05-10 (reply to the 2nd comment):
For a pool game involving so many GameObjects, I would not transfer the ownership of all objects to a client. I would:
Create a struct holding the necessary information such as:
ball_id: indicating which ball is being hit by the pool stick
hit_info: a Vector3 representing the position (on the ball surface) and direction of the hit applied to the ball, by the hit stick.
hit_force: the required force to apply to the Rigidbody of the ball that is being hit by the hit stick.
and any other information that I might need, when the player hits the ball with stick.
I can then combine this information and pass them to the AddForceAtPosition method of the Rigidbody of the ball.
Dispatch this struct in the room, for all the clients to receive.
Once each client receives this message, including the sender, (in OnEvent as EventData containing the Phton Event Data), it will apply this info to the correct ball and will create its own version of physics (small differences will be noticed between each client).
This way:
I have the minimum amount of information passed over the network to make the simulations happen on all clients
Improved performance of the game by avoiding parsing and applying unnecessary Rigidbody data
Reduced the cheating possibilities of a client moving any of the other balls that they are not supposed to, around the table or into the pots.
To increase security as well as making sure the balls on all clients are exactly where they are supposed to be, another struct will be dispatched for example by the master client, indicating the exact position (and rotation) of each ball on the pool table (or in the pot).
I would sync the ball positions periodically (either at pre-defined intervals or at specific moments of my choosing depending on the game state) to all clients to overcome any incorrect positions at any moment in the game. This periodic sync can be done by the master client or a dedicated server.
When two simulation systems are connected via HLA how are the physics engines linked?
For example, if two armoured vehicles (entities) tank A from federate A and tank B from federate B collide how is the collision physics resolved?
As I understand it, there are collision and detonation interactions that convey who hit who and the velocity but is this enough to fully resolve the collision effects?
Presumably, each federate is responsible publishing the collision interaction message and applying those message to its own entity physics engine. I can't help but think, surely there is more to it that this.
Any details or resources would be greatly appreciated.
In HLA, the RTI doesn't calculate anything it merely facilitates the communication between the federates and keeps track of time. If you have a physics engine in your federated simulation, you either have to have it implemented as its own federate that other federates need to query to resolve the physics, or each federate keeps track of their own physics.
In your example, two federates each publish a single object of type "Tank" which has attributes "Geometry" and "WorldCoordinates". Lets say they keep track of their own physics. Each federate should subscribe to every other "WorldCoordinates" of every physical object in the region, and calculate when there is a collision between their owned object and the colliding object. If you have a separate federate calculating physics (i.e. it's a submarine simulation and red team positions are masked), then the physics federate needs to subscribe to all the "WorldCoordinates" and "Geometry" attributes and calculate collisions based on that then send an interaction to the federates that own those objects.
I'm creating a Unet application, where the server is responsible for spawning units, and the clients (obviously) see the units and their movements. Clients can spawn stuff via server commands, and typical interactions.
What i'm hoping to allow, however, is each client to redefine their global 'origin' point. So if i'm in the world and i see it in front of me, i'd like to be able to turn around and determine that "hey! that point over there is now the origin", and have all the components move to that new location (which should be handled automatically by the NetworkTransforms).
Does anyone know how i would be able to accomplish this? Or even implement some sort of NetworkTransformOffset script based off the network transform?
Yes....
By moving everything by an amount equal to -1 * new_origin yourself.