Dynamic Creation Of Complex Nodes - Discussion

From Planimate Knowledge Base
Jump to navigation Jump to search
See also: Dynamic Object Creation And Deletion

Ideas for further thoughts.

One of the issues in automatically replicating a complex node (eg: a Unit or Location in a track network) is that subsystems within a copied node do
not get "global" identities - they are not added to the object list. Automatically doing so would be of little use, the model would be unaware of the new identities (object labels) of the node's subsystems.

One solution is to perform multiple passes of copying, building up the nodes at increasing levels of depth. This can require a complex co-ordination and centralised "builder'.

Instead, an approach is needed where nodes have meta-knowledge about their internal components. That way, a copied node will have a mechanism to identify its subsystems and share this knowledge with other interested objects.

(note that this is only an issue where a subsystem needs to be known externally. If it is wired into a flow and wont be directly referenced, it doesn't need to have a global identifier)

My idea is to make use of the scoping rules in enabling each node to have meta knowledge about its subsystems. It would work as follows.

A node, "A" contains subsystems "B","C" and "D" which need to be externally referenced (eg: to support them being configured or themselves pasted over,
a new feature just added).

Inside node "A" (and others like it) we have a table, called "Subsystems".This table contains 2 columns.

Upon initialisation of a new network, all "Subsystems" tables will first be
cleared, then a global broadcast is sent, say "Register". Upon receiving this BC, nodes "B","C" and "D" will insert a row into table "Subsystems" (owned by their parent) and insert the following information:


Column 1: Their global object identifier. I will implement a new routine operation to automatically create an object identifier for a
subsystem/portal if it does not already exist. This handles the copy problem.

Column 2: Their function code. This is a modeller maintained label list of sub system classes/functions. This will enable the parent node to locate what its subcomponents are and what their index is.

The modeller will have to allocate and set a function code for each subsystem type they build. Its really a "Portal Class".

Knowing what to do with given subsystem types (including multiple subsystems of a given type) will be the modellers responsibility and part of the logic of the owning node. However its a localised problem whose complexity will be determined soley by the complexity of that node and the configurations it supports.




idkbase note 60