Okay, just tested it in C++ - definitely doesn’t work. Tried using both a USTRUCT as the Key and an int32, it compiles (without the USTRUCT key), but game crashes in PropertyMap.cpp Line 417.
Nice! 
If most people are like me, they’d have started bleating on after discovering that crash. (though I guess I’ve not been bleating on)
I’ve just run into this issue too. I’m replicating a TMap<FName, float> that’s causing a crash when NetSerializeItem is called (PropertyMap.cpp:417). Are there any plans to fix this? I can use an array but it’s not ideal.
What is not ideal? If it is search, then you can employ binary search. If the array count is 1000, worst case scenario is number of loop is only 10 (vs 1000 if linear search).
Obviously there are cases where a map is better than an array or there would be no reason for its existence.
I know map has certain features which do not present in array (array is simple) but if it is searching, then there is a workaround for array and it may have the same performance. It is better than waiting for features which has no definite delivery date.
The workaround which is sort and then binary search is not difficult to implement.
The array I’m working with in this case is small so it’s not a big deal. Does FName have a predicate defined by default for sorting?
So… Still no TMap replication in 2018, 20 years later? 
What will be first - HL3 from Valve or TMap replication from Epic?
I bet on Epic - they are half step ahead 
2 Likes
What do you even need to replicate a map for, that you can’t easily work around by using rpcs or similar?
That’s a silly comment, the same can be said for any other type.
1 Like
As people said earlier, TMap replication would be horribly inefficient even if it worked. It’d be a bad practice all the way through. Think of the lack of support as a enforcing good programming practices.
There’s optimizations for FVector replication; could be there optimizations for TMap as well.
Sure, but it would be hideously complex - did you look at the array replication stuff? They’ve probably decided it isn’t worth the effort vs manually handling the few cases where a replicated map is useful.
Yes, I know half of engine would have to change lol…
But one gotta dream for life.
How mirror TMap logic via array?
Yes, you can implement a binary search for the array container, and yes, during the search it would result in a logarithmic complexity. What I am worried about, is that the complexity is actually hidden one step before. You need to have always a sorted array of elements ready. Each element needs to find its right spot, which will result in far higher complexity than adding an element to a regular map.
As a workaround, TArray may be used only for replication purposes and standalone TMap for computation, but then you get twice the memory size and twice the complexity of adding/removal of items in order to maintain both containers. Seems interesting anyway
For those who like me found this post when searching how to replicate TMaps, I ended up founding a C++ solution that worked for me.
I used the loose gameplay tags replication (from the Gameplay Ability plugin) as an inspiration: the loose gameplay tags are stored in a TMap which is then manually serialized by creating a wrapper struct and overriding the NetSerialize function. I then went a bit further and did a bit of optimization and I’m keeping some auxiliary data structures so I can have a diff and only serialize what was changed in my TMap - although my use case is quite simple and eliminates a bunch of more complex use cases).
Here’s the code that does it for AbilitySystem: https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Plugins/Runtime/GameplayAbilities/Source/GameplayAbilities/Public/GameplayEffectTypes.h#L1525