Tuesday, December 13, 2011

This is what I am thinking on...

So I don't think I was quite clear on my variable issue normally when parsing in the variable by a string you would use:


but that only works if the variable is in the local this. Most of my variables are in classes like player or data.

so i can parse in variable and do


but that means I have to know that the variable is in the data class but what if its in the player class...

player[variable]... instant crash

parsing in "data.variable"

even if we import data.*;

then go with

this[data.variable]... instant crash

but there has to be a way to parse in both data and variable and then set up


from the parse.

My current idea that is UNTESTED is to send the base stage into the class and then try


I wonder if that will work...



  1. Before going any further, it might be worth taking a step back to think about what, exactly, it is that you're trying to do, because it sounds like thing are starting to get a little too abstracted and overly complicated.

    Does this event system need access to every variable, or could you pare that down to a subset of important values that can be put in one place? It kind of defeats the purpose of permitting XML scripting, if you need to understand what all of the variables are doing, under the hood, anyway.

    Failing that, could you split the functionality into a few key classes? I understand not wanting to do a separate routine for every class in the game (it'a horrible idea), but you shouldn't have to. First of all, not every class will be important to the event system. Secondly, as I said, having to know what all of the variables are and where they're located kind of defeats the purpose of permitting people to write these things in XML, in the first place. If you can pare it down to 2 or 3 special cases though, breaking an overly complicated piece of code into smaller, more manageable chunks, it might be worth a shot.

    There might even be another solution, entirely. You understand what you're trying to accomplish better than anyone, but it's definitely starting to sound like it might be time to take a step back, take deep breath, and reevaluate the situation, because it certainly starting to sound like you're beginning to make things tougher than they need to be.

    That said, if you're certain this is the best approach, you could possibly try:

    or, since I included the document class (Main) for the main fla file, you could try using Main.instance to reference the main stage, allowing you try something like:

    (If it's a separate fla file, you could simply create a document class for that one and try something along the same lines.)

    I have no idea if it will work, but it's probably what I would try, if I couldn't find a better approach.

  2. Sorry for the monster comment. I hadn't realized quite how long it was until I saw it all written out, here.

  3. I think compuscribe has some good points. However, I just went ahead and tried some stuff:

    var foo0:String = "thing";

    trace("1: " + this["foo0"]);

    var bar0:Object = new Object();

    bar0["baaz"] = "quux";

    trace("2: " + bar0["baaz"]);

    trace("3: " + this.bar0["baaz"]);

    trace("4: " + this["bar0"]["baaz"]);

    var xyzzy0:String = "bar0";
    var plover0:String = "baaz";

    trace("5: " + this[xyzzy0][plover0]);


    1: thing
    2: quux
    3: quux
    4: quux
    5: quux

    So, yeah. It works.

  4. Good suggestions thanks compuscribe and John.


  5. An approache with virtual inheritance. In actionscript this is done with interfaces