#How exactly does InputEvent work in netcode?

1 messages · Page 1 of 1 (latest)

plush glacier
#

I understand it’s meant for single inputs and that it’s an int under the hood. When would this int ever be greater than 1?
I have an “interaction” IInputComponent with both an Entity field and an InputEvent field. On the client, in GhostInputSystemGroup, pressing a button sets both fields. However, while both fields are set in the input system, during the client prediction loop and on the server the InputEvent is set but sometimes the Entity field is not.

prisma flicker
#

Are you following the example and only sometimes the Entity field is not getting set?

plush glacier
#

Yeah, and it is definietly correct in the GhostInputSystemGroup. But for some reason, it sets the Entity to Null in the prediction loop (I'm only reading it).

#

I still don't get how the InputEvent works. All I can find is just - Use it. It works. and that's it. But I'm trying to have an Event that takes more than just a bool, and that's what I can't figure out how to do.

prisma flicker
#

Post your system code and we can see what might be happening.

InputEvent is a type within the input component data. Its for events that you don't want happening multiple times during predictions. You need to check it's IsSet to see when the event fired.

The input system is running on the client. The input component is what will get sent over the network every tick. The process input system in the Prediction Group will be reading that input component on the server and the client.

plush glacier
#

I've been doing a bit more testing (because I've moved on to a different solution) and I think I have a better way to frame my problem:

The InputEvent makes sure that if it is triggered it will be triggered correctly in the Prediction loop. However, if I want to pass data with that input event (for example, an entity), the prediction system doesn't necessarily makes sure that that is also passed correctly. And my question is - is there a simple way to make this happen? To create an InputEvent with parameters?

Here's some pseudo-code, where the InputEvent will trigger, but an Entity passed with it will not trigger all the time.

public struct Input : IInputComponentData
{
  public InputEvent Trigger
  public Entity TriggerOn
}

// job in the GhostInputSystemGroup
public bool ShouldTrigger
void Execute(ref Input input, in TargetEntity target)
{
  input = default;
  if (ShouldTrigger)
  {
    input.Trigger.Set();
    input.TriggerOn = target.Value;
  }
}

// job in the Prediction Loop
void Execute(in Input input)
{
  if (input.Trigger.IsSet)
  {
    Debug.Log(input.Trigger.TriggerOn);
  }
}
#

I want to pass the Entity from the client (and not just have the same system on the server), because this is for a "pick up item" button, where if there is only a slight difference in the server and client simulation, it could end up picking up the wrong item. And so I have the client tell the server which item should be picked up (and a system on the server to confirm that it is possible for that item to be picked up)

#

I'm pretty sure this is due to the trigger being on a partial tick, I'm just trying to figure out what would be the best way to basically implement my own custom "InputEvent" with parameters

prisma flicker
#

You might be better off using an RPC in that case. But I'm not sure why the input component Entity would not be assigned

plush glacier
#

I'd really like to know how Unity does this though with the InputEvent. That way I'm doing it the "right" way.

prisma flicker
#

From what I can tell, it doesn't. InputEvent is purely for triggers

spare jay
#

InputEvent doesn't stay in sync with other fields due to special handling under the hood (which tries to avoid values being dropped). I'd strongly recommend using an int counter instead, that you increment every time you set the Entity. Thus, every increment = one event fired.

I.e. Non InputEvent fields will always stay in sync with each other.

plush glacier
#

Yeah, I also want to avoid values being dropped. I went with an RPC instead, since it's for picking up objects, and use a buffer with the Tick to keep track of when an object was picked up.
The only issue I have is that RPCs can sometimes arrive late on the server - at least compared to input events