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

Author Topic: [Resolved] Access logs ...  (Read 2764 times)

gregoberfield

  • World Owners
  • ****
  • Posts: 10
    • View Profile
[Resolved] Access logs ...
« on: Jul 07, 10, 11:20:14 AM »

Simu-folks,

Are the access logs for which accounts log in (and possibly log out) stored in the DOM somewhere or anywhere else we would have access to them?  Or are we expected to write that into our game servers via HSL and the DOM?  Just trying to figure out what our limitations are for pulling data.  I don't want to write HSL for someone that is probably already logged somewhere else.

-G
« Last Edit: Nov 01, 12, 08:50:19 AM by HE-Cooper »
Logged

HE-CHRISTOPHER

  • HeroEngine
  • *****
  • Posts: 424
    • View Profile
Re: Access logs ...
« Reply #1 on: Jul 07, 10, 02:10:38 PM »

While this particular information is recorded, it is not at a level that is available to HeroScript.  Ultimately, logging of in-game events is something that you must address in a manner that satisfies the design requirements for your game. 

Storing log information in the GOM is one way you might choose to handle logging, though designs that require external access to the data more global types of queries would probably not be satisfied with the data living in the GOM.

If you choose to store the log information in the GOM, it is strongly recommended that it not be stored as a part of the character's hierarchy (so they do not carry that mass of data around with them as they transition from area to area, or load into the game).  Rather, utilize the capabilities of Arbitrary Root Nodes to offload the load/processing/queries into one or more system areas.

https://wiki.heroengine.com/wiki/Arbitrary_Root_Node
https://wiki.heroengine.com/wiki/System_Areas

Another possibility is through the HeroScript Extension Interface, but this is a feature that is not exposed to HeroCloud users at this time.

https://wiki.heroengine.com/wiki/HeroScript_Extension_Plugin

Recommended Features:
  • Logging exposed through an interface (a system node)
  • Asynchronous (both generating logs and querying them)
  • Log data is not part of the character hierarchy (either Arbitrary Root Nodes, or other external systems)
  • Utilize a Logging Service (system area) to which logging is submitted

Gotchas:
  • Understanding the fundamental uncertainty of "simultaneous" events in a massively parallel architecture spanning multiple physical machines
  • Consider the volume of logs generated by your systems
        Is there a potential need for multiple services (additional areas) to handle load
        Communication overhead, do logs need to queued/batched
        Memory, how much and for how long will data be retained.
~Christopher
Logged
Christopher Larsen
CTO
HeroEngine

cheyennecloud

  • General Accounts
  • *
  • Posts: 10
    • View Profile
Re: Access logs ...
« Reply #2 on: Jul 07, 10, 03:28:07 PM »

Another possibility is through the HeroScript Extension Interface, but this is a feature that is not exposed to HeroCloud users at this time.

https://wiki.heroengine.com/wiki/HeroScript_Extension_Plugin


You mean not exposed at the server level, right?  Extension is available on the client level, correct?  Not that it would help in this topic but just wanted to get clarification since I'm depending on the feature.

