5: Data Structures and logic considerations

The following data structures should cater up to at least Abstract stage 10 of functionality.

• Database: Settings
• Purpose: Admin customization of economy behaviour
• Content:
• Assorted settings true/false/values etc

XXXXXXXXXXXXXXX

• Database: Players
• Purpose: Tracks players bank balance, nickname, UID, and when they last were online
• Content:
• UID, Balance, alias, Last seen timestamp

XXXXXXXXXXXXXXX

• Database: Stale
• Purpose: Records players who have not logged in for a while and retains their balance.
• Players in this database are removed from the main Player database.
• Content:
• UID, Balance, alias, Last seen timestamp

XXXXXXXXXXXXXXXXX

• Database: Price Table
• Purpose: A generic list of default recommended prices for commodities, and a list human readable descriptions to use instead of less friendly product ID's
• This could be adapted later to record the highest and lowest buy and sell prices set by the player market
• Content:
• Product ID, plain text description, unit buy price, unit sell price,(total qty in market at all prices?)

XXXXXXXXXXXXXXXX

• Database: Order Book
• Purpose: Records all items for sale or wanted to buy by players, and the offer price, Optionally refer to the station which is selling the goods at this price (for elite style trading functionality) This could be replaced by simply creating an Order book for each station also.
• Content:
• UID of seller, Product ID, Sell, Quantity, Sell Price, Optional ID of trade station
• UID of buyer, Product ID, Buy, Quantity, Desired Buy Price, Optional ID of trade station
• Notes: Orderbook could also contain a qty filled/sold field, but shouldn't be needed as the figure drops as each sale is made.

XXXXXXXXXXXXXXXXXXXXX

• Database: Assets
• Purpose: Records any ships or space stations players have up for sale
• Content:
• UID of Seller, Description, Price, GPS location, Ship or Station ID

XXXXXXXXXXXXXXXXXXX

• Database: Blueprints
• Purpose: Records prefabs/blueprints that players are allowed to purchase.
• These could be contructed at the ship yard, spawned in, or use the old blueprint "transfer" function if it still exists to copy the blueprint to the buyer. This database may be unusable for anything but prefabs server side - and is possibly made redundant by the Assets database
• Content:
• UID of Seller, Description, Price, ID or reference to relevent prefab/blueprint

XXXXXXXXXXXXXXXXXXXXXX

• Database: Stations
• Purpose: Records the required autopilot GPS coordinates of each trade station to allow haulers to dock correctly in high precsision mode.
• Content:
• Station ID, GPS coords of the connector to dock at

XXXXXXXXXXXXXXXXXXXXXXXX

** Suggested Logic:**

• Assets would need to be flagged indestructible, and converted to stations to prevent them moving. They should also be prevented from being powered up, and possibly remove ownership so that they cannot be exploited by the seller as an indestructible warship. Optionally they could be removed entirely from the map - or moved to a "used car lot" however this may cause issues with space stations which are usually aesthetically reliant on adjacent asteroids (or planets?)

XXXXXXXXXXXXXXXXXXXXXXXXXXX

• Alternate system - ships are moved to a "used car lot" and have a "buy now" button or similar attached to it, (all doors are opened and only gravity is left running? perhaps have a single gravity generator in the used car lot providing gravity and the ships are powered off?) Similarly space stations are NOT moved but still have a buy now button on them. Sellers could opt to have an unlimited range beacon to advertise its location.

XXXXXXXXXXXXXXXXXXXXX

• Alternate system 3 - ships are moved to a hidden location, and buyers must rely on the description of the sales listing (perhaps link to a webpage, image or mod item) (buyer beware!)

XXXXXXXXXXXXXXXXXXXXXXXX

• Alternate system 4 - make use of the image functionality of LCDs to display a picture of the ship or station for sale. Ships or stations location remain hidden until purchased. (they are not moved)

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

