spockbotmc / rikerbot Goto Github PK

There's no reason to crash the bus because of a single bump in the road. Fix IO Core so that it can recover from and abandon packet buffers that fail to decode. That way every protocol bug doesn't become a show stopper for other development.

Error occurs when starting the SimpleClient in the example plugin, if the server the client is connecting to is up. Installation seems to be fine, no errors when importing.

The full traceback is:

Traceback (most recent call last):
  File "/<path>/.venv/lib/python3.9/site-packages/rikerbot/plugins/StartPlugin.py", line 30, in handle_connect
    packet.username = self.auth.username
ValueError: invalid null reference in method 'ServerboundLoginStart_username_set', argument 2 of type 'std::string const &'

Server output is:
[14:24:36] [Server thread/INFO]: /[0:0:0:0:0:0:0:1%0]:48808 lost connection: Disconnected

Tried on 1.16.4/5 server, on Arch.

dec_position bitwise operations are not implemented in the correct way, creating values that cause segfaults if used as is

Right now there is not sufficiently advanced compiler support on Windows to compile Riker, but I'm creating this issue for tracking purposes. We need MSVC to add support for abbreviated function templates, or Clang 12 and its CTAD aggregate support to be released.

Clang trunk right now can do neat things that the NBT implementation really wants, like recursive CTAD. So when that makes its way into a release we'll likely migrate the Linux build as well.

Though the instructions in the docs could be quite useful, it would be simpler if there was a pip installation.
I do not have the capability to run the setup described in the docs, and I'm sure others don't either, so if it were pre-setup, and all you have to do is run the pip install, it would increase the availability.

The installation was abnormally fast but seem to have worked without any error:

Platform: Windows 10
Python version: 3.8

Milestone on deck per feature roadmap

This feature is mostly complete, with only housekeeping left to be done

• Working parser (Still needs MultiBlockChange)
• C Interface core for accessing block data 🏃
• Python plugin for loading and dependency resolution

if you use SMPMap::get to get a x,y,z with a negative x or z, you end to lookup happens in the wrong chunk.
This is because x / 16 is not rounded the same way as x >> 4.
Fixing this in SMPMap::get fixes the case -x,y,z but if z is negative, something else seems be wrong too, since I then get garbage instead of the exptected result.

One way to see this in action is to build a tower, and look for it under the player (loop surrounding blocks), there should be only 1 block in a plane under the player, if x is negative the coordinates of that block are shifted by 16, if z is negative block that should have air have garbage in them, guessing there is something wrong with hashing of chunks

Not sure if this is a bug or just misunderstanding. The block_ids returned by SMPMap::get do not map do not map correctly with minecraft_data in most cases?

Am I missing something or is it a bug?

Using SimpleClient, I can connect to an online server, but after the ClientboundLoginSuccess event is emitted, signalling that the client should swap to Play mode, no more events are emitted. The next expected packet/event should be the "Join Game" event (which I think is called "login" in python-minecraft-data).

Setup:
running both client and vanilla server (online_mode=True) on Arch, using mc 1.16.5

edit: Same behaviour if online_mode=False

The example plugin is a good stop gap, but we desperately need documentation for every default plugin and interface, as well as the SimpleClient, and how to build your own client.

These things move fast, so there's some weight to not getting overly invested in docs right now. Still, it is easier to update docs than it is to write them whole-cloth for a late stage project. Skeleton work now will pay off later.

Not going to assign this as an August issue, but sooner rather than later I'm going to need to spend a couple days writing comprehensive on-boarding docs.

Lots of libs are providing their own pre-compiled binaries so it's a one step installation. Anyways, for this however, the installation is very hard. Lot's of error and stuff. For someone who uses python, C++ is a very hard thing to grasp. Tbh, idk what I'm doing.

Is there any way you can provide pre-compiled binaries. The project itself is great and intuitive. It's just very hard to install

I've implemented these for PluginBase locally, thought it might be nice to contribute to the repo too.

I find it practical to be able to have multiple methods called when a single event fires within the same plugin, e.g. adding a debug callback to an event that already has a callback method. Not currently possible within a single PluginBase instance as the events dict maps string -> string.

I also find it simpler to be able to use a decorator to subscribe methods to events, rather than having to edit the events attribute each time I want to make a change. More useful if the Plugin file is very long. Also makes it a bit easier to understand what a method does at a glance.

This issue is manly a reminder for myself of issues I've run into writing the setup.py file for RikerBot.

Riker is a weird project, it is supremely ill-suited for building with distutils and I have very little interest in supporting that workflow. This is fine for Windows where we can just distribute a binary wheel and be done with it, and that's the workflow that setup.py currently supports. But in the Linux world people want it both ways, they would like to install with PyPi and compile things locally, which means distutils.

I'm currently partial to the idea, that if you want Riker on Linux just build it yourself. Maybe in the future we can look into a Pkgbuild or something and install straight to site-packages, Python be damned. Or maybe someone will come along and make the build project work with distutils and I won't have to think about it.

Just waiting on PrismarineJS/minecraft-data#326, then update the default protocol target in CMakeLists.txt

Milestone on deck per feature roadmap

• Basic physics C interface
• Python plugin
• Walk
• Fall
• Jump
• Sprint
• Swim

Almost definitely something wrong with our topBitSetArray implementation, though I don't see anything obvious at a glance. Investigate when I have more time and a better plugin for dumping packets.

MCSlot and ultimately cpp-nbt are also possible sources of bugs to dig through. Somewhere in those three lies the answer.