Script API: implemented ScriptName and Type.GetByName() for all applicable types.

[ivan-mogilko]

This implements readonly ScriptName property and a static GetByName() method for all the object types that have script names. The method looks up for the object of corresponding type with the given script name, and returns its pointer, or null if such object is not found.

NOTE: passing other type's script name will also return null, for example calling Character.GetByName() with a room object's name.

scriptName argument is case-sensitive, obviously.

static AudioClip* AudioClip.GetByName(const string scriptName);
static Character* Character.GetByName(const string scriptName);
static Dialog* Dialog.GetByName(const string scriptName);
static GUIControl* GUIControl.GetByName(const string scriptName);
static GUI* GUI.GetByName(const string scriptName);
static Hotspot* Hotspot.GetByName(const string scriptName);
static InventoryItem* InventoryItem.GetByName(const string scriptName);
static Object* Object.GetByName(const string scriptName);

[ivan-mogilko]

Something for a distant future, but in a conversation we had with @AlanDrake , I realized this or similar methods may be used to initialize global variables in case we completely move to dynamic creation of everything.

Imagine the game data was loaded, and objects defined at design-time created, but how do you attach them to the variables to keep things consistent with objects created at runtime? Possibly that's how:

function game_start() { // or another "service init" function
    cEgo = Character.FindByName("cEgo");
    cNPC = Character.FindByName("cNPC");
}

[ericoporto]

I think GetByName is a better name than FindByName for this behavior.

(More similar to the GetAtRoomXY/GetAtScreenXY methods)

[ivan-mogilko]

Renamed FindByName -> GetByName.

[ivan-mogilko]

In regards to getting script names from these objects; I've been thinking of quickly adding a readable ScriptName property to all of them, but then thought to instead delay that, and experiment with creating the most basic parent class which would hold this property, thus avoiding duplicate API.

Something like

builtin managed struct Entity {
     import attribute String ScriptName;
};

(which will be the first tiny step to #1228)

EDIT:
Hmm, looking at the code though, this might take a while to do this properly (in a more or less clean way), and I would not want to rush this; so perhaps we could have a ScriptName added in a duplicate way for the time being...
Then after the parent class(es) are added, numerous properties (getters/setters) will have to be merged anyway.

[ivan-mogilko]

Note: removed Region.GetByName, realizing that regions don't have script names for some reason...