Scroll: Non-explicit binding?

edited June 2013 in Help request
I know I can use the "BindObject" tempalte to bind a ScrollObject class to a given config section, then explicitly invoke "CreateObject."

However, since I'm using generated maps, I'd like to automatically create ScrollObjects like this:

1) On startup, scan all config sections, looking for a key named "ScrollClass", and use the string specified to bind that object to a class.

2) When creating an object from config, I'd like any sub-object created that is already bound to instantiate it's bound ScrollObject. It appears that creation of a ScrollObject is limited to the top-level config section named when using "CreateObject."

On a given map, I have sensors that I'd like to bind to ScrollObjects in a data-driven way, rather than hard-coding the binding.

Comments

  • edited June 2013
    epoulsen wrote:
    1) On startup, scan all config sections, looking for a key named "ScrollClass", and use the string specified to bind that object to a class.
    This will be a bit more tricky. You can't map a string to a class, you need to actually use the class typename when calling ScrollBindObject<ClassName>("Section");
    However if you mean that you will iterate through all your C++ classes and then for each of them scan all sections in order to find a given keyword, then that would work. I do it slightly differently myself, cf. end of this post.
    2) When creating an object from config, I'd like any sub-object created that is already bound to instantiate it's bound ScrollObject. It appears that creation of a ScrollObject is limited to the top-level config section named when using "CreateObject."
    That should already be the case. As soon as the bindings are done, no matter how orxOBJECTs are created(orxObject_CreateFromConfig(), Scroll::CreateObject(), ChildList, Spawners, ...), if they are bound to a ScrollObject, the C++ class will be instantiated and both instances will be bound.
    If it's not the case, it's a bug and I'd appreciate a test case for repro as I haven't experienced it.
    On a given map, I have sensors that I'd like to bind to ScrollObjects in a data-driven way, rather than hard-coding the binding.

    The way I usually do it in my own games is that, for each class, I keep list of objects in config. In code I fetch that list and bind all the sections to that class.

    Now, that being said, there would be a way to modify how binders work, associate a class name to them and store their instance in a table. However that'd break the way bindings in Scroll are currently being used, so I need to think about it more.
  • edited June 2013
    This will be a bit more tricky. You can't map a string to a class, you need to actually use the class typename when calling ScrollBindObject<ClassName>("Section");
    However if you mean that you will iterate through all your C++ classes and then for each of them scan all sections in order to find a given keyword, then that would work. I do it slightly differently myself, cf. end of this post.

    It's not a big deal; I'll just create a binder class that "knows" about all of the possible classes to bind. I'm just spoiled by the easy introspection provided in Python.
    2) When creating an object from config, I'd like any sub-object created that is already bound to instantiate it's bound ScrollObject. It appears that creation of a ScrollObject is limited to the top-level config section named when using "CreateObject."
    That should already be the case. As soon as the bindings are done, no matter how orxOBJECTs are created(orxObject_CreateFromConfig(), Scroll::CreateObject(), ChildList, Spawners, ...), if they are bound to a ScrollObject, the C++ class will be instantiated and both instances will be bound.
    If it's not the case, it's a bug and I'd appreciate a test case for repro as I haven't experienced it.

    I'm seeing this when binding a ScrollObject to a config BodyPart.
  • edited June 2013
    epoulsen wrote:
    It's not a big deal; I'll just create a binder class that "knows" about all of the possible classes to bind. I'm just spoiled by the easy introspection provided in Python.
    if you do the bookkeeping yourself, then there's no problem.
    I'm seeing this when binding a ScrollObject to a config BodyPart.
    ScrollObjects can only map to orxOBJECTs. There wouldn't be any sense to map to anything else as none of their method could be applied. I'm not sure what you're trying to achieve there.
  • edited June 2013
    ScrollObjects can only map to orxOBJECTs. Therre wouldn't be any sense to map to anything else as none of their method could be applied. I'm not sure what you're trying to achieve there.

    I thought about this a bit after my last post, can pretty much came to this concusion.

    Not so much trying to "achieve" anything so much as quirks in how I create map .INI files.

    Presently, if the mapgen identifies an object as being a "physics" object (either wall or sensor), the resultant map.INI looks like this (simplified for clarity):

    [object.map.meta]
      ObjectName = object.maptest1
    
    [object.maptest1]
      Body = body.maptest1 ; <-- this is where all physics objects are lumped together
      ChildList = object.back-water # object.back-test # object.fore-rocks; <-- graphical elements
    
    [body.maptest1]
      PartList = bodyPartrect3762 # WaterSensor
    

    Essentially I need one object per body + bodyPart for physics elements, so I can bind them to ScrollObjects:
    [object.map.meta]
      ObjectName = object.maptest1
    
    [object.maptest1]
      ChildList = object.back-water # object.back-test # object.fore-rocks # object.bodyPartrect3762
    
    [object.bodyPartrect3762]
      Body = body.bodyPartrect3762
    
    [body.bodyPartrect3762]
      PartList = bodyPartrect3762
    
  • edited June 2013
    Ah, I see. Yes, in that case you need to do it this way, using orxOBJECTs as base elements.

    If you go with single part bodies and want a slightly less verbose format, you can do something like this:
    [object.map.meta] 
      ObjectName = object.maptest1 
     
    [object.maptest1] 
      ChildList = object.back-water # object.back-test # object.fore-rocks # bodyPartrect3762 
     
    [bodyPartrect3762] 
      Body = @
      PartList = @
      ; Defines the part here as well
    
Sign In or Register to comment.