Historic Server Versions

[gentlegiantJGC]

Is your feature request related to a problem? Please describe.

It this supposed to work with historic versions of the Bedrock server? I am trying to use this to export information from the server (block, biome, ...). It works correctly with the new version of the server but the old versions give errors when loading the server.

Creating bedrock_server_mod.exe works correctly and I can compile the plugin using the 1.9 pdb file but I get errors that symbols cannot be found when running bedrock_server_mod.exe

Do I need to generate an old version of the SDK or compile other code against the old version. If so how do I do that?

Describe the solution you'd like

I would like to use this for every version since debug symbols were included.

[KawaiiNahida]

LLAPIs is unavailable in previous versions if your goal is to access those basic hook apis, you would be able to remove LiteLoader.dll and let LLPreLoader.dll(which is basically a injector that provide basic hook and symbol query apis) run as LLCore (you are also required to link LLPreLoader.lib instead of LiteLoader.lib)

[gentlegiantJGC]

Yes my goal is to access the most data I can with all past versions.

I am very new to C so sorry if it takes me a little while to understand things

So I need to delete LiteLoader.dll from the root. Do I need to delete plugins/LiteLoader as well?

By LiteLoader.lib you mean PluginTemplate\SDK\Lib\LiteLoader.lib? Can I get LLPreLoader.lib from somewhere or do I need to compile it myself? If so do I need to compile it for each server version?

[yqs112358]

Thanks for your attention to LiteLoaderBDS. And I think more information about LiteLoaderBDS project structure can help you understand the problem better:

LLCore

LiteLoaderBDS use the techonlogy called hook & symcall to interact with BDS functions at the botton level. With this two function, we can inject our code into BDS as we want, and call BDS function when we need. It is those what called "plugins" actually do. Because these two functions are the most important basic function for LL, we split them into a seperate sub-project called "LLCore" & compile into the binary LLPreLoader.dll. This dll works for two goals:

1. Provide a tool to inject LiteLoader.dll into BDS when it launch
2. Provide basic bottom APIs like hook & symcall

LL Main Part

Then on the platform of LLCore, we created a nuge number of APIs. Part of them is tools (like those in SDK/utils) & events to help developers, but the most important is those MC headers which we generated from PDB. In previous days when developing plugins, you need to use hook & symcall to hook BDS apis and do what you need. But these functions need some knowledge about OS layer, and is complex, hard to write, too.

In order to solve this problem, we have created a toolchain to auto-generate symbols of functions in MC & make a lot of MC headers, then create a SDK repo. When develop nowadays, what you need to do is only:

1. include SDK headers (eg. #include <MC/Player.hpp>)
2. write code like native developers (eg. player->sendText("hello world") ).

When you load your plugin in BDS, LL will link those functions to correct address in BDS process, and call them. It is much more convinent than before.

Migrate LL between versions

Just like what said above, migrate LL between versions is a little complex because we need to consider this auto-generated toolchain. Those MC headers in SDK repo is generated for the newest version of BDS, and they cannot be used for old versions of BDS because symbols will always change a little between every two neighbor versions.

The Entry point no found problem you posted above is caused by this problem.

If you tried to migrate LL SDK to another version, what need to do is to let LL project can be compiled on that version of BDS. When you compile LL project for the first time, you may see a dialog said "Please choose the folder contains bedrock_server.pdb ..." and it means you need to choose pdb file in that version. The toolchain will generate necessary data & generate libs what is needed in SDK folder.

Now Problem is...

The toolchain is created by us, it is not fully tested and is being fixed in the process of upgrading with BDS versions. So some bugs is inevitable and the migration to old versions may be faced with some problems, like fail to generate or others. Since the future work and maintance of LL is very heavy, we may not have enough time to migrate LL to old version. We need the help of community developers. If you are interested in our work, I think you can have a try to help us find & fix possible problems. If most of potential bugs is solved, I think the migration work will as easy as a cake, at that time.

Another solution

Sure, in other words, these tools is so convinent & it helps you to develop plugins much quickly. But they also lead to hard work in migration. If what you need is just a small numbers of hook & symcall for a limited range of functions, you may try to only install LLPreLoader and use those basic APIs (hook & symcall). Since they are not related to BDS functions, they do not need any migration work between versions. But you may take a lot of time to develop a complex plugin & will be faced with bugs more easily.

At last, thanks for your Amulet Editor a lot. It helps numbers of Bedrock player to finallly get a way to edit maps easily (including me). @gentlegiantJGC 😁

[gentlegiantJGC]

Thanks for the response. I think that was mostly how I understood it.

I can totally understand not wanting to support past versions with the higher level API. Supporting multiple versions can be a pain. All I really need is the vanilla API to do what I need.

I have been playing around and have made some more progress. I think I have removed LiteLoader and LLPreLoader is now loading my plugin.

I think the next hurdle is the header files. You said there is a way to create them from the PDB file. How can I do that?

I am glad you are enjoying Amulet. That is the reason why I am trying to access this data to make it easier to build the specification data.

[KawaiiNahida]

Thank you for your interest in our project, we are very happy to share our knowledge about BDS

• Headers is generated by our internal project HeaderGenerator (we will not make this tool public in the near future) it is designed and verified to work only on recent versions (>=1.16.0) For earlier versions, it may have an impact on the memory structure of virtual tables due to the partial rtti and other information it contains. But if you only need to call non-virtual functions (functions starts with MCAPI), or call virtual functions by manually specifying the member type
• Some of those vanilla api are only available in specific versions, and the memory layout of structures may differ significantly or completely from the current version, so you will need to write the relevant code for the target version

we are happy to provide the data that HeaderGenerator generated for those old version and the tools to generate headers from these data to you. But dueto the potential legal risks associated with eula, we cannot release those data publicly, so we will send them via email/discord, etc.

[yqs112358]

Welcome to join our developers telegram group https://t.me/+pTDHsVifduEwZTM1 we can chat more happy here and you can chat with wang personally for those data of generator toolchain

[yqs112358]

@gentlegiantJGC Excuse me, I have a problem that what chat software mostly MC developers use. Currently we use Telegram for international development chat, but is Discord a better choice? or line? whatsapps? We don't very know about IM software usage situations beyond China. Can you tell something about this to us, thanks.

[gentlegiantJGC]

We mostly use Discord because it allows you to have a community with sub-chats and lots of other tools for managing a community.

[yqs112358]

？别乱close