Require files in other mods

[aubergine18]

Would be great if we could do this from mods marked as dependencies:

Code: Select all

require '__SomeOtherMod__/api.lua'

Instead of having mods cloning the file (which will over time become outdated).

[Rseding91]

You can already do that. People use used to do that with 'require "defines"' which was in the Core mod.

[aubergine18]

Path to the core mod is hard-coded in the game (eg. if you require a file that doesn't exist, the error mentions the core mod in its list of search paths).

I'll give it another try tho.

[Mooncat]

I have tried that before with different paths I could think of but no luck.
Now I rely on remote.call to access methods from another mod, and I am fine with that.
Allowing access to other mods' files may lead to some security issues as everyone can mess with other modder's files.

[aubergine18]

Allowing access to other mods' files may lead to some security issues as everyone can mess with other modder's files.

It won't allow people to alter the state within another mod, it just allows them to require a file from that mod as if it were in their own mod, in much the same way that prototypes can pull graphics and sounds from other mods.

The remote interface and events would still remain the only way to affect the state of another mod, and even then only if the mod allows it.

For example, in the updated EvoGUI I've been chipping away at, I want to provide an API that lets mods define sensors in a much simpler manner (early draft from a few weeks ago). In this example, things like events are all abstracted away - the mod merely needs to provide the relevant methods and properties when defining the sensor. The 'require'd API takes a sensor definition object, and wires up the events and remote calls, leaving the code of the mod using it much cleaner and more semantic. The sensor mod has no access to the internal state of EvoGUI, it can do things via the API it's pulled in, which in turn just uses remote calls and events, but in no way can the sensor mod go poking around the state of EvoGUI.

Another example is StdLib - currently mod developers have to clone it's scripts in to their own mod... would it not be better if they could simply `require` them fron a published StdLib mod?

[Mooncat]

It won't allow people to alter the state within another mod, it just allows them to require a file from that mod as if it were in their own mod, in much the same way that prototypes can pull graphics and sounds from other mods.

The remote interface and events would still remain the only way to affect the state of another mod, and even then only if the mod allows it.

For example, in the updated EvoGUI I've been chipping away at, I want to provide an API that lets mods define sensors in a much simpler manner (early draft from a few weeks ago). In this example, things like events are all abstracted away - the mod merely needs to provide the relevant methods and properties when defining the sensor. The 'require'd API takes a sensor definition object, and wires up the events and remote calls, leaving the code of the mod using it much cleaner and more semantic. The sensor mod has no access to the internal state of EvoGUI, it can do things via the API it's pulled in, which in turn just uses remote calls and events, but in no way can the sensor mod go poking around the state of EvoGUI.

Another example is StdLib - currently mod developers have to clone it's scripts in to their own mod... would it not be better if they could simply `require` them fron a published StdLib mod?

Just a little bit concern as I have seen a modder being mad just because he wanted to keep his mod as realistic as possible but some people made additional mods to make his easier to play.
So I thought there may be some people don't like others reading their files.
If we really need this feature, maybe control the accessibility so that we can only read files inside a certain folder, like "remote"? This also matches the encapsulation principle in OOP I guess.

But before we have it, would it be possible to achieve your example with multiple remote methods? One method for constructing the sensor (accept a table of data then return the constructed sensor), one for "users" (accept the sensor and return array of player ID), one for "reset", and so on?
And one little thing... I think it is better to use the common lua naming convention: lowercase + underscores when making library especially when you have plan to spread it to other modders.

About the StdLib, for now, I have only used one of its string methods (starts_with), so I haven't cloned the entire library. I just copied the method and gave credit in the comment. Rather than having an additional mod and requiring players to download it before playing ours, it would be better that the devs implement the library in their core lib.

[aubergine18]

If we really need this feature, maybe control the accessibility so that we can only read files inside a certain folder, like "remote"? This also matches the encapsulation principle in OOP I guess.

Yes, that would be acceptable. I'd prefer the folder to be called `api` to avoid confusion with `remote` interfaces.

But before we have it, would it be possible to achieve your example with multiple remote methods?

Yes, it's already all based on remote methods (and some events) and anyone who wants to implement things the hard way can still do all the manual leg work rather than using the api.

The point of the API is to abstract all that stuff away, leaving the mod author to focus on just their sensor and not worry too much about how it's all wired together. In particular, EvoGUI will be making remote calls (and sometimes event-based calls) to the sensor mods, and over time those will change to improve performance, fix bugs, etc - but that can't happen if all the sensors have hard-coded their remote interfaces and event handlers.

About the StdLib, for now, I have only used one of its string methods (starts_with), so I haven't cloned the entire library. I just copied the method and gave credit in the comment. Rather than having an additional mod and requiring players to download it before playing ours, it would be better that the devs implement the library in their core lib

When you consider how many mods have done the same, and how many have duplicated the code and not kept it up to date, it starts to become more apparent why we need the ability to include libraries from mods. I think the real problem here is that the current in-game mod manager is a bit pants when it comes to installing / activating dependencies - once that functionality is improved, it will become much less hassle for players when choosing mods with dependencies.

[Mooncat]

I think I failed to understand the difference if you can use require and if you can only use remote call

When you consider how many mods have done the same, and how many have duplicated the code and not kept it up to date

Sometimes, not keeping it up to date is also an option. I say this because I am using Unity in my company. Although the recent updates (actually, the whole Unity 5 series) have introduced some new features, more bugs appeared, and some of them were so serious that those versions are not usable.
I am not saying the StbLib has and will have such problem, but as long as it is working and as far as it doesn't have any new features (functions) that we need, why bother to update it.

However, I agree by making it a standalone mod can erase the need to have clones of it in different mods, hence, space is saved.

It will be perfect if the devs can maintain it in the core lib. No need to explicitly download and update an additional mod. But only if the devs are willing to do so.