WineHQ

Star Trek: Bridge Commander

No Screenshot

Submit Screenshot

All modded versions

Application Details:

Version: 1.x + Mods
License: Free to use
URL: http://www.bridgecommander.com...
Votes: 0
Latest Rating: Silver
Latest Wine Version Tested: 2.11

Maintainers: About Maintainership

Link Bridge Commander Modding Community

Test Results

Old test results
The test results for this version are very old, and as such they may not represent the current state of Wine. Please consider submitting a new test report.
Selected Test Results

What works

Almost everything works. 


I was testing the kobayashi maru mod, and couldn't find faults with the mod itself. Mutators are all working properly

I did not experience random crashes on QuickBattle etc.


What does not

Some campaign episodes are broken and cause an immediate CTD E03M01 for example.


Could this be the mod only problem? Did not test, need to get a clean copy of BC and will update ASAP.


Note by Maintainer: This is a general BC problem on how save/load in the engine works. Result is that almost all mods do break the save/load feature.


Workarounds

What was not tested

Multiplayer.

Hardware tested

Graphics:

  • GPU:
  • Driver:

Additional Comments

I'm giving this one a Silver Rating, because, this is a modded game so the campaign shouldn't be of much influence, even if it CTDs on you. Silver Rating because the modded aspect of the game works without a hitch.

selected in Test Results table below
Operating systemTest dateWine versionInstalls?Runs?Used
Workaround?
RatingSubmitter
CurrentUbuntu 17.04 "Zesty" amd64 (+ variants like Kubuntu)Jun 28 20172.11N/A Yes SilverBruno Oliveira 
ShowDebian GNU/Linux 7.x "Wheezy"Jul 16 20121.4.1N/A Yes PlatinumErik Andresen 
ShowMac OS X 10.7 "Lion"Jul 17 20121.4Yes Yes PlatinumHarley T. Davis 
ShowMac OS X 10.7 "Lion"Jul 16 20121.4-rc5Yes Yes GoldHarley T. Davis 
ShowUbuntu 11.04 "Natty" i386 (+ variants like Kubuntu)Oct 03 20111.3.24Yes Yes GoldAthrun 

Known Bugs

Bug # Description Status Resolution Other apps affected

Show all bugs

HowTo / Notes

WARNING

This section is mainly focused on Bridge Commander mods

Feel free to discuss any tweak, problem or performance fix here

When reporting a test result please add your video card, driver version and mod version tested, thank you.

General Notes

Installing Bridge Commander

Bridge Commander installs and updates to 1.1 without problems from original disc.


The Black Screen of Death / Fatal Errors

For good or ill, the old Black Screen of Death will not normally come up, but will instead tend to crash the game entirely while in wine. It is thus a good idea to run the game from terminal, as this will prevent wine from closing immediately and allow you to better troubleshoot these types of issues. Keep in mind that this may have odd effects on game play, depending on several factors such as distro, wine version, other programs running, modules loaded, etc. If you do get the Black Screen of Death though, it can be handled as usual.


Installing Mods

Keep in mind that you may come across case errors when installing or self-modifying mods, ships, or other mod content. Case errors will normally crash the game entirely in wine, and having Console Tracker in your install will allow you to more rapidly identify and correct such errors. Generally, case error issues are just a pain in the arse. Keep an eye out during extraction and verify you aren't getting case duplicates.

Helpful Debugging Tools

ScanBC, an abandoned project started by USS Sovereign. It's quite rough, and should be considered a program in beta.

Console Tracker, by USS Frontier. A must-have for all modded installs.

Using the SDK

It is strongly advised to do the actual modding from a Windows machine, or at least a virtual machine such as VMware Player. Most 3rd party modding tools do not work well in wine and for the exception of the AI tool (which can be run from a python console), the sdk is similarly affected.

Note
The game seems to have problems with ATI Radeon cards. I use the opensource driver, and have a very slow overall appearance of the game (The same appears with the proprietary driver). Even the mouse pointer does not move smoothly (As if the bug above is not resolved yet for ATI cards??) Apart from being very slow, everything works, even the videos.

Because of driver problems, Intel video cards which are commonly used in Laptops will be too slow for this game.
Nvidia cards with the closed source driver are working fine.

If you have problems with Sound try the set Audio Quality to High: For this open options.cfg in a Text editor and change ProviderReserveList=LowQualitySoftware to ProviderReserveList=HighQualitySoftware
Kobayashi Maru users can change this under Game Options.

Comments

The following comments are owned by whoever posted them. WineHQ is not responsible for what they say.

