docs: Clarify setup() and teardown() usecases#12
docs: Clarify setup() and teardown() usecases#12vdaysky wants to merge 2 commits intoMineplex-LLC:masterfrom
Conversation
BillyDotWS
left a comment
BillyDotWS
left a comment
There was a problem hiding this comment.
A couple minor changes
contents/docs/sdk/custom/index.mdx
Outdated
|
|
||
| <Note type="note"> | ||
| Registering a module using `MineplexModuleManager` will call it's `setup()` method. | ||
| If module is a `org.bukkit.event.Listener`, it will be registered with Bukkit as well. |
There was a problem hiding this comment.
All modules are listeners:
public interface MineplexModule extends Listener, Teardown, Setup
I think it's worth mentioning that they're registered, but let's tidy up the explanation here.
contents/docs/sdk/custom/index.mdx
Outdated
| <Note type="note"> | ||
| Registering a module using `MineplexModuleManager` will call it's `setup()` method. | ||
| If module is a `org.bukkit.event.Listener`, it will be registered with Bukkit as well. | ||
| Similarly, destroying a module will call its `teardown()` method, also unregistering events. |
| ``` | ||
|
|
||
| <Note type="warning"> | ||
| Constructing a `GameMechanic` through `MineplexGameMechanicFactory` will not cause Studio Engine to call neither of its `setup()` nor `teardown()` methods. |
There was a problem hiding this comment.
neither of its -> either
| ``` | ||
|
|
||
| <Note type="warning"> | ||
| Constructing a `GameMechanic` through `MineplexGameMechanicFactory` will not cause Studio Engine to call neither of its `setup()` nor `teardown()` methods. |
There was a problem hiding this comment.
I think it's worth improving the examples on this page too whilst you're here
BillyDotWS
added
the
docs: enhancement
|
I made some changes, wanted to know your opinion on those - if you don't agree I'll just rollback. I feel like this new structure would be more intuitive, and I am saying this as someone who spent a lot of time staring at those docs, trying to understand how things work. I acknowledge that it is possible that you already considered this structure and decided against it, and if so I would be curious to know the reasoning. I renamed built-in mechanics page into just mechanics, and moved all of the mechanics docs from game engine module page to mechanics page (potentially if you don't like the nesting mechanics page can be moved to uppermost sdk section level for better visibility, but since mechanics are coupled heavily with the game having it as nested page also makes sense. Having it inside game engine page though is too much IMO. Currently that page has information on game cycle, game interface, game states, mechanics, custom mechanics, mechanic factories, has two 175-line listings that have 4 lines of diff between them and it also documents GameWorldSelectorMechanic for some unknown reason). Also weirdly enough path of the mechanics page (/features/game/mechanics) was already implying that it is sub page of game engine module (I am starting to think that it was, but someone changed it while preserving path for backwards compatibility). Another side effect of moving both custom and built-in mechanics to one page is that same has to be done for modules, and honestly I think that would be a great change. There are two separate pages for built-in and custom modules, while they are really the same thing, with built-in being custom modules implemented and registered by mineplex (also both pages are relatively empty). On an unrelated note, why is that page called "Features" in navbar, while it contains modules and index page is titled as modules? |
| Implementing your own custom `GameMechanic`s is easy to do: just create a new class that implements the `GameMechanic` | ||
| interface, and determine if you want a mechanic that is coupled to a game, for example `BossMechanic<BossGame>`, or a | ||
| more generic mechanic, such as `SpectatorMechanic<MineplexGame>`. In your custom class, you will need to implement | ||
| the `setup(Game)`, `teardown()`, and `onStateChange(GameState, GameState) - todo: wtf is this` methods to define the custom behavior of your |
There was a problem hiding this comment.
What is this onStateChange though? Is it something from a super old sdk version?
There was a problem hiding this comment.
This appears to be removed, likely for handling state changes on older versions
2 participants
Thanks for contributing to our Studio Documentation!
To ensure quality and consistency, please complete the checklist below. Provide links and details where requested. This helps us verify everything is in order.
Please ignore any options that aren't applicable to your change.
Documentation
Testing
Once completed, share all Pull Request (PR) links in the #documentation-chat channel for review by other partners and the Mineplex development team. Thank you for your effort in improving our documentation!