foxbud/libaermre

Action-Event-Response (AER) Mod Runtime Environment (MRE).

libaermre's Issues

Redesign staging system

In its current form, the way the MRE keeps track of the current stage of execution limits the usefulness of a number of functions.

For instance, all object registration is finalized by the time object event listener registration starts. Due to the current system, however, a mod cannot call AERObjectGetChildren while registering its object event listeners--which would be a useful thing to be able to do in some situations related to the draw event.

Biased floating-point rand functions

The eight functions

• AERRandFloat
• AERRandFloatRange
• AERRandDouble
• AERRandDoubleRange
• AERRandGenFloat
• AERRandGenFloatRange
• AERRandGenDouble
• AERRandGenDoubleRange

provided by the aer/rand.h module use a method of obtaining floating-point values from integers that is known to introduce slight distribution-related bias. See this paper: https://hal.archives-ouvertes.fr/hal-02427338/file/fpnglib_iccs.pdf.

Display text

The HLD executable does appear to support these text drawing functions. These should be exposed as API to mod developers.

Make object destroy events cancelable

Currently all events except for the destroy event can be "canceled" by not calling event->handle and returning false. This includes create events.

When it comes to destroy events, if a mod listener cancels the event, the instance will still be destroyed, but none of it's destroy listeners (vanilla or mod) will be called. That means that canceling a destroy event effectively makes it such that the instance was deleted. The expected behavior is the instance not being destroyed or deleted.

As it stands, I'm not actually sure if this is possible. Further analysis is required.

Add pathfinding support

The HLD executable contains a lot of functions for manipulating paths and planning paths. These should be exposed as modding API.

This will likely involve giving mods the ability to register path indices. I'm not sure whether to force mods to register all of the path indices they might need during initializing or allow them to dynamically create and free paths. Furthermore, I'm not sure whether to present vanilla path indices as separate from mod paths or to just make them appear one-in-the-same.

This will also require allowing mods to attach "path end" event listeners to objects.

Add sprite blending support

The HLD engine has functions for "blending" or shifting the hue of an instance's sprite. This would be nice functionality to expose to mod developers.

Add support for getting and setting window data

This includes adding the ability to:

• Query whether the game window is in fullscreen or windowed mode.
• Change the game window from fullscreen to windowed mode and back.
• Query the size (in pixels) of the game window.
• Change the size (in pixels) of the game window.
• Get the position of the window's view into the game room.
• Translate positions between window and room space.

Allow inter-mod communication

Allow mods to be aware of each other's presence and potentially even discover objects/assets registered by other mods.

I don't want to start planning this until I've had time to see how the HLD modding scene develops and learn how mod developers would like to be able to interact with other mods.

Please leave feedback and suggestions in the comments.

Add save-related support

Add the ability to:

• Save the game.
• Write custom save data.
• Read custom save data.

Add audio support

From what I've been able to tell, it appears as if the HLD executable supports the so called revamped audio engine, which should make it possible to:

• Add custom sound effects and music.
• Replace vanilla sound effects and music.
• Play arbitrary sounds.
• Manipulate the sounds currently playing at any given time.

Add custom room/region support

I realize that one of the main things people want out of HLD modding is to be able to create new rooms and regions. I know that the room file format has already been the subject of a lot of study, and it is fairly well understood.

The way the engine actually handles rooms, however, is a different story. Game Maker does have a lot of built-in functionality for managing rooms, but from what I've been able to tell, Heart Machine didn't use this functionality in the way it was meant to be used. It's almost like they built their own room-handling system on top of the Game Maker system.

I think that allowing mods to create their own rooms is going to require a very significant amount of analysis (if it's even possible), so I'll be prioritizing some of the other, more-achievable features for the near future.

Make object event execution order deterministic

For events that require adding the object index to a subscription array, they should be sorted from least to greatest, but they're currently not sorted any particular way.

Segmentation fault when registering mod sprites with mesa graphics driver

The fault occurs at i965_dri.so:__driDriverGetExtensions_nouveau_vieux+4BB96B.

This will require some more analysis, but it currently appears as if it's a sequencing issue.

The MRE normally registers sprites (along with all other resources) before the main game loop has started. With Nvidia and AMD graphics drivers, this works fine. With the mesa driver, however, this causes the segmentation fault. If the sprite registration period is moved to occur during the first step of the game loop, then no segmentation fault occurs, but the engine hangs for several seconds while loading the first sprite.

This leads me to believe the point at which the engine's sprite module is ready for use depends upon the graphics driver of the host system. When using Nvidia/AMD, the sprite module is ready long before the game-loop starts, but that's not the case with mesa.

Support adding to instance position

Right now mod developers can get and set an instance's position, and they can get, set and add to an instance's motion. It would make sense to support the ability to add to an instance's position.