Software compatibility in Traveller

kristof65

Mongoose
The whole SEC file format thread got me to thinking about how Traveller seems to ignore the whole software/computer/operating system compatibility issue. Despite the relative penetration of Mr Gate's Operating System, as was pointed out in the SEC thread, there are more software OS/file compatibility/computer type debates going on that even Traveller canon can ever hope to see.

How do you handle it in YTU? Do you just ignore it? If you ignore it, is it because you've just made the assumption the issue has been solved, or is it because you feel the PCs deal with, but the players don't need to.

Or do you make an issue of it? How often? Just when it's important to an adventure, or every time the PCs try and buy a new computer, software, hack into a system, etc?
 
Well, I figure that for important communication types that can use a standard markup language like HTML to put stuff in human readable format. The AI translators can help with that.
 
IMTU, there are a series of "reference platforms", the "Imperial Virtual Machine".

Some stuff is built to IVM spec directly as hardware (especially the starship computers); many more use better hardware running hard-coded emulation or even software emulation.

So long as it passes the tests, it's IVM compatible. Most include native recompile from dissassembly.
 
CaptnBrazil said:
that and after 1100 years I'm pretty certain they've got a set of standardized protocols.

More than that, as I have pointed out before, in 1100 years, in an Imperium whose raison d'etre is encouraging interstellar trade, any Tech Level below "Average Imperial" is meaningless ... the planet may not be able to make the stuff, but it will be available as an import nonetheless ... and you can reasonably assume, therefore, that even if there are differing OSs, there will be interoperability protocols ... especially as some of the TLs last for centuries ...

Phil
 
IMTU, each polity has it's own OS. There is good work to be had developing translation software between the (in my case 4) major polities.

Independent worlds typically have adopted the OS of whomever they trade with most. Some worlds have a hodge-podge as they have changed partners over the years.

I use the Apple/DOS/UNIX systems as examples, with interfaces common but not always 100% compatible.

There are several things like HTML that are in place to help with interstellar travel.

PCs on a ship usually have to buy a clip-on interface whenever they come to a new world. Usually I keep it in the background unless I want to make it part of the story. I started off the first adventure with them having to find it and debugging it, after that we let is slip off the radar, but it is still there when needed.

In the OTU, Imperial standards would be in place for all member worlds and many client states. The Solomani probably have the same OS as the Imperium (although they may have deliberately changed it after the war).

Zhos would be the same system everywhere as would the Daryens. The Sword Worlds probably have a couple of systems as well as Imperial, Zhodani and Daryen systems in use.
 
Except that it'll be closer to 5000 years, with a "brief" Terran interuption in the middle. The Imperium is built on the ruins of the Vilani Ziru Sirka, and the Vilani were pretty ruthless cultural imperialists.

Terra probably had only the one system of measure by the time the Diaspora and later 2nd Imperium hit, so there would probably be a strong residue of the Terran Metric standard carried into the Long Night on many worlds. Whether Terran Metric or Ziru Sirka standards prevailed would probably have been a local thing, but other local standards are also possible.

Then along comes Cleons boys and their standards. Given the stated nature of the Third Imperium, I suspect that shipping, and thus ships, adhere to an imposed set of standards. The restored power of the old Vilani megacorps probably reinforces this.
 
