Disable moving pawn with platform

Hi I would like to know if there is a way to avoid moving pawns that stand on a platform which is moved with SetXXXLocation() in code.

The platform is moved very far away - and the pawn standing on it will practically teleport to that new location.

I believe the “problem” is a feature where a Pawn can be “based on” another primitive component, and when that based on component moves the Pawn will move with it. A Pawn is usually “based on” whatever it is currently standing on. You can disable this for an actor by turning “Can Step Up On” to false, but your Pawn may bounce around when on the platform.

There isn’t a way to manipulate what a Pawn is “based on” in Blueprint, but in code, the best way to handle this is to probably call a SetBase(NULL) right before your SetLocation calls.

If you want to do this in blueprint but still are using C++, you can create a BlueprintFunctionLibrary function that would call SetBase(NULL) on an ACharacter.

If you don’t want to do this with any C++ at all, you might be able to achieve this buy applying an upward force on the character or really any force that would cause the character to no longer be “based on” or “standing on” the platform when the platform is moved.

Hey, thanks for the answer. My project is basically 99% code, so SetBase could work but would be really inefficient for the way I am doing things.

I am working on a theoretically infinite world which is constructed around the player in form of procedurally generated meshes. Since it is a Top-down game I am generating a fixed amount of chunks around the player - just enough to fill the screen.

When the character e.g. reaches the next chunk in forward direction, I take all the dynamic mesh components from behind him and place them at the front of the currently visible chunks and rebuild the meshes for just those components. This way a character can walk around infinitely.

The problem is - the server needs to have the visible chunks from all other players too (for networked collision physics), clients only care about their own chunks - it doesn’t matter if other players, which aren’t in range of the own chunks - and thus can’t be seen, fall through the floor on the client side. If the server now moves the chunks around to rebuild them at other places, it will move the pawns that stood on those chunks with them - since the server has the authority over movement physics.

I didn’t really think about the SetBase() method - so thanks for the suggestion, but my structs, which manage the chunk movement don’t know which character is currently standing on which chunk. I could iterate over all the characters for each chunk to be moved and do all of that, but like I said it would be inefficient.

At first I experimented with just having the dynamic mesh not have any collision at all and just place a huge collision box at the floor of the map - since the idea was to only have totally flat tiles (but I am not really sure if I want them to stay flat anymore), but huge collision boxes have extreme precision issues - the larger the box gets, the more the characters stutter while walking over them (weird thing is, a huge BSP placed in the level didn’t have those issues).

I tried many different ways of just having a helper blueprint to build many smaller collision boxes and stuff, but it doesn’t really support the theory of infinity, so I went the more landscape-like approach with the dynamic mesh collisions.

I am also not really sure how AI would work on such a dynamic world, how would they find their way through the level if I only have the necessary chunks loaded at any time? But I guess this is a completely different matter.

I went a completely different way to solve this now, so this can be closed.

Why would you post this and not say what you did?

1 Like

Maybe, because the solution was totally unrelated to the problem (that’s why I wrote “I went a completely different way”)? But yeah, that was 3 years ago. I’m still sure I’d have posted a solution if it had been related.

It doesn’t matter if the solution was a fix for your specific technical problem. You found a solution somehow, either a workaround or using a different mechanic to satisfy your gameplay design. It is a solution and it is related.

1 Like

No, I never found a solution for this, that’s the point. I guess the word “solve” in my initial answer is throwing you off, English isn’t my main language though, so I used that word in the wrong context I guess.
I simply went for a quadtree based approach with automatic lod generation for the whole game world - is this answer more satisfactory? I guess not. I am not going to write a tutorial on how to generate procedural worlds with all the optimizations I came up with as an answer to a question that is, in my opinion, still unrelated.

For anyone looking for a potential solution to this…

I found that putting a plane mesh 1 unit above the moving ground and putting a transparent material on it to make it look like it isn’t there seems to work. You will need to move your other entities 1 unit up too but it shouldn’t be too difficult. Make sure your physics overlaps are set appropriately and you should be good to go.