High level method suggestions

I know some of these might end up being very expensive. Sadly, Mojang is doing a $#!t job at improving their command system to perform better in complex mcfunction files.

Here’s my list of suggestions:

Working with inventories

In C++ version, the container could be a class holding context about container position, possibly extra position for double chests so that you don’t have to check for adjacency every call. In C it’s a struct.

• get_item_count(container, item, slot_range=all)
  • test every slot in container for each number 1-64, sum them, use result - yes, very slow
• has_item(container, item, count=1)
  • same as above but terminates earlier so a bit faster
• modify_item_count(container, item, count=1)
  • positive count values add items, negative remove items
• Support for item frames.
  • Methods mentioned so far would allow spiffy and compact sorting systems to be written for example.

Working with data

I suggest you allow loading files (just one format is more than enough) and using their content. JSON files would probably be the best choice as MC uses JSON for its data pack content. Using fopen/fstream would be confusing, I suggest a custom name like json("rel_path.json"). This would for obvious reasons be read-only. Treat object as a struct. During compile-time, read content from the path and bake in all possible permutations (YES, slowness) based on possible states.

Make IDs a primitive type

Store a local list of all blocks and items - generated from decompiled minecraft code, not sure if there’s a better source - so that they can be treated as primitive types. This would ease the pain of generating large numbers of permutations for commands which interact with inventories.

Block states

Allow interacting with block states. These can be optimized a bit as they are block dependant. Information can be generated from each version data. Access from C++ with operator[], from C through struct values.

I haven’t looked at Minecraft for a very long time so some of these might be possible to do in a better/more optimized way. I’m aware these are a lot, but they would make writing huge mcfunctions files simple as it’s easier to generate 10000 lines of commands from python than actually writing them. Having said that, I’ll create yet another suggestion on r/minecraftsuggestions and spam the discord that they add commands for populating scoreboards with item counts and reducing/increasing stack sizes in inventories.

I’m currently very busy, but your project is something that I’ve been thinking about for two years now and I’m very interested in how it pans out. I’d love to contribute, I might sometime soon, but I’m currently working on a decompiler.

Edit 1

Raytracing

Another commonly used function that should work 99% of the time and is extremely useful is raycasting. There are some problems with it (like detecting non-full blocks), but these could be supported via tags (as in block/item lists in data json). Here’s a nice tutorial I found for it which explains in great detail several techniques and their drawbacks. A few things have changed since it was made but generally, it still applies. Some things could be optimized a bit for instance.

Possibly even snowballs could be used by teleporting them and changing their velocity (it should be possible I think), this would provide a better performance and a much better collision detection than using armour stands. Would involve complicated calculation for velocity but that’s only a problem to do without a script or a compiler.

[simon816]

I’ve been making a bit of progress on a Container API.

I’ve added Container.get_item_count

The following code snippet gets the number of stone blocks within a chest at position 193, 56, -11 (where I created a chest in a test world)

include "Items"
include "Container"
include "Text"

void main() {
    Container c(_IRType("block_pos", 193, 56, -11));
    int num_stone = c.get_item_count(Items.stone);
    Text t;
    t.append_ref(num_stone);
    t.send_to_all();
}

[Caellian]

I was trying to say that changes in other datapacks break cbl datapacks. I’d argue not all data packs are generated, and in practice, the breaking features usually are not, except when the datapacks are part of a mod. I primarily use forge datagens for loot/recipes/advancements, even for standalone packs, but as far as I am aware, few others do so as well. Also, your point about changing the configuration, yes you have to recompile the program, but if its a library, you don’t necessarily have to recompile everything that depends on it (provided the feature sets are ABI compatible), and you certainly don’t have to recompile literally everything on your computer when you flip a configure flag on some library (exception being of course something like glibc on linux, where just about everything depends on glibc).

“(provided the feature sets are ABI compatible)” is the crucial part here. I’m not sure how to be any more explicit in saying that changing blocks handled by your data pack will most definitely be a breaking change - with or without this feature. There is no way around it currently. If any other data packs depend on yours, they will have to recompile/rewrite parts of their logic to accommodate changes in yours.

Changing the list of available blocks is like disabling/enabling exceptions or certain functionality in a library. It wouldn’t be if there was a way of storing IDs and using them elsewhere, but as there’s no such option, it is. As such it is actually an “ABI” change and cannot be handled any differently.

I suppose you have never heard of an Application Binary Interface or stable versioning of that. Shared Libraries are versioned because certain changes break applications depending on them. The feature you propose means that all changes break the ABI of a datapack. This is my problem with that feature.

Ad hominem. I’d argue that there is no ABI when it comes to dynamically interpreted languages or in case of CBA a VM because neither of them is actually a binary format. CBA is not actually a compiler, it’s a transpiler adding a custom set of features (a compiled-in dependency) to allow a bit more flexibility when it comes to data mangling during command interpretation. So, we’re talking about API versions here.

Data packs haven’t been designed to work together or depend on each-other as mods do. I feel you have too high expectations from a very limited feature set being actually provided. While commands are in theory Turing complete, integration with the actual game state is very limited in incomplete.

My problem is that it would become impossible for me, as both a modder and datapack developer, to expose a stable public api for datapacks in the presence of this feature, not that my datapacks in particular are broken by an opt-in feature that breaks between environments.

If your API doesn’t use said feature it wouldn’t prevent you from exposing a stable API. Again, there is no better way of doing this. Another important thing to note is that majority of data packs are written for the vanilla game and support mods by accident.

Arguably, design limitations inhibiting the feature are very relevant. If you look to, say, the C++ standards committee, one burden paper authors have to bear is showing that it could be feasibly implemented, usually by providing implementation experience.

It’s not unimplementable. It is very possible and if you go through the entire issue you can see what is required to implement it and even make the iterated data self-maintainable.

I am offering feedback based on my use case to your suggestion. I’m sorry if I was mistaken that you were asking for comments on the features.

You keep bringing up how the feature wouldn’t allow data packs to operate together and work in modded environments but offer no alternative solutions. Yes, I’m aware and I pointed out several times that this wouldn’t allow mcfunctions to be reused by other data packs and that they could break on content changes. That’s not the point though. There is no way of defining a robust system to handle this currently. You keep on insisting that this feature shouldn’t be implemented because things would break, but they break anyway with or without it. The only alternative is to force data packs to write their own iterators and collect data they need on their own which is much more error-prone than what I’m suggesting. Even if you use something like Item("thaumcraft:wand") it’s up to the data pack author to accommodate any new content when new features get added. Eventually, every data pack definitely requires maintenance, no matter how it’s written.

This would only allow people to somewhat reliably iterate over vanilla content without having to collect all of that information on their own. Data aggregation can also be automated to a certain degree (as I’ve mentioned) which is far better than someone hard-coding list of blocks for instance.

So, instead of saying that the functionality shouldn’t be implemented because it doesn’t allow for some functionality you’d like, say what you’d like to be differently done so that it does. So far you’ve been ranting on and on about supporting mods, but I see no better alternative. It’s a small utility feature, not a be-all-end-all solution to fixing bad vanilla command design choices or missing crucial functionality to make mcfunction files actually a viable option for scripting content. There is only so much that can be done to make peoples lives easier and you keep fighting it as if what I suggested is in some way harmful when in fact it makes things a lot easier.