HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Tarra2012

Pages: 1 2 [3] 4 5 ... 8
Scripting & Programming / Re: client movement states
« on: Dec 14, 13, 04:03:31 AM »
You could fire the event on every ClientSide Input_Movement:

Script: Input_Movement
function onCmdStart(cmd as String) as Boolean

>Question for cooper so if an object is part of SAS replication for location, gets moved by a physics request, and >that object is moved 10 different ways by each client watching it. What copy of the object gets SAS data sent to >the players?

i think i can answer this, as i did it and tested many ways.

if you let the player/client move an object (that is connected to SAS Awareness) he will give the new position of the object.  this position is passed to the server, that then triggers
a) new values for the position (which are replicated to all clients, if you wrote the methods)
b) might update SAS Awareness Position

remember you get a clientside reposition request! you need a robust way to check for sanity.
i simply used the technique to see if the object is "kind of near" the player position. this doesnt take walls into account. You need raycasting for those checks.

general: never pass clientdata without rechecking for sanity. e.g. allow reversereplication of position and simply use that reversereplicated data for objects positions/sas awareness updates.

Results a) this update works for all client equally.
             b) afterwards calculated physics might deliver different results on clients. (stapled boxes that fall)
                 if you deactive physics on the object the new position is in sync.
                 yet, if the position is over ground lvl, the cube is fixed hovering in the air  (minecraft style)


Results for you specific 10 clients case:
The last update wins. As it updates the position the last time.

A small locking constraint helps. Only 1 Char/Client can reposition 1 Box at a certain time. Only if the repositioning is done, the lock is released and the position update is propagated to all clients.
Be sure to read the last part of this post, to understand why SAS Awareness itself will never propagate Physic/Location Attributes.


When i will have more time, i will investigate into the solution with char capsules. characters capsules have no real physics, but they fall down using simple "collision detetion" and they are server based. if one capsule can stand on another: voila, you can staple objects that are in sync for all clients. and that at least fall to the ground ^^

One important point, that I understood very late:
Spatial_Awareness is a system solely for makeing entities aware of each other! Nothing else. Introducing objects to each other, if they come in awarness range.

Its not updating position of objects unless you wrote methods!
Thats why the DYN Replicated Object Tutorial is so interesting. It shows you how to setup replication callback methods clientside, that repositions the connected clientside HBNode.

>> http://wiki.heroengine.com/wiki/Spatial_Awareness_System
>> ...
>>   Is Not AI, being "aware" does not translate into actions without additional code
>> ..
>>  Entity positions in awareness systems do not update automatically when the position of a node for which the >> entity is acting proxy changes

That means everytime you update a position you need those 2 factors:
a) update position attribute of the node 
   ->this triggers the callback on client if replication is setup!
b) update sas awareness
    ->keeps the sas system up to date. if you forget to update it,
       awareness still thinks the object is on "Old" position.
       can lead to funny things. if distance between true position of node and awarness position is too big.
       awareness system will send a "entity disappeard" event or sends a "entity appeared" even though
       the true node isnt located nearby. ;)

Thanks for the answer. I am testing possibilities of interactive objects, to come up with new
ideas of quest types, that are typically not seen in a mmo.

I might try to use the character capsule, as the capsule plain collision detection would enable server authoritive handling. And still all players could e.g. stand on the object. Or is this a wrong assumption?

A small scenario:
You place box_1 on ground and a box_2 on top of box_1.
Now a player removes box_1 and repositions it to any other location.
SAS awareness is setup (own hsl) to replicate the "new location" of box_1 to all surrounding clients.

a) effect without physics: box_2 hovers (all clients in sync)

b) effect with physics: box_2 falls to ground but might have small differences between clients.
                                    this difference gets bigger if multiple objects collide.

c) effect with capsule: *assumed, as i never did it*
    box_2 falls to ground (as players do, when they have no ground below)
    every client recieves nearly same position for both boxes.

d) custom construct: Serverside physic mimic
   Input: Impulse Vectors, Effected Objects / Output: New Position/New Motion Vec of Effected Objects
   In easy situation possible (1 object moves another into 1 direction).
   In complex situation I wouldnt dare. Its like trying to simulate a physic engine :)

Last questions:
Is my assumption about using character capsules for a box-object correct?
Can other players stand on top of such a capsule and thus reach a higher ground level?

@WorldWide/ ext functions:
no, i didnt test their use, but i assume the capsule sweeping for character controler are not true "physic" but more collision detection. yet it might be sufficient for the usage aim.

the physics node might be a serverside anchor for physics, but i didnt understand them yet.
is it only used to build a logic Group? how do those effect the physics?

>>Also question is what is the intent or desire to have it be exact on all clients.
We intend to make pushable/relocatable boxes. They are used by players e.g. to "reach" a higher platform.
If only 1 player sees them, the sas awareness & clientside physics would be sufficient. he could stapel them and the walk over the staple to the new ground.

