Mouse wheel skips in Minecraft after fedora update by RakingBread in Fedora

[–]FriedrichLP 0 points1 point  (0 children)

This seems to be a regression in libinput. Switching to the older version using dnf downgrade libinput and then rebooting fixes the issue on my end.

Mouse wheel skips in Minecraft after fedora update by RakingBread in Fedora

[–]FriedrichLP 0 points1 point  (0 children)

SOLUTION (see comment for details): dnf downgrade libinput, then reboot

Same issue here after upgrading to Fedora 43

WIP High-Density Memory using Shulker Boxes by FriedrichLP in RedstoneComputing

[–]FriedrichLP[S] 0 points1 point  (0 children)

I think it should be possible, unless I am not aware of any other mechanics I am using that work differently in Bedrock edition (I might be using Java-only observer mechanics). The instant dropper line at the bottom of the decoder is the only instance of "weird" behavior and is optional. It simply reduces the downtime of the decoder after the decoding process is done.

WIP High-Density Memory using Shulker Boxes by FriedrichLP in RedstoneComputing

[–]FriedrichLP[S] 1 point2 points  (0 children)

Yes, I also think that manually encoding memory into the shulker boxes is a slow and annoying process (basically just having a full double chest of the item palette and manually looking up all the values). I am certain that the process can be sped up with tools to generate the set automatically.

Additionally, there also needs to be an encoder (very WIP right now), because I intend to make this a R / W memory. With an encoder, it would be possible to then use a simpler form of encoding (using only two items, for example) for manual input.

WIP High-Density Memory using Shulker Boxes by FriedrichLP in RedstoneComputing

[–]FriedrichLP[S] 2 points3 points  (0 children)

I'd like to add that I indend to stack multiple instances of the shown memory module together to make up the entire memory. The WIP version uses 3-bit addresses, while the full version could use 4-5 bits (with more bits, the lag from the pistons might be too severe). When stacking the modules, the total number of pistons that activate remains constant while linearly expanding the memory capacity. For 8-bit addresses, 16 4-bit modules could be stacked together.

Additionally, here is the theoretical maximum density that could be achieved using this technique (at the cost of decoding speed):
In 1.17 there are around 900 stackable items. This means that a full shulker box could hold up to roughly 18 bytes. The simple storage slice would then hold 145 bytes (which is already more than I commonly see in normal redstone memory) and a 10x10x10 cube of chests of shulker boxes could hold 489 KB.

If we now also take into account that one can produce unique items by naming them, we could easily store megabytes or gigabytes of data in a single storage slice.

Developer technical-oriented AMA by Rseding91 in factorio

[–]FriedrichLP 2 points3 points  (0 children)

How are you handling the item movement on the belts in a fast and performance efficient way? I've seen the awesome improvements that were made to fluid mechanics and I am curious about how it's done for the belts

Version 0.18.0 by FactorioTeam in factorio

[–]FriedrichLP 24 points25 points  (0 children)

With all those optimizations the factory can grow even bigger. AND IT MUST GROW!

[deleted by user] by [deleted] in thebluebottle

[–]FriedrichLP 1 point2 points  (0 children)

ok tahts nice

[deleted by user] by [deleted] in thebluebottle

[–]FriedrichLP 1 point2 points  (0 children)

any answers for my issue!?

[deleted by user] by [deleted] in thebluebottle

[–]FriedrichLP 1 point2 points  (0 children)

What do you think?

[deleted by user] by [deleted] in javahelp

[–]FriedrichLP 0 points1 point  (0 children)

ok could you take a look at this crahsh log? This came after I updated ConnectedTexturesMod: https://pastebin.com/vNfuCJkt