Skip to content

Files

integration

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Oct 17, 2015
Jun 11, 2022
Aug 13, 2015
Jun 7, 2022
Nov 3, 2018
Dec 30, 2016
Jun 7, 2022
Jul 12, 2015
May 7, 2023
Mar 19, 2016
Mar 19, 2016
Jun 7, 2022
Oct 12, 2018
Oct 21, 2015
Jun 25, 2022
Nov 22, 2015
Jun 7, 2022
Oct 31, 2017
Apr 29, 2015
Oct 4, 2015
Sep 19, 2015
Jan 6, 2016
Feb 6, 2016
Dec 11, 2016
May 23, 2015
Jun 4, 2023
Jun 7, 2022
Jun 4, 2023
Nov 17, 2016
Oct 2, 2015
Nov 22, 2015
Oct 4, 2015
Apr 7, 2024
Jun 7, 2020
Mar 19, 2016
Dec 29, 2015
Mar 19, 2016
Mar 20, 2016
Jun 4, 2023
Oct 8, 2014
Nov 1, 2015
Oct 13, 2014
Jan 15, 2015
Oct 8, 2014
Jan 1, 2018
Oct 8, 2014
Sep 1, 2018
Jun 7, 2023

This package contains code use to integrate with other mods. This is usually done by implementing block drivers for other mods' blocks, or by implementing (item stack) converters.

General Structure

The general structure for mod integration is as follows:

  • All mods' IDs are defined in Mods.IDs (Mods.scala file).
  • For most mods, a SimpleMod instance suffices, some may require a specialized implementation. These instances are an internal way of checking for mod availablity.
  • For each individual mod, there is a package with a ModModname class implementing the ModProxy interface. This class is initialized from Mods.init() if the mod it represents is available.
  • Integration such as driver registration is performed in ModProxy.initialize().

Have a look at the existing modules for examples if that description was too abstract for you.

On pull requests

The basic guidelines from the main readme still apply, but I'd like to stress again that all integration must be optional. Make sure you properly test OC still works with and without the mod you added support for.

An additional guideline is on what drivers should actually do. Drivers built into OC should, in general, err on the side of being limited. This way addons can still add more "powerful" functionality, if so desired, while the other way around would not work (addons would not be able to limit existing functionality). Here's a few rules-of-thumb:

  • Drivers should primarily be used to read information.
  • Drivers may "trigger" blocks, as long as the operation is not "physical". For example, setting the maximum energy output of a block would be fine, wheres making a block drop an item from its inventory would not - unless that block is providing such functionality itself, such as a dispenser (remember, guidelines :-P).
  • Drivers should respect the mod they add integration for. For example, MFR has "mystery" safari nets - it should not be possible to read the contents of those.
  • Drivers and converters should avoid exposing "implementation detail". This includes things such as actual block and item ids, for example.
  • If there is an upgrade for it, don't write a driver for it. If you're up to it, adjust the upgrade to work in the adapter, otherwise let me know and I'll have a look.

When in doubt, ask on the IRC or open an issue to discuss the driver you'd like to add!