Classic bug: Planet-owner PRICE display
| Bug ID | GE-BUG-019 |
|---|---|
| Affected versions | Classic 3.2e and published classic source |
| Status | Verified in source |
| Fixed in | ge-next 0.1 |
| Primary source | GECMDS.C: cmd_price(), buy(), and price() |
Summary
Classic uses two different prices when a player buys an item from a planet: the game's base price for the planet's owner, and the planet's configured sale price for everyone else. The transaction calculation observes that distinction, but the classic PRICE display does not.
When the owner requests a quote, classic calculates the total at the base price but displays the planet's customer price as the unit price. The two numbers can therefore contradict each other in the same sentence.
The two prices
Each item has a global base price. A planet also stores a configurable customer price in its markup2a field. Despite the field's historical name, the value used by the published classic code is the complete customer unit price, not an amount added to the base price.
The intended rule is:
| Buyer | Unit price used |
|---|---|
| Owner of the planet | Global base price |
| Any other player | Planet's configured customer price |
Classic's price() function follows this rule correctly when it calculates the total.
Classic behavior
For a successful PRICE command, classic performs the equivalent of:
total = price(item, amount);
display_price(amount, item, planet_customer_price, total);
The total returned by price() depends on whether the player owns the planet. The displayed unit price does not: classic always passes plptr->items[item].markup2a to the PRICE1 message.
This is correct for an ordinary customer. It is wrong for the owner, whose total was calculated from baseprice[item].
Example
Suppose an item has a base price of 100 credits and the planet owner has set the customer price to 250 credits. The owner asks for the price of ten:
PRICE 10 <item>
Classic calculates the owner's total as:
10 x 100 = 1000
but constructs a response equivalent to:
10 items are going to cost 250 each for a total of 1000.
The unit price says the purchase should cost 2500, while the total says 1000. The inconsistency is visible without completing the purchase.
What happens during BUY
The accounting itself is not affected. If the owner proceeds with BUY, classic charges the base-price total. Its successful BUY message also contains an owner-specific branch and displays the base unit price correctly.
In the example above, BUY charges 1000 credits and reports 100 credits per item. A non-owner is quoted, charged, and shown the configured 250-credit customer price. The bug is therefore a display error in the owner's PRICE quote, not a price-calculation or cash-deduction error.
Gameplay consequences
- Planet owners can receive a mathematically impossible quote.
- The visible unit price can falsely suggest that buying from one's own planet costs the public sale price.
- The correct total limits the direct gameplay damage, but the player must infer which of the contradictory numbers is authoritative.
- Customers who do not own the planet are unaffected because both their displayed unit price and total use the configured customer price.
Correction in ge-next
ge-next 0.1 changed the PRICE display to use the same owner/customer decision as the total calculation:
if (sameas(plptr->userid, warsptr->userid))
display_price(amount, item, baseprice[item], total);
else
display_price(amount, item, plptr->items[item].markup2a, total);
An owner now sees the base unit price and its matching total. Other players continue to see the planet's configured customer unit price and its matching total. The purchasing rules themselves did not need to change.
ge-next 0.1 also extended PRICE so that it can report the price of a requested quantity even when that quantity will not fit in the ship. That alternate "not enough cargo space" quote uses the same owner/customer unit-price selection, preventing the old mismatch on that path as well.
Porting guidance
The displayed unit price and the calculated total must come from the same pricing decision. A port can either return both values from one quote routine or select the unit price once and use it for both presentation and arithmetic. Do not recalculate the presentation fields through a separate unconditional read of the planet's customer-price field.
Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs