Ruin0x11

I think it would be better to declare the default implementations of aspect functions in the classes implementing the aspects instead of the aspect interfaces. The concern with default functions...

When dealing with hotloading, a common issue is how to support mods that transform existing data entries. Suppose there is a mod that turns every character into a putit: ```lua...

"Talk type" refers to the kind of default dialog that will appear when talking to a character with no tone specified, and it also changes the verb endings spoken by...

As in, some config options can only be changed programmatically using `config.foo.bar = baz` and not in the Options menu. It's a bit annoying (due to the lack of #330)...

Consider moving parts of the core engine to a statically typed language

1

Related: #61. Every time I program on top of ON I get some anxieties that stem from one fact: it's possible to mess up critical parts of the engine's data...

Think about how aspect state and prototype definitions should work together

1

Currently, when an aspect is created, any parameters relevant to it will be passed to its constructor, intended to be used as instanced state. This was intended for things like...

The draw callback system can be error-prone if misused, because you have to call `coroutine.yield` (`Draw.yield`) manually inside the callback closure you submit. ```lua local cb = function(draw_x, draw_y) local...

Ability to change the character making steps based on the scenario chosen/other variables

1

As an example, this would be useful for implementing a scenario where you can only choose from a fixed set of protagonists.

Allow interlacing events on IEventEmitter objects with global events

1

Currently, running events on objects that implement `IEventEmitter` is implemented by binding a new event on the object which calls `Event.trigger` for the global event handlers. This calls all the...

I think it is most intuitive for the default operation to not be additive.