Having a Solar Panel Combined with an Accumulator

[lshallo]

I would really like to create a mod that has a solar panel with a battery below it so it cancels the need for separate accumulators. I was able to achieve the desired behavior using an energy interface type, but the solar panels still work at night and the power statistics are a bit flaky in many ways. (The solar panels show up as consumers but don't ever consume anything because the flow is internal, etc.)
I would really wish for a type that can store and give energy tertiary but also supply excess energy as output-secondary like a solar panel so you would be able to charge external accumulators aswell.

[Rseding91]

I understand the desire for such a thing but I think this is outside of what we want to support mod wise. You can already achieve the same results by using the existing solar panels and accumulators. The additional game logic overhead and potential performance concerns of making this custom combination just isn't worth it.

[eradicator]

@Ishallo
How about using surface.create_entity to spawn an invisible solar-panel-sized accumulator on the same coordinates as the panel? As far as i understand the additional entities shouldn't have too much of an impact, and if solar and accu are exactly same sized any power pole will always connect both at the same time.

@Rsed:
Would it be worth to write a request for that kind of linked creation? From what i can tell every third mod does something like this.

I think the most common "hack that might be fixable" is spawning additional entities when entity x is build (i.e. invisible inserters, chests, pipes, poles etc). If it was somehow possible to specify that (including automatic removal handling) it could remove lots of scripting, especially blueprint handling for that type of hack is pretty prone to bugs.

Code: Select all

data:extend {
 type = 'assembling-machine',
 name= 'my-modded-special-machine',
 associated_entities = {
  { name  = 'invisible-inserter', offset = {-0.5,-0,75},
  { name  = 'invisble-chest', offset = {-0.5, -1.25},
  }

[Rseding91]

@Rsed:
Would it be worth to write a request for that kind of linked creation? From what i can tell every third mod does something like this.

No, that's beyond what I want to support in the mod API.

[eradicator]

@Rsed:
Would it be worth to write a request for that kind of linked creation? From what i can tell every third mod does something like this.

No, that's beyond what I want to support in the mod API.

OK, at least i have an answer now. Thanks :)

[eradicator]

@Rsed:
Just one more question:
What about if the API only had to make an arbitrary "tags" table available for read in the API stage, and do none of the actual handling? The idea would be to mod a generic handler that hooks into on_built_entity, looks at event.created_entity.prototype.tags.associated_entities and from there decides what to spawn in.
This would allow me (or anyone else) to make a generic hanler function for "complex-entities", while mods/modders creating new complex-entities only need to specify things in the data stage.

Pros:
+ The engine only makes the table available when a mod explicitly requests it (→no performance impact).
+ All actual handling would be done by a mod (→no support impact).
+ Could be useful for other mod concepts
Cons:
- You have to carry one arbitrary table into runtime stage.
- ???

@OP sorry for hijacking the topic :oops: