Trade profit calculator for Privateer

Whiplash

Rear Admiral
*****************************************************
EDIT: I've uploaded v1.0 for your testing and feedback.
*****************************************************

Hi folks, best wishes for 2014!

I wanted to tell you a bit about my latest project. It's not another ship model; the Hellcat is still WIP and I will be sharing some more updates on that soon, hopefully.

I've been toying for a while now with the idea of creating some kind of app that could be used to calculate the most effective trade routes in Privateer. Many purists will no doubt tell me that figuring it out for yourself is half the fun, but I've done that anyway, and in fairness the official playguide also gives you quite a few hints.

Mostly though, I just wanted to see if it could be done, and to set myself a little programming challenge.

I've made good progress, and most of the groundwork for the calculation is done. As input, I used this pricelist, which should be pretty well-known to most of you:

https://www.wcnews.com/wcpedia/Privateer_Commodity_Prices

By copying this into Excel and applying some VB magic, I now have something that looks like this:

LMInfLl.jpg


The price checker, for instance, will give you the lowest and highest prices for a commodity as well as the bases where they occur.

Wuli9Kd.jpg


The function I am actually interested in though, is choosing your origin and destination, and then obtaining a list of the commodities you can trade as well as which ones will be the most profitable.

Here's the catch though: The spreadsheet gives you min and max values, but in reality these values almost never occur. You are far more likely to see values somewhere in between. Currently I'm calculating a simple average using (min+max)/2, but that is far too simplistic for my taste. It's more likely that the prices variations are defined by some kind of function.

So: If you have any thoughts or suggestions, please let me know. I'm hoping someone has an idea of how I could better model the price fluctuations.
 

Attachments

  • Privateer Trade Calculator v1.0.zip
    59.2 KB · Views: 113
Last edited by a moderator:
I think that's cool. Only during my last playthrough when Priv was released on GOG did I start to take the trading aspect a bit more seriously. Before I made my money with combat missions alone (and before that with a trainer...).
 
Glad you like it! I'd be happy to share this with anyone that may be interested. Long-term plan may be to create a mobile app that can do the calc for you, instead of running off a spreadsheet.
 
Yeah this is pretty cool... A mobile app would be awesome though. I could set it on my phone or tablet beside the screen and run it while playing without having to task switch!
 
Yeah this is pretty cool... A mobile app would be awesome though. I could set it on my phone or tablet beside the screen and run it while playing without having to task switch!

Exactly! I have quite a few friends who do a bit of mobile development, so once I have the code figured out, I can ask them for some help in writing an app. Task switching will have to do for now though.
 
I'm very excited by my latest version! Have a look at this:

FLzkhKt.jpg


You can select the bases you plan to travel from and to, and it will spit out a list of all commodities you can sell at the destination base with a non-zero profit margin.
By setting the profit threshold, you can select which ones the app should bold as being particularly profitable. Negative values are shown in red.

You can also switch between worst, best or average prices, and the output will change accordingly:

4UMGgCZ.jpg


Let me know what you think!
 
Yeah this is pretty cool... A mobile app would be awesome though. I could set it on my phone or tablet beside the screen and run it while playing without having to task switch!
Of course, you know what the irony with that would be? Your tablet - even if it's a cheap no-brand tablet you picked up at a supermarket - will look far more sophisticated and sci-fi-ish than Privateer's own Quine 4000.
 
Of course, you know what the irony with that would be? Your tablet - even if it's a cheap no-brand tablet you picked up at a supermarket - will look far more sophisticated and sci-fi-ish than Privateer's own Quine 4000.

Simple. Build an app with a GUI that looks like the Quine. :)
 
Yeah, but that doesn't get you over the irony of the fact that in 2014, our mobile technology is immensely superior to the mobile technology of 2669. And of course, you get so much of this in WC (as in any other sci-fi), with distinctly un-sci-fi-looking keyboards, CRT screens and the like. It's normal, but still somehow mind-boggling - we couldn't, back in 1993, imagine a mobile device with colour display? Well, no, we couldn't, and today we're hardly capable of imagining how our technology will look in ten years time either. I just find that so amazing.
 
