Oh lord this is suffering: Time Agents, from VG.

[Qwertytoforty]

Foreword:

The basics, as always, are easy, and done. The issue of course, is making the code not shit. This should / will be broken into multiple prs, with timestop being first.

Original version:

https://ss13.moe/wiki/index.php/Time_Agent

What is a time agent?

See above. It's mostly going to be the same as the wiki.

There is just a main problem, that I really need to look into / have other people look into, before I even finish this mess:

Code quality, and impact of having time based mechanics.

In order to send something to the future, that is easy. It's just a reworked time stop with extra steps, we make it invisible / not dense / time stopped, bobs your uncle.

Timestop in itself is not bad, though we need to block processing of objects that are time stopped, including atmos machines. This is problematic, and in itself something that will need much testing to ensure it doesn't go wrong.

And then, the problem...

And then, well. We have saving a state of something in the past.
Saving a variable is easy. Multiple is not bad. The issue comes to when everything has it's own custom variables. Most things will save properly from the past, but some things will not function as expected until exceptions are coded to them. IE, at this time, an energy gun will have it's charge reset to the past, but the BSG, for example, will not have it's crystal reset.

Then of course, the fun, of what happens when we want to get rid of something.

Qdel or not to Qdel

Let us say we have a grenade. We want the grenade, when we return to a saved past state, to reset to unarmed.
Well, we can set armed to false. That is easy. However, grenades qdel themselfs after priming. This means under normal circumstances, they would be deleted. This is problematic if we want to restore the item. How does VG handle it?

/proc/qdel(const/datum/D) if(isnull(D)) return

`if(D.being_sent_to_past())
	return`

It refuses to be qdeld if it is being sent to the past. This can lead to an infinite number of horrible situations.

For example, imagine what happens if a mob is dusted by the supermatter, and then tries to rebuild itself from returning after dusted. Or gibbed by a minibomb. A nightmare. I can only imagine how well it works on VG (EDIT: VG has it run well. Still don't trust it.) It sure as hell doesn't work well on my current port, though part of that is due to everything being moved into a mobs content on rewind, if it was moved off the mobs expected spot.. They also like to forcemove(null) as part of this process, which is really not great.

How to proceed?

I'll probably do the timestop rework. It actually stops mobs, stops things from processing, it's an actual time stop, vs only stopping mobs from moving, while they can still attack just fine.

Move to future stuff can be applied as well easily, and the antagonist itself is not hard to add, the main issue is how on earth to go about past saving. It will either have to be ditched altogether, done so it has qdeled items delete, and thus make physical guns not try to rewind, else they get empty shells loaded in, and it will otherwise mostly work as expected theoretically, but a bunch of testing will have to be done, or some magic solution found to make stuff return from the void (horrible)