Super Duper Walls or SD Walls for short adds modular flexible walls to supported Luanti games.

Functionality

The mod adds walls from various different base nodes like cobblestone or stone bricks. The walls automatically connect to all other walls created by SD Walls.

In addition to that wall pillars are automatically created where applicable.

• At all corners
• At all T-junctions
• At all wall ends
• If the wall stands alone
• If the wall is surrounded by other walls

If a wall is not in one of the above positions it will automatically convert to a neatly fitting wall part connecting to the neighboring wall parts.

If you want to use a pillar/wall where usually a wall/pillar would be placed just punch the wall while wielding a wall. The punched wall will then toggle between the pillar form and the wall form.

Please note: This toggled type will be updated according to the neighbors when placing a wall adjacent to the toggled wall and has to be re-set as wanted at no cost.

Built-in support

High-level overview about currently supported mods and games:

• In Minetest Game, cobblestone, sandstone, and brick walls are available. Wooden walls are available but disabled.
• In Hades Revisited all bricks, cobblestone, and sandstone walls are available. Wooden walls and Color Wood walls are available but disabled.
• The Moreblocks bricks are supported.
• All Morebricks nodes are supported.

There are also some of the mapgen V6 and V7 aliases being supported, but those are disabled by default and are seen more like a “demo” in situations where no supported mods are loaded. You can turn them in in the config.

Feel free to suggest mods and games where it makes sense to add walls to.

Crafting

Crafting walls from the SD Walls mod is similar to crafting the common Minetest Game walls except the top right node. An “uncrafting” recipe also exists.

Feel free to open a thread in the CDB if this interferes with any of your other mods.

Configuration

The base configuration can either be set in minetest.conf (or whatever file is used to configure the server) or in a world-specific file ./worlds/worldname/_sdwalls.conf or in the advanced configuration from within the Luanti client (which sets the configuration in minetest.conf).

The detailed configuration (individual mods and game mods) are seen as world-specific settings. While they can of course be set in the global configuration, there are no settingtypes.txt entries being defined.

By default, walls for supported mods and games are loaded. Historically there were walls from wooden source nodes registered, those are intentionally disabled by default (“Walls from wood are fences but this is a mod about walls!”).

To get an overview about the currently loaded information, set those two options and start the world.

sdwalls_builtin_support_log_style = parser
sdwalls_builtin_support_log_level = action

This gives you a summary-style set of log entries and their current setting. Just adapt the settings as needed and place them in your configuration. The syntax for the built-in support options is always identical.

# Game-specific mods
sdwalls_support_game_mod_part = value

# Mods that are not coming with a game
sdwalls_support_mod_part = value

sdwalls_support is the indicator for this type of configuration, game is replaced with the game’s ID and mod is replaced with the mod’s ID, and value is either true (feature is being loaded) or false (feature is ignored).

Due to how this works and due to keeping the code footprint small, it might be possible to have ambiguous options.

# It could be a mod using ID `foo_bar_baz`, a mod `foo` from
# game `bar_baz`, or a mod `foo_bar` from game `baz`. You
# cannot configure those independently.
sdwalls_support_foo_bar_baz = true

It is unlikely that such a situation will happen, so code simplicity over error handling was chosen here. Personal note from the mod author: If you ever stumble upon something like that, feel free to send me a message somewhere I’m more than happy to hear about this!

Connect to the base node

By default the walls and pillars connect to their respective base nodes (cobblestone walls connect to cobblestone nodes, stone brick walls to stone brick nodes, etc.). Connections between different nodes are not made (e.g. cobblestone walls do not connect to stone brick walls.

sdwalls_connect_to_base = true

Those features are server-wide and cannot be controlled for individual walls. Set to false to disable this feature. A pillar is generated at the end of the wall and the pillar connects to the base node. To have a wall there you need to toggle it.

Connect to walls of same type only

This setting allows to disable the connection between different wall types. By default walls of different types do connect. If this is not wanted simply set the value to true so walls only connect to theirselves.

sdwalls_connect_to_self = false

For the sake of simplicity of this mod this feature only controls the connection nodebox to use. When set and two different walls meet they still prepare to connect (i.e. pillar generated at meeting point, wall generated to connect to the pillar), they just don’t connect anymore.

You need to manually toggle the walls/pillars to match their surroundings.

Connect to everything

By default, this setting is disabled. But when enabled, walls connect to “everything”, that is: all registered nodes that have the drawtypes normal or nodebox

sdwalls_connect_to_all = false

This causes walls to connect to, well, all nodes and nodeboxes – including all other wall types, basically overriding the detailed connection rules, resembling the “Minetest Game” default walls behavior

Rendering bug workaround

Pillars on top of other pillars that have walls connected do not show the wall’s texture where the pillar’s bottom would be. This comes from how Luanti renders nodes starting with version 5.6. This rendering method treads connected/disconnected nodeboxes as if they were present. By adding an absurdly small offset to the wall’s height this bug can be circumvented

sdwalls_height_offset = 0.0001

This offset gets substracted from the height. While implemented as a bug-evasion this value can also be used to simply change the height of the walls. Just set to any value you like. Due to code simplicity reasons there are no constraints, so you might be able to break the mod.

If the default value results in not properly shown walls or the bug still being visible, try to make the number larger or smaller. This is not a solution but a workaround. It might work.

API

SD Walls comes with a tiny API that allows modders to add walls to their own mods by simply registering them as described below. Mods need to depend or opt-depend on sdwalls in order to use the API.

Registration

The easiest method to register a wall is simply providing a node ID. This registers the wall based on that node ID with all of the node’s features. The call needs to be made after the mod registers the node otherwise SD Walls will simply ignore it.

sdwalls.register('mymod:mynode')

It is also possible to configure the registration for the wall providing a definition table. All table entries are optional.

sdwalls.register('mymod:mynode', {
  name = 'My Cool Wall Name',  -- name for the wall/pillar
  groups = {},                 -- additional groups
  pillar = pillar_table,       -- configuration for the pillar
  wall = wall_table,           -- configuration for the wall
})

The groups entry can be a regular groups table. All of the groups are added to the registered wall and pillar nodes. The wall_table and pillar_table tables can be used to override some of the base node’s properties. The tables are identical for the pillar and the wall entry in the definition table.

{
  tiles = tiles_definition_table,  -- override tiles
  sounds = SimpleSoundSpec,        -- override sounds
  light_source = 1                 -- override light source setting
}

The tiles and sounds tables are the same that are used to register nodes with the Luanti API. See Luanti API documentation on how to set those up. The light_source value is the same as for registering nodes with the Luanti API, too.

Mass registration

It is possible to provide multiple wall definitions at once using a table as only parameter. The table can contain node IDs as string or tables as keyed table entries where the key is the node ID to use as base.

sdwalls.register({
    'mymod:mynode_one',
    'mymod:mynode_two',
    ['mymod:extranode'] = {
        name = 'This One Cool Extra Node',
        groups = { mymod_extra = 1 }
    },
    'mymod:another_node',
})

This adds three walls with default configuration and one wall with a specific name and group membership.

Translations

Missing your language? Feel free to add it!