NOGAN mvp

[TodePond]

See #31

[TodePond]

Putting these two in the same issue for now, idk

I feel like the design of each depends a lot on the other

Like, we need the structure to be lightweight enough to handle traversing forwards on the tick very easily, and cloning the whole thing, and modifying a past state, etc

[TodePond]

Made a schema and an outline of how it works with a mock syntax

[TodePond]

made some helpers for creation and some validation whenever you make a child

[TodePond]

need to consider different pulse types... do we resolve them when they reach their target? or during the process? probably worth doing it along the way... but we need to support custom arguments in the pulse... gotta validate for that. and we could have multiple pulses. blp.

[TodePond]

Maybe should refactor the isFiringRed, etc... to an array of pulses which have their own validator

yeah this is best I think. a side-bonus would be that we can then customise the phantom pulse too

[TodePond]

actually wait no that would lead to memory leaks and defeat the whole purpose of the finite-stateness of it.

it's lame but i might just need a big bulky object for fire/pulse types

maybe a partial

[TodePond]

done loads! more to do. on pulses now!

during a tick, a nod should peek into the future if it has to (or the past?)

also just realised: i should get rid of support for disconnected wires! it can be an arroost-level thing, implemented through glue nods ✅

also i probably shouldn't be firing events. let's route these callbacks in a more direct way. edit: should be an object with pulse type keys, with each value as an object of callbacks

[TodePond]

did a big refactor to start to separate out the sugar for the API

[TodePond]

got some time travel working

deno crashes though, I think it's time for some memo-ing

[TodePond]

It's because the time travel wasn't being targeted at only the required nogans.

[TodePond]

done!