Entity events, similar to Source's I/O, are perfectly possible in GoldSRC. The only slightly limiting part is the map editor.
But, let's assume we're modifying TrenchBroom to support this feature, and we want to do entity events.
Each entity could perhaps have an events keyvalue, where a list of events would be stored:
"events" "OnEnter:door1.Open(),3.00;OnClose:wall1.Break(),0;OnReset:wall1.Respawn(),0;"
Let's dissect the first event.
The input event is OnEnter, which tells us the current entity is probably some sort of door or area trigger.
What comes after the : marks what will be executed. In this case it's door1.Open(), which will open a door named door1.
The number after the , marks the delay, in this case 3 seconds.
Alternatively, we could store events this way, in raw keyvalue form:
"!OnEnter" "door1.Open(),3.00"
In this case, events have a special ! prefix. It's easier to write and read for the mapper, too, in case their map editor doesn't support the feature.
Lastly, entity events could have parameters as well.
door1.Open( angle=30, speed=90 ) could open door1 but it'll go at an angular speed of 90°/s up to 30° and stop. Otherwise, if there are no parameters, then the door's default keyvalues are used.
Entity events may get implemented in ADM 1.0.0.
Entity property awareness
Another interesting concept would be if entities were aware of their properties and properties of others.
For example, let's say we have a trigger which will trigger a rotating door.
door1.Open( speed=x ) where x can be any entity variable. For example, the X dimension of some other entity's velocity.
door1.Open( speed=myEntity.velocity.x )
In another example, let's say we have a func_train (bob) and a momentary_rot_button (billy) somewhere.
The train's speed would be billy.angles.x. This is fairly more complicated to implement, to be fair, but it gives you the idea of what entity property awareness should be like. Basically, when the train moves, its speed is directly correlated to some lever's angle, and as the lever changes, the train's speed also changes. E.P.A. probably won't be implemented until ADM 2.0.0 or 3.0.0.
Entity events, similar to Source's I/O, are perfectly possible in GoldSRC. The only slightly limiting part is the map editor. But, let's assume we're modifying TrenchBroom to support this feature, and we want to do entity events.
Each entity could perhaps have an
eventskeyvalue, where a list of events would be stored:"events" "OnEnter:door1.Open(),3.00;OnClose:wall1.Break(),0;OnReset:wall1.Respawn(),0;"Let's dissect the first event. The input event is
OnEnter, which tells us the current entity is probably some sort of door or area trigger. What comes after the:marks what will be executed. In this case it'sdoor1.Open(), which will open a door nameddoor1. The number after the,marks the delay, in this case 3 seconds.Alternatively, we could store events this way, in raw keyvalue form:
"!OnEnter" "door1.Open(),3.00"In this case, events have a special!prefix. It's easier to write and read for the mapper, too, in case their map editor doesn't support the feature.Lastly, entity events could have parameters as well.
door1.Open( angle=30, speed=90 )could opendoor1but it'll go at an angular speed of 90°/s up to 30° and stop. Otherwise, if there are no parameters, then the door's default keyvalues are used.Entity events may get implemented in ADM 1.0.0.
Entity property awareness Another interesting concept would be if entities were aware of their properties and properties of others. For example, let's say we have a trigger which will trigger a rotating door.
door1.Open( speed=x )wherexcan be any entity variable. For example, the X dimension of some other entity's velocity.door1.Open( speed=myEntity.velocity.x )In another example, let's say we have a
func_train(bob) and amomentary_rot_button(billy) somewhere. The train's speed would bebilly.angles.x. This is fairly more complicated to implement, to be fair, but it gives you the idea of what entity property awareness should be like. Basically, when the train moves, its speed is directly correlated to some lever's angle, and as the lever changes, the train's speed also changes. E.P.A. probably won't be implemented until ADM 2.0.0 or 3.0.0.