This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
projects:frontier-team-builder [2023/12/03 06:05] – oemb1905 | projects:frontier-team-builder [2023/12/03 07:29] – oemb1905 | ||
---|---|---|---|
Line 50: | Line 50: | ||
Require valid-user | Require valid-user | ||
| | ||
- | This takes care of password protecting the development instance and ensuring that LTS is enforced for all url requests. | + | This takes care of password protecting the development instance and ensuring that LTS is enforced for all url requests. |
+ | *[[https:// | ||
- | --- // | + | Next, we need to harden the production instance and/or optionally white-label it. To harden, we remove the development cog from footer.php and make write.php an empty file. To white-label, |
+ | |||
+ | *[[https:// | ||
+ | *[[https:// | ||
+ | *[[https:// | ||
+ | *[[https:// | ||
+ | |||
+ | Now, the repository also has the ability to store overrides on moves and custom meta groups, however, this is optional and more of a choice specific to each meta development team. | ||
+ | |||
+ | ------------------------------------------- | ||
+ | |||
+ | At this point, the development and production virtual hosts are created, secured sufficiently, | ||
+ | |||
+ | *[[https:// | ||
+ | *[[https:// | ||
+ | *[[https:// | ||
+ | |||
+ | The scripts above assume a detailed understanding of the upstream code. The scripts above create the files needed for metas and migrate those from development to production. There are micro tasks involved that require independent study and expertise and are presumed levels of understanding for the intended audience. At this point in the tutorial, you should know how to create a development and production instance, create metas within the development instance, and migrate those changes to production. | ||
+ | |||
+ | ------------------------------------------- | ||
+ | |||
+ | At this point, we now need to know how to pull changes from upstream. If you are not familiar with the community, you might be wondering what changes we would be pulling. In addition to coding and/or optimizations that KakunaMatata might make to the stack, he also pushes changes that are global to the game including but not limited to move additions, move nerfs, move buffs, and/or other changes. These changes impact the relative ranking and simulated combinations that the meta and battle party features of the upstream project and fork utilize. In short, since the development instance is a git repository, teams need to pull the changes, resolve conflicts, and then merge those to production. Here are the steps from top to bottom for creating a meta, and then later updating the instance to reflect the new changes to the underlying Pokemon moves. | ||
+ | |||
+ | *[[https:// | ||
+ | |||
+ | ------------------------------------------- | ||
+ | |||
+ | This should help any teams desiring to make a development and production instance and/or fork of PvPoke.com. Now, some meta developers might want to just create a locally hosted version and want to know how to create metas with as little fuss and muss as possible. If that's so, then install the latest version of pvpoke.com to your localhost webroot. Once that's done, change, create, and/or edit the following files according to how pvpoke.com works: | ||
+ | |||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | src/ | ||
+ | |||
+ | Once these are created, do the following in the web GUI (under the development cog): | ||
+ | |||
+ | - compile (with group put in from step 10 above) | ||
+ | - override moves, import movesets, copy json to 11 above | ||
+ | - compile again | ||
+ | - ranker, simulate | ||
+ | - rankersandbox, | ||
+ | |||
+ | Bear in mind, these are highly condensed instructions which assume knowledge of the underlying upstream code, familiarity with KakunaMatata' | ||
+ | |||
+ | --- // |