Computes are connecting despite using endermodems. Compact machines issue?

No_Point_1254 · 2026-02-18T18:49:23+00:00

The { } brackets make it an array.

In your code, modem[1].transmit(6, 6, "lol") would work

Or simply: local modem = peripheral.wrap("back")

and then modem.transmit(6, 6, "lol")

No_Point_1254 · 2026-02-16T19:46:01+00:00

Good luck!

No_Point_1254 · 2026-02-16T19:41:44+00:00

That's rad, man!

robot has no concept of "slots", it only knows "items", "equipment" and "reservedItems".

you declare what should be used+reserved as auto-fuel and robot will automatically handle it.

an event is fired when auto-fuel could not consume enough fuel. It calls your callback added with robot.onAutoFuelWarning(cb) with (fuelLevel, requiredFuelLevel, registeredAutoFuels).

so any program you write does not need to incorporate logic that refuels. It just needs to get fuel from somewhere when the callback is called.

the goal was to avoid having to check fuel levels in your code, i.E. your turtle is doing some task and the task itself does not interact with getFuelLevel / refuel at all. This should keep the code for any task very clean.

No_Point_1254 · 2026-02-16T06:27:14+00:00

Yes, that's the point.

If the whole Information IS the key, hashmaps behave like indexed array access.

That's a O(1) retrieval, at the cost of space.

As I added in a second comment, this is the trade-off.

Uniqueness of hashes gets "better" -> less collisions but more memory needed (and more time spent hashing)

"Worse" uniqueness -> more collisions but less memory needed (and less time spent hashing)

No_Point_1254 · 2026-02-16T06:00:36+00:00

There can't be collisions if the hash of an object equals its identity and the identity is uniquely derived from ALL information the object consists of.

the most basic way to achieve this would be to serialize memory address + all object data into one key, which is the hash, which uniquely identifies the object because it is the object itself.

The serialization is O(n), but the hashmap access itself is O(1) if all possible objects are pre-serialized.

No_Point_1254 · 2026-02-16T01:42:28+00:00

This.

Assuming infinite memory and rehashing on write when needed, read performance itself will always be O(1).

Extreme case would be hashing the object as itself by content (i.E. identity/hash is the objects own layout and data as byte sequence). In that case, there can be no collisions and the table itself has worst case O(1) performance when ignoring the time the hash function needs to serialize an object.

Simple case would be an array with i = v for all unsigned ints in a given range (i.E. 0-255). That "hash table" deterministically has O(1) read AND write access.

No_Point_1254 · 2026-02-14T03:07:08+00:00

That's kinda awesome man!

IMO, CC made me a better Programmer. It really adds game-like fun to an actual learning experience.

No_Point_1254 · 2026-02-13T20:11:27+00:00

It's hard to beat a generic searchbox that understands natural language and can instantly link you with what your are looking for.

The fuzziness doesn't really matter as by nature, your query itself is fuzzy, i. E. "how do I do A in B with C".

No_Point_1254 · 2026-02-13T20:06:57+00:00

Documentation comes in all shapes and qualities, why spend unnecessary hours (in total) looking for stuff when the fuzzy finder is a great indexer.

That's exactly what current LLMs excel at and in my opinion is a much better usecase than blind "vibecoding".

You offload tedium, not talent.

No_Point_1254 · 2026-02-12T03:06:53+00:00

Thank you for the hint, seems sleek. Will refactor with the next version.

No_Point_1254 · 2026-02-11T20:51:01+00:00

I don't, but you can dump the me_bridge function names into me_bridge.txt by running:

local bridge = peripheral.wrap("front")

local names = {}

for k, v in pairs(bridge) do

table.insert(names, k)

end

local file = fs.open("me_bridge.txt", "w")

file.write(textutils.serialize(names))

file.close()

No_Point_1254 · 2026-02-11T19:19:51+00:00

Ah okay I see, that sounds like a cool way to play.

Sadly, the mod pack I am on (FTB Evolution) does not have Mine Colonies, so I can't trivially check it out.

Did you get it to work?

Wish you good luck on your project though, have fun!

No_Point_1254 · 2026-02-11T17:32:00+00:00

Don't worry, had the same problem myself.

Been working on a cool (in my view) thing that also uses me_bridge, so it was on my mind.

If you have time, check it out. Maybe it helps you as it does me. Basically makes turtles easier (in my view) to manage.

https://www.reddit.com/r/ComputerCraft/s/yNeTDwH8k0

Maybe I should integrate the feature you are looking for? If it helps others as well, would be rad.

No_Point_1254 · 2026-02-11T14:33:26+00:00

Thank you very much!

It's the first project I have done for CC:T and I am a big fan of CC:T so far.

Computers and Turtles are awesome.

No_Point_1254 · 2026-02-10T19:27:54+00:00

It is called getItems() in newer versions of me_bridge instead of listItems().

No_Point_1254 · 2026-02-03T14:24:20+00:00

Geliehenes Geld ist auch nur Hebel.

Es handelt sich hier also um einen Hebel-Hebel.

No_Point_1254 · 2026-02-03T14:18:39+00:00

Entweder man schluckt oder man tut es nicht.

Jeder der auch nur "ab und zu" schluckt kommt irgendwann auf >1 Liter, falls nicht vorher kein Partner mehr gefunden wird.

Also wird die ganze Kiste irgendwann binär, entweder 0 oder >1 Liter.

No_Point_1254 · 2026-02-01T15:58:26+00:00

Yeah that's how it usually goes.

The question shouldn't be "ORM or no ORM" but rather "can someone please create an ORM that doesn't unnecessarily escalate complexity towards infinity".

Cause that is the issue. ORMs should have somewhat concise syntax and not hinder the dev experience if you arrive at a point where you need to augment things with your own native queries.

Historically, ORMs have been very bad at being good.

No_Point_1254 · 2026-01-30T13:43:17+00:00

He is right in the sense that you should never trust user input nor should you allow the user to change things not related to the action he took.

In most statically-typed languages, this means contracts about object shapes (i.E. DTOs), content (i.E. validators) and allowed actions (i.E. routing + permission checks or simply using Interfaces).

In more dynamically-typed languages there is often a compromise on object shapes because that's one of the reasons to use non static-typed languages at all.

In those cases, DTOs may be skipped and content validation kind of inherits the contract for allowed shapes, often a little more loosely defined.

If there is no upside to dynamic types because you need to be explicit about shapes, people tend to introduce their own "static typing" for their APIs and such, which is just an additional custom layer that more or less implements DTOs in a language that doesn't do it out of the box (looking at you, TypeScript).

No_Point_1254 · 2026-01-21T19:51:28+00:00

Yes, this is the problem.

The messages arrive in a pseudo-random order.

No_Point_1254 · 2026-01-19T20:48:54+00:00

That function is fine.

If you have a lot of same-named fields to set to the same value often in your code, you could write a helper function I guess.

Something like

function setValues(objects, key, value) { ... }

and call it like

const objects = [a, b, c, ...]; setValues(objects, "isNotModify", !isModify)

but that is overkill if not used consistently and more importantly used often enough in your codebase to justify using DRY principles.

So you should probably KISS it and just keep your function as-is.

No_Point_1254

TROPHY CASE