anegostudios / vsapi Goto Github PK

BehaviorDecor has the following line. this.block is the decor block. The decor hasn't been placed yet, so this.block is not at pos. Instead the attaching block (what the decor is going to be attached to) is there.

                    var iad = this.block.GetInterface<IAcceptsDecor>(world, pos);

This causes Block.GetInterface to search in the following order for something that implements IAcceptsDecord:

1. The decor block that's getting placed (none of them currently implement IAcceptsDecor).
2. The block behaviors of the decor block that's getting placed (none of them currently implement IAcceptsDecor).
   Skips over the attaching block.
   Skips over the attaching block behaviors.
3. The block entity of the attaching block (BlockEntityMicroBlock is the only thing that currently implements IAcceptsDecor).
4. The block entity behaviors of the attaching block.

It doesn't make sense to try to search the decor block and its behaviors for IAcceptsDecor, because if one wanted the decor block to have different placement behavior, one could just override TryPlaceBlock. It would make more sense if attachingBlock.GetInterface<IAcceptsDecor>(world, pos) was used. Then the search order would be:

1. The attaching block.
2. The block behaviors of the attaching block.
3. The block entity of the attaching block.
4. The block entity behaviors of the attaching block.

Additionally, it would good to improve the documentation for Block.GetInterface. Is pos expected to be the position of a block of the same type, or is it okay for pos to point to a different block type like the decor behavior is doing? How does Block.GetInterface relate to IBlockAccessor.GetInterface? Is Block.GetInterface supposed to be an optimized version of IBlockAccessor.GetInterface (returns the same value) when one already knows the block type at the position?

Finally, please make it easier for attaching blocks to reject specific attachments. Please change these lines (replace second occurrence of attachingBlock with blockToPlace:

                    if (!attachingBlock.CanAttachBlockAt(world.BlockAccessor, attachingBlock, pos, blockSel.Face) || mat == EnumBlockMaterial.Snow || mat == EnumBlockMaterial.Ice)
                    {
                        failureCode = "decorrequiressolid";
                        return false;
                    }

To this:

                    if (!attachingBlock.CanAttachBlockAt(world.BlockAccessor, blockToPlace, pos, blockSel.Face) || mat == EnumBlockMaterial.Snow || mat == EnumBlockMaterial.Ice)
                    {
                        failureCode = "decorrequiressolid";
                        return false;
                    }

The comment above IBlockAccessor.GetDecors says that it always returns an array with 6 elements.

        /// <summary>
        /// Get a list of all decors at this position
        /// </summary>
        /// <param name="position"></param>
        /// <returns>Always a 6 element long list of decor blocks, any of which may be null if not set</returns>
        Block[] GetDecors(BlockPos position);

BlockAccessorBase implements this method, and it forwards the request to WorldChunk.GetDecors (decompiled from 1.19.0-rc.1).

	public Block[] GetDecors(BlockPos position)
	{
		return GetChunkAtBlockPos(position)?.GetDecors(this, position);
	}

However, the top of WorldChunk.GetDecors (decompiled from 1.19.0-rc.1) returns null. So IBlockAccessor.GetDecors can sometimes return null, despite what the comment says.

	public Block[] GetDecors(IBlockAccessor blockAccessor, BlockPos position)
	{
		if (Decors == null || Decors.Count == 0)
		{
			return null;
		}
...
	}

I suggest updating the comment to say:

        /// <returns>A 6 element long array of decor blocks, with null elements for the faces that do not have a decor, or sometimes a null array if none of the faces have a decor</returns>

Could we have optional ingredients for grid recipes?
An example, we have 3 cordage items in the Neolithic mod. Sisal-twine, Sinew, and Leather Strips.
When making a recipe for a tool I actually need to make 3 recipes, because there is no way to have optional ingredients unless they are variants of the same item.
In some cases is possible to create variants, but sometimes those items are already variants of other items. Sisal has its own variants, (fiber, thread, twine, rope).
In some other situations, blocks are completely different but could have the same function inside a recipe.
What I would like to have is something like this:
{
ingredientPattern: " F W_W WWW",
ingredients: {
"F": [ { type: "item", code: "animal-leatherstrips" }, {type: "item", code: "sisal-rope"}, {type: "item", code: "game: flaxtwine"} ]
"W": { type: "block", code: "game:planks-*" }
},
width: 3,
height: 3,
output: { type: "block", code: "game:woodbucket" }
}

Datastructures/AttributeTree/TreeAttribute.cs:905 :
IAttribute existing = attributes.TryGetValue(key);

is referencing the parent tree. This is causing merged attributes of a nested tree to appear in the parent tree and not do the merge correctly.

This should be changed to :
IAttribute existing = currentTree.attributes.TryGetValue(key);

Alternatively, I think a better way of writing it would be to make re-use of the MergeTree() function above and call as:
(existing as ITreeAttribute).MergeTree( value as ITreeAttribute );
or something to that effect instead of re-looping.

Spent some time getting confused why my item codes weren't matching, then I realised RegistryObject.WildcardMatch only checks the Path and not the Domain. Just a small modification, but it would be nice to have this available natively within the api to easily match modded items. Here is how I modified it for my purposes:

public static bool WildCardMatchDomain(this CollectibleObject collectible, string wildCard)
    {
        if (collectible.Code == null)
        {
            return false;
        }

        // Split the wildCard string into domain and path
        string[] parts = wildCard.Split(':');
        if (parts.Length != 2)
        {
            return false;
        }

        string domain = parts[0];
        string path = parts[1];
        
        // Match the domain and path separately
        return domain == collectible.Code.Domain && WildcardUtil.Match(path, collectible.Code.Path);
    }

Hey may be you could add the searching om the page. It would be good
dotnet/docfx#8577

Hi, Perhaps you forgot to put ".. \Cairo\Cairo.csproj", or forgot to remove from dependencies?

VisualStudio 2017 - C#