Author Topic: External File Specs  (Read 2798 times)

JackOatley

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 732
  • Nobody
    • View Profile
External File Specs
« on: November 21, 2016, 10:49:26 PM »
I thought I'd put this up so you guys can see what's going on and provide feedback. This is mostly in regards to modding and what you might want to do with the provided tools/structure. For now I'm just going to show the main things I've been working on recently; Block Index, Item Index and Crafting Recipes. But I'll add new format explanations when they're created or requested. The goal is that all these things can be added to/overwritten via matching file structures inside mod packs, so feedback is helpful! :)

Block index format:
Here we have a name:value pair for each block, this is required in world generation, where I don't reference the name, but the number. And after the index we have an object for each thing named in the index, which has it's own display label, type of block, color on map, tileIDs for each face and a list of objects that spawn from the block with chance and number values.
Code: [Select]
{
    "index": {
        "dirt": 1
    },
   
    "dirt": {
        "label": "Dirt",
        "type": "solid",
        "color": "00337F",
        "faceTop": 17,
        "faceBottom": 17,
        "faceNorth": 17,
        "faceEast": 17,
        "faceSouth": 17,
        "faceWest": 17,
        "spawn": [
            {"item": "inv-dirt",  "chance": 100, "number": 1, "onDestroy": 1}
        ]
    }
}

Item index format:
No name:value pairing here as this is unique to the inventory and everything is referenced by name. We have two types of items currently, blocks and items. The block type simply says that this item has an associated block that can be placed in the world and we can pull it's data/graphics for the inventory. The item type has no representation in the world and can't be placed, but can be used everywhere else. For blocks, "data1" is the block index and for items it is the tile ID of it's graphic on the item sprite sheet. Items can have a "use", which determines what the player can do with it, for example; "consume" mean the player will eat/drink the item, and "vessel" means it can be used to gather resources from world blocks (like water). "uforms" (Use Forms) provides more information for the "use" cases, the bucket item below has a uform "water": "bucket-water", this means when the item is used on water it'll change into the item "bucket-water". "bucket-water", you'll see, is a consumable and it's uform is "consume": "bucket", which means when consumed it'll change back into "bucket". Items can also have "hunger" and "thirst" values, though currently these only come into play with "consume" items, these restore the player's respective stats.
Code: [Select]
{
    "inv-dirt": {
        "label": "Dirt Block",
        "type": "block",
        "data1": 1
    },

    "bucket": {
        "label": "Bucket",
        "type": "item",
        "data1": 6,
        "use": "vessel",
        "uforms": {
            "water": "bucket-water"
        }
    },
   
    "bucket-water": {
        "label": "Bucket Of Water",
        "type": "item",
        "data1": 7,
        "use": "consume",
        "hunger": 0,
        "thirst": 20,
        "uforms": {
            "consume": "bucket"
        }
    }
}

Crafting recipes:
This is basically a list of items that already exist in the Item Index, but here you define the ingredients (other items/blocks) that can be used to make the item, and how many of each. Up to 4 ingredients can be defined.
Code: [Select]
{
    "bowl": {
        "recipe": [
            {"item": "inv-wood", "number":1}
        ]
    },
   
    "torch": {
        "recipe": [
            {"item": "stick", "number":1},
            {"item": "coal", "number":1}
        ]
    }
}
« Last Edit: November 27, 2016, 12:08:46 AM by JackOatley »

R34LD34L

  • Sr. Member
  • ****
  • Posts: 340
  • "TERRABLOX!!!!!!!!"
    • View Profile
Re: External File Specs
« Reply #1 on: November 22, 2016, 03:19:49 AM »
Holy shit thats cool mod structure maker :) will become mod maker thingy
Schematic Mod Thingy!!!!

trg601

  • Hero Member
  • *****
  • Posts: 841
  • Just a guy
    • View Profile
    • Mutant Brain Games
Re: External File Specs
« Reply #2 on: November 23, 2016, 04:01:25 PM »
Is it possible to have some of the properties be optional in the json file? If you are editing the files by hand, it could get tedious to always write down the texture ID for all six faces. Maybe you could set a "main" texture and add in other optional faces if needed?
Also with optional properties you could easily add more options to the format without breaking indexes for older versions, such as light value and durability and other stuff.

Also, is it possible to have block IDs be a far off number like 5420? Nothing special about the number, but if you can make IDs numbers like that, it would be easier to set up mods that work side by side in the future. (But an automatic ID setting system would be good for mods too)

