mod request: [libox_computer]

[TheEt1234]

https://github.com/TheEt1234/libox_computer

Adds a laptop and a robot

Laptop

• Its easiest to think of it as a luacontroller that can yield + touchscreen, please see The repo, and navigate to the docs for a better explanation

Robot

• A laptop with an inventory that can interract with pipeworks, move, dig with a tool, place and drop, delays configurable by a setting (except dig delay, that's made to be the time that the tool takes to dig that node)

Discussion:

• what should the crafting recipes be?
• how to solve the possible issues, or even if to worry about them
• what should be the configuration

possible issues

• Memory: each sandbox can weigh about 10 megabytes, if a laptop/robot gets "force dug" and the sandbox is alive it may not get deleted (maybe some dumb set_node override could fix that but i think that may introduce performance problems (?))
• Balance: the robot is basically a digibuilder, a pipeworks node breaker (but with proper delay) and a dispenser, in one, is this a problem, how should the place/drop/move delay be configured
• Lack of tests: Libox (the library used for the sandboxing) is tested but this mod specifically isn't... i don't like doing the types of tests that require a world but if they are nessesary i will write some tests

[TheEt1234]

Also should i rewrite the async_controller mod to use the libox library as well, probably a good idea to have all that sandboxing and environment code in one place

[The4codeblocks]

you can already yield with luacs
just a little complicated

[TheEt1234]

you can already yield with luacs just a little complicated

how?

[SwissalpS]

Using interrupts and saving state with context in mem.

[SwissalpS]

Sounds like this node squashes various existing nodes into one. Making it even less interesting to actually build a system in-world.
Correct me if I missunderstood :D

[TheEt1234]

Using interrupts and saving state with context in mem.

that's way more inconvenient than yielding but fair i guess it could count

Sounds like this node squashes various existing nodes into one. Making it even less interesting to actually build a system in-world. Correct me if I missunderstood :D

yes it very much does that (especially with the robot, but that can be disabled if this server doesn't desire that, for the laptop, it's just a touchscreen and a luacontroller combined) but why would it be less interesting (robot has certain disadvantages compared to pipeworks and digibuilder, like digging actually adds delay, and the laptop... well i don't think it makes it that much less interesting, just has touchscreen and a fancy luacontroller glued togheter)

[SwissalpS]

There is a good reason why for example jumpdrives don't also include a luacontroller, touchscreen, beacons and travelnets: it encourages players to come up with their own designs using the other existing nodes.

Also it helps with code maintenance. Touchscreen, luacontroller etc. would need to be synced over multiple mods.

My arguments are not absolute "no"s to the proposal. I think you need to bring better arguments than "combines xyz into one". Those kinds of proposals tend to be thrown out quite quickly.

[TheEt1234]

There is a good reason why for example jumpdrives don't also include a luacontroller, touchscreen, beacons and travelnets: it encourages players to come up with their own designs using the other existing nodes.

I agree

Also it helps with code maintenance. Touchscreen, luacontroller etc. would need to be synced over multiple mods.

As long as digilines stays the same, touchscreen stays backwards compatible and the many luacontrollers out there support digilines, everything should be fine, so i don't think that's a huge issue

My arguments are not absolute "no"s to the proposal. I think you need to bring better arguments than "combines xyz into one". Those kinds of proposals tend to be thrown out quite quickly.

Well, the laptop isn't really just combining the touchscreen and a luacontroller, the laptop also adds an easy way to pause the sandbox and adds the libox environment functions (that allow you to even create your ideal editor using loadstring/xpcall)

As for why the touchscreen was combined into the laptop, see this discord message/convo

but the tl;dr was that mclv wanted a luacontroller/touchscreen textured like a laptop so i did that

and also i thought why not

As for the robot, its whole moto is combining a lot of stuff, i don't think this is a bad thing if there are disadvantages compared to the normal pipeworks forms (like being expensive and having cooldown)

[SwissalpS]

(like being expensive and having cooldown)

Adding a new mod wouldn't work around that. If added the recipes would be balanced to be similar to existing items or even more expensive since it combines so much.
And it certainly wouldn't get added without joining mesecons monitoring -> cooldown.

[TheEt1234]

(like being expensive and having cooldown)

Adding a new mod wouldn't work around that. If added the recipes would be balanced to be similar to existing items or even more expensive since it combines so much. And it certainly wouldn't get added without joining mesecons monitoring -> cooldown.

By cooldown i meant delay (pausing of the sandbox for a bit, so that the robot couldn't rapidly place/dig/whatever), sorry

If added the recipes would be balanced to be similar to existing items or even more expensive since it combines so much.

That's what i will be trying to do with the robot's recipe

[TheEt1234]

would:

    | silicon | super plastic | silicon |
    | touchscreen | glue | mooncontroller |
    | red dye |  green dye | blue dye |

be a good recipe for the laptop?

or maybe:

    | silicon | silicon | silicon |
    | touchscreen | mooncontroller | digimese |
    | silicon | silicon | silicon |

[SwissalpS]

Look at the discussions concerning digibuilder. Both here and on digibuilder's tracker.
(About reasonings, not the recipe)

[TheEt1234]

The digibuilder issue tracker doesn't really have anything besides the dignode command issue

The robot very much can be limited, just in a different way than digibuilder, it can be limited to for example placing and seeing only in a 1 block square around the robot, and that can be limited to take a longer time

Making you have to move the robot and figure out the path

and the pandorabox issue tracker doesn't really have anything(?)

[SwissalpS]

a quick search brought up these and more:
#331
BuckarooBanzay/digibuilder#14
BuckarooBanzay/digibuilder#16
#367
#360
#328

[TheEt1234]

331

doesn't really tell me anything about the recipe (none of theese do actually), that's just an abadoned proposal to see inventories with digibuilder, that's why i didn't include it in my message earlier

digibuilder issue 14

that's what i had responded to in my message

digibuilder issue 16

i don't know how that's relevant, just a proposal to make digibuilder less painful to work with

360

i don't know how relevant that is(?) many many many robots could potentially act as a mass-scale building tool(? i don't know how painful that would be) they have loadstring so changing the code wouldn't be such a pain

367

(both robot and laptop have wrench support btw)
the libox_computer doesn't have any state nodes, i may change it later to make it more obvious when it is running

328

I don't know how that's relevant here...

(Wait i am an absolute dumbo, i just realised that this wasn't about the recipe, im sorry)
(But still same points apply)

[TheEt1234]

well uh how can i improve this mod