Will GLOMming work with a replication class?
GLOMming replicated classes onto the server's representation of an Asset Instance will have undefined behavior depending on when replication is started to a destination client. An Asset Instance (i.e. part of the area's geometry) is introduced to the client via the Repository/Local Repository Cache when the area's .DAT files are read, consequently depending on timing replication could potentially attempt to GLOM class on to the node before it was constructed properly via the expected mechanism (which would cause a node to be created from the default base class _object, but not spin up the necessary C++ class to back it) resulting in undefined behavior.
There are a couple of ways you could do this, the most common implementation for objects people click in games is essentially described in the replication tutorial (Replication Tutorial). This walks you through the introduction of an object via replication and the instantiation of an asset instance (the visualization) through a prop bucket. Assuming the classes you GLOM onto the replicated object also are set up with replication definitions then those classes will also be on the client object. When you instantiate the prop, you would notify the classes that make up your replicated object and provide them the opportunity to GLOM stuff onto the prop instance (such as highlight when moused over behavior).
One issue with the route described by the replication tutorial is that it requires you do some HSL work to support editing the object via HeroBlade's tools (such as changing its position). In essence, you add a class to the prop bucket instance when it is selected via a heroic mouse event which you catch in $INPUT's HE_HeroicOnMouseClick() (or other heroic mouse events) and update the server object with position/rotation changes...as well as any other properties you wish to expose. The class contains a timer that checks to see if the node is still selected...and if not sends the update.
An alternative to the method described in the replication tutorial would be communicating a list of IDs to the client either during login, or via files stored in the repository (on a per area basis probably) which when received you GLOM on your class to the nodes specified. This list could be derived from a new association that your code could use to gather a list of the nodes (associations can be added using the library command /heassociations $ASSOCIATIONS, though there is a bit of work you would need to do to shift the association from a system node which is not persisted to one of the nodes in the area hierarchy. This is accomplished via a shared function in the system node's class.)
Why are my replication callbacks not being triggered when GLOMming while using a replication class?
A system node is represented by a unique, nonpersisted, singleton instance that is instantiated automatically by the engine the first time an attempt to reference it is made in script. Consequently (and by design), the ID of a system node will be different in every GOM in which it is instantiated. Fortunately, you do not need to know the ID because you have a convenient syntax in HSL to find the local singleton ($NAME).
It is also by design that the node instantiated to represent a spatial awareness system is not persisted. As you discovered, you do need to add routines to add any entities you want to have represented in the default area spatial awareness during area spinup (or some other time as is appropriate for a particular game system). Typically, you the introduction of spatial entities for objects that are a part of area is done during area spinup as you implemented.
Callbacks for replication are made to the "primary" node of the replication group. If you are not getting any callbacks, the first thing to do is to check what node you have as the primary node. Verify that the class(es) that make up your primary node have destination classes specified for replication. If the primary node is a system node, then you will never get any callbacks as the IDs of system nodes are different in every GOM (i.e. the server's ID is always different from your local client's ID for a given system node).
Another possibility is that the replication traffic is arriving before the AssetInstances are instantiated. Your primary node should verify the existence of the AssetInstance to which you intend to add class(es) to and if it is not found then it will need to retry at a later time. Asset Instances are actually instantiated when the Room in which they reside is activated, so it is quite possible to have instances that are introduced at a point later than when replication introduces the secondary node depending on the awareness ranges you have specified for the entities involved.
For systems like this, I generally have a "root" (which for the sake of dicussion I am going to call the HighlightableRoot) which is created as a persisted node (if instantiated in the edit instance) and hard associated to the AreaRoot. All highlightableObjects are then created as persisted nodes (if instantiated in the edit instance) and soft associated to the Hightlightable root and hard associated to their AssetInstance. Using this structure (hard associated to the AssetInstance) ensures that if the AssetInstance is deleted then its Hightlightable object is also deleted (by virtue of the hard associatiation). The soft association to the "root" allows you to query and find all of these objects during area spinup so you can add entities to spatial awareness at the position of the AssetInstance.
The required engine class InstanceClassMethods forwards spatialawreness events to shared function calls on the instance so you can GLOM on helper classes to the AssetInstance to foward those events to your highlightable object if you desired. Additionally, shared function class are made when the AssetInstance's position or rotation is adjusted allowing you to catch those changes and adjust the spatial entity's position if you desire.
When GLOMming a class on a trigger node, how do I retrieve the name of the trigger?
myName as string where me is kindof TriggerInstance myName = me.name .
Now, while munging a name will work, it is recommended that you add a field questSpecKey to your GLOM class and simply set and use that field's value. Using the name field has a significant disadvantage in that it is easily changed using the Properties panel and you are relying on your designers to not mess with it.
The button on the DOM Editor is there to simply provide you an alternate method of adding a class to an instance, ultimately it is issuing CLI commands just like you can via the Console Panel. While both the button and CLI commands are useful for development, HSL is much more commonly the mechanism used for actual game systems and/or objects that require GLOMming. The spec system is one of the most common ways that GLOMming occurs, and "smart objects" created from the library are another.