And the item system looks great! However, I noticed that you call the dirt block item "inv-dirt." Is there a problem if you call it "dirt"?
Also, an idea for block items, would be to allow different block IDs to be placed based on which face you spawned them on of a block, like in MC, you could create something like a jack o lantern that faces you when you place it (the different orientations could be different block IDs or a special setting inside the block, if that is possible)

And about the recipes, is it possible to put them inside the item index file? I feel like that could make things more organized, but it would have to be an optional property, and Idk if you can do that with Json files in GM.

I love modding, and I cannot wait to play around with this!
« Last Edit: November 23, 2016, 04:10:07 PM by trg601 »
I've made some stuff for terrablox, but I'm too lazy to link to much of it.
Terrablox Solder
Join the Terrablox Chatroom!

JackOatley

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 732
  • Nobody
    • View Profile
Re: External File Specs
« Reply #3 on: November 23, 2016, 10:06:18 PM »
@trg601,

Yes, that's possible. You'll notice in the actual blockindex.json file that things like grass blades and flowers only have the 1 face defined, and the others are set to a default when missing, so they could just be set to the first defined one.

Currently no, block IDs need to be within 8 bits (0-255). As voxel data is currently an 8 bit buffer, extra voxel data, such as lighting, is stored in a separate 32 bit sparse grid/buffer structure. When I come up with a better storage system, either a spare system like the extra data or a RLE system, I may supp0rt 16 bit voxels (0-65535).

I call it "inv-dirt" as just a method of avoiding confusion. Yes, you can name it the same and just call it "dirt". "inv-" is to specify that's it's the item-equal of a block. And sometimes there's things like "coal" and "coal-block". So, anything to avoid confusion, I do. But again, nothing stopping you from giving them the same name, they're separate systems. :)

I could add a feature to "inline" recipes. The craftingrecipes.json is just another itemindex.json without the other data and just the "recipe" data. But keeping it separate seemed like the wiser choice. For example, you might want a mod that adds recipes, but not change items. Think in terms of using multiple mods; if loading 2 mods designed to add recipes, just appending a separate file is easier than merging/overwriting the whole item index.

Anyway, I'll work to add as many tools as possible. You should see a release of this a couple days after I show off crafting working, lol. :)

trg601

  • Hero Member
  • *****
  • Posts: 841
  • Just a guy
    • View Profile
    • Mutant Brain Games
Re: External File Specs
« Reply #4 on: November 24, 2016, 04:37:30 AM »
Do you think it would be possible to create additional texture packs for modded blocks and items? Or perhaps a way to combine multiple pages into a single texture dynamically? I had the idea for making a patcher, which could add stuff like block indexes together. I think official support for multiple would be awesome, do you have any plans for something like that?

And if the block IDs are limited by 255 it isn't that big of a problem, but perhaps there could be some sort of automatic ordering of IDs, for mods and stuff? I suppose that would easily break if you wanted to change the order. Maybe just some safe-guards could be put in place, so the game would tell you if two mods were trying to use the same ID for something.

I see what you mean about the crafting, it makes things more compartmentalized.

Less important:
Spoiler (hover to show)
I've made some stuff for terrablox, but I'm too lazy to link to much of it.
Terrablox Solder
Join the Terrablox Chatroom!

JackOatley

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 732
  • Nobody
    • View Profile
Re: External File Specs
« Reply #5 on: November 24, 2016, 03:31:16 PM »
@trg601,

It's possible, but a little complicated. See tile IDs are currently 8 bits just like the actual voxel values. The ID is combined into a 32 bit vertex value with other data, there's two 32 bit values per vertex. And currently there's only 5 bits left, 1 bit by itself in one value and a 4 bit row in the other. These spare bits could be used to extend the tile ID range (ID range doubles per bit). Or keep the tile ID range 0-255 and have the 4 spare bits, for example, hold a mod/texture ID, so that would mean you could have 15 mods enabled that have their own block index (this would make mods more compatible). That would give you 4096 possible different tiles in game. Using the 5th spare bit (at a theoretical push) could give you 8191 possible different tiles.
But then comes the actual texture issues. It does work having multiple textures on the same page, in fact this is already implemented similarly with some faux mip-mapping I done to color out distant textures (just never released with it enabled). But, if using all 16 possible mods, the texture they all get put on becomes rather large, you're talking 4x4 2048x2048 textures (current default size)... The other solution is to pass them into the shader, 16 mods would still require 4 merge textures I believe. And I kind of want to keep those pass-in textures free for future stuff atm.
Anyway, to clarify; we're talking about texture packs associated with NEW (modded in) blocks. Texture packs that replace the existing default one are fine.

