kcinnaJlol

Looking at the image you sent, i can see the borders around the bars are blue (they should be gray-ish). This means you're using either a T2 GPU or a T3 APU, meaning the resolution of your screen is capped at 80x25, while a T3 GPU+screen has a max resolution of 160x50. So to fix your GUI being too large, you'll have to put a T3 GPU inside your computer. As for the reactor not starting, check to make sure the addresses you put inside your config are correct. You can copy the address of an adapter by control+shift+right-clicking on it with an analyzer, and you can paste said address into th

Each component function (should) also have docs on the function itself, accessible by causing the function to be converted to a string. Else you can just attempt to read the source code to try to understand what it does.

It also needs an OS to boot from. Attach a disk drive and insert the OpenOS floppy in it (dark green)

Robots should not be able to connect to external components, not even wired networks. This is definitely a bug. For now, you can have the first parameter of each message be some unique number and not accept any message whose number you have already encountered in the past 30 seconds.

From reading the Mekanism source code, Mekanism in itself supports energy counts until the 63 or 64 bit number limit, or the double number limit, depending on what branch you are reading. This probably means that your problem is an integration issue, so you should create an issue to Mekanism, as they made the OC-Mekanism integration.

This is normally impossible, as OpenComputers hides item Nbt data by default (to ensure no one can read possible secret data that is hidden in the nbt data) You can, however, change config option 'allowItemStackNBTTags' inside 'vanilla' inside 'integration' to 'true', allowing you to read the NBT data in GZIP format. However, the data card uses ZLIB. Fortunately, from what I can find, GZIP is basically ZLIB with a header, so it shouldn't be hard to make a program that ignores the header and then decompresses it as ZLIB.

I'm assuming that you fly your drones above the build limit to ensure that you don't hit obstacles Call one point (probably either the start or world origin (x 0, y 0, z 0)) the 'origin', represented as x 0, y 0 and z 0. Then you can put the start, every destination and every recharge node in a list with their coordinates relative to the origin and type and have your drones keep their x y and z position relative to the origin in a (or multiple) variables. When your drones move, they also add the dx, dy and dz arguments to their relative x, y and z respectively. You can the