• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Trade Goods Program w/History

I skimmed through the file library here, but didn't see anything current or quite what I was looking for.

I'm looking for a subsector/sector market tracking program/simulator. Here's what it would do (ideally).

You input the worlds of your subsector by UWB. It calculates your trade codes (or you can put them in manually) for that world.

It randomly chooses the kinds of good available on that world and the price for them, buying and selling, based on the trade codes. It keeps a record of that price in a database.

The user could, when s/he wished, advance the markets ahead 1 week. The program would then randomly increase or decrease the prices of the goods by 1-5% to reflect variations in planetary economy. There would be a small chance for even bigger price swings, and small chances for other types of goods to become available periodically, as well as others becoming unavailable. (If we wanted to become REALLY complicated, we could generate the amount of goods available for trade, along with a resupply rate, so as goods go out, they may run low (and the price goes up) or if they get too much surplus the price goes down.)

This information would be for the Ref's eyes only, generally, and s/he could use the player's broker skill and other factors to raise or lower the prices the players are offered.

Example of how this might work:
Players land in the Phorest system, an Agricultural world. They find Wood for sale. Our program lists Wood's base purchase price at 1,000cr per ton on this day. After the negotiations, factoring skills etc., they get a price of 900cr per ton.

They load up the ship and fly to the Gizmo system, an Industrial world. The Referee advances our hypothetical program ahead one week, and the program makes random variations in the prices. When they land on Gizmo, the program tells the Referee that Wood has a base selling price of 1200cr. Negotiations ensue (dice, skill, etc.) and come to a selling price of 1500cr. Happy with the deal, they load up some cargo from Gizmo to take back to Phorest.

We advance another week. Now when the players land, the program has modified the price of Wood on Phorest two times, and it's gone up. The buying price base is now 1100cr. The players may be able to get the same deal as before, but it'll be harder.

All of these price changes are kept (and possibly able to be viewed as a graph). It's a way to keep track of the markets in a (very simple) economy simulator.

So. What do you all think? Anything like that out there? Is this something that could be done in Excel or something?
 
Is this something that could be done in Excel or something?

You would have to combine it with Access in order to not have to do all the data entry yourself as far as I know. At least I haven't found a way for Excel to modify itself and keep the modifications. Also, keep in mind every time you change a cell, the randomizers will all cycle, unless you set it to only calculate when you press f9, which only updates cell changes at that time as well. For quick and dirty calculations or running thru data, Excel will work fine. Access (or the open office equivalent) or something will be your baby. I might have missed something in Excel so another guru might have a better answer.
 
Probably...

Yes, Access will do what you're looking for. I've done some access programming, and what you're looking to do is doable (at least until you get to the 'if you want to make it complicated' part). Adding in the the idea of supply is a good one, but I'm not real sure how to implement it off the top of my head. I'd take a whack at it, but I'm eyeball deep in projects as it is.
 
You can do these things in Excel - yes it can even change its own cell formulas. Not that I recommend Excel for such a thing - a DBMS is a better fit - but Excel can run SQL queries, among other things.

Excel actually has used the JetDB engine (since '97 version, IIRC), which is the database API originally under Access - renamed in more recent times and separated for office products. In non-XML formats, it even uses the Access/JetDB data format internally. Irregardless, Excel can be used to access/create Access databases. But the same can be said for MS-SQL - it can even be attached to Pervasive, DB-2, Progress, etc. with the right ODBC drivers.

Access gives you a front end interface (GUI) ability that Excel doesn't, er, excel at.

Tools like Access are great for getting your feet wet - till you try to actually do the things you want to do, then you will find you fall into the deep end real quick without a life jacket. If you don't know what you are doing, Access and Excel will make it hard to progressively evolve something - you will get so far, then realize you have to redo everything. Usually multiple times. Such are very unforgiving of amateur designs.

Programming languages are generally a bit harder to get started with (though that gap has grown quite small with things like .Net), but a whole lot more forgiving when you want to make things 'better' - which often means fully functional. Access programmers can get paid big bucks - often maintaining older programs built with Access (and decent budgets) - and Access comes with office, so it gets great exposure and lacks the connotation of requiring programming skills (which is often a lie - to really use it one must use script programming with conditionals and error handling, etc.).

Just bear in mind, these are 'end-user' friendly tools that suffer from the fact they are dependent on particular products never intended to meet the expectations of consumers regarding off the shelf custom programmed packages. What I mean is that they allow non-programmers to do things that would normally require a programmer.

That last is the good part. The bad part - they don't replace programmers. :oo:

Er, I mean to say, they are limited and non-programmers have an even harder time realizing and getting around those limitations.

Ultimately, one can only simplify so much. Without experience, getting programs like these office apps to act like a standalone program can (and in the long run, often do) require more effort than learning a programming language!

If you are serious about doing this - look into a high level language. The Visual .Net (express versions are free) tools will let you do everything Access does and a whole lot more. You make GUI interfaces just as easily - and they can work for standalone and web. And did I mention - for free? ;)

