kcinnaJlol

On 3/30/2024 at 12:40 PM, Bjoerniboii said:

https://postimg.cc/Th5b4Sds

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 the config with either the Insert key or with the middle mouse button (note using the middle mouse button moves the cursor first!)

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 then set 'routes' from the start to each destination (probably just a list of the indexes of the different nodes in order) and have the drones go to each node and, do one of the following according to what it is:

• Start: Report to the warehouse that you are home, recharge and listen for a network message of a new order and grab required items
• Recharge node: Recharge until battery is about 99% full / whatever is needed to get to the next recharge node
• Destination: Drop off items inside a chest and maybe also recharge

Then, you can listen at the warehouse for 'new order' messages and send them to one drone from the list of 'ready' drones and remove said drone from the list

When a drone reports that its home, you can add it to the list of 'ready' drones to use when a new order comes in.

You can send most of this data (nodes + routes) to the drone over a wireless network when the drone starts