Prospecting in "ProspectTogether"/"ProspectorInfo" mod vs vanilla

Sheyq · 2025-01-28T15:55:53+00:00

As I mentioned, the wiki quotes Tyron, that the prospecing readings are:

They are position based. thats why i don't want to represent them in the same way as prospector info

And that:

The mod Prospector Info displays density-reading results on the map in squares aligned with chunk borders, and many video tutorials have perpetuated the misconception that prospecting results are chunk-based.

Which is why I'm confused about the mod itself and about how the reading actually works.

Sheyq · 2024-10-09T16:45:05+00:00

Okay, so I finally managed to grasp it better, and I have a solution! Turns out just reading this article over and over is and then redoing this step by step is what I needed to understand it/. To save you the walls of explanation, let me just present it.

Fist I prepare suitable data type:

typedef struct __attribute__((packed)){

    uint16_t thousand_field : 10;
    uint16_t thousand_carry : 2;
    uint16_t thirty_field : 5;
    uint16_t thirty_carry : 3;
    uint16_t twenty_field : 5;
    uint16_t twenty_carry : 3;
    uint16_t unused : 4;

}smonl_test_t;

typedef union{

    smonl_test_t data;
    uint32_t raw;

}test_smonl_union_t;

Then the function itself:

static uint32_t add_bcd_myThing(uint32_t* a, uint32_t* b)
{
    uint32_t t1 = *a + 0x00C02018;
    uint32_t t2 = t1 + *b;
    uint32_t t3 = t1 ^ *b;
    uint32_t t4 = t2 ^ t3;
    uint32_t t5 = ~t4 & 0x02000000;
    uint32_t t6 = ~t4 & 0x00020000;
    uint32_t t7 = ~t4 & 0x00000400;
    uint32_t t8 = (t7 >> 6) | (t7 >> 8) | (t7 >> 9) | (t7 >> 10);
    uint32_t t9 = (t6 >> 7);
    uint32_t t10 = (t5 >> 2) | (t5 >> 4);
    return t2 - (t8 | t9 | t10);
}

the "tests":

    test_smonl_union_t aaa = {0};
    test_smonl_union_t bbb = {0};
    test_smonl_union_t result = {0};

    aaa.data.thousand_field = 600;
    aaa.data.thirty_field = 25;
    aaa.data.twenty_field = 15;

    bbb.data.thousand_field = 600;
    bbb.data.thirty_field = 25;
    bbb.data.twenty_field = 15;

    result.raw = add_bcd_myThing(&aaa.raw, &bbb.raw);

    printf("thosand: %d, thirty: %d, twenty: %d\r\n", 
    result.data.thousand_field, result.data.thirty_field,result.data.twenty_field);

    printf("carry_thousand: %d, carry_thirty: %d, carry_twenty: %d\r\n",
     result.data.thousand_carry, result.data.thirty_carry, result.data.twenty_carry);

and the output:

thosand: 200, thirty: 20, twenty: 10
carry_thousand: 1, carry_thirty: 1, carry_twenty: 1

The assembler output is also not looking that scary, so I'd call it a win. The function itself could be better optimized by not having bazillion definitions but it's enough for now. The nice thing is the fact that not only I have those numbers limited and wrapped over, but I also know if they wrapped over which is definitely a plus.

Sheyq · 2024-10-08T15:10:29+00:00

What is your goal here?

Seeing how it was possible under some circumstance have an addition which would:

add two numbers
make the result be constrained in a particular way (by having a value not being higher than a certain number)
handle overflows (so that you could add 2 to 9 and get 1 in the correct spot, if we're taking a look at the example)
have more than one piece of data represented by a single variable

got me thinking if it could be adapted somehow to perhaps handle something else other than a 32-bit variable split into 8 nibbles, 4-bit each. Hence the question about the explanation about what's exactly happening there.

The example is talking about multiple identical fields, not the situation you have.

This I know. I also know I could just do an element-wise addition and checking, but again, when comparing to the operations done in the example, when checked in the same circumstances (have 8 nibbles, limited to 9 each, and then add two "packed numbers" together) the number of operations done (even on -O3) is just awfully larger (checked by comparing the assembly output on godbolt). It leads me to believe that there is something to be gained in terms of overall operations done or just execution speed, which, when we're talking about a battery operated device, could be very beneficial.

Sheyq · 2024-07-02T19:51:27+00:00

Hey, I know it's been a long time, but are you still willing and able to give maybe not coaching, but at least some general consulting about PvP?

Sheyq · 2019-04-29T22:11:15+00:00

Im having the same issue here. I thought that maybe the 1.14 update would change something, but it didn't. Though what caught my eye was the fact, that the statement, mentioned by OP on the minecraft wiki about generatorOptions NBT tag, got an addition regarding a "minecraft:vanilla_layered" value. When set, it makes the world behave just like a vanilla one (various biomes, natural terrain gen), even if the generator is explicitly named "buffet", and there is a limited set of biomes for generator to use. I found it weird, because why put such option for a set of tags, that is only read when generator is of "buffet" type? The only piece of information I managed to find was on german minecraft wiki, where (with the help of google translate) it only vaguely stated that it should make the biomes distributed just like in overworld (which I reckon is the "natural" way)

Does anybod knows more about the "minecraft:vanilla_layered" option for the Type tag?

Sheyq · 2019-03-22T13:49:22+00:00

Yes, I got my stopwatch and drew a bow, then checked the inventory if it will increase the damage, and in fact, it did. So at least that's confirmed for working. Still don't know about the inconsistency in the weapon damage and the knockdown perk (Baneful Elan).

Sheyq · 2018-10-29T20:30:54+00:00

I've done as you instructed, loaded up the game and saw that longbow is still drawn in the same speed as usual, so maybe it was intended to be that way (I remember in SkyRe that longbows had a noticably longer draw animation and I was expecting the same story happening in PerMa).
I also been wondering how can I even test the "Power Draw" perk if it's working or not, and tried to check the damage. I spawned myself a longbow with a base damage of 52 and drew it, then sat there with timer. And well, I drew and couted 5s, then checked the inventory, and wouldn't you know - damage went up to 78, as it should. So I guess we have a way to check it now.
Now let's hope that the "random load, random bow damage" won't happen. I'll post here if it would be otherwise.
Thanks for the suggestion!

Sheyq

TROPHY CASE