DMInternalWiki Logo

Want to edit this Page? Pull Requests are always welcome. https://github.com/Jaysonjson/DMInternal/

Addons

Addons for Dalek Mod are allowed, but we would like that any Addon follows these Guidelines and also these special cases:
- Your Addon should not use the dalekmod modid when registering stuff
- If your addon is both client and server (common) please disable the DMU Button in the Titlescreen
DM Assets and Data can be extracted from the .jar file or downloaded from here: https://jaysonjson.github.io/DMInternal/assets.zip

Addon Packs

Addon Packs are extensions for Dalek Mod which basically combine Datapacks and Resourcepacks into a single file.
They are .zip files which can have these extensions:
- .zip
- .dma
- .dmaddon
but .dma is preferred, so you know that it is a DM Addon.
An example Addon can be downloaded here:
https://jaysonjson.github.io/DMInternal/example_addon.zip

TARDIS

Builder

Dalek Mod 1.21.8 will use "TARDIS Builders", which handle how the TARDIS should be placed and destroyed in the world. For example, during demat the TARDIS Builder will remove the TARDIS Blocks and during remat it will place the blocks again with the required data.

TARDIS Builders are not Datapack driven but done via Java Code.

As of now Dalek Mod has 2 TARDIS Builder:
- DefaultTardisBuilder (Places 3 Blocks: TARDIS, TARDIS_TOP, LIGHT)
- NoLightTardisBuilder (Places 2 Blocks: TARDIS, TARDIS_TOP; Useful if your exterior does not have a lantern)

To create a custom TardisBuilder you need a class that extends TardisBuilder

public class MyTardisBuilder extends TardisBuilder {}

TardisBuilder is an abstract class that has the following functions declared:
- rematAction
- dematAction
- finishReMatAction
- finishDeMatAction
- setBlock
- createTardis
- buildTardis
- destroyTardis
- constructTardis

rematAction and dematAction get called during remat/demat, their finish actions get called once the animation is done. setBlock is a helper function that places a block in the world and updates it. createTardis is already defined, it calls constructTardis and then creates a new TardisData and its regarding TardisId. buildTardis is also already defined and will rebuild the TARDIS in the World with the existing TardisData. destroyTardis and constructTardis will place or destroy the TARDIS related blocks in the world but not do anything with data. In further, you can check our custom TARDIS Builders how they work code-wise, it is not rocket science and a simple system.

TARDIS Builders can be registered using a custom Fabric Registry

Registry.register(DMRegistry.TARDIS_BUILDERS, ¬ID¬, ¬builder¬);
Exterior

Exteriors are done using Datapacks and Resourcepacks.

Datapack Side - Server

Datapacks are only for the server, so this does not require much data to work with.
The Server only needs to know which TARDIS Exteriors exist, so the jsons will only be an array of data.
The jsons for exteriors are located inside data/your_namespace/tardis/exterior/ and will look like this:

[
  {
    "id": "dalekmod:test",
    "builder": "dalekmod:default"
  },
  {
    "id": "dalekmod:corrupted",
    "builder": "dalekmod:default"
  }
]

ID and Builder is technically self-explanitory, but id will be the exteriors id and builder will be the builder it uses.
You can have multiple jsons as you like with different data, if you want to organize your exteriors a bit - it does not matter since all jsons inside this folder will be loaded if valid.

Resourcepack Side - Client

Now the Client needs to know which Models and Textures it needs to render - thats where Resourcepacks come into play.
It can be internally in the mod or an extern resourcepack.
The jsons for exteriors are like for Datapacks located inside assets/your_namespace/tardis/exterior/

{
  "id": "dalekmod:test",
  "name": "Test",
  "description": "Test",
  "model": "dalekmod:geo/block_entity/tardis_exterior/canon/1963_police_box/1963_police_box.geo.json",
  "animation": "",
  "texture": "dalekmod:textures/block_entity/tardis_exterior/canon/1963_police_box/1963_police_box.png",
  "layers": {
    "snow_map": "dalekmod:textures/block/1963_police_box_snowmap.png",
    "light_map": "dalekmod:textures/block_entity/tardis_exterior/canon/1963_police_box/1963_police_box_lightmap.png"
  }
}

This is an example exterior json.
Every json entry is self-explanitory again, but I will talk a bit more about the layers:
Layers are what the snowmaps used to be in Dalek Mod 1.16.5 and you can add it using the Layers ID and then a path to the texture.
Something which is TODO is a System that allows to override the layer array from existing exteriors.
Reason for that is, if you have 2 addons that add new layers and both want to add them to default exteriors, one will override the other one.
You can do it via code by getting the ClientTardisExterior class from the TardisExterior Registry using its ID and add the layer, but I will also add an option to do it via resourcepacks.
For more information about layers, see the Layer section

Server-Client mismatch

