Project Modding Arc

[Immortius]

Multi-shape blocks and unspecified shape blocks are now supported.

For the former, you can specify a list of shapes in a definition and a block family will be produced. For the latter, any block with no shape specified, that is uniformly textured, and not rotated can be requested in any shape. This includes the blocks generated for tiles in an 'auto' directory.

To go with this change block ids are now only bound to blocks when the block is first requested, so even though we now have... a few thousand odd block variations, it still works under our current 256 block limit.

 

[Skaldarnar]

Is it possible to add something like

"shadowColor" : #hexValue
"shadowIntensity" : [0-1]

to the block template system. That would allow blocks like colored glass casting colored shadows.
The default values could be black for the shadowColor and 1 for the intesity.

 

[Skaldarnar]

As I am talking about colored Glass : Whats the reason that placed Glass blocks don't have the translucent color whereas the block I held in hand and the block in item bar are displayed correctly?


Uploaded with ImageShack.us

 

[Immortius]

Don't know! Will have to look into that.

In general I'm reluctant to add shadowColor/shadowIntensity at this stage. Partially because the shadow implementation needs an overhaul or potentially replacement with SSAO.

Actually that gives me an idea on how coloured lighting could be supported generally - keep separate light intensity values for different color channels (maybe but not necessarily RGB - might get better effect with different channels), and combine when generating the chunk mesh. Obviously increases memory per block though.

 

[begla]

The answer to the problem might be quite simple: The chunk shader uses an alpha reject value which rejects any pixel with an alpha value below 0.5:

if (color.a < 0.5)
discard;

Regarding SSAO...

In general I'm reluctant to add shadowColor/shadowIntensity at this stage. Partially because the shadow implementation needs an overhaul or potentially replacement with SSAO.

This should not be too much work anymore taking the current state of my branches into account. All that is missing is a valid math library which eliminates transposing matrices all the time and does not fill up the memory in no time! I've got some camera motion blur using velocity vectors hidden in there... And some unfinished work regarding object motion blur.

All the necessary calculations to implement a deferred pipeline are in place too. I'll be happy to continue my work in that area starting next month.

 

[Immortius]

Nice . I look forward to seeing what you come up with.

 

[mkalb]

Will it be possible for a mod to use its own world generator and change the initial inventory?

I am playing with my children "lego duplo" and I like to make a mod for children.

 

[Immortius]

It is my intention that this should be possible, yes.

 

[mkalb]

That sounds very good.

 

[Kai Kratz]

The answer to the problem might be quite simple: The chunk shader uses an alpha reject value which rejects any pixel with an alpha value below 0.5:



Regarding SSAO...



This should not be too much work anymore taking the current state of my branches into account. All that is missing is a valid math library which eliminates transposing matrices all the time and does not fill up the memory in no time! I've got some camera motion blur using velocity vectors hidden in there... And some unfinished work regarding object motion blur.

All the necessary calculations to implement a deferred pipeline are in place too. I'll be happy to continue my work in that area starting next month.

Shesh put a gun to my head...

 

[begla]

I would never do that.

 

[Cervator]

I would!

* aims pixelated gun at Kai Kratz *