Access ain't free.

Also you can access, er, Access files from .Net; extend Access with .Net; use DirectX and OpenGL from .Net - none of these things can as easily be done from Access. Access is a general purpose end user tool... if you are intending a single application - the tool can be over/underkill.

For doing an app like this in Visual .Net, there are easy tutorials that guide you through 90% of what you would need to know - and plenty of forums online to help you. This does not include the SQL/Database info that you would need to understand regardless of which tool you use.

Note, though, .Net is mostly limited to the Windows platform (though .Mono allows for others, it is not as full featured...). Java/Swing and many others can meet the need here - but none have delivered on their ultimate promises - and the .Net platform has, by far, the greatest support for the newcomer. There are some good, multi-platform web program environments you can use - the most applicable escapes me at the moment - but, they all have issues when one starts talking database access (at least for folks new to such things).

BTW, I've done plenty of .Net (mostly C#, but it really doesn't matter - though I really like F#), but it is not my first choice as an experienced, multi-platform programmer. The key word is 'experienced'. For a novice, its actually allows one to do a lot with almost no programming background - and there are tons of free support available, as well as free tools as good as, or better than any available.
 
Thanks for the advice everyone.

I've been doing a lot of Excel spreadsheets for UWP generation and some T5 playtest stuff and my self-taught Excel-Fu surprises even myself at times. But nested IF()s and LOOKUP() arrays are one thing... the database stuff is another.

Just for gits and shiggles, I picked up Open Office and put together a simple database of 20 planets, their trade codes, and the Mongoose Traveller trade goods with their availability codes and prices.

Then sort of stared at the Query screen while I tried to figure out what to do next. :P I'll keep staring.

However, if .NET isn't that hard to learn I might have a look... (Been a LONG time since I was writing programs in BASIC...)
 
You would have to combine it with Access in order to not have to do all the data entry yourself as far as I know. At least I haven't found a way for Excel to modify itself and keep the modifications. Also, keep in mind every time you change a cell, the randomizers will all cycle, unless you set it to only calculate when you press f9, which only updates cell changes at that time as well. For quick and dirty calculations or running thru data, Excel will work fine. Access (or the open office equivalent) or something will be your baby. I might have missed something in Excel so another guru might have a better answer.

No, not really. But it would involve EITHER Access OR using the scripting language (a superset of a subset of MS Visual Basic)... And that can do randomizations separate from general calculations... but also raises hackles when the macro code is encountered...
 
No, not really. But it would involve EITHER Access OR using the scripting language (a superset of a subset of MS Visual Basic)... And that can do randomizations separate from general calculations... but also raises hackles when the macro code is encountered...


Then write them up as custom functions. It doesnt set off the macro alarms and I think it wont let you futz with the computer from that area. Then again, I haven't tried to futz with it cuz I don't want to break it.
 
Yep - these things are all doable in the office suite - but, as the above posts illustrate - there are gotchas...

LiminalMask - if you've done BASIC before, then you are ahead of the masses. Got an aunt into programming with a Microsoft book 'Build a Program Now!' - it was quite well done, IMO, and she'd never programmed before.

BTW: You can build a database and a GUI without any real code, as I recall. .Net's biggest advantage, IMO, is its ability to work with a database. The beauty being you can add code easily to do just about anything except driver level code.

.Net apps require no installer - just file copies and the .Net framework downloaded from MS if the client doesn't already have. The last used to be a big deal (given the big file size), but not much anymore. However, one can also setup the app to run as web page - more work on the backend/host requirements (not code) - but user needs to install nothing.
 
.net's biggest problem is non-MS OS's... the installer does not work right under WINE.
 
It is a factor in why I am not using it for all my projects - but not the biggest. (I love Objective-C, Cocoa and Quartz, etc., though they are definitely even less supported re: multi-platform. ;) )