When a Player joins, the Server will send all of its Exteriors to the Client, if the Client is missing an Exterior, it will render the "Corrupted TARDIS Exterior".
If you don’t know how to make a mod and result to a Server Datapack and Resourcepack, the Clients will need your Resourcepack in order to Render the TARDIS Exterior, otherwise its an ID Mismatch.

Pulses

TardisPulses control how the Demat/Remat animation look like. The TardisBlockEntity contains a float called "pulses", this float is used to calculate the alpha during Animation.
For the lights, lightPulses exist. The pulse ID is stored inside TardisData, so a player can choose which Pulse they want to use.

To add a new TardisPulse, you need to implement ITardisPulse

public class DefaultTardisPulse implements ITardisPulse {
    @Override
    public void pulse(TardisBlockEntity tardisBlockEntity, TardisData data, long tickTime, TardisBuilder builder, World world, BlockPos pos) {
        defaultHandler(tardisBlockEntity, data, tickTime, builder, world, pos);

        if(tardisBlockEntity.getState() != TardisState.NEUTRAL) {
            tardisBlockEntity.pulses = (float) (1 - tardisBlockEntity.dematTime + MathHelper.cos(tardisBlockEntity.dematTime * 3.141592f * 10) * 0.25f * MathHelper.sin(tardisBlockEntity.dematTime * 3.141592f));
            tardisBlockEntity.lightPulses = tardisBlockEntity.pulses;
        }
    }
}

Example Pulse class.
Your custom Pulse can be registered using our Registry DMRegistry.TARDIS_PULSES:

Registry.register(DMRegistry.TARDIS_PULSES, id, pulse_class);
Layers

Dalek Mod 1.21.8+ has these default Render Layers:
- snow_map
- light_map
- cherry_map
- sculk_map
- ash_map
- sand_map
- red_sand_map
- mossy_map
- pale_mossy_map
- mud_map
Custom Layers can be added inside data/your_namespace/tardis/layer

[
  "snow_map",
  "ash_map",
  "cherry_map",
  "mossy_map",
  "pale_mossy_map",
  "sand_map",
  "red_sand_map",
  "sculk_map",
  "mud_map"
]

The data will be sent to the client once they join.
Layers are checked inside the TardisBlockEntities tick, to add a custom check for your layer or to extend our checks for custom mod blocks/biomes you can make new entries into data/your_namespace/tardis/layer/checks

{
  "type": "block",
  "object": "minecraft:snow_block",
  "layer": "snow_map"
}

type represents the type to check, the types can be either block, biome or weather.
object is the object to check, so either a blockId or a biomeId or a weather type (rain, snow).
layer will be the layer to apply.

Sonics

Styling

General style rules

Almost all assets should follow the Jappa art style and the Minecraft style as a whole (Exceptions covered later). An overview of what that entails can be found at https://www.blockbench.net/wiki/guides/minecraft-style-guide/.

Consistency

Everything added in the mod should be consistent with everything else in the mod. When making an asset, try to base the asset on similar existing assets in the mod, or in vanilla Minecraft if there are none in the mod. If there is nothing similar in either the mod or the base game, then and only then can the asset be created completely from scratch (still ensuring to remain within the general confines set by other assets).

If making a new asset which is in a new art style, either the added asset should be adapted to better fit the style, or all previous assets should be updated to the new style.

Asset Creation
TARDIS Exteriors

These are almost certainly going to be the most common asset; any asset creator could theoretically turn whatever they wanted into a feasible TARDIS exterior to use in the mod. There are, however, some rules that should generally make all exteriors feel homogeneous.

Details

Any police box model with roof signs should typically have these signs as two seperate cubes; one for the front and back and one for the sides. This, of course, does not apply if the roof signs are a differerent shape from the typical designs, but most crucially (unless somehow recreating a police box with this particular feature) the signs should not be merged into one single cube. Exceptions may of course true for a "police box" that is supposed to be something "mimicking" a police box (See the Valentine’s police box from 1.16.5, which is mostly made from foodstuffs).

While, in general, any 3D detail that could be represented within the texture of a larger cube should be, there are some cases where TARDIS exteriors are allowed to spend a few extra cubes. The most notable areas for this that appear on most police boxes are handles and lamps.

Handles (unless very small) should be modelled, usually with a single cube textured on its front, top and bottom faces. These should usually only extend 1 or half a pixel out from the door it is attatched to. NEVER MODEL THE LOCK.

The lamp can now be whatever size it needs to be (as long as it is roughly in proportion with the rest of the box). Generally, lamp pillars should be represented by planes (usually each rotated 45 degrees in either direction). Despite this newfound freedom (at least compared to 1.16.5’s models) details that can become a single cube should still be represented as such if possible.

Door Size

