40) Being able to give objects a 'Trigger only once' attribute. Like, in a runtime, there are various things I'd only EVER want to do ONE single time throughout the whole game and not repeat it once I re-enter the layout. That's a bit of a bitch to do right now, cause I'd always have to set variables and use them as conditions or I'd have to come up with some other clever idea like using hash tables or whatever and that's still sorta crappy in terms of organization.
If we'd have an adventure game where you could set an event to only happen once EVER, it'd make things a lot simpler.
I think it's necessary to take a step back and look at how a story line should logically be run here.
You want to run a part of the story only once per play through, therefore this event has a designated name or identifying feature, maybe it's called "Meet Robert", for example. The method you propose would arbitrarily make just one event run only once, with no identifying feature or name to signal what it is. What if you want two events linked to it? What if you want to reset the event, for example, you meet an enemy, battle him, and lose. What happens then.. do you get stuck? Using a hash table requires one condition (the same amount as your method would), and then just 1 action to signal that the event's happened (adding the identifying name to the hash table). This hash table entry can then be deleted (to allow replaying), or even incremented (if you want to allow it to happen several times). Another major advantage is that this list of events that's happened can be checked in the debugger, and also that it can be saved/loaded to disk. A system condition to check would not persist over save/loads, nor be in any way superior to organise as a hash table. You'd quickly forget where and how many story line items were going on, and their names, whereas with a hash table they're safely organised and named.