Maybe I can’t see some obvious solution to that, but I really need help! Let’s start from this tutorial:
It’s good, but the solution with RPC events bother me. In the chapter “Boost Dodge”, author is setting the value of “MoveDirection” through the RPC event and both in SetMoveFor/PrepMoveFor. Why? As far as I tested and read in code, movement component is sending over to server only the compressed flags. Not sure how the predictive corrections work either, those need to run locally, to make those settings make sense. So how does it even work correctly in that tutorial setting?
My thinking is simple: player movement component needs to know when (timestamps!) to use the values we are giving it, and the compressed flags seems the only way of telling that to it. The whole system is using timestamps and all that magic which I don’t have time to implement the second time. My headache is, when we use RPCs the data transit is not instant, so timestamps is a must!
Looking on source code it is impossible without modifying the engine code because this code is deeply rooted in UCharacterMovmentComponent code. My best bet for fastest and easiest extension of the flag size i can think of is to go to the engine source code and modify all “uint8” types related to the flags and change all of them to either uint16 or uint32 (if you need more) and you need to be careful since changing types alone might not be enough as code processing them might prepared only for 8-bits, you will need to do proper modifications if thats the case, but if you skilled i don’t think it will be hard to figure how.
Hopefully this isn’t too late but while you are limited to saving only 4 bools, you can still combine them for different abilities. For example say you were limited to only 2 flags and you had made “Ability 1” and “Ability 2”
you can make “Ability 3” and set both “Ability 1” and “Ability 2” to TRUE. Then when check what ability to use, check if both are true and then call “Ability 3”. There are some limitations that need to be worked around because there will be conflicts from using the combination of bools. I haven’t really looked into how exactly moves are saved but I would not be surprised if you somehow activated both “Ability 1” and “Ability 2” before the move was sent then it would be read as “Ability 3”. My solution to this problem is to set all other flags to false when calling an ability. The trade off is that you will overwrite abilities instead of saving them both in the same move (I’m guessing moves are saved every tick so this is probably pretty rare).
If anyone is thinking about modifying the engine I would recommend trying this method before going down that road.
Let me know if there was anything unclear about this, I can go into more detail if needed.
All of these headaches are because of data transit via RPC is not instant. Other replication methods except using character movement’s timestamp are so slow. UE have to give us another proper way to implement it.
Yup exactly! Just be aware of the issues that may come up. When you have 1 “action” per flag there is no issue sending multiple flags in each move. However combining the flags will trigger unintended actions if the flags that make up that action are processed at the same time. For example if both actions (0001) and (0010) are processed at the same time action (0011) will be fired. Most of my actions are context dependent and can’t be activated at the same time (single button that is context dependent). The ones that have a very slight chance of interfering I made sure to separate.