This is something that I don't think is required, and it may not necessarily be worked on, but I do think that there is grounds to change how time behaves in the script.
To explain, I think that time is flimsy and can be as out-of-order as one desires. I think this may be fine, but I do want to decide whether I want to allow this behaviour. Every CREATE, MOVE, or DELETE tag must have a time attached and that makes it difficult to write effectively.
I think that instead, the script could be required to be written like a timeline of events. Out-of-order scripts for medias such as movies would be unfeasible in real life anyway, so this takes the temptation out of the equation. Instead, the script should have a means to "advance time". In fact, I think there should be multiple variations of this.
ADVANCE <timeAmount>;
This would advance time by the specified amount.
ADVANCE TO <time>;
This would cut straight to the specified time. This should cause an error if ends up going backwards.
If it truly becomes necessary, then I could add a means to head back in time. I think it would be something like this:
REGRESS <timeAmount>;REGRESS TO <time>;
I would sincerely rather not implement that if I decide to force a timeline, but that's a plausible addition.
trystyncote
commented
1 year ago
This is something that I don't think is required, and it may not necessarily be worked on, but I do think that there is grounds to change how time behaves in the script.
To explain, I think that time is flimsy and can be as out-of-order as one desires. I think this may be fine, but I do want to decide whether I want to allow this behaviour. Every CREATE, MOVE, or DELETE tag must have a time attached and that makes it difficult to write effectively.
I think that instead, the script could be required to be written like a timeline of events. Out-of-order scripts for medias such as movies would be unfeasible in real life anyway, so this takes the temptation out of the equation. Instead, the script should have a means to "advance time". In fact, I think there should be multiple variations of this.
ADVANCE <timeAmount>;This would advance time by the specified amount.ADVANCE TO <time>;This would cut straight to the specified time. This should cause an error if ends up going backwards.If it truly becomes necessary, then I could add a means to head back in time. I think it would be something like this:
REGRESS <timeAmount>;REGRESS TO <time>;I would sincerely rather not implement that if I decide to force a timeline, but that's a plausible addition.