(It's okay, it shoots smiling GelCubes with big starry eyes)

 

[Cervator]

Quick (hopefully!) request regarding blocks and getBlock / getItem: Can we tweak the console commands to make them look for a block/shape by pure name rather than forced inclusion of a namespace? As in, rather than:

giveBlock "minerals:marble:engine:slope"

Do the following with a couple assumptions (can throw an error on ambiguous names + give the user a list of namespaces that block/shape exists in - but that's later, not needed yet):

giveBlock "marble", "slope"

It would also be nice to have a lookup fail for a non-existing combination, currently the console just accepts the command happily but gives you no blocks

 

[Immortius]

Done.

 

[Cervator]

Sweet! Thanks

I got a weird IntelliJ Groovy plugin error trying to compile, but then I've needed to update IntelliJ for a while, was still on 10-something. Worked fine after upgrading to latest.

 

[Immortius]

Added support for block categories - they can be set by

{
    "categories" : ["soil"]
}

in a block definition. BlockManager provides methods for finding available block families in each category.

I also changed the console command system so that commands are registered through annotations, which also provide the documentation for help:

public class TestCommand implements CommandProvider {
 
    @Command(shortDescription = "Opens every door in the world", helpText = "This command opens every door in the world and summons the elder god Tfarcenim")
    public void unlockTheWorld(@CommandParam(name = "delay") float d) {
        // ....
    }
 
}

With this the data directory has been removed - it never worked properly with the Applet anyway. Multiple CommandProviders are supported, and this can be extended for use by the modding system in the future.

 

[Cervator]

Awesomesauce

That block category thing will prove especially useful, especially with a tabbed block picker UI element

 

[Immortius]

Started working on mods with code. The initial work has been around the build script and a restructure of how mods are laid out. Mods are now set up as subprojects so can be worked with properly in an IDE. They compile into a classes folder within the mod folder, with the intention that they will work either just like that (exploded), or jar'ed (in which case the contents of the classes folder move up one directory). Assets on the other hand move into an assets directory, while still living in subdirectories based on their type.

Setting up a new mod is now a 3 stage process:
1. Create the mod folder and give it a mod.txt file with the info on the mod.
2. Add the mod to the subprojects list in settings.gradle.
3. Generate the IDE project for the desired IDE (either IntelliJ or Eclipse at the moment) using gradlew.

As far as making use of the code in the mods... at the moment new console commands can be added through mods, but nothing else and security still needs to be worked on. Things are coming together though.

 

[Immortius]

Added support for components, component systems and events - all these can be added to mods and registered either automatically (components, events) or through an annotation (component systems).

Did some messing around with security, have a sense of how it might work but decided to leave it for a bit. May want to do a big restructure to aid the security, need to think about it some more.

Started extracting out a couple of things that should be mods - the potions and books code - along with moving miniion code into its mod.

Two things stick out as needing changes so these can be done in mods - input binds and hud plugins or something similar. Started with input. Set up an annotation driven registration of buttons and axes as so:

@RegisterBindButton(id="forwards", description = "Forwards")
@DefaultBinding(type = InputType.KEY, id = Keyboard.KEY_W)
public class ForwardsButton extends BindButtonEvent {
}
 
@RegisterBindAxis(id = "forwardsMovement", positiveButton = "engine:forwards", negativeButton = "engine:backwards", eventMode = SendEventMode.WHEN_CHANGED)
public class ForwardsMovementAxis extends BindAxisEvent {
}

There are a couple of other optional settings for those annotations around when the event will be sent. Still need to hook into or (probably) replace the saving and loading of input config settings.

It is still possible to register binds programmatically too.

 

[Immortius]

Input configuration has now been linked to the the bind button discovery. To support binds introduced by mods, I've dropped to protobuf input configuration for a json one which is more flexible and is also user editable. The current format looks like

{
  "input": {
    "engine": {
      "attack": "MOUSE_LEFT",
      "backwards": "KEY_S",
      "console": "KEY_TAB",
      "crouch": "KEY_C",
      "dropItem": "KEY_Q",
      "forwards": "KEY_W",
      "frob": "KEY_E",
      "inventory": "KEY_I",
      "jump": "KEY_SPACE",
      "left": "KEY_A",
      "pause": "KEY_ESCAPE",
      "right": "KEY_D",
      "run": "KEY_LSHIFT",
      "toolbarNext": "MOUSE_WHEEL_UP",
      "toolbarPrev": "MOUSE_WHEEL_DOWN",
      "toolbarSlot0": "KEY_1",
      "toolbarSlot1": "KEY_2",
      "toolbarSlot2": "KEY_3",
      "toolbarSlot3": "KEY_4",
      "toolbarSlot4": "KEY_5",
      "toolbarSlot5": "KEY_6",
      "toolbarSlot6": "KEY_7",
      "toolbarSlot7": "KEY_8",
      "toolbarSlot8": "KEY_9",
      "toolbarSlot9": "KEY_0",
      "useItem": "MOUSE_RIGHT"
    },
    "miniion": {
      "toggleMinionMode": "KEY_X"
    }
  }
}

As mods are added new sections are automatically added for their binds, and the config file is automatically populated with the default values from the annotations.

Ultimately I envision all our configuration will move from protobuf to this file, to allow user editing, but I haven't enacted this yet.

I've also hooked in the input configuration UI to this new config system, although the inputs it handles are still hardcoded.