Multi-boot is an option for almost all users (sure, its an expense/headache - but that is one's own choice). Heck, windows even runs on supercomputers.

Access doesn't natively work on Macs - and Mac Excel has some big issues when one gets fancy with macros/DB (and no VBA support in some versions, IIRC).

Wine has problems with other windows programs... this is not unique to .Net.

A web based version, running on a .Net host, however, supports a wide range of users on any platform supporting a modern browser -> example: www.travellermap.com.

[P.S. - I am writing this on a Mac - and my latest traveller utilities are running on iOS :D ]
 
BytePro:

Decided to give .Net a try. There were several options to choose from. I DLed the Visual Basic 2010 Express. Is this what you recommend? And any particular recommendations on those tutorials you mentioned? I'd appreciate it if you'd point me in the right direction; I don't mind doing the hard work myself once I get started.

Thanks much.
 
By far the biggest resource (arguably for any development) is MSDN -> http://msdn.microsoft.com/en-us/
Specifically for BASIC -> http://msdn.microsoft.com/en-us/vbasic/
(Under the Getting Started section and the Learn menu option.)

There you will find a wealth of information - all for free. Drill down in the Learn section and you should find whole books, though I'd focus on the overviews and a few samples. Older versions had sample code for each language (in a big file).

Some other quick links (Googled):
http://www.homeandlearn.co.uk/net/vbnet.html
http://www.a1vbcode.com/

Aramis mentioned .NET's biggest problem is non-MS OS's... IMO, the biggest problem is actually the scope of development from MS.

Don't get overwhelmed (ok, you probably will - don't let it get to ya) - remember this is a huge company whose primary 'product' is code (which is embedded in every one of the >40 OSes I've ever used). .NET allows a programmer to leverage that wealth of experience (and bloat ;) ).

Also be leery of 'version creep' - MS is always updating and MSDN will seem to focus on the newest (and beta). Don't let that throw you - one aspect of .NET was to support backward compatibility and versioning (that MS screwed up for decades). MS supports the .NET platform pretty indefinitely to date and has a track record of doing so (if you know what you are doing - most programs dating back to DOS and EMM memory managers, thru Win 3.11, W95, etc. will work).

Have fun and take baby steps... don't expect to code up a Traveller trade app in one day. ;)

I pick up languages and IDEs by just looking at code and options - so my books and links are more for reference than tutorial value. The online stuff is very comprehensive, not to mention the integrated help and class browsers.
 
Also, there are several options for using a variety of databases. Several free ones floating out there, such as MySQL, Postgres, MS has 2: CE which does not do stored procedures, and SQL Express which does (but not triggers).

Accessing data from VB is straight-forward regardless of DB chosen.. Harder part is understanding what you actually put INTO the database, and how.

But it is all fun - enjoy learning new stuff!

(BTW, there is a semi-defunct trade program that does some of that stuff in the files section. Let me know if you want the source code, but it is C#, not VB. I have this odd aversion to VB, but as that can cause as much factious fighting as Traveller canon, best leave that alone!)
 
Yeah - I've avoided bringing this up for the same reasons. ;)

It is not so much anything against the language, but rather my experience with how it commonly gets applied to real world programs that it is not as well equipped to deal with and generally by folks not experienced enough to compensate for such.

I've never written applications in VB myself - but have fixed (and replaced) a good many over the years. The newer VB.NET incarnations are much more C# like, IIRC. And C# is more VB like in some ways (as opposed to C++).
 
That's because VB only went to version 6 ... VB.NET is not VB7 (despite what MS says). VB.NET is .NET programming using VB-like keywords (but isn't VB) and C#.NET is also .NET programming but using C++-like keywords (but isn't C++).

If your experience is in one of the old-school BASICs then the biggest thing will be to learn how to think in 'objects' (for .NET) rather than traditional linear. And to think in 'sets' (for a relational database using SQL) rather than traditional linear.
 
Yep - that's also why I did not harp on VB.NET - VB really doesn't exist anymore. ;)

MS killed that dog and avoided the inevitable bad PR by throwing out a bone... MS had wanted to kill VB for some time (and Access much earlier). VB.NET is more of a marketing scheme than its own product.

Again, the reasons go back to what was in my previous post was by far not limited to just my own experiences - MS was paying big time for the corporate IT 'get program quick' schemes that proliferated from these 'simplified' technologies. Access is an end user tool - and as such, MS has never been able to kill the underlying DB. Though JetDB was given several obits - eventually MS addressed this with Access DB and transitioning Access to better support the SQL line. (Access DBs can be promoted to MS SQL - eliminating MS's responsibility for the common inadequacies not planned for when dealing with many realworld applications.) Legal 'anti-monopoly' practices also hindered MS optimally addressing this (the separation of divisions within the corporate structure).

VB is a developer tool. Much easier to kill in the long run. Programmers were not fooled (at least for long), but they only have so much say in corporate purchasing. Managers and execs are easily fooled and placated by calling a tulip a rose and applying some marketing spin. (I.e. - that law of corporate America that goes - higher management will believe unqualified outsiders over their internal technical people whenever possible.)

Of all the (mostly BS) terminology fostered over the last several decades in the software and hi-tech domains, one I have retained is 'Best Practices'. For me, the founding principles of this are embodied in KISS and making things only as simple as they need to be, but not simpler (a like saying attributed to Einstein). And my favorite addendum - You can't polish a turd*.

(*Regardless of anything 'MythBusters' tries to assert to the contrary!)
 
This is relevant to my interests and I wish to subscibe to your newsletter. :D

Seriously, though, this would save me an acre of paper. Have you gotten anywhere with it yet? I'd be willing to do some crunch-work, though I Am Not A Programmer.
 
Back
Top