ZeroPoint Energy API

ZeroPoint Energy API is a Power API mod. It was in early stages and only ever made for 1.13 Rift.

There is no capabilities (which I think Tesla and later RF/FE used) but it uses it's own structure for interactions.

Unclear if elements from it were ever used in a Fabric Power API. Would assume that any made for Fabric were for Fabric, or took from other mods like GregTech, Tech Reborn or made for their own purpose.

ZeroPoint is an energy system for Rift and Minecraft 1.13. It is mainly an API and adds a generator as an example block. There are a few fundamental goals:

Provide a deflated environment. RF and Forge Energy went through a massive power creep, to the point where base-level cables transferred thousands of RF/t and base-level batteries stored millions. This isn't conducive to a fun experience, so ZeroPoint is starting fresh.

Stay simple and easy to understand. ZeroPoint exposes itself in energy per second instead of per tick, so you have a better sense of how long things really take. Ticks are great for computers to understand, but not as great for humans.

Keep capable without capabilities. Capabilities aren't in Rift yet, so ZeroPoint adds its own structure for interactions. It will continue to be updated and improved while Rift develops.

For information on how to integrate ZeroPoint with your mod and guidelines on using ZeroPoint properly, please check the wiki.

Changelog: Initial release! Energy is now available to use in 1.13! Please make sure to check the wiki for guidelines on developing your own ZeroPoint-compatible systems so everything stays fun and balanced.

Github Description:

Energy for a new age!

This mod is open source and under a permissive license. As such, it can be included in any modpack on any platform without prior permission. We appreciate hearing about people using our mods, but you do not need to ask to use them. See the LICENSE file and API LICENSEfor more details.

ZeroPoint is an energy system for Rift and Minecraft 1.13. It is mainly an API and adds a generator as an example block. There are a few fundamental goals:

Provide a deflated environment. RF and Forge Energy went through a massive power creep, to the point where base-level cables transferred thousands of RF/t and base-level batteries stored millions. This isn't conducive to a fun experience, so ZeroPoint is starting fresh.

Stay simple and easy to understand. ZeroPoint exposes itself in energy per second instead of per tick, so you have a better sense of how long things really take. Ticks are great for computers to understand, but not as great for humans.

Keep capable without capabilities. Capabilities aren't in Rift yet, so ZeroPoint adds its own structure for interactions. It will continue to be updated and improved while Rift develops.

ZeroPoint is out, and energy is now in Rift! The implementation is currently most heavily geared towards blocks, but can be used for items as well. Entity support might be more difficult without capabilities, so we'll see how things go.

Note: the light version of ZeroPoint does not come bundled with the API. The API jar contains compiled classes, but may not yet work properly on its own and is primarily for development. The standard jar contains both the API and the reference implementation.

Github 1.0 download

Github Wiki:

How to Use ZeroPoint as a Modder

Meredith Espinosa edited this page on 18 Aug 2018 · 4 revisions

Pages 2

Home

How to Use ZeroPoint as a Modder

Importing

Player Interface

Balancing

Further Reading

Clone this wiki locally

ZeroPoint (ZP) is an energy system for Rift. It's similar to RF or Forge Energy, but focused on being a more enjoyable experience for users. This document will describe how to use ZP in your mods to to keep the game fun and engaging. Importing

At the moment, there is no specific maven for ZeroPoint. You can To add ZeroPoint to your project, you can use jitpack, Curse maven, or add the API jar to your libs folder. Player Interface

Since mods are meant to be played with, making sure the player interface is easy to understand is crucial. Fundamentally, ZP measures rates in power per second instead of power per tick, because it's much easier to get a feel for how long a second is than how long a tick is. All code-side interactions will still be per-tick, but any player-facing information should be power per second.

Almost all power systems have a distinct color, and ZeroPoint is no exception. I've designed ZP bar gui elements that you are free to use in your ZP-based project. For anything else that shows ZP, the color should be #005A5A or other colors appearing in the ZP bar.

Full ZP bar texture | Empty ZP bar texture Balancing

ZeroPoint is based off of Forge Energy and Redstone Flux, so is usable for many of the same cases. However, it isn't affected by the power creep that's impacted RF for a long while. It's best for the players to keep it that way, so here are a few guidelines to keep things in balance.

No (powerful) passive power generation.

While passive power gen can be convenient and helpful, it doesn't lead to a good experience for the player. Passive power generation is what's known as a First Order Optimal strategy, meaning that it's seen as the best way to go, even when it's not very efficient. This can lead to a lot of server impact with people just spamming weak but passive power gen instead of creating more powerful systems that take more effort. Vazkii had an experience with this in his time developing Botania, and decided to remove passive power gen to improve his mod.

Many tech mods have issues with this, especially ones like Environmental Tech and Draconic Evolution. Their systems are expensive, but they generate so much power that you never need to worry about it again. It just doesn't feel fun to grind to a payoff of having no more work to do.

Furnace fuels generate at most 10 ZP per fuel tick.

This doesn't mean that all solid-fueled generators can only generate at 200 ZP/s. This means that for any item where TileEntityFurnace.isItemFuel(item) returns true, the generator will generate a total of 10 ZP times the TileEntityFurnace.getBurnTimes for that item, as fast or as slow as you'd like. No matter the generator, if it runs exclusively off solid fuel, it should generate exactly 16,000 ZP for a piece of coal.

This might not seem like a lot of power, but that's exactly the point. As I mentioned, ticks aren't a good time unit for player understanding. It makes everything seem so much smaller than it really is. Use the 200 ZP/s figure instead of the 10 ZP/t figure, and it suddenly becomes a lot more clear how much power is being made.

No single block, machine, non-configurable multiblock, or item can hold more than 10,000,000 ZP, and nothing can produce or consume more than 200,000 ZP/s.

As mentioned earlier, Forge went through a massive power creep because of mods trying to be OP by requiring huge amounts of power. I want to avoid that, since power creep just increases grinding and doesn't make anything more fun or engaging, no matter how ridiculous the powers you get in return are. While it makes perfect sense for freeform multiblocks (like EnderIO capacitor banks) to connect to each other and share a collective energy storage, strict-structure "multiblocks" like a Draconic Evolution orb are much closer to a single big block than an actual multiblock made out of many components. While there are multiple tiers of Draconic Evolution orb, no two orbs of the same tier are any different, so structures like that don't count as a multiblock.

ZP is not magic. Don't use it (alone) for magic.

While magic mods are very cool and fun to play with, ZP is not designed for magic mods. Unless it makes sense in your mod (for example, it's explicitly a magitech mod or the magical item has technological components), do not use ZP to power it. Specifically, ZP should not be used to power creative flight or death-cheating (lava invincibility, total damage shielding, hunger-filling, etc), unless there is some clear reason why ZP is the thing that's necessary to power it.

These are some pretty aggressive restrictions, but remember that they are first and foremost guidelines. I can't force you to follow them, and it may turn out that doing things differently might lead to a better mod. I will, however, recommend that you follow them, because a stable, cohesive mod ecosystem leads to better experience for everyone. Further Reading

Beyond the Vazkii article I linked earlier, I'd recommend you watch Extra Credits' video on first order optimization, and general primers on engaging game design are helpful as well. Minecraft is still a game, and making it a fun one is the first priority.