# Investor Overview

# Introduction
This document contains information related to Graft, Hummingbird (Proxy), AGE (Add-on Generation Engine), FriendConnect, and the PDB. As this document is going to be read by people who have not read the previous documents, we have included extra contextual information.

- This document goes over what Graft can do then what Hummingbird cannot do that Graft could do.
- An elaboration on AGE and what it does.
- Information on the PDB and how to acquire it.
- The FriendConnect rewrite.

# Projects

# The Graft Mod Loader

## What is Graft?
Graft is a Bedrock Dedicated Server plugin loader.

*For more information refer to our previous documents... As not everything has been included here to reduce on complexity and length.*

## Features
Here is a list of features we plan to implement into Graft:

### Extensive Event System.
Graft would have hundreds of events like forge to make development as easy as possible.

### Add-on Generation
With the symbols file we would be able to add additions to add-ons. We would be able to create different events and components to allow for more item functions. We could leverage this to make proper custom enchantments, like what Java edition received via data-packs.

### Biome API
Add-ons already have an API for registering custom biomes, however attempting to add it to world-generation does not have any effect. We would be able to create an API to allow a developer to have deep control over generation and the rates something can show up in the world.

### Dimension API
While Bedrock dimensions are mostly hardcoded, it is still possible to add another dimension. We would be able to let a developer have control over generation, biomes, and structures that can spawn in that dimension. The BDS does not handle chunks with lots of blocks super well, empty worlds have negligible effect on performance, so you could create multiple dimensions for different mini games.

### World Data API
There would be APIs for grabbing information from the world itself. This would add methods for grabbing the seed, gamerules, time, day count, etc.. This would also be for modifying blocks in the world. We want to create a system efficient enough for mass changes with less performance impact on the server.

### Particle API
Add-ons can create particles, so we are able to allow plugins to register custom particles and send them to specific players or "broadcast" it to each player.

### Player API
Player data contains lot of information that only the server can obtain. Differnt things like the players inventory, enderchest contents, armor, etc. would all be able to be queried or modified by a plugin with Graft.

### Generation API
We want to provide an API for modding the generation of the world. This would allow for modification of what structures/biomes show up. Our API would provide events that allow plugins to quickly jump into some step of the generation process and tweak some settings.

### Large Event API
As mentioned in a few previous topics, we plan to have a very expansive amount of events. Tools like Spigot and Forge provide enough events that you rarely need to delve into Java Edition's code (with NMS). We want to provide a similar developer experience where someone does not have to open a decompiler to make a plugin.

### Crasher Prevention
We would have control over both packet crashes AND bug related crashes. Sometimes players can crash the game in a way that packets still look normal. Graft would be able to find the source of the crash and either patch them or prevent the action that leads to a the crash.

### Lag machine or player caused Lag Prevention
We would be able to monitor information in each tick to manage how many things are happening. For example, stopping too many pistons from being used in a chunk or too many block entities being pushed by one piston.

### Crash Recovery
We can catch errors and implement custom cancelation to stop an action if it would result in a crash. This would would allow us to prevent the player from disconnecting during a server crash.

### Game Scripting API Modification
We have reversed eengineered the entire QuickJS library that is used by the BDS for add-ons. This allows us to register custom functions and events into the Scripting API which allows AGE and regular add-ons to do more.

### Bug Fixes
We would be able to fix regular bugs in the game before Mojang can get to them. There are many small bugs in Bedrock that get over looked. This is in large part due different problematic bugs taking the spotlight. However we would be able to fix them while Mojang does not have time to commit to them.

### Potion API
We would be able to create an API for custom potion effects. A player would be able to define a potion effect, recipe, and what forms the potion is able to be used in.

### Map Data Manipulation
Maps in Bedrock use RGBA formatting for their colors. We would be able to allow plugins to specify custom colors for the map or even provide an image for the map to display.

### Enchantment API
We could be able to provide an API for registering custom enchantments. Developers would be able to restrict what tools and define what effect enchantments would have.

### Task Scheduling
Allows plugins to schedule a function to run at a set interval.

### Custom Gamerules
We could register custom gamerules that plugins can use for configuration. For example a custom piston push limit or some rate at which some mechanic can happen.

#### Packet API
The packet API would be the core of most plugins. The packet API will be designed to be extremely fast for quick dispatching of packets and reading incoming ones.

#### I18N API
This API is a simple API to handle translation of plugins to other languages and handle other languages that use MBCS (Multi byte character sets).

### Performance Optimizations
We would be designing a section of the loader that makes innate changes to the code. We would be able to make performance improvements to improve the TPS of a server and create a smoother experience.

Something like LeviOptimise, a plugin made for LeviLamina by its own developers, implements many bug fixes that improve the speed of the server. We would be able to embed optimizations like it made directly into Graft's runtime.

### Exploit Prevention
Bedrock is notoriously a very broken game. Of its many bugs, a large amount of them are exploits that allow players to gain an advantage over others in a survival or PVP setting. We would be able to patch cheats to create an equal playing feild for players to enjoy.