but i am evaluating ideas, how to make those interactive objects usable in "group instances" (areas created for 4-6 people). i come up with fun ideas, but they all depent on all clients beeing in sync. the server must be authoritive and gives physics calcs or at least "impulse" vectors so that all clients update similar.

one more thing:
i never found parameters that distinguish clientside from serverside physics. aka friction serverside, density serverside. which makes me more curious, if real serverside physic exists.

@keeper:  thats wrong. i tested it many times and wrote in my entry text, that the solution to use sas awareness to update clients WONT give a true severside physic. it will update positions.

The Dynamic Replicated Object Tutorial
- has only a "HBnode" and "Physics" Properties on Clientside.
- If you move it, no other Clients gets the new Position.
   (This can be fixed, by updating the position with a servercall that then updates SASAwareness Position)
   Yet this doesnt mean there is a true physic Object existing on Serverside.

You update the position of moved objects via SAS Awareness. Which i did several times. YET NO true physic representation exists severside. You end up with several clients calculating different results clientside. just staple 5 boxes. remove the lowest and update its position via sas awareness.

3 clients will reposition but calculate the physics differently. You end up with a big mess of different clients holding different endpositions for the objects.

how to create a TRUE serverside physic object? DYN Replicated Object creates clientside physics. Sas awareness cant fix it.

cant think of a true way to misuse npcs. but the sweeping tests of character capsules seem (not 100%tested) to be truely serverside collision/physics. which indicates that serverside physics exists. my mentioned wiki pages enforce this. if this is the only way:

"The Physics Character functions create a PhysX Character Controller in the physics scene. The character controller is a generic approximation of a character's volume (box or capsule) that can be moved around the scene. The Character Controller, when told to move, will do continuous collision detection and handle wall-sliding, slope limits and steps. This is merely a collision detection system and not intended to mimic the precise movement of animated characters."

Anyone got a tiny idea, how to create a true serverside physics object in hsl?
Or is this only possible with sourcecode access?

A use of HE BoneTracker would solve this: http://hewiki.heroengine.com/wiki/Bone_Tracker_Node
You attach the Tracker to a Bone "say Bip01 Head" and then parent an Object to the Tracker.

But how to eval the absolute World Coords for an object that is a bit Ahead of the Character?
Until now, I couldnt find a correct calculation. Anyone got this sorted out?

Say you have the pos/rot of a Bone like "Bip01 Head".
Try to eval a newpos that is (0.5 range) towards rotation.
Is there any Vector Function that might help?

How would a true serverside physics object be "created" and "replicated" to all clients in HSL?
Are there any hints? A simple cube that is pushable and updated to all clients would be sufficient.

The Dynamic Replicated Object Tutorial
- has only a "HBnode" and "Physics" Properties on Clientside.
- If you move it, no other Clients gets the new Position.
   (This can be fixed, by updating the Position with a servercall that then updates SASAwareness Position)
   Yet this doesnt mean there is a true physic Object existing on Serverside.

I have asked some people and scanned the forum/wiki entries. Couldnt find any answers.
My best guess lies within the following "non working" serverside code.

Code: [Select]
  myphs as NodeRef of Class physicsinstance = $EDIT._CreatePhysicsInstance("default")
  myphs.PhysicsBeginAwake = "0"
  $EDIT._SetInstanceCreated( myphs, 0 )

Similar open, not resolved Topics:
Dynamic Physics replication

Playground Equipment Physics questions:


Scripting & Programming / Re: persistent asset inventories
« on: Nov 27, 13, 06:11:20 AM »
Am elaborating over the use of http://hewiki.heroengine.com/wiki/Arbitrary_Root_Node

It seems the ARN can be used to save persistantly position/rotation/ID of objects.
You can link the ARN to a player and access the information when needed.
Without having it in memory in other cases

Say if player enters the ARN connected "Area101"
-> load the ARN and create the objects on the stored position.
-> player can change/position/associations (ownership) to object
-> When Player leaves the objects should be persisted in db and "removed from gom"


...we strongly favor instead the use of the Arbitrary Root Node mechanism to create a root node that is in charge of persisting information about the player's customizations.

Scripting & Programming / Re: persistent asset inventories
« on: Nov 21, 13, 08:30:09 PM »
This might be the problem. Hard assocs between gom nodes can only be working if both (source/target) are persistant. Because they are loaded from DB. Only a node that has been persisted to DB can be loaded.

Yes, i see. Still i dont understand the reason and i mostly only use the "hard" assoc.
The only reason i see for "doubling" relationsship is the function queryassocs. (work with filters for quicker access) But i would love to see a HE Dev answer on this one.

c. inventory 2 area
that might be worth to investigate. maybe it happens in the background foundation classes. inventory as itemcontainer must be persistant and be "hard assoced" to some root node.

