HOWTO?: Removing items from player inventory for #31 (or inserting for #32)

[jpcsupplies]

I can't get much further until I can work out how to remove items from a player inventory.. Googling has been less than helpful :)

Assumptions: this probably is only needed as client side code, since I assume client inventory is only saved server side if someone logs out in a cryo chamber or creative mode, or dies full of loot and a body spawns.

Basically I am at the stage where I need to do the following: At startup Init:

check (and/or create) an NPC bank entry - probably need to be at start up init - and probably needs a default balance constant like the bank balance one. (i can probably work this part out myself eventually)

check/create a trade region record for 0.0.0 (default trade region) (this one may be hard for my c# level - but the basics are in the mod already if I overdose on chocolate or caffeine first and do autopsy)

When player requests to sell:

Check the player is within 2500 (5km diameter) of a valid trade region, or the player they want to trade with. (could we make trade regions work like "discoverable" gps points where the game messages a player a gps point if they enter a trade region..? these points can be later used to locate the area or as autopilot targets..) (no idea where to begin here, probably reading the registered traders file and compare to player xyz based on a distance formula)

Check the player has enough of the item (s)he requested to sell in their inventory (ideally have it check any ship they are controlling too but not sure how hard that is) (This one i have no idea where to start)

Calculate the value of the goods (if no price specified, if a price is specified its a sell offer and will need to be checked when goods actually sell) (I can probably do this)

check the NPC (or player requested? although we could skip this and let the player worry about this, and only do the check if they /approve) has enough funds in their bank account to cover the trade (may be able to work this out) - this part is tricky as we are working with players and regions owned by players too - either way a range check is probably appropriate.

deduct the goods from the players inventory and add the quantity to the price file (or the offer file as appropriate) deduct the funds from the NPC bank record (or buying player record) if applicable and pay it to the seller (No idea how to get items out of player inventory)

[midspace]

This is the Admin command for clearing your own player inventory. https://github.com/midspace/Space-Engineers-Admin-script-mod/blob/master/midspace%20admin%20helper/Data/Scripts/midspace.adminscripts/InventoryManagement/CommandInventoryClear.cs

The code would go a little like this.

var inventoryOwnwer = player.Controller.ControlledEntity as IMyInventoryOwner;
var inventory = inventoryOwnwer.GetInventory(0) as Sandbox.ModAPI.IMyInventory;
//inventory.Clear();

decimal amount = 123;
var items = inventory.GetItems();
foreach (var item in items)
{
    if (item.Content.TypeId == ???? && item.Content.SubtypeName == ??)
    {
        var point = MyFixedPoint.DeserializeString(amount.ToString(CultureInfo.InvariantCulture));
        MyFixedPoint altPoint = (MyFixedPoint)amount;
        inventory.RemoveItems(item.ItemId, point);
    }
}

Comments: The MyFixedPoint has been a little irritating when dealing with floating point, which is why I've typically converted to string, and then used DeserializeString to convert back again. If we are only dealing with decimal, we should be able to use the cast where you can see altPoint used.

[jpcsupplies]

ahh.. ok something to play with, will give that a crack later

[jpcsupplies]

.. much later.. still struggling to even get a debug reply in my current sell command, let alone even think about trying to pass all the appropriate item data to remove the item being sold from my inventory..

[midspace]

Inventory movement issue.

To Bank

1. Player A offers to sell "X units of item C" to bank.
2. Bank accepts immediately.
3. "X units of item C" disappears from Player A inventory.

To other player

1. Player A offers sell "X units of item C" to player B.
2. Trade Offer is sent to Player B.
3. Player B is given Y minutes to confirm offer. 4. Player A has a short window to move some of item C somewhere else.
4. FIX: We should immediately move "X units of item C" to holding inventory.
5. If Player B rejects offer, return items to original inventory. If it doesn't fit, place in front of player.
6. If Player B accepts offer, transfer items to new player inventory. If it doesn't fit, place in front of player.

Also, I think the other player should be given an additional option to extend the offer timeout. They may not be in a position to currently accept the offer, but don't want to reject it either. They may need to either move themselves somewhere, or need to turn off gravity to prevent the new inventory from damaging something.

And. Trade offers (looks like I've adopted the Steam term. I'm not sure what you want to call it) need to be queued. If Player A gets an offer from Player B, and whilst typing in their response, they receive an offer from Player C. Their currently unfinished chat response needs to go to the first (oldest) offer, and not the most current one.

[jpcsupplies]

For Short term simplicity on the queue offer side, this release we can just respond they are already negotiating a deal; try again later. Depending how we track the offers we may also need some startup check that releases any deals active during a server shutdown.

Long term Another approach might be making use of the global stockmarket logic. Each player as a trader will have a cut down version of the NPC price table associated with them; but listing only goods they have posted or received offers for. Players offering to sell could have their offers posted there during the time limit, eliminating the need for a queue at all. All we need then is a timer to remove the offer at the end. That means the buyer can pick and choose when to buy however much he can within the time limit...

[jpcsupplies]

Looks like we need to get something in place for #35 before we can finalise this issue.