1.12.1 Advancements using Universal Bucket

[Liahim]

How can I use a universal bucket in custom advancements?

I need "inventory_changed" trigger with filled universal bucket.

An example from Choonster does not work: https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/1.12.1/src/main/resources/assets/testmod3/recipes/_factories.json

 

Trigger:

"trigger": "minecraft:inventory_changed",
            "conditions": {
                "items": [
                    {
                        "type": "mist:filled_universal_bucket",
                        "fluid": "mist_acid"
                    }
                ]
            }

 

The console writes the following:

"There is no ItemPredicate of type mist:filled_universal_bucket..."

 

I think this is because the factory returns an ingredient, not an item.

 

Help!

[Abastro]

The factory is for recipes, you need to register ItemPredicate to ItemPredicates.

[Liahim]

Is there any example?

[Abastro]

Probably OredictItemPredicate class and this:

https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/test/resources/assets/oredict_predicate/advancements/recipes/wood_unlock_tnt.json

And this is rather fully-fledged with criterion, but could be help.

https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/test/java/net/minecraftforge/debug/OredictItemPredicateTest.java

Edited September 22, 2017 by Abastro

[jabelar]

Alternatively, there is actually a way to make a more "code based" custom trigger where you make a simple JSON trigger that always fires and then just call it when you want it to fire in code. I have an example here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-custom-triggers-aka.html

 

The JSON system is great for combining existing triggers and conditions (and probably can be made to work for your case) but it sort of an "indirect" system where it tries to fire and then is filtered based on predicates and such. I think there are a lot of cases in modding where your trigger is more unusual and it makes sense to have a trigger that always fires when you call it.

 

Note: Also I have to say that some of my longest debugging efforts have been related to problems with JSON files. The problem with moving logic to JSON files is that your IDE doesn't help you much with checking the logical stuff. Your IDE can ensure you have a properly formed JSON and can format and color code to make it easier to read, but it really doesn't have a sense of whether it will execute the way you want. And then when it doesn't work you actually have to debug it is complicated to trace because it all funnels through some pretty complicated JSON deserializer code.

[Draco18s]

You can do more complicated things as well, the magic happens inside the trigger() and test() functions.

 

Basically just make the test function check against whatever values you want to pass when you call the trigger in the code.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L83-L85

 

It'll throw errors, of course, all you have to do is work backwards to fix it. test() is called from trigger(), so fix that next:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L116-L120

 

Now your trigger call happens wherever you want to trigger the event from, just have to pass in the appropriate values.  If you want to let the json control some values, then head to the instance internal class, declare the class properties to hold them (and which you may already have in your test() method!)

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L74-L75

And then head over to deserialize:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L69

 

Lastly, you need to pass the deserialized values to the instance constructor.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/BreakBlockTrigger.java#L76-L117

And save them to the fields you created

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L78-L80

 

Add whatever's needed. I used an enum and used a string->enum parse already built into Java. If you want blocks/blockstates or items, look at the existing vanilla classes that use those and just copy-paste the deserialization bits over. Other types should be pretty easy.

[jabelar]

Draco, I think the "problem" I have with the system is to me the idea of a trigger is that once I call it, it should trigger. Instead, the system is designed to sort of filter the triggers so you call the trigger but it still may not match all the conditions. The idea of calling a trigger and it still having to test if it really triggers just seems unnatural to me.

 

The reason they did that is they wanted to allow the logic to be controlled and extended by JSON, presumably because then resource packs and people who don't know how to code well could still do some cool stuff. However, if you're already coding in Java (and assuming you're not specifically trying to enable people to replace your logic with resource packs) it makes a lot more sense to me to just trigger directly.

 

In other words, just look at how much you just wrote about what needs to be done. Also you're a strong programmer who's comfortable with serializers, factories, enums, and such so it is easy for you. I can do those things too, but not as well and I generally like simplicity so it is a lot easier for me to simply trigger directly in code. And just imagine how much trouble all those people who are trying to mod while struggling with Java will have.

 

For example, if you wanted to do something like have an advancement to trigger when you're killing a bat while simultaneously jumping and holding a custom sword, it is just one line of Java to instantiate it, one line of Java to register it (actually I put them the instances in an array so don't even need that), and one line of Java wherever in the code it makes sense to trigger it. I don't need to make predicates or fiddle with any JSON at all. If I want another advancement where for example you need to be playing a specific record inside a specific structure, same thing -- between two and three lines of code and its working.

 

