I plan on implementing this myself
Why is this necessary?
Level.TeleportTo is vanilla behavior typically used in cutscenes, however there is no way of calling the method outside of a custom cutscene.
Level.TeleportTo is a simple teleport that effectively acts as "starting a map" from another room (that is, it plays an arbitrary intro type like you started the map from that room), and is
- effectless
- stable
- seamless (with the Transition) intro type
and these qualities do not exist simultaneously in existing modded teleport triggers.
Is there precedent for this being an Everest feature?
Yes, features such as the Custom NPC and Dialog Cutscene triggers both expose vanilla cutscene functionality in an accessible way to mappers, and Level.TeleportTo() is exactly that, perhaps even moreso as it would be literally exposing a vanilla helper function to mappers through a trigger.
Does this follow Everest's rules for new content?
Content added must not change the functionality of the base game, or change any public facing API.
While many mods also make use of non-public code it is not as important to maintain backwards compatibility for it.
Yes, this does not modify anything, it simply adds a way to access existing vanilla behavior.
New features should only be added to improve or un-hardcode vanilla features, especially for general use in code mods (f.e. StrawberryRegistry, CustomNPC, Custom Events).
This improves vanilla features in the same way CustomNPC does, by exposing very basic behavior (Textbox.Say in the case of CustomNPC) to mappers.
Gameplay mechanics, entities, and other features not present in the base game are usually better suited for a mod, although some exceptions will be made on a case by case basis.
This is present in the base game.
Planned implementation
Create a trigger that adds a call to Level.TeleportTo to the Scene.OnEndOfFrame delegate.
TLDR
The feature has nearly identical precedent in other Everest features, would be trivial to implement, fits the template for new Everest content perfectly, and would provide very useful functionality for mappers that cannot be found in its particular form in existing mods.
I plan on implementing this myself
Why is this necessary?
Level.TeleportTo is vanilla behavior typically used in cutscenes, however there is no way of calling the method outside of a custom cutscene.
Level.TeleportTo is a simple teleport that effectively acts as "starting a map" from another room (that is, it plays an arbitrary intro type like you started the map from that room), and is
and these qualities do not exist simultaneously in existing modded teleport triggers.
Is there precedent for this being an Everest feature?
Yes, features such as the Custom NPC and Dialog Cutscene triggers both expose vanilla cutscene functionality in an accessible way to mappers, and Level.TeleportTo() is exactly that, perhaps even moreso as it would be literally exposing a vanilla helper function to mappers through a trigger.
Does this follow Everest's rules for new content?
Yes, this does not modify anything, it simply adds a way to access existing vanilla behavior.
This improves vanilla features in the same way CustomNPC does, by exposing very basic behavior (Textbox.Say in the case of CustomNPC) to mappers.
This is present in the base game.
Planned implementation
Create a trigger that adds a call to Level.TeleportTo to the Scene.OnEndOfFrame delegate.
TLDR
The feature has nearly identical precedent in other Everest features, would be trivial to implement, fits the template for new Everest content perfectly, and would provide very useful functionality for mappers that cannot be found in its particular form in existing mods.