### MOTD API
The ability to edit the Message that is sent to the client on ping.

### User Made Modifications Outside of the API
If the PDB is made public again, plugin developers would be able to use it to create their own APIs or direct modifications to the game. Our hooking API would be designed so that plugins can work in tandem with Graft and modify functions Graft may already have hooked.

### Pros and Cons

| Pros | Cons |
| ----------------------------------------- | ------------------------------ |
| More Control | |
| Synchronous Plugins | |
| Less reimplantation | |
| Cross platform (if we receive a full PDB) | |

# The Hummingbird Proxy

## What is Hummingbird?
Hummingbird is the proxy that we will replace Graft with if we must change our focus to a proxy.

## What would Hummingbird Lose over Graft?
Hummingbird would lose the following features:

### World Data API
The proxy could only modify the world data at server startup and after shutdown.

### Player API
This API would have delayed accses to player data, where it out of sync with the server. The plan is to have another method which would keep it in sync with the server, this would add more overhead compared to the ladder.

### Generation API
The proxy would be limited to what the Add-on API is capable of.

### Event API
The event API would not be able to cancel stuff on the server synchronously, limiting the power of the event API. This API would be limited to the information sent between the client and server.

### Lag Prevention
The proxy could only prevent packet spam and other related lag techniques.

### Bug Fixes
The proxy would only be able to fix bugs that occur on the packet level.

### Performance Optimizations
The proxy could only optimize packets and how they are sent.

### Game Modification
These features are simply not even possible within the proxy:
* Potion API
* Server Bug Fixes
* Dimension API
* Biome API
* Enchantment API
* Custom Gamerules
* Game Scripting API Modification

## Pros and Cons

| Pros | Cons |
| ------------------------------------------ | ------------------------------------------------------- |
| Proxy to proxy communication | Slow Reactions to server actions due to network latency |
| Can be configured to be lightweight | Less features and control |
| Server stitching, many servers on one proxy | Will take more time to develop, time needs to be spent figuring out the most viable way to do a part of the API if its possible at all |
| Cross platform | Asynchronous plugins |

# AGE - Add-on Generation Engine

## What are Add-ons
Add-ons allow for things to be sent by the server to the client that change the vanilla experience. We can register blocks, items, entities, ores and so much more with add-ons.

*Add-ons can be thought of as advanced datapacks*

## Add-on Limitations
- Add-ons are unable to modify certain systems due to an API not having been made yet or is unable to be made due to console manufacture platform restrictions.
- No packet API
- They are very slow
- No redstone event API
- No nether portal related events
- Limited piston events
- Many other parts of the game are untouchable by add-ons
- While add-ons are documented, the API is very segmented which increses development difficulty.
- Microsoft has changed sections of the API drastically, add-ons often have to rewrite large sections to keep up to date with each change. This makes it much more difficult to maintain an add-on for future versions.

## What is AGE?
AGE is the special sauce of the project as a whole.

This allows us to on the fly (on server start) generate add-ons that react to other parts of a servers enviroment.

*AGE would allow for Hummingbird or Graft to stand out.*

We can create an API that allows plugins to create these items right inside of their plugin without creating an add-on. As the loader creates the add-on, we can intelligently handle duplicate items to allow plugins to be cross-compatible with less effort required on the mod developer's end.

## Features
AGE will be able to be ran in a standalone configuration or with Graft. This allows AGE to be used for development outside of Graft. Marketplace teams (via a license) or even just solo developers could use it on their own projects as well. AGE is more than just an add-on generator, such as:

- A graphical JsonUI editor (the current UI standard in Bedrock)
- A preview features to show you how the game would interact with your add-on before loading the game, cutting down on development time.

### Faster Add-on Development
One of the main benefits of using something like AGE is speed.

AGE speeds up add-on development, as it allows for creation of custom presets and components in a developer friendly way. For example a developer could have a lot of different wood blocks that share a set of components. Instead of copying the components across different files, they can just make a wood block with the said components and AGE would handle the rest.

### Fast Add-on Updates
AGE can update older add-ons if Microsoft breaks the add-on API, we can update them without any bother. As the backend of the generation can be updated while the user end of the API can stay the same.

### A Standard
We plan to implement APIs to allow for a standard implementation for most things. This could span to ores, crops, and all of them would work without patching add-ons. Add-on developers tend to find a method to do something and percid to gatekeep their discoveries. AGE attempts to combat this by implementing the difficult parts into an easy-to-use API.

### A Java Like Development Experience
AGE allows for a developer to simply extend any class and or interface with the API in a classical programmatic way.

# The PDB

## What is a PDB and What Happened to It.

The creator PhoenixSC made an informative, and well written video about the topic. https://youtu.be/Z5np5hPNKjc?si=OD2_biTml5-BBNYn