I just think the JSON system is more suitable for allowing other people to modify your advancements (which may be important for some people) but is much less efficient and way more error-prone compared to if you just code it.

Edited September 24, 2017 by jabelar

[Draco18s]

  On 9/24/2017 at 2:05 AM, jabelar said:

Draco, I think the "problem" I have with the system is to me the idea of a trigger is that once I call it, it should trigger. Instead, the system is designed to sort of filter the triggers so you call the trigger but it still may not match all the conditions. The idea of calling a trigger and it still having to test if it really triggers just seems unnatural to me.

Expand  

Think about this for a second:

Distance traveled by rail, say.

You want 2 different achievements, one at 1,000 blocks and one at 10,000.

Which would you rather do:

if(distance > 1000) { OneK.trigger(); }
if(distance > 10000) { TenK.trigger(); }

Where OneK and TenK are two separate classes: one that checks for the trigger "oneK" and the other checks for "tenK".

 

Or:

OneK.trigger(distance);
TenK.trigger(distance);

Where OneK and TenK are the same class with the value that they trigger at controlled by a resource-pack-modifiable JSON data value?

(Now, 1K and 10K distance traveled probably shouldn't ever be modified from those values, they wouldn't make sense, but the idea that achievement trigger conditions are generic and resource-pack-modifiable in the general case has a pretty strong argument: afterall, the triggers on recipes work this way and I don't think you'd argue for chanting each recipe trigger to be a unique class).

 

  On 9/24/2017 at 2:05 AM, jabelar said:

In other words, just look at how much you just wrote about what needs to be done. Also you're a strong programmer who's comfortable with serializers, factories, enums, and such so it is easy for you.

Expand  

It's literally ten lines of code.

1, 2: the test
3, 4: the trigger
5, 6: the deserialization
7,8: the constructor

9: the class field

10: the place where you call trigger() (which you'd have to write anyway)

 

And every single piece falls from the previous one. You edit the test to take a different parameter? Trigger throws an IDE red underline error on trigger. So you fix that.  If you aren't reading any values from the JSON file, that's all you need (I have one like that). If you are reading a value from the JSON file, you start again in test(), checking against a non-existent field. That's an error, so you create the field and assign a value to it in the constructor. Now the deserialization has a red line, so you parse some values from the JSON object.  99% of what you do is either going to be a simple object (float, int, string, enum) or already done in an existing trigger (block, item). You add those lines, pass the values to the constructor....and you're done.  You've touched literally 10 lines of code for a single configurable value. Each additional value only adds 3 lines (as the remainder touch lines that would be touched for a single value anyway).

Edited September 24, 2017 by Draco18s

[Liahim]

Guys, guys!
Thanks for the help, but the custom trigger will not help me.
I need to look for a Universal Bucket in the vanilla trigger minecraft:inventory_changed.
Custom trigger will require a custom call. And this is a bit stupid.

 

Perhaps, all the same, will you help me register my own ItemPredicate?

 

P.S. I know the custom trigger system.

[Choonster]

The vanilla ItemPredicate class (used by the inventory_changed trigger) supports NBT, as documented on the wiki. 

 

You can also register your own ItemPredicate implementations, as I explain in this thread.

[desht]

Encountered this myself today and did a little research.  Choonster is exactly right about NBT & ItemPredicate, but it wasn't clear to me just what should be in the NBT.  With a little research, I learned that something of this form works:

"criteria": {
    "etchacid_bucket": {
      "trigger": "minecraft:inventory_changed",
      "conditions": {
        "items": [
          {
            "item": "forge:bucketfilled",
            "nbt": "{FluidName:\"etchacid\",Amount:1000}"
          }
        ]
      }
    }
  }

So, the item needs to be "forge:bucketfilled", and the NBT includes FluidName and Amount tags (it's a serialized FluidStack, to be exact).  The fluid name is of course the name under which you registered your fluid, and doesn't have to be from your mod.

[Liahim]

O! Thank you so much!
I think that this will help me )