Cargo Contracts MOD for Oolite v1.77 and v1.79!

[Switeck]

And as for the oxp changes: it just doesn't make sense that newbies have to start with long contracts, and that veterans are "rewarded" with short contracts. It should be the other way around: newbie traders should only be offered short contracts with astronomical down-payments, and veterans should be offered both short and long distance contracts, with much smaller down payments, and much larger rewards for long distances.

Commodity prices are what they are -- the potential profit (their price differences TIMES the amount being carried) is so small that low reputation OR long distance will only make that awful.
That's why the profit difference for varying distance and reputation for "regular" TC contracts in my OXP is noticeable (like 1.1x to 3x difference) but not a magnitude (10x or more) apart.
And why high reputation does not get very long range contracts.

The original doesn't vary the deposit or profit ANY for different reputations, so the only difference is whether you get precious metal contracts.
In the original, Gold/Plat/Gem contracts usually sees max profit bonus. You'll NEVER get max profit bonus on any TC contract hauled by a Boa 2 or smaller.

The reputation scale could probably use an overhaul: short hauls should not be worth the same as long hauls: rep could in fact be directly related to the minimum # of jumps required to satisfy the contract. Long contracts are just death to the reputation as they are now, which makes no sense at all -- there should be some motivation for accepting the long hauls: more Cr, and more rep makes sense.

A large, long distance contract raises your reputation by only 1...so yeah, by the time you've got there your reputation has likely fallen by 1 or more points.

What if when you complete a contract, you regain all randomly lost reputation along the way as well as gaining 1 reputation point?
This would only occur if you've not failed a contract during that time. If you failed a contract as well, then completing a contract would not regain any randomly lost reputation.

[Switeck]

Cargo Contracts Mod v1.3!
https://www.boxcn.net/s/ila5kqznbn57br5ul9i0

v1.2 to v1.3 Changes:

I corrected a silly rounding bug on my part that was causing my estimated original profit to use a much lower discount than it should. This had me believing my mod was already "wildly better" profit-wise than the original.

It bothered me that the player could "luck up" and get a giant Gold/Plat/Gem contract with large profit and only have to do a jump or 2 to reach the destination, so Gold/Plat/Gem contract maximum sizes now depend on distance.
If it's for only 1 jump, it can't be as large as one far away. (Smaller even than v1.2 mod up-close, same or slightly larger at longer distances.)
The original contracts directly reduced profit instead of size for short distance contracts.
Maximum Gold/Plat/Gem contract size is considerably smaller than the original v1.77 contract max.

Minimum Gold/Plat/Gem contract size has at least doubled from the original. (was 30, now at least 60.)

