"Live" power system implementation

[Grenkin1988]

Power system discussion
Currently, initially developed by @TheRiven , we have “static” power system:

• Power generator produce amount of power
• Power consumers consume it
  Power level = sum of power generators – sum of power consumers.
  It is already possible to change power level of objects on fly representing not operating objects.
  But we need to solve issue () when generators are refueling. Right now generator stops working and all things that need power also. This could be solved by refueling generator earlier that it has absolute zero.

Another solution is to have “live” power system:

• Power generators produce amount of power per time.
• Power consumers need amount/time power for operation
• Something should accumulate power excess.
  This looks a little bit more realistic but this would involve implementation of this produce/consume logic.

We need to decide what we what now. Later this would be very difficult to change. Lets discuss this and find out all drawbacks of both types.
@quill18 just to make sure quill is involved in core discussion :-)

As decided, implementation of “Live” power system is going on.

New power system is in place
Connection is used to represent that Furniture has connection to power system.
System can contain multiple Grid.
In the future logic for new Grid generation depending on wires could be added.
In XML – new tag: <PowerConnection inputRate="" outputRate="5" capacity=""/>
inputRate – power consumption
outputRate – power production
capacity – maximum accumulated power

Implementation iterations:

• Power system prototype
• Integrated new system into game
• Fix [BUG] There is a bug in power system #1038
• Add first accumulator
• Implement save/load logic for system

[GamerInspired]

I think I prefer the "live" power system as I could be expanded on more easily later on.

[sboigelot]

We could also take the advantage to make the system more generic then just power.

It could be any stream requirement.

For instance RAM or CPU usage. Some computer are producer of CPU power, some machine use it, etc..

[Ferr013]

I think the "live" solution could be more realistic: imagine a nuclear reactor that produces (x) Watt per hour, or a dam with an hydroelectric turbine. We could assume that the power they produce is constant through time, so we can average an amount of power available each second and apply the same approach to power-consumers. The power in excess could be stored in a backup battery (in case the generators are damaged).
Since we are in space, it could be possible to have also solar panels (that have to be installed in a room with index zero) as well as the already implemented uranium based power supply!

[Grenkin1988]

I was thinking to have this pattern for all furniture. It just should have <Consume> and <Produce>

[Xeni91]

@Grenkin1988 do we have to differntiate this? Why cant we just use a <power> tag and increase it with generators and decrease it with consuming furniture?

[Grenkin1988]

@Xeni91 My last comment was not about power. It was just thoughts about generic solution. Some objects could produce multiple things, and consume multiple things

[mikejbrown]

So like a generic resource system? We could have (say) IProducer and IConsumer interfaces which classes implement as needed. A consumer could then register a callback with a producer, or a producer manager class, saying that it wants to know any time a new unit of resource X is produced... Then the internal logic of the callbacks can be very simple. The trickiest thing would be to keep connections up to date as objects are built/destroyed. Is this the sort of thing you are thinking of?

[Grenkin1988]

@mikejbrown Some kind of. But let's focus on power system right now :-) Producer/Consumer pattern is topic for another issue. Should I create one?

[quill18]

@sboigelot I like the concept of a generic "stream" to/from resource consumers/producers.

I also like the idea of it being "live". Unlike base Rimworld, I think it would be nice if things only consumed power while performing their task. This could lead to surges in demand, making batteries (and/or capacitors) very important parts of the network.

[quill18]

It's possible that all consumers -- but really "spiky" ones in particular, like lasers -- should probably act as their own capacitor/battery. They will "consume" up to X power to charge their battery, but then stop consuming from the network while their battery is full.

[mikejbrown]

@quill18 definitely like needing power only when working & having a real need for batteries... but only as long as you don't have Rimworld's zzzzt event! :)

[Grenkin1988]

For now most people is for "live' power system. But more feedback is needed. We should also remember that somebody going to implement Utility System - Pipes, Power Conduits, Air Ducts and so on

[Grenkin1988]

@quill18 @sboigelot I opened another issue to discuss this #604

[TheRiven]

As with most I would agree that switching to a live system would probably be a good next stage for the power system. 👍

And yeah it will definitely need to keep that future Utility system in mind so it will be easier to put them together later.

[Grenkin1988]

If nobody against I am going to do some prototyping for this. For "live" system with possibility for improvements with connections

[ajahraus]

@quill18 I love the idea of batteries and capacitors. I think that they could provide a fun game mechanic.

Like perhaps batteries should be good for storing power (i.e. store large amounts of charge for long periods of time) but bad for providing power (i.e. charge/discharge slowly or else they take some type of 'damage').

Capacitors on the other hand change and discharge very quickly (making them great for high power activities like laser weapons) but gradually lose charge over time, making them bad for storage.

Maybe in a space fight between ships, being able to fire laser cannons more quickly depends on how many capacitors you can keep charged? Perhaps it's too early for this type of discussion, but I think it has potential.

[Grenkin1988]

#761 More to be added soon

[vogonistic]

After reading the code in #793 I realized that PowerRelated is a connection between a Furniture and the PowerGrid. Have you considered putting the whole system in a namespace Power and call them Grid and Connection? It'd would be PowerConnection in the XML.

The new job system I'm working on is in a namespace ProjectPorcupine.Jobs

[Grenkin1988]

@vogonistic All my new code is in PowerSystem folder. But I think there is no such thing as namespase in Unity? But I definitely could go for PowerConnection

[vogonistic]

Unity has namespaces and it works fine in my tests.

https://docs.unity3d.com/540/Documentation/Manual/Namespaces.html

[NogginBops]

@Grenkin1988 You just need to put the classes in a namespace and you have a namespace. Unity doesn't care.

[Grenkin1988]

Next iteration ready for review #968

[Grenkin1988]

New live power system is in place and all existing Furniture updated to use new system

[Grenkin1988]

Added fully operating accumulator with placeholder image #1079

[Grenkin1988]

Next would be save/load but I would prefer to wait with it before we finished or data format discussion.

P.S.: just interesting does anyone read my updates :-)

[vogonistic]

I read everything :)

[mikejbrown]

Where is this on the save/load logic? This is currently assigned to v0.1. Are you close or do you want to bump the last step to v0.2?

If you want to wait for the data format to settle it might be best to bump it in case it changes for v0.2.

[mikejbrown]

Alternately if anyone wants to claim "Implement save/load logic for system" please do so here and submit your own PR.

[mikejbrown]

Okay, bumping this.

[bjubes]

@mikejbrown neither @TheRiven or @Grenkin1988 have branches on their repos so I assume that any work that is not already merged into master is non-existent or is being implemented by someone else. as said by @Grenkin1988 he held of on saving b/c of the data format discussion

[dusho]

what is meant by save/load here.. only current statuses of accumulators? If yes, then it should be covered by #1520

[dusho]

now that #1520 is merged, this can be closed, I guess.. unless there is still something missing...

[koosemose]

Closing as this seems to be addressed.