Extending Room scripts

[Deivore]

Hey all,

I'd like to add an attribute that all rooms would have via script. This would be vanishing points or vectors that affect the directions of keyboard movement, so it is specific to the art in each room.

Reading up on the manual, it looks like I want an "extender function" which lets me add new functions to types that other scripts can see and call. This seems ideal for me because I would like the keyboard movement script to get a new room's vanishing points/vectors when a new room is entered.

However, the manual says Extender Functions are to be placed in the script header, and Rooms don't seem to have script headers, only .asc files. Is it possible to add extender functions to rooms?

[Crimson Wizard]

Because of how AGS scripts work (a script may only "see" declarations from script above it in the list), you won't be able to call a room script's function from anywhere else anyway.

Note that the extender function is simply a "syntax sugar", the only difference from regular function is that instead of DoSomething(character) you call character.DoSomething(). So it's mostly a means to group functions under some namespace, and is similar to ordinary function in every other aspect.

You may still create an extender function for a Room type in a global script or another script module, but you won't be able to define different implementations for that function per room, as extender function relates to a type rather than exact object.



For your case, I see two potential solutions that would be flexible enough.

1. Use custom properties, and set these axes in custom properties for each room, either in the editor, or in room's "Before fade-in" event. In global script you would read these properties from current room.
See Room.GetProperty and Room.SetProperty functions in the manual.

2. Go other way around and make your movement script expose arrays, or functions for filling these axes data. This way you will be able to fill them in each room's "Before fade-in" event.

[Deivore]

Thanks Crimson!

I was worried something like that might be true. Thanks for your proposed solutions!

I like #1 better in principle because all the data's in one place, but the data might be complicatedenough that I'd waste more time with parsing errors, I'll play around with it.