Free ship!
Moderators: winston, another_commander, Getafix
- Cmdr James
- Commodore
- Posts: 1357
- Joined: Tue Jun 05, 2007 10:43 pm
- Location: Berlin
Free ship!
In an unmodified trunk, with a handful of oxps, I sometimes get a zero cost ship for sale in the shipyard. If I buy it, then it has its normal resale value, so I could make a stack of money this way. It is very hard to test, as I do not know what conditions cause it to occur, and removing oxps removes most of the ships I have seen it on.
In my most recent case (save-file available) it is a mosquito trader available for free. It is a "standard customer model, forward weapon upgraded to mining laser" There is another mosquito for a normal price (212300) at the same shipyard.
Is anyone looking at the (many) different ways ship value is calculated? If no one is, then I might try to get a single method on ShipEntity called something like calculateCost and see where I get to.
Just an idea, the standard forward weapon is a beam laser, which is 1000, and it is "upgraded" to a minig laser (800) it doesnt seem likely, but maybe this downgrade is breaking the calculation someplace?
In my most recent case (save-file available) it is a mosquito trader available for free. It is a "standard customer model, forward weapon upgraded to mining laser" There is another mosquito for a normal price (212300) at the same shipyard.
Is anyone looking at the (many) different ways ship value is calculated? If no one is, then I might try to get a single method on ShipEntity called something like calculateCost and see where I get to.
Just an idea, the standard forward weapon is a beam laser, which is 1000, and it is "upgraded" to a minig laser (800) it doesnt seem likely, but maybe this downgrade is breaking the calculation someplace?
- Influence D
- Above Average
- Posts: 23
- Joined: Wed Jan 16, 2008 10:44 am
- Location: Mooooooon
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
- Influence D
- Above Average
- Posts: 23
- Joined: Wed Jan 16, 2008 10:44 am
- Location: Mooooooon
- Influence D
- Above Average
- Posts: 23
- Joined: Wed Jan 16, 2008 10:44 am
- Location: Mooooooon
I've just found another case of this, also with an FdL with just a mining laser.
Some random logging revealed the cause of it:
Fer-de-Lance base_price = 485000
the code then adjusts prices for the cost of weapons:
Fer-de-Lance price2 = 484100
Fer-de-Lance price3 = 484820
Fer-de-Lance price, base_price before cunningFee = 484820 485000
(this is the only ship where price ends up lower than base_price)
Fer-de-Lance price after cunningFee = 0
Some random logging revealed the cause of it:
Fer-de-Lance base_price = 485000
the code then adjusts prices for the cost of weapons:
Code: Select all
price -= [self getPriceForWeaponSystemWithKey:fwd_weapon_string] * 90 / 1000; // 90% credits
Code: Select all
price += eq_price * 90 / 100;
Fer-de-Lance price, base_price before cunningFee = 484820 485000
(this is the only ship where price ends up lower than base_price)
Code: Select all
price = base_price + cunningFee(price - base_price);
- Influence D
- Above Average
- Posts: 23
- Joined: Wed Jan 16, 2008 10:44 am
- Location: Mooooooon
since it wasn't very clear what I was saying there - this appears to be being caused by an unsigned/signed conversion when the difference between price and base_price goes negative.
if I printf 'value' in cunningFee, I get 18446744073709551616.000000 - which is clearly way, way too big.
I'm not entirely certain how this ends up making a zero total price - perhaps cunningFee bombs out and returns the last value on the stack? perhaps an overflow? I'd assume that it would not be consistent for every OS / build...
a simple patch would be:
alternately, you could just drop the 'else' clause and leave price with its current value, which I have tested and works.
if I printf 'value' in cunningFee, I get 18446744073709551616.000000 - which is clearly way, way too big.
I'm not entirely certain how this ends up making a zero total price - perhaps cunningFee bombs out and returns the last value on the stack? perhaps an overflow? I'd assume that it would not be consistent for every OS / build...
a simple patch would be:
Code: Select all
if (price > base_price)
price = base_price + cunningFee(price-base_price);
else
price = base_price;