ClaytoniousRex

We're trying to reproduce it here, Typhon...

Yes, it's been on our list for some time and will get in there eventually. Balance comes from the attackers "bleeding points" more slowly than the defenders. Once the defenders lose the objective, they lose points very rapidly. Once they regain the objective, they regain those lost points very slowly. In contrast, once the attackers seize the objective, they gain points very rapidly and if they should lose it again, they lose points very slowly. Being the defender can be very painful against a competent team. If they're smart with the combination of sensor jamming, mortars, artillery support, and advancing forces, it can sometimes seem impossible to defend.

No, these haven't been reported, so thanks for posting them. This isn't happening here. Is anyone else seeing this? Are your other settings being saved, Type98? Maybe there's a permission issue with the settings file? Yes, including standalone/server for LAN games. This is disabled in the public multiplayer test release. Is that mode listed multiple times in your X config?

Yes, it would. It's now on our flyspray list, but at low priority (we're pretty busy with big features such as infantry).

Draykor, what version of Catalyst is installed, you sneaky ATI'er?

You can speed it up by reducing the "Terrain quality" and "view distance" sliders on the Settings tab. Let's see how fast we can make your old tub sail!

So this is the client getting the segfault, Bonxa? Does it always happen or is it intermittent? If you can make it happen at will, then do so and then email the Dropteam.log to support@tbgsoftware.com.

No. Based on range the ballistics computer selects one or the other, even if you're out. This probably should be changed to allow the high velocity rounds when the range is short, but to continue to disallow the low velocity rounds when range is too high.

You must do some graphics programming? It's nice to see that Demeter is installed on your system (we're the authors of Demeter as well as of DropTeam). Are you trying to run the game by using the runClient.sh script? If so, can you please do that ldd command again, but this time instead of ../bin as you did above use ../lib, like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">LD_LIBRARY_PATH=../lib ldd ./SpaceVikings</pre>

Hi, Caesar. Thanks for offering to help! The next time this "glitchey" stuff happens, please email your Dropteam.log to support@tbgsoftware.com with a note about what happened. Are you running Windows? If so, please send the error report whenever there's a crash so we can get a stack trace. I'm looking forward to getting out there with you and watching some of your creative landings...

Yes, Sgt, Terragen's a great tool for creating DropTeam scenarios (but it's only one of many ways to do it). DropTeam reads elevation and texture data from a broad range of sources including DEM, SDTS, raw binary, etc. so you can use real digital elevation data or your own procedural stuff from Terragen, MojoWorld, Leveller, etc.

It should be working. What happens when you try to save one?

Ja, Kratz. You know what we really ought to do in runClient.sh is this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:../lib</pre>

It's good against buildings. For example, if you're attacking an objective that has an air defense tower on it, then hit the tower with HE rounds to destroy it (if you can't manage the better alternative, which is to have your team capture it with a Cutter EV). Overpenetration is not, but ricochets are. Overpenetration has been there in the past, so we might turn it back on again. This is a really nice idea. We'll see what we can do.

Drusus, your HEAT hits to the flank definitely should be very lethal - IF THEY PENETRATE. With HEAT rounds it can be difficult to see whether the round penetrated or not since its warhead always explodes (so you always see some kind of explosion even if it doesn't penetrate). You can see the difference by looking closely, though. When it penetrates, you will see the hot red spray of sparks. When it fails to penetrate, you will see the round "puff" without a shower of sparks. With dust, muzzle flashes, and the heat of the moment, you can't always see the difference, but once you learn what to look for you often can. The Hurricane is particularly tricky sometimes because it has so many sloped surfaces on its sides, but those rear hits of yours should have done the trick for sure. Based on your description of events it sounds like there may be a problem with the Hurricane's side and rear armor. Do you remember what server you were on and what time you were on it, so I can go look at the server log (every single projectile hit is logged in detail so I can see exactly what happened when you were hitting that Hurricane). Thanks!

Hmmm, I'll bet that on your Powerbook it's taking an extraordinarily long time to get to the AAR screen in the first place and then to load the next scenario? If it's taking a really long time, then the server's probably dropping you because it thinks you have disconnected. Does this sound like what's happening to you? We can probably clean this up to accomodate people who take a little longer to load. To try a workaround in the meantime, you can turn off Texture cacheing. This will make scenarios load faster but at the expense of more jerkiness in the first few minutes of the game.

This issue has been resolved and here's a summary in case anyone else runs into it. The Good General had an old OpenAL driver installed on his sytem and it was somehow the driver for a different sound card than what he actually has! The fix was to manually remove the old OpenAL driver by deleting these DLL's from system32: OpenAL32.dll wrap_oal.dll ct_oal.dll This kind of thing is only recommended for experts who know what they're doing, but it resolves the problem if you somehow have the wrong OpenAL driver on your system.

Thanks for your comments (and compliments), Chris! No, unless you're starting to uncover a flaw we haven't seen yet. It's using on average about 23kbps per client, though this can definitely go up with lots of folks using voice chat. This is a trivial volume of traffic on the client (downstream) end. Rune played with 3 machines on wireless connections through a single router without trouble - a pretty awful case. This makes your increased lag with a second player very interesting. Do you know how repeatable it is? For example, have you had time yet to try it on different servers with and without the second player? Would love to hear more details about that. Yes, that is definitely classic lag! What is your ping to the server like? Does it happen on all servers? Where are you located geographically? One of the biggest problems with this first phase of the public test is that all of our servers are in the southwest USA. Point taken. I would also add a quick summary of using the tac display (space bar) to your list above. We'll beef the quickstart up. Yes, we've been bouncing that one around for some time now. We've even been thinking of a much more interesting, more graphical feature than simple text (kind of a pop-up, but unintrusive, penetration diagram). At any rate, you're right that it would help (especially with ... uh ... "certain" types of players).

Make it crash again, then email the Dropteam.log (which should be in /Applications) to me with a note that it's from Bnej. After doing that, if you want to try some workarounds while waiting for us to reply, you can try reverting to default settings to see if she will fly again. To do this, you will need to delete the file called Setting.dat inside of the DropTeam.app bundle. It's in DropTeam.app/Contents/Resources/data. You can get in there via Finder by right clicking on DropTeam.app and selecting "Show Contents", or you can do it in Terminal like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">cd /Applications rm -rf DropTeam.app/Contents/Resources/data/Settings.dat</pre>

Sergei's so right. Can you give us some specs please, Canuck, and a summary of what settings you're running at (resolution, options turned on, etc.)? Thanks!

Were you running the PCF Test Server, Cameroon?

Things change drastically on other scenarios, though. For example, the Hurricane is a real beast to use in low gravity or on terrain with lots of steep slopes. When playing on various planets, the relative value of different unit types changes dramatically.

That is a fantastic idea. We'll see what we can put together.

Yes, we can make it more obvious somehow (maybe not a warning popup, but some kind of cue) Our fear (or maybe it's a hope?) is that someday there might be enough servers out there that refreshing the list might take a long time - maybe 10 seconds? - and when clicking the network tab you might think the app has hung and give it the 3-fingered salute. Anyway, we'll look into it (refreshing on another thread is probably the "right" answer - then we could refresh automatically when you go to the network tab as you suggest).

Outstanding. Thanks for slugging through it, Macavity! We'll update the /libs for the next build.