Adding new mesecons/digiline devices

[Klaranth]

Orekart
If node-breaker gains digiline support, should it report the quantity of items inside or just binary state via reporting the item name; luaC support for node-breaker, how should it be done?

SX
If node breaker gets basic digiline support it should not be reporting anything but just triggering it via digiline, that is very simple addition and would probably be accepted to upstream mesecons as is. After that could possibly think about other features. Upgrade recipe would be nice thing but not sure if mesecons devs would accept that, could be done by adding new item or by adding metadata tag for upgraded item without adding new. I think most there do not care about recipes but more if it works well in creative mode, metadata recipe is bit harder to use with /give.

orekart
Why would they not accept it? I mean, it just seems like it will be updated soon anyways to get a better formspec compatible with mobile use (autocrafter PR was accepted for this same reason).

SX
Oh nvm, actually I mixed up things. This is pipeworks not mesecons. For mesecons it was just that simple change to make detector commands consistent and that's probably not a problem. And yes, pipeworks seems to be a lot more open to actual feature upgrades.

orekart
I think so, too. Without adding too much feature creep it could just be making sure the formspec is mobile-friendly and current, but then the digiline interfaces to go along with this. The question would be if it should just return the item type as event.msg when queried or if it would be reasonable to return the item name and the quantity as a table. Now that the mithril (technic) chest is pretty well understood, it would be an example of how to apply to the node-breaker and node-deployer.

Can node deployer deploy multiple nodes at once? I think not but I want to be sure. I know there can be overlapping loose items occupying the same block (when you drop a bunch of items from inventory).

SX
Currently node deployer can deploy 2 nodes, not at once but 2 positions.

orekart
I really don't know how to adapt that for digiline, but node-breaker should be pretty non-controversial

SX
For mithril chest it would be nice to actually implement inventory cache to make queries really cheap and fast. It should also be able to cut maybe 99% of processing time when using digiline injectors with mithril chests but might require support from pipeworks, too.
(Performance gains for lookups would come mostly from cutting every expensive call to c++ side of engine.)

orekart
Yeah, performance (real world) should improve, that is a benefit.

Are there any digilines enabled mesecons items that can be "activated"? As digiline filter injector is disqualified from this question because it doesn't react to mesecons (?)... that kind of makes the case for a digiline node breaker as mentioned otherwise.

The trouble is whether "activate" on nodebreaker should make its mesecons state toggle high/low momentarily; we could handwaive this away and say that mesecons is input-only for the node-breaker. However then you have the question of whether mesecons input state change to the nodebreaker should register as a digiline event.

SX
Does active node breaker activate mesecon wire on other side? Or does it activate mesecon conducting tube placed behind it?

orekart
SX: negative to both, tested now. It appears to be input-only. Should it report mesecons status though to digiline as an event or query-able condition?

SX
I'd say do not send unnecessary events that complicate code and increase workload without adding really anything new, querying also is unnecessary in my opinion because there's already multiple ways to see if it is activated by mesecons. ioexpander, lua controller, detectors and more.

orekart
Is there already a way to know what is in the node-breaker inventory slot?

SX
Only by tracking what you put there. I've done that with tree farm to know if there's chainsaw, fertilizer or being empty.
There was pull request (for mesecons modpack...) that would add things that can inspect inventory next to it.

orekart
That would be helpful yeah. Yet to activate node-breaker with digiline is really desireable.

SX
This one: minetest-mods/mesecons#540
In my opinion it would be better to create some mesecons-extras mods and put things like that there... it is unlikely that mesecons modpack would accept that anytime soon

