Is it not possible to extend the Map Blueprint Library with C++?

Guy_Paddock · October 20, 2021, 5:05am

We’re trying to supplement the “Utilities” → “Map” Blueprint library with two additional functions:

An Invert function, which swaps the keys and values of a map (assuming the values are unique).
A Build function that can assemble a map from two arrays of equal length – one containing keys and one containing values.

For reference, here’s the code for what I’m describing below:

gist.github.com

https://gist.github.com/GuyPaddock/60a773da39b2297a197d20eb8d2b1a2e

PF2CollectionBlueprintLibrary.cpp

// OpenPF2 for UE Game Logic, Copyright 2021, Guy Elsmore-Paddock. All Rights Reserved.
//
// This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not
// distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.

#include "PF2CollectionBlueprintLibrary.h"

void UPF2CollectionBlueprintLibrary::GenericMap_Build(const FArrayProperty* KeysProperty,
                                                      const void*           Keys,
                                                      const FArrayProperty* ValuesProperty,

This file has been truncated. show original

PF2CollectionBlueprintLibrary.h

// OpenPF2 for UE Game Logic, Copyright 2021, Guy Elsmore-Paddock. All Rights Reserved.
//
// This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not
// distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.

#pragma once

#include "Kismet/BlueprintFunctionLibrary.h"

#include "PF2CollectionBlueprintLibrary.generated.h"

This file has been truncated. show original

For the “Invert” function: we followed the patterns in UBlueprintMapLibrary ( Engine\Source\Runtime\Engine\Classes\Kismet\BlueprintMapLibrary.h ) but since our function needs to both take in a map and return a map there doesn’t seem to be any way to properly define the type of the result in relation to the original types (i.e. we need to be able to say that a map with keys of type X and values of type Y becomes a map with keys of type Y and values of type X).

In addition, it looks like the engine uses the MapParam annotation on the UFUNCTION() to perform some “magic” under the hood to transform the integer parameters into wildcard map parameters, but there can only be one parameter that is targeted by this annotation, even though code elsewhere says that the parameter is pipe-delimited. It looks like this is caused by an assumption in FCastWildCard::FCastWildCard() because there’s a comment that reads Map container param types (only one param per function call) above the code that parses the map parameter when wiring up the wildcard. So it doesn’t seem like there’s a way for a map-related blueprint library function to handle any more than a single map at a time.

For the “Build” function: I figured that this might be more straightforward since it’s like the Map_Keys and Map_Values UFUNCTIONs, but in reverse. I even got Blueprint to accept and display what seemed like the right types. But when the Blueprint gets compiled, the whole Blueprint graph gets filled with errors and suddenly the function refuses to accept the types it previously accepted.

Before compiling:

After compiling:

Drakgoku · January 29, 2023, 8:54pm

Can someone reopen this thread?

Guy_Paddock · April 30, 2023, 5:29pm

The thread is still open; you were able to comment on it, after all. Do you mean, revisit it?

RecourseDesign · April 30, 2023, 6:39pm

If it’s just to reverse it or assign the keys/values - it’s pretty straight forward without overriding the map at all:

Guy_Paddock · May 1, 2023, 2:40am

Though it’s true that you can do this in Blueprint using the approach you described, I was trying to find a generic way to do it that didn’t involve instantiating so many nodes. It wasn’t possible to do it with a macro nor a Blueprint function because it would be coupled to the specific key and value type of the map.

After a lot of research and trial and error, I eventually was able to build a solution to creating a custom “Invert” node that works with any map if it has a value type that can be used as a key type. The implementation is complicated because it required both a custom K2Node and a custom thunk so that the input and output pins are type safe.

Here’s the code:

github.com/OpenPF2/PF2Core

[#8] Implement a Custom, Generic "Invert" Blueprint Node for TMaps

committed 02:37AM - 01 May 23 UTC

GuyPaddock

+793 -2

This finally adds the ability to easily invert any type of map in a blueprint, a…s long as that map has a value type that can be used as a key (the type must implement `GetTypeHash()`). This functionality is too complex to express through normal metadata on a `UFUNCTION` because the key and value types on the return value are expected to be the inverse of the key and value types of the input value. To accomplish that feat, a custom K2Node was implemented that initially appears with a wildcard input and output pin. Once the input pin has been attached to a non-wildcard map input, the output will automatically assume the inverse of the input type. At blueprint compilation time, the custom K2Node is expanded to a hidden, internal-only node from the new `PF2MapLibrary` blueprint function library. The internal node is defined with a custom thunk and accepts a wildcard input and wildcard map output. Blueprint would never allow this node to be used directly since the output pin provides no type information to later nodes that receive input from it. Instead, the custom K2Node forces the types of the pins on the internal node to match the types on its own pins. For example, if the K2Node received an input of type "const Map<String, Int>" then the internal node will be wired up to accept "const Map<String, Int>" and return "const Map<Int, String>". Since the internal node accepts wildcard parameters, it has a custom thunk to extract the input and output map references off the stack. The implementation then calls the `GenericMap_Invert` native code to perform the actual invert operation by swapping the pointers of every pair from the source map. This is a LOT of code for what should be a straightforward use case, but it is understandable given that the type safety built into Blueprint is there for a reason and can't reasonably be expected to support this use case easily since the types on the map are changing radically during the call and are generic to begin win. The only known limitation is that the constness of map values is not preserved during the inversion. This is a side effect of the fact that blueprint doesn't have a way to track the constness of map keys; it only tracks the constness of map values and the map itself. So, after inversion, we will lose the constness of the map values (which are now the keys).

Here’s what it looks like: