BeaconPrototype.profile but for modules

[protocol_1903]

As stated in title, I'd like modules to have a profile. I'm still unsure of the implementation, whether it would be summed based on the number of that module, that module category (productivity, speed, quality, or custom categories), or based on total number of modules in the entity, or if it should be based on the number of modules with that effect category. I would also love a way to select what kind of summing is used, like how you can do so for beacons. My preference of (default) implementation and knowing how it would be used is one of the first two, probably the second one. I'd like to see this as an incentive to mix modules, especially in high-slot machines where the usual move would be to spam productivity or quality modules but a more balanced play would be to mix prod with speed or efficiency.

Additionally, with a profile style implementation, you can have powerful modules that can only be used once per machine, or even more powerful modules that cannot be used with any other modules period. Or others that get progressively more powerful, especially so after 5-6 modules.

I know MrSmoothieHuman has expressed interest in using this mechanic in Periodic Madness or an expansion for it, and I'm sure other developers would be interested in using it for their own mods.

[curiosity]

And what of the modules in beacons? Do they count? Does the count get multiplied by the beacon's effect multiplier, resulting in a fractional number? How are you going to define a profile then?

[MrSmoothieHuman]

I can think of a couple different ways to implement it personally, both having some draw backs however:

1. Have the profile be defined on the ModulePrototype, which means that you could have each tier of a module have a separate profile and would allow for things like side-gradable modules. It'd also mean a lot less overhead compared to the other idea, as each profile would be set separately for every type of module - instead of having to set it for each module effect/type of module.
The major downside to this is that buildings wouldn't be able to have their own unique profile, and would instead be at the whims of the profiles set on the modules; which wouldn't be a major issue but could definitely be annoying if you want specific buildings to have specific module profiles.

2. Essentially the opposite to the first idea, give buildings their own profile. I can see a couple issues with this though (some of which protocol mentioned) - do you allow modders to set what effects/modules get profiles, if so does that mean you have to write x amount of profiles, how does that work with modules with multiple effects (like all of them ), etc

I'd be in favor of the first option specifically, or an alternative: give buildings a module_effect_multiplier - while it isn't as dynamic as a profile, it does allow specific buildings to be stronger or weaker with modules. (If i'm going to push it, which i am, you could technically have x amount of multipliers for every type of effect, since it'd be a lot less bloat then 5 different profiles)

*(written before i saw curiosity's reply)

[protocol_1903]

And what of the modules in beacons? Do they count? Does the count get multiplied by the beacon's effect multiplier, resulting in a fractional number? How are you going to define a profile then?

The beacon uses the same profile as other machines. It's transmitted results reflect those of the profiled modules.

[curiosity]

Oh, so every entity's module profile is limited to its own modules? Beacons don't affect it?

[protocol_1903]

Oh, so every entity's module profile is limited to its own modules? Beacons don't affect it?

Correct, at least the way I envision it. Beacons would profile their modules, then those profiled effects are transmitted as normal. This sort of system would benefit more beacons per machine, and be less beneficial to high slot count low beacon count setups. Imo it would also be easier to implement/mod/use as a player overall.