Other types of contracts have no reason to be reduced in size due to distance, but they may get randomly reduced in size if they're >125 TC.
If the created contract size is <30, force the size of the contract to 30-35 TC (barely within a Cobra 3's ability) instead of running the normal size formulas again in a loop.

Minimum profit "floor" has been raised to 100-150 credits so low reputation, short distance, or small contract size doesn't totally destroy all profitability.
These occur more often if you have a very negative reputation.

Greatest profit is chosen from multiple similar formulas to maximize profitabilty further.
These formulas are limited to the maximum profit within the possible price differences at start and destination.
In v1.4 of this mod, I will probably eliminate all but 1 of these extra formulas...if I can determine which is the "best" one.

The end result of all this is my modified TC cargo contracts at high reputation will often be more profitable than the original cargo contracts...with exception of Gold/Plat/Gems precious metals contracts.
My mod's Gold/Plat/Gem contracts typically have much larger profits than regular TC contracts but are seldom more profitable than originally in v1.77.

[Switeck]

Here's my Cargo Contracts MOD v1.4:
https://app.boxcn.net/s/tc9gqpabptk0lfnr9m67

v1.3 to v1.4 Changes:

Added a readme file as well as the missing License info.

Extra profit methods are eliminated, leaving only max profit based on min/max prices differences.
Profit can be reduce to 50% of that due to low reputation, short distance, and small contract size.
Deposit has been increased to at least as much as the local cost for the commodity at the starting system's main station.

Average profit per contract has increased slightly since v1.3 of this mod.

Large or distant contracts are split into 2 contracts to double their reputation increase.

[Switeck]

Preliminary Contract test for v1.79 trunk builds using OXZ format!

oolite.oxp.Switeck.Cargo-Contract-Mod_1.5.oxz
https://app.boxcn.net/s/d6cv49ftfer8pd9vowm3

This is my first attempt at creating an OXZ, so I may have something wrong.

Changes since v1.4:

Updated date to 2014 in license.
All changes are coded into v1.79's original cargo contract .js file instead of editing my previous v1.77 modified contract .js file.

Distant contracts are split into 2 contracts based on minimum time to travel the cargo route (with bonus for high reputation) rather than the minimum deadline time. I changed it when I saw v1.4's contracts being split in 2 at max reputation even if they were very short ranged because you were given an extra week to complete them.

Changed player.contractReputation to player.contractReputationPrecise. (found only in v1.79 and later) Minor changes were needed to keep relatively similar profit/distance balances with v1.4.
Destination systems are no longer discarded if the starting system is a poor agricultural and the destination system is also a poor or at least average agricultural system, since Furs, Liq/Wines, Platinum, and Gems are as cheap as possible and still have a significant profit due to their large price variations.

Generally, small profit (<1000 credit) contracts are now paying max profit when at positive reputations. Only the highly profitable but short-ranged ones are typically reduced when at an "average" starting reputation.
Stuff like minerals, food, and textiles will still give dismal payouts, but they are seen far less often at higher reputations.
Close to max reputation forces basically all contracts to max profit.
Bad reputation often shows terrible contracts with low profit.
Even at average reputation, it is possible to get a very small, poor-paying cargo contract...usually for Minerals or Textiles.

[Zireael]

Why is this here and not in OXPs?

[Diziet Sma]

Why is this here and not in OXPs?

Perhaps because Bug Reports is where Switeck originally started the thread, with the title "Cargo Contracts are buggy in Oolite v1.77!" ?

And I'm guessing when he changed the title a few months back and didn't request that the thread be moved, everyone was used to it being here already, as it had been in Bug Reports almost a year by then.

[Switeck]

Yeah, what Diziet Sma said.

I consider cargo contracts so messed up that it's a bug.

This is what I've seen at max reputation when I tested with gold/plat/gem contracts removed:

[Switeck]

Oolite 1.82 makes the commodities.plist-style variables used by cargo-contract-mod obsolete. Essentially, this makes this._priceForCommodity return 0 every single time, which in turn makes profit 0 every single time. Meaning that the cargo contracts menu doesn't show up because every contract is rejected.

The replacement method in Oolite 1.82 for determining a remote system price for a commodity:
this._priceForCommodity(commodity,destinationInfo)
...can only create random values.

These are some example cargo contracts at max (7) reputation computed by my mod under Oolite v1.82:

platinum size=279 econ=7 DestEcon=6 jumps=6 Price=70.2 remotePrice=65.2 profit=-1395 profitORG=8644 share=59
platinum size=1694 econ=7 DestEcon=6 jumps=4 Price=66.2 remotePrice=71.1 profit=8301 profitORG=68628 share=39
platinum size=4256 econ=7 DestEcon=2 jumps=6 Price=70.2 remotePrice=69.1 profit=-4682 profitORG=151354 share=59
platinum size=2688 econ=0 DestEcon=2 jumps=4 Price=75.2 remotePrice=78.1 profit=7795 profitORG=115282 share=33
platinum size=1410 econ=0 DestEcon=1 jumps=6 Price=75.2 remotePrice=71.1 profit=-5782 profitORG=48874 share=53

gem_stones size=8940 econ=7 DestEcon=7 jumps=5 Price=17.9 remotePrice=17.5 profit=-3576 profitORG=79812 share=44
gem_stones size=2100 econ=7 DestEcon=6 jumps=4 Price=19.9 remotePrice=16 profit=-8190 profitORG=12317 share=40
gem_stones size=5980 econ=7 DestEcon=6 jumps=7 Price=20 remotePrice=19.3 profit=-4186 profitORG=57871 share=64
gem_stones size=3621 econ=7 DestEcon=5 jumps=7 Price=17.9 remotePrice=19.9 profit=7242 profitORG=42538 share=66
gem_stones size=2280 econ=0 DestEcon=6 jumps=4 Price=21.4 remotePrice=18.6 profit=-6384 profitORG=18115 share=34

gold size=1872 econ=0 DestEcon=2 jumps=6 Price=40.1 remotePrice=38.3 profit=-3370 profitORG=35451 share=57
gold size=4251 econ=0 DestEcon=2 jumps=6 Price=39.1 remotePrice=39.1 profit=0 profitORG=87262 share=59

proft is based on the formula I was using before the removal of the commodities.plist-style variables...but now modified to use systeminfo.samplePrice(commodity)/10
profitORG is what the original game's contracts would generate (NOT my mod's profits)...before subtracting out the share amount.