Latest Wine, DIB and STBC
by Harley T. Davis on Monday July 16th 2012, 16:15
I know it crashes a lot, but I was seeing graphics that were really choppy. Adding the blend fix, though it has no effect on the actual graphics objects, seems to allow the DIBengine to take over some of the older styled calls for the graphics, and forward them properly on the mac. While the NEW DIB does run some games, this one won't render properly after 1.4.1 (on the mac) due to many of the graphics conforming to older standard formats, which don't match new calls yet (support is under development), so they render improperly, but even with the older DIB, I was getting worse graphics chop than ever before. However, by setting the graphics medium on a 256 card, and using the vertex blending method on RC5, I was able to get rid of most of the chop (motion blur doesn't work right either way).
I'm going to try the Maximum Warp Edition soon, to compare all of the modes. For most systems with 512 or greater, use medium settings (512) for graphics with limited opponents, and remember that this game was buggy to begin with. If you use XQUARTZ on mac, remember to install the package correctly and test small apps first. For Lion (10.7), you'll have a few issues. Just remember the screen needs to Override, then set to fullscreen, then set to current res, and force normal. You can do this with a custom exe to keep your setings palette at the ready, and set the wrapper to pull the XQUARTZ from the system, not the engine. Let the system window manager handle windows, but turn off decorations. You can toggle between windowed and fullscreen modes with cmd opt A, so if you wish to have smaller res to accomodate your vid card, set it in game. I suggest you don't as you won't be able to leave the window (only some systems); however at full current res, you can window it to leave the window temporarily to check other apps.
RE: Latest Wine, DIB and STBC
by Erik Andresen on Wednesday July 18th 2012, 1:23
hmm You submitted a new Version..

I'm not going to create a new version in the appdb for every mod out there.
Instead I say we put the KM Version and all content to the 1.1.
RE: Latest Wine, DIB and STBC
by Harley T. Davis on Wednesday July 18th 2012, 18:40
Try adding it to the description that they are there together (you could just add that the Full Maximum Warp Edition is included). This isn't just another mod... ...KM isn't one mod, it's several that are classified as an upgrade when bundled together. SO is Supermod (though there are fewer mods in it), and the two sets upgrade different areas, and are incompatible with one another. The two are different variants, and if they are to be added as one, then describe it properly, otherwise it's bound to be more headache. Maximum Warp is an all inclusive disc and I'm fine with putting them all together, I love that idea---one place to find it all---; just make sure that it is described that way, otherwise I guarantee you'll probably get another add request from somebody who didn't want to search a thread that didn't pertain to their version. Minimize your headache as much as possible. Have a good day. And thanks for checking it out.
RE: Latest Wine, DIB and STBC
by Erik Andresen on Thursday July 19th 2012, 13:31
From my point of view KM is a mod :)
Btw maximum warp contains a very old KM. I recommend an update.
About last change of note
by Erik Andresen on Saturday May 16th 2009, 1:00
> well know that Kobayashi Maru 1.0 zip file, comes with subdirectories and files with different capitalization to the original files shipped on Bridge Commander 1.1,

Wrong. Show me at least one file that is.

> while this is not a problem when installing on FAT or NTFS filesystems (these filesystems are case insensitive), it can be a little trouble on Linux filesystem like ext3 or any other widely used on linux, because it will lead to duplicate filenames (with different capitalization) that will lead to missing features, or even crashes, so please install it into a FAT drive and then copy it into your Linux filesystem.

Also not 100% correct. Why VFAT does not allow to hold test.txt and TEST.TXT in the same folder, both filenames will be still different. So overwriting App.py with APP.py will result in a file now found error.
Also this problem is not limited to KM, but to many mods for BC.
RE: About last change of note
by Athrun on Saturday May 16th 2009, 13:19
>> well know that Kobayashi Maru 1.0 zip file, comes with subdirectories and files with different capitalization to the original files shipped on Bridge Commander 1.1,

>Wrong. Show me at least one file that is.

Maybe you didn't looked closely enough...

Only one? There is a lot of them, jut o prove did the following:

Got my installed working copy of BC 1.1, copied that install to the following sites, to a VM with Windoze installed, to a VFAT drive and to a EXT3 drive. Then I had renamed Bridge Commander to KM1.0, to only have to unzip kobmaru1.0full.zip and do no touch anything. Decompressed kobmaru1.0full.zip in every drive.

Then I compared recursively the resulting files of every install, first the VM install with the one of the VFAT drive, these were identic, then I did the same with the VFAT install and the EXT3 one, these are the results:

pastebin.com/f518f78

As you can see, there are a lot of naming differences, most easy to find is KM1.0/data/TGL to KM1.0/data/tgl ones, but not restricted to that, I also got false negatives (duplicate files) and I suspect, that if I had tested the same under a brand new, clean and untouched BC 1.1 install, list of differences will be bigger.


