TriggerLatentEvent triggering multiple times

Although, fivem/EventReassemblyComponent.cpp at master · citizenfx/fivem · GitHub causes another (but possibly related?) set of issues…

targetData->lastBit may wrap around to ensure all packets have been acked. However, this condition may prevent that from happening (i.e., all trailing packets have been acked, but early ones have not). This will (and can) lead to a latent event never being reassembled by the target/server as it will be considered as a doneTarget by the client.

A (shit) outline of what I suspect should be done:

// All packets have been processed
bool hasAll = true;

// find the first packet we have to send
int packetIdx = -1;
auto bc = ackBits.size();

// check if any 'early' bits still need to be acked
for (size_t bit = 0; bit < targetData->lastBit; bit++)
{
	if (!ackBits[bit])
	{
		hasAll = false;
		break;
	}
}

// find a packet to send in this 'burst'
for (size_t bit = targetData->lastBit; bit < bc; bit++)
{
	if (!ackBits[bit])
	{
		hasAll = false;
		packetIdx = bit;
		break;
	}
}

if (hasAll)
{
	// hey, we're done with this target!
	sendPacket->targetData[target] = {};
	doneTargets.insert(target);
	break;
}
else if (packetIdx == -1)
{
	// reset the loop as earlier packets have not been ack'd. Possibly
	// cache a packetIdx in the first loop.
	targetData->lastBit = 0;
	break;
}

To clear some confusion, I’ll be referring to FiveM packets as “FiveM packets” and IP packets as regular packets, to distinguish between the two.

But what I noticed is that it appears that the compression flag is set on a packet basis, but that compression is applied on a per “FiveM packet basis” so the msgPackedClones is compressed, but the msgReassembledEvent is not.

I might be completely wrong here, the code is a bit hard to read, got a habit of looking a bit to deep into things, but that’s what I can find seeing as it’s only combined “FiveM packets” into 1 packet which get seemingly ignored.

This doesn’t seem related, an enet datagram can potentially contain multiple (un)reliable enet packets if they’re sent rapidly enough, and handling of this should still work fine.

1 Like

I think this is indeed what might be going on in the packet capture snippets shown, yes.

I’ll try injecting some payload to push to packet size to multiple packets, see if the problem persists that way.

** Edit
So far it seems to be true, for around one hour, not a single double event, I pushed to payload to around 5 Kbytes now, I’ll wait a bit longer to be certain about it.

Waited about an hour, as soon as I added the data the double events stopped, normally got double events every 1 minute or so.

1 Like

A post was split to a new topic: Event playerConnecting triggers multiple times