Skip to content

Wipe parsing#1053

Merged
SnipUndercover merged 7 commits into
EverestAPI:devfrom
SilverDorian46:wipe-parsing
Jun 28, 2026
Merged

Wipe parsing#1053
SnipUndercover merged 7 commits into
EverestAPI:devfrom
SilverDorian46:wipe-parsing

Conversation

@SilverDorian46

Copy link
Copy Markdown
Contributor

this PR adds some alternative ways for modders to apply their Screen Wipes to a map.
this mainly serves to give unique identifiers to the Screen Wipes, so that the game doesn't have to check for their full type names, and their classes can be freely reorganised if needed.

Everest.Events.MapMeta.OnParseWipe accepts a method that returns an Action<Scene, bool, Action> and takes the argument string wipe, which is the value of the current Wipe metadata being parsed.
the parameters of the returned Action are similar to the constructor for a Screen Wipe: (Scene scene, bool wipeIn, Action onComplete).

the [CustomWipe] attribute should be placed on a class that extends ScreenWipe, and is used to give it a unique identifier. the class requires one of the following in order to be registered as a custom wipe:

  • a public static generator method (called Load by default) that returns ScreenWipe and has the signature (Scene scene, bool wipeIn, Action onComplete), or...
  • a constructor with the signature (Scene scene, bool wipeIn, Action onComplete).

@maddie480-bot maddie480-bot added the 1: review needed This PR needs 2 approvals to be merged (bot-managed) label Dec 29, 2025

@microlith57 microlith57 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few stylistic concerns but looks good!

Comment thread Celeste.Mod.mm/Mod/Everest/Everest.Events.cs Outdated
/// Mark this renderer as a custom <see cref="ScreenWipe"/> with an identifier.<br/>
/// If there is no match, then the full type name of the Screen Wipe is checked for.
/// </summary>
/// <param name="ids">A list of unique identifiers for this Screen Wipe.</param>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: might be good to note that this follows the ID[=MethodName] pattern!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we do the same for the other attributes too?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, i guess i neglected to check those :p
yea if you can add wording to their docs too that'd be good!

namespace Celeste {
public class patch_AreaData : AreaData {

public static readonly Dictionary<string, Action<Scene, bool, Action>> WipeLoaders = new();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: can the Action<Scene, bool, Action> be a named delegate type instead?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may just be my experience, but getting an Action and a delegate to work together like this is kind of tricky.
so I thought just using an Action would be easier

Comment thread Celeste.Mod.mm/Mod/Meta/MapMeta.cs Outdated
Comment on lines +165 to +166
if (Everest.Events.MapMeta.ParseWipe(wipeStr) is { } wipeLoader
|| (patch_AreaData.WipeLoaders.TryGetValue(wipeStr, out wipeLoader) && wipeLoader is not null))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: can this be split into an if/else if? it feels a bit cramped as a single condition

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, will do

@Wartori54 Wartori54 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to merge once conflicts are resolved!

@maddie480-bot

Copy link
Copy Markdown
Member

The pull request was approved and entered the 3-day last-call window. Since no PR should be merged within 3 days of the next rolling release, the last-call window is extended further.
If no further reviews happen, it will end on Jun 28, 2026, 12:00 AM UTC, after which the pull request will be able to be merged.

@maddie480-bot maddie480-bot added 3: last call window This PR was approved, and is in the 5-day last-call window before getting merged (bot-managed) and removed 1: review needed This PR needs 2 approvals to be merged (bot-managed) labels Jun 23, 2026
@maddie480-bot

Copy link
Copy Markdown
Member

The last-call window for this pull request ended. It can now be merged if no blockers were brought up.

@maddie480-bot maddie480-bot added 4: ready to merge This PR was approved and the last-call window is over (bot-managed) and removed 3: last call window This PR was approved, and is in the 5-day last-call window before getting merged (bot-managed) labels Jun 28, 2026
@SnipUndercover SnipUndercover merged commit f5a7d5a into EverestAPI:dev Jun 28, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

4: ready to merge This PR was approved and the last-call window is over (bot-managed)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants