TODO: expand on the pay system to have a "request system" for money etc too?

[jpcsupplies]

missed This one.. and its in the user docs.. oops

/request # X Y (Send a request to player X for # qty of money, for reason Y[A prompt will display on the target player screen to approve or deny]) [not implemented]

eg /request 50 bob for the iron ore delivery

on the other side would be something like /approve or /confirm or /deny the deny side could have a time limit, so we dont have a pile of requests sitting somewhere

If we make the request system fairly generic - we can reuse it for paying players or selling goods to other players.

We need to think up the architecture for this - in the buy/sell system we can use the offer table for holding goods (table may need to hold cash too) this also has our timeout.

In the case or requesting money - we could use a keyword "money" or similar and instead of holding goods the qty represents a financial amount? then the timeout field is reusable for pay and buy/sell

[midspace]

Yes, I was thinking that we need a confirmation system when paying someone.

Ie, /pay bob 1400 uranium. PAY : You are about to pay 'Bob The Builder' 1400 for 'uranium'. Type '/confirm" if you approve. /confirm PAY : You have paid 'Bob The Builder' 1400 for 'uranium'

[midspace]

We may need to add a timeout to the transaction in case they take too long to authorize it. Say 5 minutes. It should also echo back to the player if it has cancelled.

[jpcsupplies]

hmm well yes if we put it on both the pay and request side we can sorta reuse the same logic in both commands - just with the originator on the other side in the case of request

[jpcsupplies]

Updated OP slightly..

[jpcsupplies]

Suggested logic:
When we need to set a timeout for something - call our p2p trade engine module pass following data: type as string, amount as decimal, price as decimal, item as string, person intended for as steam ID, person sending request as steam ID, time to wait in minutes

"type" is a key word representing type of action - eg.
PAY (request a player pay them x amount) Bob requests Fred Pay him 200 for bounty on Pirate kill BUY (request a player to sell them item) Bob asks Fred to sell him 5 rifle for 10 each SELL (offer to sell a player an item) Fred offers Bob 5 rifles for 15 each HOLD (wait until the player is online then transfer/return goods to them )

"amount" is the number of items requested. 0 if it is a payment request "price" is amount of money offered "item" is the code of the item. nul or "" if it is a payment request "person intended" identifies the person the request is sent to. "person sending" identifies the person Making the request "time to wait" is a time in minutes to wait for a response - if it is not time sensitive leave it empty or -1 to disable timer

Program logic: Check if a player has already sent this player a request. Only one request can be sent to a given player at a time, although multiple players can send requests to the same person. Or one person can send requests to many different players. Once called - check input data is valid Get timedate() deduct the money or items being offered from the player making the offer Write the (timedate plus "time to wait") and money or items being offered to a trade record "timeout" field, and all the details. If they are requesting to buy goods, deduct the money, and record the desired amounts If they are requesting to be paid, just set the price field; don't deduct anyones money until it is approved. If they are requesting to sell goods, deduct the goods and record them in database Send the "person intended" a notification.

Have the plugin regularly check the trade data table for time stamps ( public void UpdateAfterSimulation100() { } ??? ) if ((system datetime) >= timeout ) then remove this record (and return any remaining funds or items to owner) else do nothing (or perhaps resend the request each minute)

If the target player issues a /deny sender check sender id is valid or online. If not flag the "type" to HOLD and leave items there until the player logs on again return goods or money as applicable to the owning players remove the record containing a request

If the target player issues a /approve sender confirm time hasnt expired Check the data base for a record with both players steam IDs if it is a pay request - transfer the money across to the other player as per normal pay logic if it is a buy request - remove the money from the record. Pay the seller. remove the items from the record, give them to the requesting buyer - or sell partial amount if stock low if it is a sell request - remove the money from the buyer, pay it to the seller, remove items from seller record, add them to the buyer, remove record

[jpcsupplies]

Downgrading this as the player to player stuff is covered by a closed issue

[jpcsupplies]

Is it worth still adding in the /request command ? it is basically a pay command in reverse, where a player demands payment for something from another player.. it might be useful later in that we could reuse some of its logic when selling ships.. so might be worth it.. but i am not sure if this is compatable with our current accept deny system?

[jpcsupplies]

I am thinking given we plan to automate major things like ship sales, or restock / delivery subsidy missions we can probably scrap this ENH as not needed - Agree/Disagree?

[midspace]

I think we can still do it. It's just not a priority compared to other functionality.

[jpcsupplies]

OK, I will leave it active then.