HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.
Pages: 1 [2]

Author Topic: Social System Issues  (Read 6947 times)

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: Social System Issues
« Reply #15 on: Jul 03, 13, 11:45:18 AM »

Not really expecting a response, per se.  Just noting things I found as I explored it.  Eventually I presume that the fixes will go into a patch, but in the meantime others who use it can put in the fixes themselves.  Just make note of the changes you make to clean engine scripts so those changes can be restored if a release overwrites them.
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

MarlonB

  • General Accounts
  • *
  • Posts: 38
    • View Profile
Re: Social System Issues
« Reply #16 on: Jul 05, 13, 03:01:14 AM »

As a customer you should be expecting one ;)

Something in the line of .. "we acknowledge the issues you mentioned (or not) and are working on a fix to be released in patch xxxx".
This way we at least know what to expect and that it's being dealt with.

1.5 months with no response at all .... is worrying at best.
« Last Edit: Jul 05, 13, 03:04:36 AM by MarlonB »
Logged
Cerberus of The Repopulation.

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: Social System Issues
« Reply #17 on: Jul 05, 13, 06:07:01 AM »

True, but moving it to the "Issues Being Investigated" category is basically saying that, so I am not too worried about it, particularly since we have access to the script code and can change it.  If it was in the source code that would be different.
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: Social System Issues
« Reply #18 on: Jul 12, 13, 01:02:43 PM »

#13 Method suggestion

In server _LobbySystemClassMethods the function EventRaisedNotify() calls HE_LobbySystemEventRaisedNotify if it is defined allowing us to respond to events ourselves.  It will be helpful to have a similar override in _SocialSystemClassMethods EventRaisedNotify.

In fact, if HE_LobbySystemEventRaisedNotify were simply changed to HE_SystemEventRaisedNotify, then that same method could be glommed onto any of these systems and be ready to work.
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: Social System Issues
« Reply #19 on: Jul 17, 13, 12:37:27 PM »

#14 Probable Algorithm Mistake
Important because public data object ref counts determine when they are unloaded (i.e. when the count goes to 0).

In server _SocialQueuePublicDataNode method _RootNodeLoadedNotification() there is the following code for replacing a persistent data node with a non-persistent one, or vice versa:
Code: [Select]
  // Restore the social public data object
  if(me._socialStringStatus == "swap")
    // Set the previous ref count
    social_public_data_object._SetSocialRefCount(me._socialSysRefCount)
   
    replication_group as NodeRef of Class _ReplicationGroup = social_public_data_object._GetReplicationGroup(true)
    // Replicate back to each target
    foreach destination in me._socialSysDestinationList
      replication_group._AddClientDestination(destination, destination)
    .
  .
 
  //Increment the ref count
  social_public_data_object._IncrementSocialRefCount()
The problem is the last line.  Since the ref count for a swapped node is set explicitly by _SetSocialRefCount(), the count should not be subsequently also incremented.

So I believe it the increment should be in an "else" block, i.e.
Code: [Select]
  // Restore the social public data object
  if(me._socialStringStatus == "swap")
    // Set the previous ref count
    social_public_data_object._SetSocialRefCount(me._socialSysRefCount)
   
    replication_group as NodeRef of Class _ReplicationGroup = social_public_data_object._GetReplicationGroup(true)
    // Replicate back to each target
    foreach destination in me._socialSysDestinationList
      replication_group._AddClientDestination(destination, destination)
    .
  else
    //Increment the ref count
    social_public_data_object._IncrementSocialRefCount()
  .

***EDIT:
After testing this I found one more wrinkle to this.  Not incrementing the ref count when swapping is not always correct; it depends on whether the swap is persisted-to-copy or copy-to-persisted.  This is because for the first one, that happens in method _UnloadSocialPublicDataObject() which calls _DecrementSocialRefCount() prior to calling for the swap.  In that case, the ref count is already correct, so we don't want to increment after the swap.

However, when _LoadSocialPublicDataObject() calls for a swap from copy to persisted, it does not have an increment call, and so it would need an increment later.

To resolve this, I kept the skipping of increment after the swap is loaded, and for the copy-to-persisted swap call in _LoadSocialPublicDataObject(), I increment the value stored in me._socialSysRefCount, i.e.
Code: [Select]
      #if debug
        dbgmsg += "Current Public Data Object is not persisted, unloading and replacing$R"
      #endif
     
      me._socialStringStatus = "swap"
      me._socialSysLoadNodeCopy = false
      me._socialSysRefCount = social_public_data_object._GetSocialRefCount()

becomes

Code: [Select]
      #if debug
        dbgmsg += "Current Public Data Object is not persisted, unloading and replacing$R"
      #endif
     
      me._socialStringStatus = "swap"
      me._socialSysLoadNodeCopy = false
      me._socialSysRefCount = social_public_data_object._GetSocialRefCount() + 1



