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

Author Topic: Unique Areas, Glomming, Data Storage, Persistence, Etc. Questions  (Read 1581 times)

Hiro_Protagonist

  • World Owners
  • ****
  • Posts: 30
    • View Profile

Sorry for the crazy title, but I feel like I am RIGHT THERE with my understanding of HeroEngine, but no matter how many times I read the wiki I can't seem to put together a couple of last questions.

I have overridden the clean engine $AREA scripts by unglomming the E_Area object and adding my own MO_Area object. No problem, I understand that- all areas now have the code in our MO_AreaClassMethods script. Cool.

What I can't quite noodle out is how to override the code in a particular area. I have my SkillSystemArea, and I want that particular area to have it's own code (HE_PostOnAreaLoad, stuff like that), that overrides what is in the basic MO_Area script. If I glom a new class to that $AREA node, that area will get the new fields and the new script- pretty sure I understand that. But does that persist? If the area goes down, does it come back with the glommed class, or do I need to re-glom it every time? If I do need to re-glom it, is there a good pattern for this? Currently, I have in the MO_AreaClassMethods:HE_PostOnAreaLoad code something that looks like this:

if area.ID = MY_AREA_ID
  glomClass("SkillSystemArea", area)
.

This just doesn't seem like a good way to do this*.

Next, after I glom the class on, does the glommed class override the callbacks? For instance, can I define my own HE_PostOnAreaLoad function in SkillSystemAreaClassMethods? Do both functions get run, or does one take precedence? And if there is precedence, how is it decided? I get how glomming works vis a vis fields and the flat namespace.

I have been trying to figure this out via the clean engine Chat, lobby and social systems, but they have quite a bit going on and I'm still not sure how the _SocialSystemArea makes contact with the code in _SocialSystemClassMethods - there is the $_SOCIAL system node that the world and area scripts call on, but how it is populated I still don't quite understand.


* Separate question:  There seems to be a lot of times in the engine were I need to run some bit of HS just once- glom a class onto a persisted node, or changing the data in a prototype for instance. What do people generally use to accomplish this? The tutorial videos seem to make use of Chat commands inside a throwaway class- is this normal, or is there a better way, or is it really that if you are writing one-time only code you are doing something wrong? Or is it that I really just need to learn the CLI and do it that way?

Thanks everybody for your patience- I think I just about get it, and once it clicks I'll be good to go.
Logged

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.

Quote
If the area goes down, does it come back with the glommed class, or do I need to re-glom it every time?
Yes, I believe you would need to re-glom it, since system nodes are never persistent.

But I also do not think that is necessarily the best approach.  Does it really need to be on the Area Node?  You could make a prototype of the SkillSystemArea class and then use it directly as its own system node.



Quote
can I define my own HE_PostOnAreaLoad function in SkillSystemAreaClassMethods?
For what you described, no.

As per the HeroWiki section on Class inheritance and methods:
Quote
A node is of one class and another class is GLOMmed on to it...in [that] case... if more than one class specifies the same Method then the results would be unpredictable... which one should you call? Since there is no clear answer to that, it is considered an error and a script error results when you try to call the method (and eventually during run-time during the GLOMming ).

So between the base class of a given node and all of the classes glommed onto it, only one may define a given method.
« Last Edit: Feb 09, 14, 02:41:08 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.

Also, when an area instance first spins up, the Clean Engine code checks for Area-specific setup by examining the instance's AreaRoot node (different from the $AREA system node).  I am not logged in at the moment, so I can't recall exactly how that goes, but that could be worth exploring.  I believe you basically glom a class onto the AreaRoot, which is persistent and put the area-specific code in a method of that class.
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile

I think we used the association concept.
You create an own class, make a persisted node out of it and "hard link" it to the area root.
Thus you dont have method collisions.

>>
Storing the data in a node requires that you; Instantiate a persisted node from a class containing the field(s) you need to store your data and associating that node to the area root node in the EDIT instance of your area. The node(s) must be associated to the area root with at least a base_hard_association and may optionally have additional soft associations to facilitate querying for the node(s). Using nodes to store the data has an advantage over storing the information in a class GLOMmed on, in that you may have multiple nodes to store data should your system require them.
Logged