Dynamic 'metaproperties'

[Fidcal]

I've suggested this idea before but maybe we should have this thread for other mappers to post suggestions to be included.

 

Most entity properties cannot be changed once the game starts. The spawnarg is simply the value given to a property when the game starts so changing the spawnarg makes no difference once the game has started.

 

We already have some properties we can change in-game such as the brightness of a light. But there are others that would be useful. Unfortunately each one must be given individual code support to convert a value into an actual property while the game is running. So I suggest over a period we come up with a reasonable list of properties we feel it would be useful to change.

 

One idea might be to have a new entity say trigger_property. It's target would be the entity whose property you want to change. On the trigger you put eg,

set speed

99

 

Here are a few suggestions for properties that might usefully be changed in-game:

 

speed - func_rotating, func_pendulum

notouch - triggers (effectively enables/disables)

shaderparms - various, eg fog murk, water surface current speed

used_by (on doors = instant keyring)

[Tels]

I think the idea that we can come up with a definitive list is rather futile - we have over 1500 spawnargs, and just documenting them is apparently too much (we only have about 50% of them documented, give or tatke 10%). So listing them up and even saying "this one is dynamic" is a futile attempt.

 

What I think we'd need to do is to redesign the code so that the modify of a spawnarg (via spawnArgs.Set as well as $entity.set("foo", "bar")) results in an auto-update of the actual property. Either by copying all spawnargs, and syncing them, or by never having internal variables and dstore everything in spawnargs (I think this might be too slow, too).

 

It is certainly tricky and/or a lot of work, but in the end it will be better for the mappers as they never need to worry that they cannot modifiy spawnargs - everything is dynamic and every change is immiditely reflected in game.

[Fidcal]

Well, that sounds ideal from a mapper point of view.

 

As for my idea, I wasn't suggesting we go through all spawnargs and decide which ones should be dynamic. I was saying over the next few months or a year that mappers, as new uses come to their attention, that they list them here. When we have 10 or 20 or 50 then an entity be created with the code. Whenever a mapper needs another then hopefully it can be added.

 

At the moment, most mappers probably have no idea what this is about so they are not particularly showing any interest. But next month someone might be asking how can they change the speed of a door or make an AI walk slowly at a certain place or how to change the voice of a possessed person and so on.

[ungoliant]

funny i was just thinking of something along these lines while I was mapping today before reading this thread.

 

I would wish for _color spawnarg to be modifiable dynamically, for lights as well as colorme models. I have a particular light that I would wish for the glass/light to change from green to red and vice versa via a switch/lever.

[Tels]

funny i was just thinking of something along these lines while I was mapping today before reading this thread.

 

I would wish for _color spawnarg to be modifiable dynamically, for lights as well as colorme models. I have a particular light that I would wish for the glass/light to change from green to red and vice versa via a switch/lever.

 

Your wish is my command: Write a script along these lines:

 

void light_change_to_red( entity mylight, entity activator, entity target_entity )
{
 mylight.fadeToLight("1.0 0.0 0.0", 1.0);  // 1.0 seconds to full red
}

void light_change_to_green( entity mylight, entity activator, entity target_entity )
{
 mylight.fadeToLight("0.0 1.0 0.0", 1.0);  // 1.0 seconds to full green
}

 

Then setup an trigger_multiple or trigger_once, or indeed a lever and link it to an atdm:target_callscriptfunction. Set on this:

 

"call" "light_change_to_green"
"foreach" "1"

 

From this entity, link it to your light (or multiple if you want).

[ungoliant]

yaaaaaayy!! thanks tels!!

[Fidcal]

I've added 'used_by' for doors to the list because this should an easy and immediate keyring option. All we need is a keyring inventory icon, put it on any key, name that key say, keyring, then whenever a key is found it triggers 'used_by_keyring' to be added to the door with 'keyring' as the value and the key can be deleted.

 

However, I don't like the method myself. I prefer a keyring that is simply an alternate inventory where you scroll around the keyring to select the key you want. This is why I want the optional blocker on scrolling inventory categories so they all scroll within the category only.