DOM FAQ

From HEWIKI
Jump to: navigation, search

Contents

Is it possible to create DOM definitions without using the DOM Editor or CLI commands?

It is not currently possible to create DOM definitions without using the DOM Editor or CLI commands via the console. It is of course possible to add support to HSL to do so, its simply a matter of priorities and having a use case that justifies the effort.

Why can’t I change the type of a field in the DOM editor once it’s created?

It is not possible to change the type of a field once created. Allowing the type of a field to be changed would break the serialization of nodes in the database, and is therefore not permitted.

However, you may delete the current field and then recreate a new field with the same name and the desired type. This process results in a new field (with a new unique id) and thus does not interfere with the serialization.

How do I perform DOM Reflection?

The basic technique for DOM Reflection is now detailed here: DOM#DOM Reflection via HeroScript Language

In essence, you utilize the external functions for DOM Reflection to gather the classes comprising a node (GetClassesOnNode()), gather their parent classes(recursively) and for each of those classes get a list of their member fields. I have organized the (server) external functions script to have broad categories for the external functions, the section on DOM Reflection contains the external functions you need.

There is a special field collection for nodes, but it requires the programmer know exactly what they are doing to avoid script errors during use. We like to call it the "Trust Me I Know What I am Doing Field Collection". The tricky part of using the fieldCollection is that it requires you use appropriately typed variables when working with it based on the fieldtype and does not allow for any type of autoconversion.

// Assuming you have a list of fields for some node n
  foreach f in fields
    when getFieldType( f )
      is "string"
        s as string = n.fieldCollection[f]
        println( s )
        n.fieldCollection[f] = "someString"
      .
      is "integer"
        i as integer = n.fieldCollection[f]
        println( i )
        n.fieldCollection[f] = 1
      .
      is "float"
        f as float = n.fieldCollection[f]
        println(f)
        n.fieldCollection[f] = 2.4
      .
    .

Do we have to create our own DOM nodes or are these read-only parts of the HeroEngine artchitecture?

The DOM (Data Object Model) contains definitions that are created by default as well as those created for your Game-specific needs. DOM definitions created by default will, by convention, be named using a leading underscore "_" (In effect we reserve the leading underscore for our namespace) and will be marked as "Required" (or in some cases "Optional") in your Distribution Package. These definitions you may not change.

DOM definitions created by your own developers should not have a leading underscore, and will automatically be placed in the "Game" package. There is no reason to place game-specific DOM definitions in any other package than Game.

For more information, see HSL for programmers.

Are GOMs just data-populated, usable Instances of DOM nodes?

In essence, yes. GOMs contain instantiations of things defined by the DOM.

So in comparison to OOD terminology/thinking, is a DOM effectively a class and the GOM is an instanced object of that class?

A DOM definition for a class is roughly the moral equivalent, though a DOM definition does not allow for the specification of default values (the exception being prototypes which are kind of a special type of citizen). Additionally, you use the DOM to define things that are not classes, such as enumerations and associations.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox