mirror of
https://github.com/zaaarf/lillero-book.git
synced 2025-03-28 06:01:36 +01:00
added loader chapter stub
This commit is contained in:
parent
dac703cce5
commit
7bb66f655e
5 changed files with 26 additions and 2 deletions
|
@ -36,6 +36,6 @@ For disclosure, I'm excluding [Lillero-mapping-writer](https://github.com/zaaarf
|
|||
Incidentally, its file size makes Lillero far more portable than Mixin (technically, this just isn't true for those modloaders where Mixin is bundled, but that just isn't playing fair). For instance, if you were to bundle it in your mod, you'd only need to bundle the core library; if you were to use the recommended flow for modern Minecraft Forge, you'd need just that plus the refernece loader. On top of this, there are just the classes generated by the processor, which get compiled normally into your mod. You may be tempted to assume that those make up for the huge difference in space from Mixin... but no, not really. Mixin is just that bloated.
|
||||
|
||||
### Simple
|
||||
A glance at one of the generated classes should be plenty for anyone experienced enough to figure out how the thing works.
|
||||
A glance at one of the generated (or manually written, in environments which don't use the processor) classes should be plenty for anyone experienced in Java to understand the logic of the program.
|
||||
|
||||
Anyone wishing to read up on how it works (not that I think it's a masterpiece or anything like that) can do so by looking into the repo. I've tried to keep the codebase clean and easy to follow. For anyone wanting to dig deeper, they'll find that all code in the Lillero project is heavily documented, perhaps more than necessary, with a Javadoc for every last method and field and plenty of comments explaining step-by-step particulary long methods.
|
||||
Anyone wishing to read up on how the code generation works (not that I think it's a masterpiece or anything like that) can do so by looking into the processor repo. I've tried to keep the codebase clean and easy to follow. For anyone wanting to dig deeper, they'll find that all code in the Lillero project is heavily documented, perhaps more than necessary, with a Javadoc for every last method and field and plenty of comments explaining particularly long methods.
|
||||
|
|
2
src/3_loaders/example.md
Normal file
2
src/3_loaders/example.md
Normal file
|
@ -0,0 +1,2 @@
|
|||
# Example: Minecraft Forge 1.12 Core Mod
|
||||
|
17
src/3_loaders/loaders.md
Normal file
17
src/3_loaders/loaders.md
Normal file
|
@ -0,0 +1,17 @@
|
|||
# Loaders
|
||||
You have fully figured out patching by now, but you can't or won't use any of the loaders we have already implemented, and want to build your own. This chapter will explain what is expected of an up-to-standard Lillero loader, by building an example one. If you want to know more about the topic, [`lillero-loader`](https://github.com/zaaarf/lillero-loader) and [`lillero-mixin`](https://github.com/zaaarf/lillero-mixin) can serve as ulterior examples.
|
||||
|
||||
Be mindful, however, that writing a loader is heavily dependant on the runtime environment of your program: as such, there is no "general recipe" to building a working loader. This section is mostly focused on common pitfalls and on the sort of consideration you have to make when writing your own loader.
|
||||
|
||||
## Getting the classes
|
||||
> This section will vaguely explain the part that is the most implementation-specific: converting the classes into a format that you can feed to the loader. If you are plugging Lillero into an existing ASM-friendly environment, this step has most likely been already done for you.
|
||||
|
||||
There is one rule which generally can't be broken: your patching must happen *before* the class is loaded.
|
||||
|
||||
> Actually, some modern JVMs support hotswapping classes, but if you know about them, have guarantees that your application will be running on those exclusively, and know how to do that, you probably don't need me to explain this to you. Not to mention that I know nothing about the topic.
|
||||
|
||||
The typical approach to doing this is to write a small bootstrapper program that will read the target's classes, patch them if necessary, add them to the classloader, and then invoke them. A small proof of concept of that might look like is provided below, but I won't elaborate further on this topic: to talk about application or game modding in general goes far beyond the scope of this book, and I'm not even remotely qualified enough to talk about the topic.
|
||||
|
||||
```java
|
||||
TODO
|
||||
```
|
2
src/3_loaders/requirements.md
Normal file
2
src/3_loaders/requirements.md
Normal file
|
@ -0,0 +1,2 @@
|
|||
# Requirements
|
||||
TODO
|
|
@ -26,3 +26,6 @@
|
|||
- [Proxies](./2_patching/writing/proxies.md)
|
||||
- [Guidelines](./2_patching/writing/guidelines.md)
|
||||
- [Mitigating Collisions](./2_patching/writing/collisions.md)
|
||||
- [Loaders](./3_loaders/loaders.md)
|
||||
- [Requirements](./3_loaders/requirements.md)
|
||||
- [Example](./3_loaders/example.md)
|
||||
|
|
Loading…
Add table
Reference in a new issue