Elouda -> RE: RUNNING POLL - ScenEdit requests (2/17/2014 4:16:12 PM)
|
Any chance we might see some kind of logic to the triggers, conditions, etc in the event editor? What I mean with this, is for example the ability to list two 'triggers' for an 'event', and designate them as either OR (as they are now by default, requiring one or the other to activate) or AND (new option, requires both to be true to trigger the event). This would allow for a much more complex set of events to take place. Initially just one 'level' would probably be sufficient (ie pick if theyre all AND or all OR), but eventually a 'layered' approach would be nice (ability to have for example an OR operator for a pair of AND triggers, meaning you need to fulfill all the conditions listed under one of the 'second level' triggers). I can illustrate this with example in case the above isn't clear. A second, much more complex request echos that of snowburn (and maybe others), and that would be the addition of user definable flags/variables - I guess these would be created/handled under a new section (like the existing events, triggers, conditions sections), and have associated triggers, conditions and actions to read, set, increment, etc. them. For example, the user could creating an amphibious scenario could create a 'hasLanded' variable, initially set to 0 or FALSE. Upon a amphibious unit reaching one of 3 designated LZ's, each with their own event trigger (which would require the variable to still be 0 or FALSE) a certain group of units would teleport onto the beach for that LZ, and the variable would be set to 1 or TRUE. This way the forces could be landed on one beach, but still allow choice. To my understanding, attempting the above is impossible currently - you would either have to have one 'beach', or allow for dropping off units at several locations. This simple example illustrates a fraction of the potential that this sort of system could have - it could allow for some very complex 'behind the scenes' work when joined with existing functionality.
|
|
|
|