>> while this is not a problem when installing on FAT or NTFS filesystems (these filesystems are case insensitive), it can be a little trouble on Linux filesystem like ext3 or any other widely used on linux, because it will lead to duplicate filenames (with different capitalization) that will lead to missing features, or even crashes, so please install it into a FAT drive and then copy it into your Linux filesystem.

>Also not 100% correct. Why VFAT does not allow to hold test.txt and TEST.TXT in the same folder, both filenames will be still different. So overwriting App.py with APP.py will result in a file now found error.

If we were talking about NTFS of wich I'm not 100% sure, maybe, but not on a VFAT partition, if you have an, lets say, README.TXT file, and you try to copy there a readme.txt or readme.TXT or even a wacky ReAdMe.TxT, resulting file wil be ever README.TXT, since it keep case sensitiviness of the previously existing file. Maybe on NTFS isn't that way, maybe that can happen if you delete firts the file... then umount/or eject your VFAT partition or do a fancy script to regenerate the whole directory hierachy...

But no under standard conditions. Thats why I suggested that method, it gives the same result as copying your BC from you Windoze partition, and... not everyone have one, of couse it not the most ellaborated method, but works better and gives less headaches than installing ciopfs, or creating a fancy and unsupported install script to check and give an correct "case sensitiveness", and even dealing with VM and or NTFS...

Is not elaborated, but it works as expected.


>> Also this problem is not limited to KM, but to many mods for BC.

And not only related to BC, there are other games/apps that silently suffer of same "sensitiveness" problem.
RE: About last change of note
by Athrun on Saturday May 16th 2009, 13:39
Forgot to say that the side effects of an KM1.0/data/tgl is a Wine crash if you select Missions > Custom Missions > RHCD Missions > Any mission
RE: About last change of note
by Erik Andresen on Sunday May 17th 2009, 6:13
ok, I see - how could those case differences come into KM?
And why didn't you make a Bug report for that on the KM tracker?
bckobayashimaru.de/BugTracker/view_all_bug_page.php

Please, next time you find something, do so - report a bug.

The following will be fixed for the next KM version:
tgl->TGL
viewscreenloading.tga->ViewscreenLoading.tga
newcomp.tga->newcomp.TGA
high->High
Birdofprey.NIF->BirdOfPrey.nif
low->Low
Galaxy.NIF->Galaxy.nif
Ai->AI
RE: About last change of note
by Athrun on Sunday May 17th 2009, 16:26
> ok, I see - how could those case differences come into KM?

Thet're capitalized that way in kobmaru1.0full.zip zip file, you can check it easily, and errors will only surface if you install BC and then extract the files into a fully case sensitive filesystem.

> And why didn't you make a Bug report for that on the KM tracker?
> bckobayashimaru.de/BugTracker/view_all_bug_page.php
> Please, next time you find something, do so - report a bug.

Most mods (speaking widely about the huge world of computer games) are released without any support, much less with a bug tracking system, I didn't know that this one has that kind of support.

Anyhow, if a fix is to be made, I should redo the process from start, because as I said in the previous post, used my working (and very used) installed copy of bc 1.1, so chances are that not all differences were catched.

So I should reinstall BC 1.1, and do a proper directory comparison with that clean install (just to be sure, the previous one was a fast one)

Hope not having too much work in the following weeks and having time to do it.
RE: About last change of note
by Erik Andresen on Sunday May 17th 2009, 23:44
> Most mods (speaking widely about the huge world of computer games) are released without any support, much less with a bug tracking system, I didn't know that this one has that kind of support.


> Anyhow, if a fix is to be made, I should redo the process from start, because as I said in the previous post, used my working (and very used) installed copy of bc 1.1, so chances are that not all differences were catched.
You can get the svn with
svn co kobmaru.de/svn/trunk/ kmsvn
and then copy it to your BC installation with rsync:
rsync -uvrC kmsvn/ BCInstall
It is important to call rsync with -C to strip out the .svn/-Folders - bc doesn't like them.
RE: About last change of note
by Erik Andresen on Monday April 19th 2010, 13:03
ok new changes, I would like to comment them:

> The SDK, while not specifically part of the game, does not acceptably operate in wine.
I guess you refer to the MPE here. Wasn't able to get it running either.

>>>
Beam weapons suffer from a non-specific d3d error (fixme:stub) that does not allow them to fire correctly. Holding down the beam firing button while continuing to maneuver will let them fire, but the error greatly decreases the effectiveness of ships using beams, especially if Inaccurate Phasers is active. This error is persistent through re-installation, and can sometimes show up in the unmodified version of the game. This error does seem to affect AI.
>>>
A d3d error shouldn't have anything to do with Phaser accuracy. All Phaser missing events should be caused by the inaccurate Phaser stuff.
To check you can try to disable "Foundation Tech" in KM 1.0 or KM2010.02. All Phasers should be 100% accurate now.

> Widescreen resolutions under normal operation.
Well not really part of the game, but..
RE: About last change of note
by Erik Andresen on Monday April 19th 2010, 13:05
Also please note that your "stability issues" probably mainly come from BC, not wine. So your experiences that some wine versions play the game more stable can be just luck.
re: needed clarification + methodology
by A. Turin on Monday April 19th 2010, 20:36
>>I guess you refer to the MPE here. Wasn't able to get it running either.

The entire software development kit independent executables, including chickenkiller, damagetool, not just MPE.

>>Well not really part of the game, but..

I know. I tossed it in since I was able to get the game to run properly in widescreen on windows, and it can be considered a mod.

>>A d3d error shouldn't have anything to do with Phaser accuracy.

It doesn't. Between normal inaccuracy and the fact that the beam weapons 'stutter' instead of immediately firing as they should, it greatly reduces the efficacy of beam weapons as a whole. It is most painfully clear when fighting enemies using dominantly disruptor and/or torpedo-style weaponry. Most AI (including Felix) seem to try to fire, and when that fails to properly fire the first time, they stop trying to fire their beam weapons for a little while, cycling through their AI subroutines. So this also makes enemies that have mostly beam weapons way too easy. Due to circumstances beyond my control, I cannot continue to troubleshoot the issue as I'm to the point where I need more hardware.

>>To check you can try to disable "Foundation Tech" in KM 1.0 or KM2010.02.

A side note about this. A very large amount of current-gen mod content depends on F-tech. Heavily modified vessels can sometimes depend on it entirely. Back when I was thinking that it was related to inaccurate phasers, I had to locate the two specific scripts that directly controlled it and comment specific lines out. Once I can find my case notes of how I did that, I'll probably post it for reference. Either way, the removal of phaser inaccuracy had no effect on the incidence of the glitch.

>>Also please note that your "stability issues" probably mainly come from BC, not wine. So your experiences that some wine versions play the game more stable can be just luck.

For testing purposes, I established a baseline in Windows XP and Vista (as well as their equivalent wine modes) with the same hardware setup (swapping in and out multiple system drives), using defined settings that do not change (because any time I do change those settings, I have to re-establish the baseline). A similar baseline was established playing with each vessel for approximately ten hours each to give me a fair idea of how each vessel fits in standard deviation. Notes of known issues, their frequency of incidence and thus a regular tolerance between in-game handler crashes and API crashes allowing me to plot stability data with any degree of reliability.

The internal console tracker mod, external konsole output and debug packages set to verbose traceback by default as well as six separate stress tests (one on one 256^2, 512^2 and 1024^2 res models, three on three 512^2, up to 30 minutes at DS9 playing as the 2048^2 USS Challenger from the DJGalaxy pack against Dominion waves from DS9FX and no less than 12 hours at warp, usually Earth to Romulus as I've calibrated the distance) done several times over a week will typically give me quite a great deal of information. It grants me a relatively dependable judge of stability (as very few crashes go completely unexplained, and I'm easily able to identify internal issues and not count them against the wine version) with a tolerance around ±15%. That's a large tolerance, I know, but what it allows me to do is report only significant changes in general stability with as little influence from typical variance during a too short sample period as possible.

While I can post the large amount of raw data that leads me to believe there is a significant delta stability, it's not needful to do so. I'm not going to report higher or lower stability within the baseline tolerance of ±15%, and as always 'Your Mileage May Vary' due to differences in base operating system, RAM, v-card, s-card, their drivers, other stuff you have running at the time, and on and on and on. I do try my best with what I have, as a game with such a community as this one's deserves nothing less.
re: needed clarification + methodology
by Erik Andresen on Sunday May 9th 2010, 16:26
>> The entire software development kit independent executables, including chickenkiller, damagetool, not just MPE.
Chicken-what?
I remember getting the damagetool to work on windows was not easy either. Anyway I never heard of someone using the DamageTool or the exporter. The AI-Editor however works fine.

>> A side note about this. A very large amount of current-gen mod content depends on F-tech.
Right, but only minor stuff like Ablative Armor, Breen damper weapon etc will stop working. Rest will continue to work fine.

>> Back when I was thinking that it was related to inaccurate phasers, I had to locate the two specific scripts that directly controlled it and comment specific lines out.
Should be a '#' before
oAiInacTrigger = InacAITrigger()
in scripts/FoundationTech.py near line 1439.

>> Notes of known issues, their frequency of incidence and thus a regular tolerance between in-game handler crashes and API crashes allowing me to plot stability data with any degree of reliability.
Uhm if you can reproduce a crash in KM2010.02 please fill a bug report at bckobayashimaru.de/phpBB3/viewforum.php?f=45
Back