it seems to me that even if you do posit an Imperial standard ( which I don't ), that standard would be the minimum requirements to be certified to that standard and that doesn't guarantee that some company, hardware or software, couldn't add features on top of such a standard. Most companies would want to do that to differentiate themselves form others and to claim some sort of advantage for their product.
The added features would be enough to make for incompatibilities. Libraries to support such added features would make for dependency nightmares perhaps. Each feature added on top of a standard would make for trouble unless it too became part of the minimum standard. Hardware/software might only be truly compatible ( beyond the minimum spec ) with equipment from the same manufacturer.... even if we say megacorp instead of local non-megacorp controlled indsutires, that'd be a lot. Given the intense competition between megacorps and perhaps between branches within a megacorp, I feel certain such incompatibities would be built in.

Add in several different tech levels worth of changes and available products and it gets worse. Each tech level may mean a shift in methods. Different tech levels might be compatuible only with machines/software of the same tech level.

same tech level and same manufacturer..okay..compatible...maybe.
otherwise compatible with greatly reduced functionality.

ports and interconections should be fine though ( except for special things as per ref or story needs ). nothing else, imo.

" yay, we found a data collection card that can watch fuel flow rates to the jump regulator for us....oh crap! its ISA and we only have pci-X !! #%$#^@#$ it! Anybody got a spec sheet for it in case I have to break out a soldering iron? "
" oh?...do ya have the most recent SGI drivers for it? Even if you can make it fit and pass a smoke test?"
"not really, but we do have a couple of code snippets that looks possible"
" $%$#@#%$@# it requires an obscure library for a compile and noone knows where we can get one.... maybe I can push out a hack for it.....What?..you need it when?...if it doesn't work, we are get hurt really really badly?"

that's my take on it anyways....
 
Ishmael said:
it seems to me that even if you do posit an Imperial standard ( which I don't ), that standard would be the minimum requirements to be certified to that standard and that doesn't guarantee that some company, hardware or software, couldn't add features on top of such a standard. Most companies would want to do that to differentiate themselves form others and to claim some sort of advantage for their product.
The added features would be enough to make for incompatibilities.

I suspect there are standards, as in more than one.

Like it or not, these are spacecraft, and if you are going to have your shipyard's work looked at by other shipyards, quality and protocol standards are going to be necessary. A certain level of interoperability is also going to be required, at least within the Imperium, precisely because of the Imperium's attitude toward trade. Make your local embellishments too proprietary and no one else can fix problems with your product. Amongst starship operators that has the potential to be the kiss of death, quite literally. And word *will* get around.

As such, exclusionary and proprietary development tactics are not going to fly, at least when interstellar travel and commerce is involved. The local manufactured groundcar you bought three systems back might be a different story, and some crazy process ROM you got from a Vargr trader could be all kinds of "fun", because "standards" only last as long as the government that published them...

The one area where standards are likely to be recognized is in commerce, however. The Imperium would likely see the use of local weights and measures as having a high potential for subterfuge. For an empire based on trade, that's the equivalent of coin clipping.
 
BenGunn said:
Oh within Impy space there IS an official standard otherwise the canon Imperial Data Packages won't work out

But not necessarily one official Imperial Standard. Frex, several programs are available for multiple Operating Systems today, and at similar cost. Many data vendors like ebook publishers tend to sell things in multiple formats. One could say the same is the true in Imperial Space.

My take on this for MTU is that while there are all these different standards and operating systems, for the purposes of game play, dealing with them is fairly routine for the PCs and are for the most part glossed over. In my next campaign, I'll probably have some sort of mention or minor incidents occur in the first couple of sessions to highlight this to the players, so that it won't be a complete and total surprise should I decide to use some form of incompatibility as a challenge in a later adventure.

For some reason, the following dialogue just makes sense to me:

Pilot: "Rhylanor Downport control, this is Free Trader Beowulf, on course for landing at pad M12, per your authorization code YE3554BB. We're configuring the local interface for connection with your facilities, and are wondering what protocol you use? Our Library Data entry on this is unclear."

Controller: "Beowulf, this is Rhylanor Downport control. We can currently support all of the LSP protocols, the Tukera protocols up to version 5, the Nemreg Type B protocol and the Ryko 4 protocol."

Pilot: "Thank you Rhylanor downport, we have the Tukera v4 protocol, we should be good. Beowulf out."

Controller: "oh crap. Um, Beowulf, do you have Tukera v3 available?"

Pilot: "No, we do not. Why, is there a problem?"

Controller: "Maybe, I just checked the setup for pad M12, and it hasn't been upgraded for the newer Tukera versions yet. Wait - M14 has, and it's empty - I'll just move you over there. Give me a moment and I'll transmit your new landing auth code."
 
Maybe software is so expensive because it has to be ported to each ship?

A long time ago, I considered "software" in MTU to be "soft" in name only, and actually comprise a set of semi-autonomous modules installed into a ship's mainframe system. "bis" computers had dedicated "jump math accelerator" modules built into them, and the computer's rating was sort of a combination of number of bus connections, power requirements and the level of sophistication of the CPU. I didn't worry too much about the hardware compatability, figuring that the Vilani would have standardized a "card cage" format millenia ago.

The CPU always ran a UI as well as coordinating user access to the "program" modules, and the players interacted with the CPU through voice and/or consoles. I let any TL9+ or better computer talk, though until TL12+ they were pretty robotic, and you didn't get "Andromeda" or "Cortana" level interaction until TL14-TL-15.

The only module that was upgradable in the field was the Library Data module, which I considered to be basically a hard drive full of whatever data I wanted to be in there, much like the Ship's Locker.

There were Cannonical problems with my view of course, including the near impossibility of writing new software. (Maybe you buy a "developer module", like a programmable logic array device?) But though I'm moving away from that view, it still sort of appeals to me.
 
kristof65 said:
For some reason, the following dialogue just makes sense to me:

I like it! It would also allow for complications at "company run" starports. If you haven't licensed Tukera landing protocols, you're not landing at that facility. At least not without a Piloting roll and some possible legal complicaitons.
 
BenGunn said:
With only a few MegaCorps dominating the ship building market (IIRC it's 4, one WillyCorp, GSBaG, Ling and one more), the Willy influence to press everything in "has been done so since Grandfather" rules sets and the decriptions from the OTU I'd say there is exactly one Imperial/IDP standard.
First off, let me start by reinforcing that I was asking what people do in their Traveller Universe, and that I don't consider any response here "wrong." If that works for you and YTU, great.

However, I'd like to share my viewpoint about this based on my experiences. I work in an industry that has 3-4 major manufacturers, and hundreds of smaller ones. I subcontract for one of the smaller ones that makes controls that interface with pieces of heavy equipment made by the bigger guys. If even two of these major manufacturers could get together and agree on an interface standard, that standard would quickly dominate our industry. However, not only can those manufacturers not get together and agree on one standard to share, most of them are using multiple interface standards within their own lines of equipment! Any suggestions to come together on a standard are either ignored, or met with derision. I've found there are two primary reasons for this - One, engineers who feel their way is better or are too stuborn to design to a standard. Two, they want to keep things as proprietary as possible to ensure they continue to dominate their market.

As a result, the company I subcontract for has to ensure their equipment can support over a dozen different interface types. That's just the interface with the heavy equipment - our control equipment is a Point of Sale terminal that also has to interface with credit card companies and other cash register systems, which each add their own layer of confusion.

For the most part, this is all transparent to the people purchasing the equipment for their businesses - it's set up and maintained by technicians who typically know what needs to be done. The only real issue with it is when a tech runs across a combination they've never encountered before, or the tech is incomptentant to begin with.

If I scale my experiences up to the 3I and the megacorps there, I can easily see each megacorp not only having their own standard, but having multiple standards within their own company. Even if a megacorp tries to maintain a single standard, the distances involved could mean standards occassionally split until a choice is made at the highest levels.

So from my viewpoint, all of that is part of the skill set that make up being a starship engineer, pilot, captain, etc and is a large part of why it can be ignored - either completely, or just mostly. I prefer the mostly approach, simply because it gives me another tool in my GM toolbox to make things interesting for the PCs when I feel it's appropriate. It would be tedious to play it out every time - but occassionally can be fun.
 
kristof65 said:
So from my viewpoint, all of that is part of the skill set that make up being a starship engineer, pilot, captain, etc and is a large part of why it can be ignored - either completely, or just mostly. I prefer the mostly approach, simply because it gives me another tool in my GM toolbox to make things interesting for the PCs when I feel it's appropriate. It would be tedious to play it out every time - but occassionally can be fun.

That sounds like a pretty good way to run with it.
 
Back
Top