In general, if the doors on any particular exterior can be 16*32 pixels (the same width and height of a vanilla door), they should be unless there’s a very specific reason. For example, most police boxes should have two 8*32 doors (that together make up the full 16*32), but some oddly shaped (see the Halloween police box from 1.16.5) or dramatically scaled (see the teeny tiny police box, also from 1.16.5) are allowed to have very different doors because without them their designs would not be practical. Even if trying to replicate, for example, a canon police box prop that is noticably smaller or larger in real life than other similar police boxes already in the mod, it is ideal for the doors to stay the same size (making sure the rest of the box is scaled proportionately).

With police boxes specifically (although this may apply to other types of TARDIS exterior), this does not mean that the space between the pillars, base and roof signs (where the doors sit) must be 16*32 pixels, as some police boxes may have an 'overhang' that sits between the doors and roof signs (such as the 2018 police box).

Shading

All TARDIS Exteriors with slanted roofs should be shaded in such a way that the parts of the roof that would face forwards or backwards (relative to the exterior) are lighter than those that would face to the sides.

Any and all indents/extrusions that are suggested by the texture alone (i.e. not actually in the model, such as police box panels) should be shaded as if light is coming from the top left. This ignores face direction; do not have light coming from different directions on differerent sides of the model.

Do not leave all shading up to the model; In some cases you may wish to make an area that should be in shadow darker (despite the fact that this should already be done by in-game lighting) to properly define these areas. Similarly highlights should be included in the model, especially if the material is supposed to be shiny.

Remember that anything that is supposed to glow should be included in a seperate lightmap texture. Although it shouldn’t matter in most cases, all pixels included in the lightmap should appear identical in the base texture. This is to ensure that if, for whatever reason, the game does not load the lightmap, the model still appears intact.

Exceptions

The style rules highlighted in this document can be broken for only a select few reasons.
- If an asset is supposed to be an asset ripped directly from an earlier version of the mod, this can be included in its original state (possibly with small modifications like file format etc.) so long as the asset is clearly labelled as such in game.
- If the source an asset is trying to emulate has an extremely important recognisable feature which cannot be replicated within the art style, some rules may be bent slightly to allow for this feature to be present.

Note: in cases where stretching the art style introduces a new way of representing features on previous assets, said previous assets should be updated to match the new style.

Sound

General sound rules

Every sound should be mastered such that its volume is relative to other existing sounds of the same type. This includes both in-game sound effects and all music.
All sound files should be stored in the .ogg format.

Music

There are three types of music used in the mod, namely title screen, ambient and music disc tracks.

Title screen tracks

Title screen tracks have fewer rules than their ambient counterparts, but more than music discs. These will usaully be arrangements of the Doctor Who theme, but other themes (perhaps themes from various Doctor Who spin-offs) may be included as well.

These will usually be upbeat (especially compared to the ambient tracks) and are free in their intrumentation.

Ambient tracks

Ambient tracks should be mostly consistent in both feel (to use a rather vague term) and intrumentation relative to other ambient tracks from the same dimension. Having said that, each track should be distinct enough from one another that it is possible to recognise which one is which when playing in game.

These are, as the name implies, ambient, and should not distract the player from what they’re doing, but rather enhance it. The vanilla tracks create a sense of importance to moments that would otherwise be dull, making said moments more memorable; we should be striving to achieve the same affect.

Music disc tracks

Music discs have the fewest rules of the three types of music, being able to be almost anything. They can be fast or slow, they can have variable dynamics or stay consistent the entire way through, and they are entirely free in their intrumentation (or could be almost entirely devoid of "intruments", such as the vanilla track 11). They do, as can be guessed, need their own unique music disc (clue’s in the name) and these should list the track’s title and composer.

For certain special music discs, they may have particular ways of obtaining them. You may wish to keep this "special" aspect in mind when composing/arranging said track.

Structures

TARDIS Interior

When designing a TARDIS interior to use in an addon, you should respect the limitations put in place. All interiors in the mod fit within a 64x64 area, equivalent to 4x4 chunks.

X Axis: Red | Z Axis: Blue

Red is the X Axis, while Blue denote the Z Axis. Each square is a chunk.

If designing a canon interior (one that has been in the show), you should aim to keep the styling consistent with the other canon interiors already in the mod.

If designing a custom interior, then you have free rein. It can be as expensive as you want, but it has to be obtainable in survival. This means no player heads or bedrock-equivalent blocks.

Redstone contraptions should not be part of the interior as they may break when generated.

Generated Structures

When designing a structure to spawn in dimensions, try and keep it within a chunk. There will be some exceptions, such as boss arenas or dungeons.

Simple structures, such as Thal houses (from 1.16), should aim to utilise the block palette of the area it will be generating in.

Larger structures may utilise a wider variety, but not go over the top. The structures should not become a resource farm (Dungeons are the exception).

If you have to use rare blocks, use them in moderation, don’t allow it to become the focus of the structure.