• Data would be interpreted as follows.
• When displaying order book, "summary"
• Note: an additional filter by station may be needed for Elite style trading model
• -----sort by product ID and sum qty of all each item for sale
• -----locate the highest (or lowest as applicable to buy or sell) price for display as current price
• -----for each item for sale cross reference Product ID with its plain text description in the Price table,
• -----sort by buys or sells, and item name, and display to the player -
• ---------- Sells: Item(plain text), current (lowest) price, qty in market, (qty at this price)
• ---------- buys: Item(plain text), current (highest) price, qty in market, (qty at this price)

XXXXXXXXXXXXXXXXXXXXXXXXXX

• When displaying orders book, "all orders on a given product"
• ----iterate over file, and pull out all items of that type into an array
• ----sort by price
• ----cross reference by product ID in price table to get plain text description for heading, and the Price table recommended price.
• ----display heading (product name/description), Table price, and then the sorted price list
• --------Item description (RRP $xxx.xxx)
• -------- Sells: qty, price
• -------- Buys: qty, price

XXXXXXXXXXXXXXXXXXXXX

• When completing a sale -
• ---- Total each orderbook item qty sold*price, Look up UID of player who posted sale, and increase his balance by the total. Reduce the item qty (or remove entirely if all sold) from the Order book. Look up the player UID who made the transaction, decrease his balance by the total, and transfer/spawn the required amount using the specified method (in his inventory, or drag dropping into a crate, or spawning it near him and throwing it at him, or dumping it like a connector into his docked ship whatever.)

XXXXXXXXXXXXXXXXXXXXXXXXXXXX

• When posting a buy order at a price nobody is selling at -
• Look up the UID in the Player database, deduct the value of his order fom his balance, if he doesnt have enough cancel the buy and display a warning, if he has enough add the order to the Order book.

XXXXXXXXXXXXXXXXXXXXXXXXX

• When posting a sell order at a price nobody is buying at -
• Look up the players UID, Look up the players inventory/drag drop source and check if there is enough to cover the amount they want to sell, if not cancel and display warning, otherwise remove the item from the players inventory, and post the sell order in the order book.

XXXXXXXXXXXXXXXXXXXXXXXXXXXX

• When selling ships or stations
• Transfer ownership and/or "teleport" the ship to the player, or the player to the station.

XXXXXXXXXXXXXXXXXXXXXXXXXXXx

** Logic considerations -**

• When multiple players post items at the same price, the script needs to cater for this and tally the totals for the orderbook at that price, it also needs to be able to pay the right amount to each player

XXXXXXXXXXXXXXXXXXXXXXXXX

• When posting a buy at a price higher than the lowest price it should purchase all orders to the specified qty up to the price chosen. Example:
• Order book -
• Ice for sale (RRP: 40):
• 10 at 40
• 20 at 50
• 100 at 80
• 200 at 100

XXXXXXXXXXXXXXXXXXXXXXXXXXXX

• Player requests to buy 150 ice at 100 each
• The script deducts 10*40 (400) and adds 10 ice to his inventory
• The script deducts 20*50 (1000) and adds 20 ice to his inventory
• The script deducts 100*80 (8000) and adds 100 ice to his inventory
• The script deducts 20*100 (2000) and adds 20 ice to his inventory

XXXXXXXXXXXXXXXXXXX

• After the sale the player has 150 ice, and order book looks like this:
• Ice for sale (RRP: 40):
• 0 at 40
• 180 at 100

XXXXXXXXXXXXXXXXXXXX

• The player who posted the 10 ice will have increased their balance by 400
• The player who posted the 20 ice will have 1000 more cash
• The player (or NPC) who posted the 100 or shares therin has 8000 more
• The player selling 200 has 200 more
• etc etc

XXXXXXXXXXXXXXXXXXX

• Alternately for simplification simply only allow ore at a given price to be purchased per transaction, however this has potential issues as well, especially if a lot of tiny amounts are listed.