Passing component into custom replicated event doesn't work for some object names

I have a custom event “handle button press on server” which accepts ActorComponent. On client, when button is pressed, this event is called and button is passed into it.

If there is a dot in components name, server event will receive None. More specifically:
“Test1” - receives component on server just fine
“Test1-1” - receives component on server just fine
“Test.1” - receives none on server
“Test.1-1” - receives none on server

This only happens in multiplayer game. When server sends the event to itself, all components work regardless of their name.

In the examples below, when testing on server itself, the result is:

Test1

Test1-1

Test.1

Test.1-1

When testing on client, the result is:

Server: Test1

Server: Test1-1

Server:

Server:

Hello Black Phoenix,

I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps to reproduce this issue on our end?
  3. Could you provide screen shots of any other blueprints that may be involved in this issue?

No other blueprints are relevant to the issue. This issue is trivial to reproduce:

1 Create a first person template based game.

2 Create a “Test button” blueprint, give it a “BlockAllDynamic” collision preset (make it a static mesh or collision shape). Name it “Whatever1-1”.

3 Modify the FPS template as following, replacing the “fire” button with imitation of pushing a button through ray trace:

4 Now try to push it. Initially, the result is exactly what one would expect:

70599-good.png

5 Now rename the "Test button"s component to “Whatever.1-1”, adding a dot there. Component is no longer transmitted into custom event:

70600-bad.png

The only difference is the presence of extra dot in the name. This is essentially the exact replica of blueprint from the main project.

Hello Black Phoenix,

I was able to reproduce this issue on our end. I have written up a report (UE-24517) and I have submitted it to the developers for further consideration. I will provide updates with any pertinent information as it becomes available. Thank you for your time and information.

Make it a great day

You shouldn’t use a period (.) in a component name, that is a reserved character used to indicate the Outer chain of a UObject. I’m actually surprised the engine let you do that! How did you create the component with a name like that?

There is no error check against giving components that kind of name. It can be set by directly adjusting name via C++ code, or from the UI.

It’s way too convenient for our project if component names could contain a dot, but it’s not decisive. The naming scheme for something we interface with involves dots, and the engine seems to allow fairly arbitrary component names.

Any update?

I am seeing the same behavior but only sporadically.
I reproduced it with a derived Foliage Instanced Mesh Component.

If I pass as parameter a HitResult containing this component from Client to Server in the Hit Component field, it’s always None on the server.
If I pass the Component as parameter, it either always works or always fails depending on the blueprint. And I haven’t found any difference between the 2 blueprints.

EDIT: I closed everything and restarted, and it’s now working fine for that other blueprint which had the issue. The foliage component are not replicated, but they are static level objects. Is that an issue?

Hello cperthuis,

As mentioned by , this issue was caused by having a period (.) in the component name. If this is not the case in your issue than it is more likely that you are experiencing a different issue. Could you please create a new thread for tracking purposes? You could this place a link to that new thread in a reply here.

Questions for the new thread:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps to reproduce this issue on our end?
  3. Could you provide screen shots of any blueprints that may be involved with this issue