wait
That I've found is next to useless, it constantly caused errors in
the event hierarchy because it would re-check the above variables
after the time had passed instead of only causing a delay before the
next action occurred.
For example, if you had it check if a private variable were equal to 0
before running some events, one of which would need to change that variable
to 1, when it reached the next action after waiting maybe 200 milliseconds,
the events condition wouldn't be valid anymore and it won't occur.
I am no friend of the wait object, because it makes event sheets harder to maintain. That's why I never use it. I just proposed it, because quite a few people here swear on it, and I didn't want to hide it ;)
timer
that's what I've had to use for objects so far, but it becomes an issue
very easily.
#1 if there is more than one object on the screen (if it's an enemy in which multiple enemies would be created, you couldn't get a timer to
start on individual enemies without it occurring on others. For some objects that I have destroy after a certain amount of time, even if there are multiple you can use that timer by only setting the timer
when a condition that a variable is equal to 0 is met, then change that
to 1 after the timer is set in the same event. But that only works because you only need to use the timer once and it's an event based off the objects creation.
I'm not quite sure if I understand. PVs are unique to every instance, it is just a case of picking right. If I pick one instance and set 'timestamp' to timer, only 'timestamp' of that one instance is set. So, if you want to pick an instance at times, when it is not created, you can do so by picking based on oid or uid, or set an 'pid'-pv on creation.
For a situation, where one object would have to spawn a few instances delayed, there are objects like array or hash table, where you could store the timestamps, test against timer and clear/remove the cells, when creating the corresponding instance. Straightforward and easy to control :)
#2 if you want multiple areas of an object to be based off time, it'd very easily become a large hassle and difficult to manage if you kept having to create private variables and setting them to time and checking them.
I can't agree here. I use the 'timestamp' method in every project, sometimes on hundreds of sprites and instances. If you carefully prepare your project, you won't get into trouble. Instead, while using something like the wait object would really be a problem under such conditions, it is relatively easy to follow the logic behind the 'timestamp'-events.
The reason I want some events to not be affected by timescale, is I want
to slow down the world by using timescale (all events/objects/etc), however
some things I don't want to slow down, for example how long a text object
spawned off an enemy displaying the damage they have taken would last
before being destroyed.
I see. Well, this is a situation, where you have to decide, which one is more important to be time-based.
You could, for example, constantly check the framerate (e.g. through getting the mean of 1/TimeDelta) while timescale = 1. Then, when reducing timescale, you'd calculate the proper timing for the text boxes based on that framerate, and alter them tick-based until timescale = 1 again.
Or you could leave timescale untouched and slow the world down by changing all the timebased values, including animation speed, etc. But that would mean a huge effort to make.
I recommend to download Verve!, an example game that is completely time-based. There are a lot of the things realized that you are thinking of (For example, there's a commented volume fade over time, although timescale=0 at that time). I commented every single event, so it should be a good source of information.