this means:
Normally a ContainerOwner is hard associated to the Container (Player-Inventory)
You could parent the area class with "_ContainerOwner" and than handle it.
 ... setContainerOwner(Area_Noderef). But i fear this isnt the intend way.

Scripting & Programming / Re: persistent asset inventories
« on: Nov 19, 13, 06:33:38 PM »
a. Only Derived from the error msg i guess one of the objects you try to hard_associate is not persistant.
    Be sure to use CreatePersistantNodeFromClass ...
b. Why use 4 associations? Arent 2 hard assocs enough?
    1. rootnode - object
    2. inventory - object   
    I often stumble over code pieces with "Multiple" Relationships between 2 identical objects. From an engineering viewpoint thats a strange thing in HE.
    Is it because you can access/query them faster?
    I used associations and mostly am fine with only the hard assocs. But maybe i miss the benefit of the 2nd soft assoc. In such a cases where objects are loaded with the area the hard assoc is fitting.
  If you d like to express the more "loose" kind of relationship, that doesnt require another node to be in gom,
  use the soft assoc. E.g. if you want to express that a object belongs to a guild. Still i dont see why using multiple relationsship between 2 identical source/targets.

    Remember you can define own association types. In this case i would brand the two associates with names like
    "ha_rootnode_object" + "ha_areainventory_object" and set them to unique source/multiple target/hard base kind.

A question:
How do you connect the inventory to the area?

As an last example i will post a code piece that creates a private Replication Group per Player.

There is a small addition that helped to reduce strange bugs.
In the Else Branch you add the current account to the replication Group.
Even though the RepGroup is exisiting. I have no idea why you need it, but without that line
cases happen, where the ClientDestination is null. Resulting in no replication.

Remember its useful for
db-persistant per player mutable data that needs to be updated to the client. E.g. experience per skill.
Of course you can choose to use the existing Public RepGroup at the player.  Or other ways as events or rpc.

Code: [Select]
  // In Serverside InitPlayerCharacter()

  // Init Private ReplicationGroup for Skill/Buffs/Tasks
  rg as NodeRef of Class _ReplicationGroup = me.Player_Private_RG
  if rg == None
    //println("Rep Group is beeing created")
    rg = createNodeFromClass("_replicationGroup")
   //println("Rep Group was exisiting!")
  foreach s in me.SkillList
    cskill as NodeRef of Class E_Skill = me.SkillList[s]
  me.Player_Private_RG =rg

I have scanned clean engine scripts to find the answers. Until anyone disagrees, i now assume that

1.  replication groups are intended to be non persistant.
Might be, because client connections and areas are shutting down/starting overtime and thus those groups become unneeded and would be a DB-Waste, because they would always need reinit.

2. the noderef to the group is saved with the _NPC/_PC
Didnt see a Iterator for Replication Groups and it seems better to have the noderef handy at each NPC/Char.


Found a thread that offers information about the subject as well.
I conculde, that a secondary replication group (with one client as reciever) is a normal design choice for private data. Even more, dont use the default replication group, as then all the private data is shared to others...

In the item example above, the details of your inventory may be public or private depending on the game design.
If it is public, you might as well simply add all of the items to the default replication group for a character.  If it is private, you might opt either to have a general private replication group in which you place all objects ...


GUI Creation / Re: Icons Drag and Drop
« on: Nov 09, 13, 06:39:48 AM »
Dont use "inherit". Neither in Class nor in GUI Prototype.
Use "parent classes" and overwrite any needed methods.
This eliminates a lot of error sources.

Now the discussion runs into the intended way.

>>I wouldn't think replication groups would go well for things like buffs.
I dont think rep groups are hard connected to "spatial awareness" and thus hopefully dont do spatial checks.
They might do it behind the scenes to do "priorization". I understood them as a general way of efficient network communication. Area bound, but normal GOM nodes themself. If there is only 1 recieving client in the rep group, why do any spatial checks?

>>But once again you aren't replicating data, you are just sending area based script events
Thats a design decision. Sending effects to players can be done via 3 methods "RPC, Replication, Events"
In your given situation I would
1. calculate serverside who is affected
2. use one of the three methods to send an "effect ID/impact info" to the affected clients

>> did the area go down, come up, is it a system area?
Here is the reason why i ask my question. IS a replication group node itself intended to be a "persistant" node or a "non persistant" node?

>>just hard to figure out without a tad bit more detail on overall system
I have information that needs constantly updating the client (experience on per skill base).
I used replication groups to achive this. Yet i am unsure, wether a replication group itself should be persistant.

I intend to use this replication group later for other information too:
Deliver information like "experience per skill, active tasks IDs, buffs IDs" to a client.

I could choose to pass this data in the playernode. But then the player attributes
would grow very long and i think the rep group of the player already does a lot behind the scenes (updateing hitpoints, player positions, player animations)...

Pages: 1 2 [3] 4 5 ... 8