Vanilla Injection Script

Injected Vanilla
Video Structure

Greetings everyone, this is Energyxxer. I've created a system that allows the communication between a vanilla game and an external program, providing a way to make complex systems that would otherwise be difficult or even impossible to do with command blocks. Here are a few examples of what this can do:

List of demonstration ideas:
	Warp system 				(Chat detection)
	Chat bot    				(Chat detection)
	Procedural tree generation 	(Command execution)
	WorldEdit   				(Raycasting and chat detection)
	Physics gun 				(Raycasting, picking up entities and launching them)

HOW IT WORKS
Most of the work required to run these contraptions is being done by another program, and then instructions for Minecraft to run are added, or "injected" into the world in the form of commands. To achieve this, we need a few things:

INPUT

First, we need something that allows the program to read input from the game. Simply put, this is the log file generated by the game.
Each time a command executes or a chat message is sent, it is written to a latest.log file within the logs folder of the minecraft directory. This is how Minecraft communicates with the program.

That was simple. However, we still need something else.

OUTPUT

We need something in-game that can access information from outside the game.
Luckily enough, we have structure blocks.
Structure blocks read .nbt files inside the world's structures folder. This is the main idea behind this concept.

First, we have a redstone clock powering a structure block. This structure block is trying to load a file called "vi0". However, this structure file does not exist in the world's structures folder, so the structure block is essentially doing nothing at the moment; that is until the injection program decides that it wants to do something in-game. So, the program creates a structure with a few command blocks inside, and saves that structure under the name "vi0".

On the next cycle, now that there *is* a file called "vi0", the structure block will realize that there is now a file to load, and so it will spawn the structure, with all the commands in it. Since these command blocks are set to Always Active, they will trigger immediately, running the commands inside.

This works fine initially, but what happens if the program wants to do something in-game a second time? After all, whenever the game loads a structure, it will "remember" it until the world is reloaded, even if that file changes. So, even if the program did generate the file again, the game would not see it as a new structure.

The way around this is to generate structure files with different names every time.
The original structure block had zero offset, meaning that it would replace itself after loading. Additionally, the generated structure also had a structure block at the origin. This means that, when the structure "vi0" is loaded, the structure block would be replaced with another one that's trying to load "vi1" instead. The external program will remember the last number it generated, and will continue generating structure files with the next name in the sequence.

Of course, there is a lot more behind the scenes. The external tool needs to remember the last number it generated when relaunched; the structures folder shouldn't have more than 15 injection structure files at any one time; and it shouldn't generate structures if the game is paused or closed.
All of these things have been considered to make the system as optimized as possible.

SOURCE CODE
I have left the Java code for the injection library in a GitHub repository linked to in the description, as well as the examples shown in this video for you to try out.

That's it for now, thanks for watching.

[...]