(Sorry if I'm hijacking the thread)
Logged

HE-CHRISTOPHER

  • HeroEngine
  • *****
  • Posts: 424
    • View Profile
Re: Access logs ...
« Reply #3 on: Jul 07, 10, 04:19:15 PM »

You mean not exposed at the server level, right?  Extension is available on the client level, correct?  Not that it would help in this topic but just wanted to get clarification since I'm depending on the feature.

Correct, the ability to write client extensions is exposed.  With regard to server extensions, we looking at various ways to expose the capability (but it is not currently exposed).

~Christopher
Logged
Christopher Larsen
CTO
HeroEngine

gregoberfield

  • World Owners
  • ****
  • Posts: 10
    • View Profile
Re: Access logs ...
« Reply #4 on: Jul 08, 10, 09:04:58 AM »

While this particular information is recorded, it is not at a level that is available to HeroScript.  Ultimately, logging of in-game events is something that you must address in a manner that satisfies the design requirements for your game. 

Storing log information in the GOM is one way you might choose to handle logging, though designs that require external access to the data more global types of queries would probably not be satisfied with the data living in the GOM.

If you choose to store the log information in the GOM, it is strongly recommended that it not be stored as a part of the character's hierarchy (so they do not carry that mass of data around with them as they transition from area to area, or load into the game).  Rather, utilize the capabilities of Arbitrary Root Nodes to offload the load/processing/queries into one or more system areas.

https://wiki.heroengine.com/wiki/Arbitrary_Root_Node
https://wiki.heroengine.com/wiki/System_Areas

Another possibility is through the HeroScript Extension Interface, but this is a feature that is not exposed to HeroCloud users at this time.

https://wiki.heroengine.com/wiki/HeroScript_Extension_Plugin

Recommended Features:
  • Logging exposed through an interface (a system node)
  • Asynchronous (both generating logs and querying them)
  • Log data is not part of the character hierarchy (either Arbitrary Root Nodes, or other external systems)
  • Utilize a Logging Service (system area) to which logging is submitted

Gotchas:
  • Understanding the fundamental uncertainty of "simultaneous" events in a massively parallel architecture spanning multiple physical machines
  • Consider the volume of logs generated by your systems
        Is there a potential need for multiple services (additional areas) to handle load
        Communication overhead, do logs need to queued/batched
        Memory, how much and for how long will data be retained.
~Christopher

Chris - in-game events I knew we had to script for (although putting that into the GOM seems a tad silly since a server reboot will wipe all that data out won't it as the GOM is memory resident unlike the DOM).  However, getting account login/logout entries is not something we should have to script for - we should be able to grab that data in some way since I know you guys keep it.  Maybe even exposing it through the account website here for the access logs so we can download and parse.

Thanks,
-Greg
Logged

mdunham

  • General Accounts
  • *
  • Posts: 2
    • View Profile
Re: Access logs ...
« Reply #5 on: Jul 08, 10, 04:18:43 PM »

I have to agree with Greg, it would be a nice feature ;)
Logged

HE-CHRISTOPHER

  • HeroEngine
  • *****
  • Posts: 424
    • View Profile
Re: Access logs ...
« Reply #6 on: Jul 08, 10, 04:23:16 PM »

We should be able to grab that data in some way since I know you guys keep it.

It is not stored in a fashion that can be exposed at this time.


Chris - in-game events I knew we had to script for (although putting that into the GOM seems a tad silly since a server reboot will wipe all that data out won't it as the GOM is memory resident unlike the DOM).

Allow expound upon the environment slightly...

The GOM (Game Object Model) contains instantiations of DOM (Data Object Model) definitions, those instantiations are persisted based on the following:

  • Instantiations are created as persistent or non-persistent (e.g. CreatePersistedNodeFromClass() vs CreateNodeFromClass())
  • Persistent instances ARE persisted in the database
  • Non-persistent instances do not persist and cease to exist at process termination (the database never knows anything about them)
  • Updates to the database for persistent nodes is done based on the Write Strategy for the modified field(s) as defined in the DOM (https://wiki.heroengine.com/wiki/Write_strategy)


So, that covers persistent of GOM instantiations...now what?  Persistent instantiations are stored and loaded from the database:

  • HeroScript has the ability to load special instances called "roots" from the database (accounts, characters, areas and arbitrary roots).
  • When a root is loaded, all instantiations associated to it via a "hard" association are loaded with it. (a character, its inventory, spells, quests, etc)
  • HeroScript can not load non-root persistent nodes, consequently creating a persistent node but not associating it to a root results in a "orphaned" node in the database.  It exists, but there is no way to load it.

So, ultimately if you wish to persist GOM information...
  • Create a persistent instance
  • Either make it a "root" or associate it (via a hard association) to an existing root

If you wish to persist GOM data with an area you can do so by hard associating it in the EDIT instance of the area to the area's root node (GetRootNode()).  Please note the difference between PLAY instances and EDIT instances is important here, associating persistent nodes in a PLAY instance to the area root results would result in orphaned nodes in the database (consequently a script error will occur).

For something like logging, should you choose to utilize the GOM then we would recommend the data be associated to a character's "logging root node" (i.e. a child root node of the character root).

See Also:
https://wiki.heroengine.com/wiki/Data_storage
https://wiki.heroengine.com/wiki/Arbitrary_Root_Node



~Christopher
Logged
Christopher Larsen
CTO
HeroEngine

gregoberfield

  • World Owners
  • ****
  • Posts: 10
    • View Profile
Re: Access logs ...
« Reply #7 on: Jul 08, 10, 07:06:14 PM »

Hmm - for some instance I thought GOM was memory resident only and not persisted.  Confusion on nomenclature there on my part.

I just need to keep in my head that (basically, not perfect, but basically) DOM is the schema and GOM is the data.

As for the server logs - feature request! :)
« Last Edit: Jul 08, 10, 07:40:40 PM by gregoberfield »
Logged

davec

  • General Accounts
  • *
  • Posts: 1
    • View Profile
Re: Access logs ...
« Reply #8 on: Jul 09, 10, 03:55:04 AM »

I have to agree with Greg, it would be a nice feature ;)

agreed.
Logged