Pull Request #540 - The Scanner Node
The scanner node will scan any inventory of the node behind it and output a signal depending on its configuration. It also has digilines support (which means every node with invent...

Huhhila
Tracking without querying can be somewhat unreliable. Which that kind of separate querying device could handle with somewhat less clutter than implementing such everywhere else.

SX
For extras mod like this there would also be:
minetest-mods/mesecons#509
minetest-mods/mesecons#489
minetest-mods/mesecons#491
So already a lot of content that could be added without thinking about (imo too strict) mesecons modpack requirements.

orekart
Is node-breaker pipeworks?

SX
Yes it is. None of these links are about node breaker but mesecons devices that would add some asked functionality and more.

And as you see all are pull requests, not just issues asking to implement something. There's code available and it can take years before merged to mesecons if miracle happens and those will get merged.

In my opinion most of that stuff does not belong to mesecons modpack, it should be separate mod that just depends on mesecons.

Anyone wants to grab code, refactor it if needed so it can be separate mod and test it? I could create project under mt-mods organization for that and add people who'd like to work on it to repo.

I could possibly write some code too but as I don't really need any of those devices for anything I'm not going to start it or do much preliminary testing.

Might be good to create issue for it, maybe someone is willing to do some work for it as all the code is there and just need to be collected and combined. Issue is good so that anyone can tell if they would like to start thing like this, mt-mods organization for project is good because there actually happens something and people do not fear that much introducing some new bugs to fix bigger problems or bring new features into game.

Hedgehog
So this is NOT related to the node-breaker or node-deployer issue already in the list?

SX
Not at all, it is about possibly adding completely new mesecons/digiline devices and putting together mod that provides those using code that already exists.

Only connection is that this extras mod, in addition to providing other cool stuff, might also solve some other things that were mentioned while discussing node breaker / deployer things.

[Klaranth]

The new mod to be build may solve some problems from #95 and/or #96 .

[Klaranth]

specing
#100 digiline remote. Using it brings up a formspec, the formspec is generated by punching a luaC (and the luaC handling that event). Then, when you push a button/type text in that formspec, the luaC gets another event.

SX
Kind of like remote data you can currently do with luac+nic+touchscreen but as tool you can take with you? But event based instead of requiring polling like nic would.

specing
Yes, it should also transfer your coordinates.

SX
Should be possible and even without causing any additional lag as it can be made to work without loading or activating anything that is not already active...

specing
So you could click a button and your ship would jump to my_pos with y = y+20

SX
Activating things remotely would also be possible but would require some care and rate limits, there it could be enough to make it technic powered tool with charge just for few messages before requiring recharge.

specing
The JD is already rate-limited, right?

SX
It is not about JD but activating lua controller. Basically about loading blocks into memory (to find out if there's luac in first place) and then activating that area.
If area is already loaded and possibly even active then it is not that big problem, basically tool can be made to behave fairly well if not loading map areas and not activating but then it would only work if areas are already active

BuckarooBanzai
FYI: an example of luac+touch+jd is here: https://pandorabox.io/index.php/Digiline_Jumpdrive_controller

[Klaranth]

et
Mesecon conducting air

SX
Bumped so answering: this is available, kind of. Wireless (in world) communication is available through other stuff and also few nodes can actually carry signal over small gap (take a look at torch for example, and yes mesecon torch isn't just a light).

[Klaranth]

The4spaceconstants
event gen
name it "quartz clock"

Huhhila
et: with clock resolution set to 200ms... a luac can actually send more than a hundred messages inside such a clock tick. But it can't handle receiving 20+ during a second without overheating.

et
i mean in a game you want to have consistant~ish signals, not just a burst

iceyou
I wonder if luacs would overheat after being hooked up to this

et
the limit is 19 events/s so

[Klaranth]

wf13
Would it be possible to remove the limiter on mesecons/digilines? It screws things up very much
et
ok but to be fair the ratelimiter lets me know that i am killing the server before i think to do /status and after that lag spike it makes mesecons unusable for literally everyone on the server lmao, basically killing the fun for everyone
et
wdym by "too big" and why is that a bad thing

et
make the digiline selectionbox taller

[Klaranth]

FeXoR
Non-lying nodes like for Digilines Limiter (digicontrol:limiter) display: After a message further messages will be blocked for [player input] (And ofc. invert the input processing) (If the current description was correct then a request and answer - both through the rate limiter triggered every few seconds would get through if set to 2 - but they don't)
AceRichman
the limiter isn't very precise, it counts how many messages have passed though in the last second, but not when in that second

[SwissalpS]

et
make the digiline selectionbox taller

I have no idea what this is refering to and if it is on-topic at all

[Klaranth]

et
digiline device that can interface with formspecs directly thru on_receive_fields

Second time et is suggesting something without explaining what they mean.
Tempted to no longer add it to the list here until clarification is given.

[SwissalpS]

Yes, it would be great if only ideas that are explained reasonably well make it to this forum.

The digiline device that reads formspecs, I can somehow understand what he wants. As I understand it, he is asking for a digilines fakeplayer.

[Klaranth]

frog
Some sort of wireless digiline transmitter
Doesn't need to load the mapblock, just needs to transmit a digiline signal for a short distance, or a long distance if both mapblocks are loaded
Use case: control rooms where wiring everything would be slightly icky

The4spaceconstants
you can already do that with items and tags and tele tubes
SX
There's digiline NIC that allows doing this, pandorabox offers key value store which can be used with NICs https://pandorabox.io/index.php/Key_Value_Store
For private proxy approach there's also global memory which can be used for this. But true that both these will require polling instead of being event based.
For event based wireless digiline there's also a mod that adds some digiline wifi nodes, never looked at that so no idea if it is good or not and don't remember exact name of the mod.