DefianceLlama: Trade plugin loading but not allowing trades

By @DefianceLlama
 

19 hours ago, DefianceLlama said:

Trade plugin loading but not allowing trades

 

18 hours ago, IIIaKa said:

What exactly is not working? Starting the trade or completing it?

17 hours ago, DefianceLlama said:

the trade Ui pops up put cant accept so the trade window stays open

Changed Status from Pending to Work in Progress

@DefianceLlama
Hello. Could you please send a screenshot of the window you're referring to?

at this moment in time the plugin is disabled due to the issue, the issue is when the UI opens and players add the things to trade, when you press accept nothing happens just the UI stays open

not to jump into ur feed but same. i came looking for possible fixes. when you open the ui and send the item both accept and it goes back to before accepted. not allowing the transfer of items at the moment. its not showing any errors in the console but its not working as it should for sure

Root cause: Trader's item-swap (line 2116) only runs if the trade carries both confirm flags — Reserved1 and Reserved2, vanilla's "both sides ticked accept" markers. Since the Sep-3 wipe/update, those flags aren't being set the way the plugin expects, so when the trade "completes" it hits a silent goto exit — no swap, no error, and no log line. The proof is decisive: the Trader log's last successful trade is 19 August — every trade since the wipe has silently exited. Same disease as today's composter bug: a plugin hooking vanilla code that Facepunch changed underneath it.

On 9/4/2026 at 3:36 PM, IIIaKa said:

@DefianceLlama
Hello. Could you please send a screenshot of the window you're referring to?

The cause is a change in ShopFront's accept flags in the new build. Vendor accept still sets Flags.Reserved1, but customer accept now sets Flags.Reserved3 (with Reserved4 set once both sides have accepted). Reserved2 is no longer used at all, and SubmitClicked has been removed from ShopFront.

TraderShopFront.TradeCompleted() still checks Reserved2:

if (vendorPlayer == null || customerPlayer == null || !HasFlag(Flags.Reserved1) || !HasFlag(Flags.Reserved2))

goto exit;

so every trade takes the exit path — items are returned and nothing is swapped.

Checking Reserved3 (or Reserved4 as the both-accepted marker) instead of Reserved2 should restore it. The SubmitClicked branch in OnRpcMessage (rpc 172945471u) is now dead code and can be removed.

Minor secondary issue: /trade <name> throws a NullReferenceException in Trade_Command (offset 0x00737) when the target player is mid-respawn or reconnecting — a null check on the resolved player would cover it.