# Ways to get the PDB
## Reach out to Microsoft
This method would be less likely than a featured server but is the method we would prefer. This involves finding a vector to ask Microsoft to partner with Bisect (and by extent the Graft team). It would require Bisect to enter into a partnership with Microsoft to get the PDB files.

### Pros and Cons

| Pros | Cons |
| --------------------------------------------------- | -------------------------------------------------------------------- |
| The Most Cost Effective | Less likely to receive the PDB |
| Creates a relationship between Bisect and Microsoft | Microsoft may impose limitations on what can be open source |
| Doesn't require any additional commitments | Some points of communication do not guarantee a rejection a response |
| A Cross-platform mod loader could be made. | Graft may have to be closed source |

## Featured Server
Minecraft Bedrock has a select number of servers that are accessible by console users. Platform restrictions don't allow them to have an "add server" button, so Microsoft created featured servers. If people have the resources to host and maintain a server for a large number of players, they are able to apply to become a featured server.

When it comes to profit earned by the server, we *want* to split it with Bisect.

### What makes US unique
At the moment the featured servers don't contain any vanilla based survival modes. While Lifeboat does have a survival mode, they use a private fork of PocketMine meaning they don't have all the vanilla mechanics. Using AGE, we would also be able to create powerful features that allow us to expand from the vanilla base.

*There is an opportunity here*

The unique thing about a survival experience is the level of personalization a player can put into something. The reason this is different from the other servers on the market is due to how unpredictable the survival experience is. The average player on a survival server will try to do something to be a part of a group. The current servers make themselves with this large identity, while truly forgetting what Minecraft is about, self expression.

### What do we need from Bisect
- Funding
- Server hosting in different regions

### What Bisect Gets

#### A Reputation in the Bedrock Space
When a featured server is done well there is acclaim to be had with such an achievement. It would be a leap into the Bedrock space where Bisect can utilize their resources. People in the community would be likely to choose Bisect for their next server as they would know how it would perform from their experience on the featured server. This would allow us to showcase our tools we maintain without the extra marketing costs. Blockception owns Galaxite, they are well respected in the commuinty for their commitment to developer tools.

#### A Potential Return
Here is a list of some avenues for a potential return on investment:
- The use of the marketplace to sell things on and based around the server.
- Different cosmetics that players can purchase.
- Monthly subscriptions/ranks that would give people access to different things around the server. This would be a discussion about what would and would not be paid to prevent community dismay.

### Pros and Cons
| Pros | Cons |
| --------------------------------------------------- | ----------------------------------- |
| Most likely to gain a full PDB | Has a higher cost of investment |
| Highest potential for a return on investment | Long time before any return |
| Server is shown to all Bedrock players | Longer development times |
| You have a captive audience with little compitition | Graft may have to be closed source |
| Graft would be developed primarily for Linux | |

# FriendConnect
## What is FriendConnect
[FriendConnect](https://github.com/GraftMC/FriendConnect) is a project for Minecraft Bedrock/ (Java with Geyser) that allows players to join servers via the in-game friends tab. The most notable differing factor is, that console players can connect to servers without using an advanced method.

*Thats it.*

[A Video Showcase](https://youtu.be/77qXotN9jGo "A New Realms Replacement, A new method for joining servers on console.")

## Notable Features
* FriendConnect supports the use of many accounts with one session to cut down on bandwidth used.
* It automatically fetches the protocol version of the server and applies it to the friend session.
* Auto friending of accounts that follow each account.

## The Rewrite
The plan is to rewrite the project in Go, this choice was made due to the apparent struggle people have with downloading NodeJS and setting up the project. Using Go will give us access to the GopherTunnel libraries.

## New Features
* A way to rotate the MOTD displayed to the client, might investigate animating the text in the MOTD.
* Better friend management for distributing the followers on each account.
* A server selection system that would allow players to select a server of their choice.
* IPV6 support

### How does this benefit Bisect?
This should allow Bisect to grow their presence in the Minecraft Bedrock space. As console players make up a good portion of the player base, this would allow server owners to attract this audience.

### Stuff to investigate
There are a few ideas that have been thrown around, we could attempt them depending on if anyone at Bisect is interested.

* An App: It wouald allow players to host it on their mobile device to reduce on the hosting workload.
* Integration with Hummingbird and or Graft.
* Include the use of the LAN method as another inclusion for an App.

### The *But*
When FriendConnect was created, it was known that the concept was skating on thin ice. There still is uncertainty about whether this method is viable, as it lies in a grey area. Each method for joining servers on consoles operates in a grey area, which is something that is not really recognized. Recently Josh made a post on the Androecia Discord server asking about the communities experience. The responses that were received told of how this method has allowed servers to branch out and grow larger with the console player base. There is someone who has been hosting it since v0.1 with 12 accounts, they have only lost one account in the past two years. Another has been using it for a year and a half with only one account giving them an issue. When they agree to use FriendConnect, they hold any responsibilities that come with hosting it.