There is almost no control over how profitable my contracts are, except to say none are very profitable -- especially compared to profitORG amounts. Some are even hugely negative! This is completely unworkable.

I have a workaround, but it requires looping and brute-force calculations which can cause a noticeable game-freeze when generating contracts...and it's pretty much guaranteed to be less profitable than what I was using with Oolite v1.79. So that's unusable as well.

[cim]

So long as you only work with commodities using the standard Oolite pricing algorithm (i.e. ones which don't have a script), you can get the maximum and minimum prices fairly easily and in a short time. So far the only commodities I know of which don't obey standard Oolite pricing rules are the ones in my scenario OXPs which don't have cargo contracts anyway. You could either restrict contracts to those goods or only use the expensive algorithm for other goods.

So, for any good, look up the price_average, price_economic and price_random parameters.

The price will vary between average * (1+(efactor*economic)-random) and average * (1+(efactor*economic)+random).

efactor varies between -1 and +1 depending on whether you're at an importer or an exporter, based on this formula (ObjC, but should be easy enough to convert to JS) - look up the peak_import and peak_export values:

Code: Select all

	int exDiff = abs(economy-exporter)*2;
	int imDiff = abs(economy-importer)*2;
	int distance = (exDiff+imDiff)/2;

	if (exDiff == imDiff)
	{
		// neutral economy
		return 0.0;
	}
	else if (exDiff > imDiff)
	{
		// closer to the importer, so return -ve
		return -(1.0-((float)imDiff/(float)distance));
	}
	else
	{
		// closer to the exporter, so return +ve
		return 1.0-((float)exDiff/(float)distance);
	}

[Switeck]

"The price will vary between average * (1+(efactor*economic)-random) and average * (1+(efactor*economic)+random)."

No problem at first glance there...I come up with this:

Code: Select all

var PriceLow = system.mainStation.market[cargo.commodity]["price_average"] * ( 1 + ( efactor * system.mainStation.market[cargo.commodity]["price_economic"] ) - system.mainStation.market[cargo.commodity]["price_random"] )
var PriceHigh = system.mainStation.market[cargo.commodity]["price_average"] * ( 1 + ( efactor * system.mainStation.market[cargo.commodity]["price_economic"] ) + system.mainStation.market[cargo.commodity]["price_random"] )

My problem is I can't make sense of efactor. It seems a pretty complex calculation just to determine whether 1 number is bigger than another, and then convert them into a ratio.

I get completely lost on this:

Code: Select all

var exDiff = Math.abs(economy-exporter)*2;
var imDiff = Math.abs(economy-importer)*2;

It doesn't seem explicitly clear on what "economy" is referring to.
system.economy?
destinationInfo.economy?
system.mainStation.market[cargo.commodity]["price_economic"] ?!
Something else?

Also, "exporter" is...
system.economy?
destinationInfo.economy?
system.mainStation.market[cargo.commodity]["peak_export"]?
Something else?

Likewise "importer" means...
system.economy?
destinationInfo.economy?
system.mainStation.market[cargo.commodity]["peak_import"]?
Something else?

[cim]

destinationInfo.economy?
system.mainStation.market[cargo.commodity]["peak_export"]?
system.mainStation.market[cargo.commodity]["peak_import"]?

These three. (Or system.economy rather than destinationInfo.economy if you want to calculate the local prices, of course)

It's a slightly complicated formula because it needs to deal with OXP goods where the peak export and import aren't the ends of the range. For "traditional" 0/7 or 7/0 goods, it gives a straight linear trend between the two peaks, just as in Oolite 1.80 and earlier. For goods with the peak imports and exports closer to the middle of the economy line, it still gives a straight trend between the peaks, but gradually levels off towards neutral outside of that zone.

Here's a demonstration of a good primarily exported from economy 6 and imported by economy 4.

[Switeck]

Code: Select all

   var exDiff = Math.abs( system.economy - system.mainStation.market[commodity]["peak_export"])*2;
   var imDiff = Math.abs( system.economy - system.mainStation.market[commodity]["peak_import"])*2;
   var ecoDiff = (exDiff+imDiff)/2;
	if (exDiff == imDiff) {
		var efactor = 0;	// neutral economy
	} else if (exDiff > imDiff) {
		var efactor = -(1.0-(imDiff/ecoDiff));	// closer to the importer, so return -ve
	} else {
		var efactor = 1.0-(exDiff/ecoDiff);	// closer to the exporter, so return +ve
	}

var PriceLow = system.mainStation.market[commodity]["price_average"] * ( 1 + ( efactor * system.mainStation.market[commodity]["price_economic"] ) - system.mainStation.market[commodity]["price_random"] )

   var exDiff = Math.abs( destinationInfo.economy - system.mainStation.market[commodity]["peak_export"])*2;
   var imDiff = Math.abs( destinationInfo.economy - system.mainStation.market[commodity]["peak_import"])*2;
   var ecoDiff = (exDiff+imDiff)/2;
	if (exDiff == imDiff) {
		var efactor = 0;	// neutral economy
	} else if (exDiff > imDiff) {
		var efactor = -(1.0-(imDiff/ecoDiff));	// closer to the importer, so return -ve
	} else {
		var efactor = 1.0-(exDiff/ecoDiff);	// closer to the exporter, so return +ve
	}

var PriceHigh = system.mainStation.market[commodity]["price_average"] * ( 1 + ( efactor * system.mainStation.market[commodity]["price_economic"] ) + system.mainStation.market[commodity]["price_random"] )

var PriceX = system.mainStation.market[commodity]["price_average"] * ( 1 + ( 1 * system.mainStation.market[commodity]["price_economic"] ) + system.mainStation.market[commodity]["price_random"] )

commodity=furs
system.economy=7
destinationInfo.economy=6
PriceLow=704
PriceHigh=NaN
PriceX=NaN
efactor=0.7142857142857143

NaN?!

Game Bug or Bad Math, you decide!

[OneOfNine]

Hi everybody,

because of some problems with the Hyperspace Hangar I "worked" in my save-file and after that the Cargo-Contracts didn't run anymore, which means, the line won't show in the F4-Screen. I deinstalled and reinstalled the oxz, nothing. It makes no difference, if I buy another ship, but the oxz is on the F4-Screen if I start a new commander, so the reason should be found in the save-file.

Any ideas?

[Cody]

Welcome aboard, Commander! Hopefully, a boffin will wander by soon with some advice.

[Diziet Sma]

Hi everybody,

because of some problems with the Hyperspace Hangar I "worked" in my save-file and after that the Cargo-Contracts didn't run anymore, which means, the line won't show in the F4-Screen. I deinstalled and reinstalled the oxz, nothing. It makes no difference, if I buy another ship, but the oxz is on the F4-Screen if I start a new commander, so the reason should be found in the save-file.

Any ideas?

Sounds like a save-file problem, all right.. first thing to do, would be post a link to a copy of your save file.. in a dropbox account or something similar, preferably.

That way, someone familiar with how Cargo-Contracts saves data, might be able to spot the problem.