Hi

Firstly, i'm pretty new to modding so sorry if this has any glaring issues, but I had this idea and thought i'd run it by you devs to see what you think.

You can return tables from a java function in a dependent mod using MethodResult and a Map, which is really nice

But there are certain things that i'm not sure can cross the lua / java barrier, for example metamethods, and processing that makes more sense to do on the lua side that the modder might want to add inbetween the call a user makes to the peripheral, and the java function itself (the actual peripheral.call)

So that got me thinking of a way this might be able to work without touching any of the java side, and only modifying peripheral.lua. I wanted to run this idea by you before trying to actually implement a change, to see if there's anything that is wrong with this approach.

My approach

A folder / namespace can be chosen in rom for mods to place a lua file which returns a function, that function accepts a wrapped peripheral, and does whatever the mod maker wants to it before returning it.

peripheral.lua caches everything in that folder / namespace when it is loaded, and if a peripheral is found that matches any of the types in the dictionary, the function is called and the result is given from the wrap call.

The same would need to be extended to find.

This should not impact any existing peripherals behaviour, normal peripherals will be unmodified, only ones from a mod that adds functionality like this.

The impacts I have identified

1. A memory impact on every computer regardless of whether the peripheral that would use those functions is connected.

2. A fairly negligible performance overhead with one table access and one comparison to nil in the case of "unmodified" peripherals, and only when they are wrapped.

3. One person has told me this may impact custom OSes, or programs that override or augment the peripheral global directly.

4. It breaks the assumptions made by getMethods if the lua layer modifies them or adds new ones.

My rationale

This would allow mod developers to add rich lua behaviour to their peripherals and any values they return from calls, and could simplify creating behaviours that only modify the values in a lua table. One example is returning a table of position data from a java mapped LuaFunction, intercept it before it gets to the user's code and add metamethods, allowing them to be modified on the lua side by just using operators, for example. The main draw of putting it in peripheral would be that it does not require any other input from the user, it just works like a peripheral always did but with extra stuff.

Hopefully this makes sense, and of course the decision of whether this is a change that makes sense for the mod as a whole is down to you guys.

Thanks for reading :)

Ok, but what if I use peripheral.call on your peripheral? If your magic code only modifies wrapped peripherals, then I am going to have a very different experience with peripheral.call than with the wrapped version.

Ok, but what if I use peripheral.call on your peripheral? If your magic code only modifies wrapped peripherals, then I am going to have a very different experience with peripheral.call than with the wrapped version.

Yes, that is true, I didn't consider that. I always use wrap, but that's not the point, and it would end up annoying people who are used to using call, or have a use for it I haven't considered.

Just generally, it seems that this is something that might be nice to have, but won't sit well in the wider ecosystem of CC stuff. I do hope that I communicated that this would be neat to do, but the only benefit it has is preventing the user from needing to do one require call, which can be documented anyway and included with the mod.