Astrabit-ST / ModShot-Core

A fork of mkxp, forked for OneShot, forked for OneShot mods, (not to be confused with the ModShot server)
https://nowaffles.com
GNU General Public License v2.0
19 stars 9 forks source link

[DRAFT] Merge upstream master into stable #31

Closed Speak2Erase closed 2 years ago

Speak2Erase commented 3 years ago

Stable's purpose is to serve as a "stable" iteration of ModShot, while development is the more up-to-date branch. Since I feel we've ironed out of the bugs from development, I think it's about time we merge them over into Stable.

There's still a few lingering bugs/features to fix (such as fiber serialization) and audio filters are still not feature complete or quite ready for release, so until they're fixed/finished this PR won't get merged just yet.

rkevin-arch commented 3 years ago

Stable's purpose is to serve as a "stable" iteration of ModShot, while development is the more up-to-date branch. Since I feel we've ironed out of the bugs from development, I think it's about time we merge them over into Stable.

I think most users of ModShot (and by most I mean both) track the master branch closely to get the new features, and they have custom changes in their private repos anyway, so I don't think a stable branch is super useful (we usually try to not break the master branch anyway). That's just my opinion, and I think we are stable enough for a stable release if you want to.

There's still a few lingering bugs/features to fix (such as fiber serialization)

I'm not sure how to do that properly while still keeping it a fiber. We should probably discuss what to do with this. My opinion is we should probably remove this feature altogether. Another idea is to just destroy the fiber (assume it has finished running) whenever saving the game, but frankly I'd prefer not having the feature over having one that does not behave like the average developer expects. I guess we can add gigantic warnings about this, or just make it something OSFM specific and not advertise it as a feature.

The alternative is to "implement" our own more restrictive fibers using some sort of state machine (and serialize the current state as an integer). Not ideal, and probably a pain to use, but it's probably the only thing we can do if you want to keep this as a general feature.

Also, I'm not sure if modifications to RGSS code is in scope for ModShot (we're mostly dealing with changes in the engine itself). If this is out of scope, then technically the fiber problem is not ModShot's issue to deal with (users would have to make changes purely in ruby to get it working anyway).

audio filters are still not feature complete or quite ready for release

I think the AL filters / effects are pretty much finished (until someone finds a bug / has a feature request). The other custom audiofilter idea has been scrapped, since it's not really feasible to make it usable and extensible. For OSFM since you just need one type of custom filter and need it constantly enabled, we can just implement it there. I don't really see how to implement them while allowing users to create new filters, enable / disable them on the fly, etc. tl;dr: I think AL filters and effects are ready for release, and custom audiofilters are not supported upstream.

Also, I think we might have to deal with the performance issue with long vertical areas. I think it's the reflection code lagging, but I don't know whether the problem is in ruby land or C++ land. I'd have to do some profiling to find out (plop one more thing on my todo list), and if the problem is in ModShot I'd want to fix it first.

Finally, I think we need to get documentation into better shape before a "stable" release, but once all this stuff is addressed I think we can make a stable release. (Unless you or @CryroFox have feature requests that aren't implemented yet)