1.19.2 Version! #103
1.19.2 Version! #103
Conversation
|
Hm. Nevermind some werid things seem to happen serverside... WIP |
|
I'd rather avoid having IDE specific configuration files. And while the devcontainer stuff is interesting, I'm unsure why it's necessary: all you need is Java 17 and you can compile and run the project using the Gradle wrapper. |
|
But also, why the update to 1.19.2 instead of 1.20.4? |
I'm on NixOS, had no clue if java was gunna just work, so I tried the devcontainers. Mistake. Ill spend some more time this afternoon to see if can finish the port. |
Because my own server is running 1.19.2, so that's the version I primarily care about. Thought I believe a working 1.19.2 port should make a 1.20.4 port a lot easier. What I discovered yesterday (CEST) is that I'm an idiot and also need to adjust data transmission to the new world gen? At least that seems to be the issue. That would be work that no longer needs to be done for 1.20.4 if I get 1.19.2 running. |
|
Yeah, MapSync doesn't have any way to transform chunk data according to the client version, which effectively deprecates existing chunk-data. If you try to send a 1.18.2 chunk to a 1.19.2 client, stone bricks will instead be interpreted as purple-stained glass. The best-case scenario for this is just having weird-looking chunks, but I can imagine this causing more serious problems. MapSync really needs some ViaVersion/ViaBackwards style packet transformation. |
|
Okay made some progress, Though things are still far from working correctly. One of the issues I had is that the docker version which pulls from GH, is not running the most recent version of the code. This causes issues with the buffer reader, I believe #89 is the breaking change here. Building with yarn locally on the server instead of docker gets it working to the point where data is being transmitted and the database on the server, built, that inconsistency was annoying to debug. |
There was a problem hiding this comment.
yea this makes no sense to me, lockfiles are extremely important. if this project was migrated to pnpm or something, sure, but the total absence of a lockfile should not be allowed.
| @@ -284,7 +284,7 @@ void setUpEncryption(ChannelHandlerContext ctx, ClientboundEncryptionRequestPack | |||
| } | |||
|
|
|||
| private static byte[] encrypt(PublicKey key, byte[] data) throws NoSuchPaddingException, NoSuchAlgorithmException, BadPaddingException, IllegalBlockSizeException, InvalidKeyException { | |||
| Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); | |||
| Cipher cipher = Cipher.getInstance("RSA/NONE/OAEPPadding"); // RSA_PKCS1_PADDING is no longer supported for private decryption | |||
There was a problem hiding this comment.
It may be worth switching to websockets (#43) and letting TLS do all the encryption, though this does add complexity in terms of self-signed certs.
There was a problem hiding this comment.
if you run map sync behind a reverse proxy, (as should be the recommended setup anyway,) self signed certs become less of an issues especially with many featuring lets encrypt integration, or highly popular tooling around that.
There was a problem hiding this comment.
That's true, but it also adds more complexity to server setup: the client will no-doubt expect to connect to a wss:// target, but running the server directly would not produce a wss:// target to connect to, which likely means a higher reliance on docker (or similar), which is not particularly noob-friendly. And this is MapSync, we shouldn't expect our users to be highly technically literate. Setting up a MapSync server should be as easy as running those OTT executables that were handed out to people stuck in Wholefoods.
There was a problem hiding this comment.
I mean that's a somewhat noble goal, I just feel like its unrealistic that many will run the server at all. Who knows though, if that is the case for whatever reason, we could always embed a lets encrypt library and do it all ourselves.
There was a problem hiding this comment.
It just seems like a bit of a zero-sum game to do it like that: switching to websockets makes development easier since encryption and packet framing is all done for you, but requiring a third-party reverse proxy makes server setup and maintenance more difficult for our users. If it's a choice between the two, I say we choose ease of use. But if we are still keen on using websockets, we could automatically generate a self-signed cert if the configuration doesn't already specify a pre-existing one. That way we wont be spamming Let's Encrypt anytime someone spins up a development server.
Hi, today I got it working on 1.19.2. Its all bit messy and I have not quite found the time to test the fabric version, but the forge version runs! Both versions build...
(I frist tried code-spaces because I didn't wanna go through the hastle of setting up a dev environment... turns out those are more hastle)
First time I am ever really doing work on a minecraft mod but I would love to develop this further, I think it's a really cool project.
THIS PR IS NOT READY TO MERGE
I still need to test the code and tbh make some improvements.
But if anyone needs a 1.19.2 version, this should build.