cervator [00
8]
@xtariq and
@jellysnake could you two weigh in on
https://github.com/MovingBlocks/Terasology/pull/2767 please? it is about optional modules which i figure might relate to you two (content focus + inventory fun)
[00
9]
in particular maybe coming up with some use cases that could demonstrate the usefulness of the system
xtariq [01:06]
Intersting...
[01:07]
I'll take a deeper look at it tomrrow.
jellysnake [08:45]
So, I'll add my thoughts onto the pull request (and/or the issue) but whilst it looks good, I'm having issues thinking about when I'd be used. I think it stems from simply, that having the ability to conditionally register a system based on modules isn't enough.
What I mean by this is that if I'm going to have a system that I only want to work when module `foo` is activated, I'm also going to be listening for an event from that module as well most likely. Or I'll be reading from a component defined in it. Either way I need to be able to access the code of that module without requiring it to be there.
Right now if I try that IntelliJ gives me a bunch of errors (and rightly so) about "Cannot resolve symbol" and the compiler is annoyed about "cannot find symbol"
I'm not sure if this is even possible, I'm no java wizard, but for optional dependencies to work that's the level of functionality I'm imagining.
[08:47]
(I think I'm gonna post onto the issue and mention it from the pull or something)
[08:49]
(however I'm gonna do it in the morning when I wake up) (edited)
skysom [08:50]
Yeah I'm not sure how I can see conditional registering systems is a thing.
[08:50]
Like recipes and additional minor content based on certain modules makes sense.
[08:50]
Systems? eh.
jellysnake [09:10]
I'm not 100% sure if conditional systems is the way to go but it seems to work better than alternatives when I think about it.
For instance, say you made a module that adds a bunch of machines to do things. And say I had a module that gave you magic abilities. If I decide that I want to be able to turn on and off your machines with my magic module how would you do that. I don't want to have to always depend on your module. But I want for instance to be able to access a component from your mod to turn it on or off. If you had a module that wired them together then that seems way to superfluous for a simple one off thing.
[09:12]
It may be that my thinking is flawed on some level or that I'm missing an easier way to do this but I'm not java wizard so I'm not sure of an alternate way
[09:13]
(unless of course the terasology way is to split things into small modules as far down as is reasonable.)
skysom [09:15]
I mean for me, adding modules as compile dependencies isn't a huge thing for me...
[09:15]
As I'm used to doing it in MC
skysom [09:15]
looks at his 10 maven dependencies...
jellysnake [09:18]
What do you mean by compile dependencies?
skysom [09:45]
I mean I guess that's what I thought your issue with dependencies was
cervator [10:00]
one "optional" thing that works right now is referring to non-existing components in prefabs
[10:01]
so you could create some prefab with a component in it from an optional module, and that component will just gracefully fail to attach if the module isn't active
[10:02]
yet if it is then the component will be present and whatever systems and events from that module will be live and able to react to the original entity
[10:02]
we've also got occasional "bridge" modules
[10:02]
i'm not sure what the ideal level of support is
[10:04]
once upon a time the `BreathingComponent` was attached in the `player.prefab`, but only triggered if the Breathing module was active. That itself wasn't super clean since as a Breathing dev you'd need your thing attached to the original `player.prefab` ... later on we then got delta prefabs and various on-spawn events and such to where Breathing could be entirely self-contained again
[10:04]
i dunno how much of the interest in the topic actually originate from days when we needed it more
xtariq [12:42]
Alright, I'm awake and ready again.
xtariq [13:40]
Optional components is what I would use optional dependencies for.
cervator [14:48]
one question is whether we have enough hooks now to do without somehow. Can we structure modules in a way where you don't *need* a formal system for optional dependencies?
skysom [14:52]
works in MC
[14:53]
Most of my code is just locked behind classes that only get called if
```Loader.isModLoaded("<modid>");```
[14:53]
returns true
cervator [14:58]
that might be why some coders would expect to find the functionality available. But then MC mods are structured somewhat differently. I wonder if we could sneak around it using some better techniques - may be hard to know early on
skysom [14:59]
I'd be cool with a simple side module system
[14:59]
But yeah.
[14:59]
MC mods are structured oddly indeed.
[15:00]
But yeah that'd be why it's sorta expected
[15:00]
But there are some times (Like I said recipes) where I'd only want to do something if that module was installed
[15:00]
So I'm not sure the best way to handle that.
cervator [15:03]
it seems like using overrides/deltas is a powerful tool
[15:03]
is that at all a thing in MC land?
skysom [15:04]
HAHAHAHAHAH
[15:04]
What little I've heard of them?
[15:04]
Not even close
[15:05]
But yeah there isn't really anything other than what I just said to deal with other mods.
[15:05]
So I'm just gonna assume that we don't have those.
cervator [15:16]
interesting
skysom [15:28]
Mind explaining Overrides/Deltas? I've heard bits and pieces, but never a full explanation
oniatus [15:41]
@SkySom https://github.com/Terasology/TutorialAssetSystem/wiki/Deltas-and-Overrides
skysom [15:41]
Oh hey sweet
[15:43]
Yeeaaahh MC ain't got anything close to that
[15:43]
But it could be more cause we don't have any type of component system
xtariq [15:44]
There's also another nice feature of deltas, where depending on the module load order, you can replace individual components of prefabs. (edited)
skysom [15:53]
But yeah
@Cervator we don't have anything like that...
[15:53]
Basically you either replace something direclty with your version
[15:53]
Or you just suck it up
cervator [16:00]
yeah there's a reason we expected a more extensible system could be done from scratch :smile:
[16:00]
now i just wonder if its inherent benefits negate the need for optional modules entirely
skysom [16:02]
I still feel like you could
[16:02]
unless you want to start writing glue modules.
xtariq [16:04]
We'll eventually need branch modules.
jellysnake [17:47]
Okay, so the way In Game Help works at the moment is that modules like Cooking have to depend on it and then listen to an event from it. In Game Help is a perfect candidate for being an optional module.Cooking does not need it at all, but at the moment, it's required.
How would you listen to an event from an optional dependency with in terasology at the moment?
[17:49]
Because adding a component to the prefab containing all the info needed for In Game Help wouldn't work because
a) you'd have to manually update it every time content was added
b) You'd have to reference the component from Cooking, again leading back to the same issue as before in that you can't without all kinds of funky errors
cervator [18:16]
nice example
@jellysnake :slightly_smiling_face:
[18:17]
i try to think of it all as a big tree, engine is the trunk, libraries the roots
[18:17]
modules make up the branches and get finer and finer in details the further away you get ("leaf" modules with most the actual content/config)
[18:18]
as
@xtariq developed the effects system starting from what was left in TTA we added a bunch of assorted effects to it
cervator [18:24]
as we kept adding some general types and other stuff became more and more visible
[18:24]
and some really generic stuff seemed a candidate for pushing closer to the engine (damage types and registering new ones)
[18:25]
so one outcome there could be pushing some generic stuff closer to the trunk so it is easier for more stuff to get it from the dependency chain naturally (no optionals needed) and more detailed stuff further out to prevent the main relevant module from becoming too bloated
[18:26]
that way keeping everything really slim and minimal might make it overall easier to work off regular dependencies without getting too much fluff you don't want
[18:27]
but yeah if for some reason you wouldn't want a help system enabled (hard core / primitive survival) it should definitely be possible to turn it off, even if it is something closer to the trunk
[18:28]
maybe there would be a way to "push closer" how the help system exposes information, much like how damage type *registration* at least should be pretty close to the engine
[18:28]
make the leaf modules enable more creative damage types tho
jellysnake [18
3]
That works for things that are a natural extension of where they come from, but again the issue is what if you want to go across branches. Ie, an magic mod with damage spells would make sense to depend on say alteration effects or damage types. But if that magic mod also thought it'd be neat to be able to control machines from another mod how would it do that?
[18
3]
A machines mod and a magic mod are separate branches of the tree, it makes no sense to have one depend on the other
cervator [18
3]
yep it doesn't seem difficult to come up with use cases, we just don't have a ton in action right now to play with. InGameHelp is a good one
[18
5]
it is tempting for me to think about sort of reversing direction on the help system and instead of having Cooking depend on InGameHelp instead smarten up IGH to where it will scan for *anything* with valid data of some sort it can display within itself, no dependency needed - but that probably violates the spirit of the ES and not leaving "inactive" extras around (like better decorating prefabs / recipes / components in Cooking)
[18
6]
although in that case there wouldn't be any cross-module logic in action
jellysnake [18
6]
See, there are a bunch of other work arounds but you'd need different ones for each use case, and it's just be so much simpler to have option systems that only work when a module is activate _and can access the code of the optional module_
[18
7]
That last bit is the issue. I can't think of a way to do that. You can't not compile it, because the modules are compiled prior to when they know if the module is going to exist or not.
[18
7]
and you can't compile it anyway because the compiler spits out errors about not being able to find the stuff from the other module
[18
8]
(I've got to go but that outlines my general thought process around optional modules
cervator [18:41]
thanks :slightly_smiling_face:
[18:41]
i wonder if we could draw some inspiration from the `compile` vs `runtime` vs `provided` dependency settings in Gradle
[18:43]
so for building code (and developing) optional dependencies are mandatory, but at runtime they're not. Although how that compares vs. just using feature flags ... eh. Purists might prefer not having the code present if it is optional
[18:44]
and i guess it would still need some clever code to avoid bumping into unavailable code at runtime (much like the little MC example
@SkySom posted)
[18:45]
for fetching source and binaries for development there could be an option to get transitive dependency modules as well, all as source, only mandatory as source, or all as binaries beyond the target top level module
[18:45]
(well, any dependencies, regular or 2nd, 3rd, etc level)
