No announcement yet.

global variables are not really global.

  • Filter
  • Time
  • Show
Clear All
new posts

    i hope it's not silly, and I wish it was not needed. there must be a simpler way for the Cars to read a variable from one singular object, and then write to it. If not, then Uscript has some serious problems.

    (my level does have thousands of actors)


      Thousands of actors, or thousands of cars? Big difference.

      As for reading from one location, yes uscript can easily do that. But its how you are implementing it that is impossible.

      If you put your variable in the GameInfo (for example), any actor in the level can get to it via MyGameInfo(Level.Game).MyVariable. They will all read/write the same variable.

      But if you expect every pawn in the game to have the same Weapon variable point to the exact same object, you're just being silly.

      All you need in your function is this:

      Foreach AllActors(class'carState',CS)
      if (CS == None)
      	CS = Spawn(class'carState');
      It will only spawn ONE car state, every other car will use that one.


        thousands of actors. not cars.

        but hey, It works! I used your GameInfo suggestion.


        you can refer to the GameInfo's 'var int myState' variable just like this from anywhere!(as you already know). Yayyyyy:up:

        thanks for all your help.

        All also learn more about the AllActors syntax for the cases where above isn't applicable.


          I think your Pizza example clearly demonstrates your misunderstanding of the class hierarchy.

          Pepperonis are not pizzas!

          There are two concepts in programming you are confusing:
          1) Inheritance.
          2) Composition.

          Inheritance expresses an "is-a" relationship. As in:
          "a Pepperoni and Olive Pizza is a Pizza".
          This concept is useful for subclassing (making classes that are either more specific versions of their superclass (avoid the term "parent" in this context!), or in the case of Unreal, it is often used to make classes that have slightly different parameters than their superclasses.

          The code:

          class PepperoniAndCheesPizza extends Pizza;

          is an example of Inheritance.

          Composition expresses a "has-a" relationship. As in:
          "a Pepperoni and Olive Pizza has Pepperonis and Olives."
          This concept is useful for *instances* of some class that contain references to other instances (of other classes or even of the same class [e.g. linked list nodes point to other linked list nodes]). Sometimes the containing class/instance is called the parent, but only when the composition is also best thought of as a parent-child relationship. Sometimes the term "owner" is better. Unreal uses both terms sin various places in ways that make sense. If for instance, you wanted to discover which pizza "owns" a particular instance of a peppertoni, you might put a variable in the Pepperoni class called "owner" or "parent", to refer back to the containing pizza instance.

          The code:

          var Pepperoni myPepperoni;

          is an example of composition.

          What you were looking for was the keyword "static" as used in C++ class definitions. Here is a snippet from the Wiki talking about its abscence in Unrealscript:
          Why UnrealScript does not support static variables
          While C++ supports static (per class-process) variables for good reasons true to the language's low-level roots, and Java support static variables for reasons that appear to be not well thought out, such variables do not have a place in UnrealScript because of ambiguities over their scope with respect to serialization, derivation, and multiple levels: should static variables have "global" semantics, meaning that all static variables in all active Unreal levels have the same value? Should they be per package? Should they be per level? If so, how are they serialized – with the class in its .u file, or with the level in its .unr file? Are they unique per base class, or do derived versions of classes have their own values of static variables? In UnrealScript, we sidestep the problem by not defining static variables as a language feature, and leaving it up to programmers to manage static-like and global-like variables by creating classes to contain them and exposing them in actual objects. If you want to have variables that are accessible per-level, you can create a new class to contain those variables and assure they are serialized with the level. This way, there is no ambiguity. For examples of classes that serve this kind of purpose, see LevelInfo and GameInfo.


            Hi, yes, I realize that Pepperoni's are not Pizza's. It's more that I'm not great at analogies. I just wanted to use the idea of a Parent, it's children, and something controlling both. ie. OvenTemp, Pizza, and its Pepperoni's.

            But, as you mentioned, this relationship is best described as an "Owner". that is a better clarification, thanks.

            "var Pepperoni myPepperoni"

            yeah, I'm just learning about this syntax now. though it does get confusing to me.


              Its just the term "global" does not refer to "one for all" it means "open to all", as in any other object can access it. Private and protected members limit access to variables in specific ways as well. Though most people in uscript dont use encapsulation, as it is generally a pain in the butt, heh.


                As for "static variables", the only thing I guess I can do is complain. Epic couldn't decide which rules to put on these variables so they eliminated them completely. :bulb:

                my confusion most likely comes from my coding experience being in Javascript(Flash) and Lingo(Director), rather than C++. I'm just used to being able to easily reference variables, functions, objects, etc. from anywhere in code without restriction.

                "If you want to have variables that are accessible per-level, you can create a new class to contain those variables and assure they are serialized with the level."

                this is what I was originally trying to do. but I couldn't figure out the correct syntax, as I was spawning a unique instance of the class variable container everytime I wanted to reference it in a different class.