TLDR: An alternative which may well be easier than all of the above is to forgo both the skipping of increment after loading and the incrementing of the ref count in _LoadSocialPublicDataObject().  Instead, the original Clean Engine code may be changed to simply decrement the ref count stored in me._socialSysRefCount for _UnloadSocialPublicDataObject().

Code: [Select]
        // replace with a copy
        me._socialStringStatus = "swap"
        me._socialSysLoadNodeCopy = true
        me._socialSysRefCount = social_public_data._GetSocialRefCount()

becomes

Code: [Select]
        // replace with a copy
        me._socialStringStatus = "swap"
        me._socialSysLoadNodeCopy = true
        me._socialSysRefCount = social_public_data._GetSocialRefCount() - 1

That will compensate for the increment later when the swap node is loaded, while still keeping that later increment in place for the copy-to-persistent swap.

I hope that makes sense. ???
« Last Edit: Jul 17, 13, 01:21:19 PM by ScottZarnke »
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.
Re: Social System Issues
« Reply #20 on: Jul 26, 13, 11:25:07 AM »

#15 Issue with loaded public data not subscribing.

I have a Friends social circle set up for each of our characters and adding and removing works just fine.  For display, I am reading the circle's _socialCircleIDIndex and then reading each node from those IDs, counting on them being replicated to my client.

However, I had been having a problem with not all of the public data objects for my circle being replicated to my client all the time.  Usually this was after closing the client and re-entering the world.  After that, if I returned to the character select screen and re-entered the game from there, the dataobects would be on my client.

I realized the key difference was in how method _LoadSocialCircleContents() of the social circle class works:  For each ID in _socialCircleIDIndex, if it is already loaded, it subscribes the client to it (which replicates it to the client).  If the node was not yet loaded, it requests it to be loaded as a copy.

In _SocialPlayerCharacterPublicDataObject method _SocialPublicDataObjectLoaded(), it was testing whether the newly loaded data object was a copy or not, and then only subscribing the client if it was not a copy.  Hence, when social circle contents are loaded and the objects were not previously loaded, they do not get replicated to the client due to being copies.

If I re-enter with the character without closing the client, it tries again to load the circle contents, but this time they are all loaded, so it goes ahead and subscribes them all.



At first I tried to make it work by changing _SocialPublicDataObjectLoaded() to do the subscription every time, even for data object copies.  I did keep the copy-check in place for the other part about setting Online status to true.  That part makes sense because the only time a data object is loaded as a persistent non-copy is when the anchor for it is loaded, which means the character is logged in.  So inside of _SocialPublicDataObjectLoaded(), being a non-copy is a flag that the character is online, being a copy means they are not.

However, that was wrong: I realized that the subscription which is being done in _SocialPublicDataObjectLoaded() is for the client of the anchor of this data.  In other words, it only subscribes the new data when it is the owner loading it.  Hence, having it inside of the copy check as it originally was is correct, and there is not a good way to handle subscribing another client in that function.

I believe the key is in method _RootNodeLoadedNotification() of _SocialQueuePublicDataNode.  It needs to be marked with the ID of a requesting client for when there is one, such as in loading circle's contents or add a connection to a circle.

My approach was to create a child class derived from _SocialQueuePublicDataNode and added an ID field for the requesting client.  Next was to create a method in my $_SOCIAL override node that requests to load a social public data node.  It is the same as _RequestLoadSocialPublicDataObject(), except it also requires a requesting client ID argument.  Then everywhere that _RequestLoadSocialPublicDataObject was called, I replaced each of those with a call to my method, supplying the requesting client ID.  Finally, in the _RootNodeLoadedNotification() override method in my SocialQueuePublicDataNode class, when the node is loaded right after calling social_public_data_object._SocialPublicDataObjectLoaded() I check if the requesting ID is not 0.  If so, that client is subscribed to the public data object.

Now, all of the public data objects of a friends circle are replicated to the client each time that character logs in.



Sorry for the long post, again, but the above was needed to get this part of the system working properly.
« Last Edit: Jul 26, 13, 12:54:15 PM by ScottZarnke »
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

Irushian

  • General Accounts
  • *
  • Posts: 44
    • View Profile
Re: Social System Issues
« Reply #21 on: May 12, 15, 03:27:14 PM »

This has been noted under "issues being investigated", though it has been an extremely long time without a single HE dev post regarding it.

Scott has done a lot of testing with this, and also offered some decent feedback with it, it'd be nice to hear from some of the HE devs regarding this foundation framework, and especially these noted issues.
Logged
Pages: 1 [2]