Well, like I said, the ideal would be to extend the range of possible block indexes. If done similarly to what I said above, having mod IDs, then that could be handy too.
It technically is also possible to dynamically change block IDs. But the save file will need to have name-value pairs (basically a dupe of the block index used), to detect if those orders change. But this will require that the block names stay the same, making the block index defunct anyway. I'll think about changing the block index system to just be dynamic my default, removing the need to list numbers, I'm not sure if there was a reason it doesn't already, lol.

Yes, that is exactly how the save files work. Previous versions of TB just done a memory dump (very big), or string compression (very slow), but they also weren't truly procedural, they were random. Nor would those methods work in a potentially infinite world. This version is now fully procedural, whenever, wherever you are, it generates exactly the same (or SHOULD, lol) terrain, so there's no point saving it. So we only save the changes that you make and apply them after generation.
That's not to say I can't add a memory dump command or something, but it'd have to be of a specific finite area. So "/world dump", for example, could export voxel data for all generated chunks around the player. Depending on the size, this should be < 100MB. Same could be done for the models, if you want to export a model of your world for external rendering.
Well, raw data is easy enough, formatting it is another thing, but if you're interested I can add these features and talk you through the data and you could create formatting tools? Like vertex buffer > OBJ, 3DS, etc.

trg601

  • Hero Member
  • *****
  • Posts: 841
  • Just a guy
    • View Profile
    • Mutant Brain Games
Re: External File Specs
« Reply #6 on: November 24, 2016, 06:52:45 PM »
-snip-
Well, raw data is easy enough, formatting it is another thing, but if you're interested I can add these features and talk you through the data and you could create formatting tools? Like vertex buffer > OBJ, 3DS, etc.
I like the idea of dumping parts of the world, that would make things easier to mess with.
That being said I don't really feel the need to make formatting/editing tools right now, but perhaps in the future, it would be nice to have something like that, so you could run your worlds through some fancy rendering software, or an external world editor like Terrabloxian's TBEdit (for legacy 1.3)

And here is an idea, I don't know if you already were planned for this or partially have it in already, but there could be a command to spawn in structure files in the game, like the trees and the ice spires.

Also, I think a lot of modding capabilities could be added to the monsters when (or if) you add them to the game, like modeling and stuff.
« Last Edit: November 24, 2016, 06:54:19 PM by trg601 »
I've made some stuff for terrablox, but I'm too lazy to link to much of it.
Terrablox Solder
Join the Terrablox Chatroom!

JackOatley

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 732
  • Nobody
    • View Profile
Re: External File Specs
« Reply #7 on: November 24, 2016, 09:32:09 PM »
And here is an idea, I don't know if you already were planned for this or partially have it in already, but there could be a command to spawn in structure files in the game, like the trees and the ice spires.

Also, I think a lot of modding capabilities could be added to the monsters when (or if) you add them to the game, like modeling and stuff.
Yes, spawning models is planned, always has been too. :) It's on the current task list.

This is also a definite yes, it just needs me to do the modelling/animation interface. All the underlying code is there and complete. However, you may see these things externalized first, before the implementation of a GUI toolset. The same design tools that I use will be part of the game and fully open for mod creation. :)

JackOatley

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 732
  • Nobody
    • View Profile
Re: External File Specs
« Reply #8 on: November 27, 2016, 12:16:25 AM »
Updated the Item Index section to detail "uforms", a potentially really powerful tool! While I currently just use it for buckets that gather water, it can be changed for any item to be used on any block. Imagine a bottle gathering water from cacti, or sap from trees, sharpening a sword on a rock, gathering snow in a cone for a rudimentary ice-cream. :)

trg601

  • Hero Member
  • *****
  • Posts: 841
  • Just a guy
    • View Profile
    • Mutant Brain Games
Re: External File Specs
« Reply #9 on: November 27, 2016, 04:58:12 AM »
Ooh! I love the "uform" feature! There could be a whole load of functions tied to that, like special potion effects, ground tillage, or maybe even being able to interact with certain blocks like buttons.
I've made some stuff for terrablox, but I'm too lazy to link to much of it.
Terrablox Solder
Join the Terrablox Chatroom!