It's normal, but still somehow mind-boggling - we couldn't, back in 1993, imagine a mobile device with colour display? Well, no, we couldn't, and today we're hardly capable of imagining how our technology will look in ten years time either. I just find that so amazing.

I don't entirely agree that we couldn't imagine it back then. Watch any of the early 90's Star Trek series. Tricorders and especially PADD's are basically mobile computing devices. The PADD looks identical to todays tablets. So maybe the simplified look and feel of Privateer was done deliberately?
 
Yeah, everything having a 'crude' industrial look in Privateer is definitely intentional. You see the same kind of aesthetic in Starcraft 2, for instance, with monochrome screens and big fat mechanical keyboards existing alongside more or less modern tablets and holographic displays. Granted, they're probably just sticking with the look of the original, but still.
 
Yeah, everything having a 'crude' industrial look in Privateer is definitely intentional. You see the same kind of aesthetic in Starcraft 2, for instance, with monochrome screens and big fat mechanical keyboards existing alongside more or less modern tablets and holographic displays. Granted, they're probably just sticking with the look of the original, but still.

Agreed; thus the intention being to create a universe that feels "lived-in" and familiar as opposed to slick and ultra-modern, but somewhat alien.
 
I don't entirely agree that we couldn't imagine it back then. Watch any of the early 90's Star Trek series. Tricorders and especially PADD's are basically mobile computing devices. The PADD looks identical to todays tablets. So maybe the simplified look and feel of Privateer was done deliberately?
Well, Star Trek has always stood out in this field, they always made the effort to visualise future gadgets (and even they have trouble getting more than like a decade ahead of reality, except for magic stuff like transporters and the like).

You are of course correct that a part of it was trying to get across the low-tech feel of some Privateer aspects: the Tarsus in particular used keyboards and big monitors to highlight the fact that it's obsolescent. But I don't think it was all intentional, either. There is definitely a limit to how far our imaginations can go, we can generally think of ways to improve existing technology, but find it hard to come up with genuinely new concepts.
 
Well, Star Trek has always stood out in this field, they always made the effort to visualise future gadgets (and even they have trouble getting more than like a decade ahead of reality, except for magic stuff like transporters and the like).

You are of course correct that a part of it was trying to get across the low-tech feel of some Privateer aspects: the Tarsus in particular used keyboards and big monitors to highlight the fact that it's obsolescent. But I don't think it was all intentional, either. There is definitely a limit to how far our imaginations can go, we can generally think of ways to improve existing technology, but find it hard to come up with genuinely new concepts.

It's scary how accurate some Trek predictions have been. :)

http://weknowmemes.com/2013/07/star-trek-predicting-the-future-since-1966/

Anyhow, I agree with you completely, it's hard to try and imagine something truly futuristic because we always end up with something rooted in the familiar. CR and team are going through this exact same exercise again with Star Citizen.
 
Keyboards with discrete keys still fill a function that touchscreen "virtual keyboards" can not--you get tactile feedback from every touch, which is pretty vital to being able to touch-type with any speed--I defy you to find somebody who can type sixty or more words per minute on an iPad screen with as few errors as with a standard keyboard.

As for the argument that typing itself will be supplanted by voice interface, I offer two counterarguments:

1: Some things that one would wish to write are inherently difficult to vocalize, such as forms of notation that do not correspond to spoken words (e.g. mathematical symbols whose meaning are expressed through their relative spatial location to each other. It would be quite awkward to try to pronounce complicated equations using only speech--imagine taking a math course exclusively from audio recordings with no written materials, diagrams, or visuals of any kind and you will see what I mean). A means to use one's hands for input will be needed, whether with a keyboard or a touch screen or whatever.

2: Even among those things which can be transcribed from voice, the situation of the moment may inhibit one's ability to do so, either due to background noise or due to not wishing to be overheard speaking aloud everything that is to be recorded.
 
Riveting as this GUI discussion has been, I'd like to get back to my app, if I may. Any further comments / questions / suggestions? Any ideas or changes you would like to see?
 
Are you planning on posting a test version soon? That would probably help people provide even better feedback.
 
This is a nice idea. It's true that trading probably isn't quite as profitable as quickly as taking combat missions is but it'd be a handy thing to have all the same.

As for modelling the price fluctuations, I don't know. When I made those commodity price lists all those years ago, I didn't recall seeing any discernible patterns. I can't recall either if just reloading a saved game is sufficient to change the prices (I think it might be).

As a suggestion, even if it's a bit tricky to implement, I'm wondering if it's worth bothering to have a more thorough trade route planner or something, for someone playing as a dedicated merchant. I imagine that all base types would be accessible from any given base of origin within six jumps... but I don't know it might not be always be the case (perhaps near the Kilrathi border?). While we have major bases being unique locations (Perry, New Constantinople, etc), I'm thinking something along the lines of specifying a starting system and working out what base types are within six jumps from that location.

But perhaps it's not worth the effort. After all, one doesn't have to sell all their cargo after six jumps, unlike combat missions which appear to expire after landing (from what I recall).
 
Are you planning on posting a test version soon? That would probably help people provide even better feedback.

As soon as possible; I just have a few bugs to iron out. The code in its current state is the very definition of quick and nasty programming; I've not followed any proper conventions, and my knowledge of VB is basic at best. The plan was to create a rapid prototype, see if it could be done, and then figure out how to write it properly.

As far as the mobile app is concerned... Well, this may take some time. I'll have to move from VBA for Excel to a different language and program design, since I obviously can't then use an Excel file as source data.

While we're on the subject, do you suppose I can expect some frowns from-the powers-that-be if I publish an app such as this with very overt references to Wing Commander? It will be free, of course, but you never know...
 
This is a nice idea. It's true that trading probably isn't quite as profitable as quickly as taking combat missions is but it'd be a handy thing to have all the same.

As for modelling the price fluctuations, I don't know. When I made those commodity price lists all those years ago, I didn't recall seeing any discernible patterns. I can't recall either if just reloading a saved game is sufficient to change the prices (I think it might be).

As a suggestion, even if it's a bit tricky to implement, I'm wondering if it's worth bothering to have a more thorough trade route planner or something, for someone playing as a dedicated merchant. I imagine that all base types would be accessible from any given base of origin within six jumps... but I don't know it might not be always be the case (perhaps near the Kilrathi border?). While we have major bases being unique locations (Perry, New Constantinople, etc), I'm thinking something along the lines of specifying a starting system and working out what base types are within six jumps from that location.

But perhaps it's not worth the effort. After all, one doesn't have to sell all their cargo after six jumps, unlike combat missions which appear to expire after landing (from what I recall).

Thanks Wedge. I started digging into the price fluctuations myself to see if there were any clues as to how it might work. Save/reload is indeed enough to see the variance. It appears to randomly select a value between the defined min and max values for the commodity.
For example, Grain has min 6, max 20. Ten consecutive reloads at Helen got me a sequence of 14, 14, 19, 19, 14, 6, 11, 8, 8, 15. This averages out to 13. Lo and behold, (min+max)/2 is also 13.
Seems to me that with enough repetition, rand(min,max) will eventually average out to the same as avg(min,max). If it's purely random, there is no sense in me trying to predict a price; average should be close enough for all practical purposes.

I like your trade route planner suggestion, but that will have to wait until I've completely rewritten the code. If I implement Base as a proper class with parameters, I could maybe create an instance of it and then specify what the neighbouring bases are. Chances are I'd have to create the systems and the bases they contain as well, so this could quickly get very complicated.
 
Back
Top