ClaytoniousRex

In non-command vehicles, you do *not* see enemies spotted by others. While in a command vehicle, you *do* see enemies spotted by others. If you're actively playing the role of commander in a hands-on way, telling your team mates where to move and what to do, then you need this information. Even a good team that's constantly calling out their sightings of enemy units to you is vastly inferior to realtime update of those enemy units on the tac display, mini-map, and HUD. This is doubly true for effective use of artillery. If you're playing the role of a more "hands off" commander, where you're basically letting the whole team run amok but ask you for help occasionally, then this information is far less useful. In this case, you might indeed be better off in a more conventional fighting vehicle. There's nothing wrong with this, but it shouldn't be surprising that a command vehicle is not useful when no one is really commanding. The restrictions are the gain. If you're really going to execute a PLAN, then you don't want "just any schmuck" wasting the next Resupply or fire mission on a target *he* thinks is important but that doesn't help with the plan. Now you've lost your fire mission for 5 to 7 minutes just because Private Jones wanted to really stick it to a single enemy Shrike in a corner of the map. You don't pay Private Jones to think...that's *your* job.

Email me your username and password and I'll check the account server. (Remember to send your username and password with correct case sensitivity.) In the meantime, you can try registering a new account.

The account server was down for a few minutes while we made some upgrades. It's back up now. Are you able to get in now?

Yes, that's what I was asking for. If you're willing, here's a more definitive way to find the problem: Download and install this tool: Dep Walker This is a utility that lists the DLL's that an .exe will load when it is launched. Run the depends.exe program in that tool. A window will open with a blank work area. Drag your DropTeam.exe from your DropTeam/bin directory into this blank workspace. (Not the one in the root of DropTeam, but the one in the /bin subdirectory). It should now look something like this: Select DropTeam.exe at the top of the tree on the left (just by single left clicking it one time to make it highlighted) and then press F9. This will turn on full paths for all DLL's in the tree. So now it should look something like this (but your paths will be different): Finally, select File/Save as from the main menu and save as a text file (just plain .txt in the list of file types) and then email that file to me. Hopefully this will identify the problem!

You won't hear yourself except when playing standalone (which you can't do with this public test build). Everything's probably configured fine on your end and the next update will have you voice chatting just fine. (The issue was that on some Linux distros we have to use a NULL for the default audio capture device, whereas on others we had to actually enumerate the devices and pick the default one. On the next update, DropTeam should do the right thing for your distro.) Edit: If the next update doesn't fix this issue for you, then I'll eat a bug. [ April 23, 2006, 08:54 PM: Message edited by: ClaytoniousRex ]

Thanks, Raj. Is it generally safe to assume that bash is present?

I've just checked in some changes that will probably fix your silent microphone on Linux, Poesel. These will be in the next update. One thing to watch out for, at least if you have a Creative card, is that you *need* to turn on the Mic Boost in your alsa mixer in order for your team mates to hear you. The mic boost is one of the channels that you can "unmute" with any of the alsa mixer front-ends. This next update also includes doppler sound on Linux, some fixes to 3D sound attenuation, etc.

It's still fixed but still not in a release yet. We'll probably hold it for 1.0.0.

Surely there's another zlib.dll, SDL.dll, and/or Demeter.dll out there somewhere?

Hi, Minas. The main similarity between DropTeam and BZ is the mix of FPS and RTS (much like in BZ, you not only issue orders to units but also directly control them, including taking control of different units at different places at will). Beyond that, though, there are plenty of differences, notably a realistic combat system with detailed penetration and damage (as opposed to BZ's arcade style "shoot it until it dies" kind of system), there's not really base building in DropTeam (though there are deployable items like turrets, sensors, jammers, mines, etc.), there's a more believable mix of unit types in DropTeam, etc. Anyway, I'm sure you will see the differences for yourself. Have fun and welcome aboard!

I'm sad to report that there is still not a Universal Binary build ready for your new Intel Mac, Dan. However, if you want to volunteer to try out an experimental Universal Build, then please drop me a line! Otherwise, it will be a few more weeks for the Universal Binary version. And, sure, I'd be happy to apologize to your wife. Just finished doing that to my own, so I'm on a roll right now.

Yes, in-game you can send a chat message that looks exactly like this in order to show frame rate: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">/showfps true</pre>

Hi, Danez. Is your desktop at 32-bit color? If so, and it's still not working, then post your DropTeam.log here or email to support@tbgsoftware.com with a note explaining that it's from Danez on the forum.

Wow. Weasel, I'll be quite curious to know how far up you can pump the graphics options and still maintain a good framerate. For example, start with 800x600 with HDR, foliage, shadows, etc. all on. Then try 1024x768, then 1600x1200... Even with that monster rig, I'll bet HDR at 1600x1200 will slow it down. Congrats on your new setup!

This new behavior in 0.9.45 is the game checking to see if a new version is available at startup (it didn't do this prior to 0.9.45). This was added because a surprisingly high number of people had no idea they could update to the latest version and they've been sending us angry emails asking why we would release a public test version 0.9.40 when all of the servers are a higher version... Now that this check is happening at startup, it seems to causing this new problem for you ZoneAlarm users. I'll see if we can move it to a slightly later time, when the application's message pump is already running. Hopefully then it will behave like it used to, allowing you to switch over to the ZoneAlarm window.

Decreasing the Hurricane's armor was NOT an attempt to address the reported balance issues with the Hurricane. Reducing its armor values has been done in response to the earlier change which made armor slopes more sensitive. Since the Hurricane is one of a few vehicles with an unusually high amount of sloping on its armor, we've been reducing its armor thickness simply because it "accidentally" became too tough due to the previous change. We're still looking at the balance issue itself and haven't settled on a final fix for it yet. One of the problems is that there are supposed to be fewer Hurricanes on each team (from 1 to 3 instead of the current 4 to 7 or so) - this is a problem with the inventory system that we're looking at now. Whatever the solution to the Hurricane's balance problem is, here's a little insight into our design philosophy: there is never any requirement that all units in the game be "equal". Not only are all unit types better in some situations than others, but some unit types are *usually* better than some others in *most* situations. As a modern day analogy, you might have a force with some T-72 tanks and some T-80 tanks. Well, obviously, the T-80 is just simply better than the T-72, but the reality is that the force has to make do with some slightly less effective tanks. It's also quite fun to have some really fearsome, powerful units on the field. It's exciting when you hear a team mate call out on voice chat "Enemy Hurricane at waypoint 1!!!!" with that special quiver in his voice - then watch as your team rallies and focuses its attention on the new threat. Of course, this is NOT fun if that kind of threat materializes too often and too easily. I think everyone in this thread agrees with these points, and you're all correct when pointing out how important balance is. It's usually not even this black and white in DropTeam since the mix of unit types and scenarios is interesting: there are occasions when a Shrike is better than a Thor and vice versa, which is great. Currently, the Hurricane is almost always better than anything else no matter what the circumstances (at least on these 2 public test scenarios), which all of you are correctly pointing out as being a problem. So, yes, we're looking at ways to make the Hurricane less dominating, but the "fix" might not be to directly "nerf" the Hurricane itself - it might simply be to limit its availability or to otherwise make using it more costly for the team as a whole. The goal is certainly not to make it "only as fearsome as a Shrike, but in a different way".

...is now available via Update. On Windows, use Start/Programs/Battlefront/DropTeam Public Test/Game Updater to get it. On Mac OS X, double click on the Update icon in /Applications. On Linux, use the runUpdate.sh script. Fixes in 0.9.45: </font> Improvements to the fragmentation component of the damage model</font>Improved bot driving of tracked vehicles</font>Tips for new players</font>Slightly increased effectiveness of automated guns (such as on the Hermes)</font>Reduced armor the Hurricane (again)</font>Reduced toughness of a few internal components</font>Fix crash if using voice chat with sound disabled</font>Don't show cancel button on Drop Dialog when it can't be used</font>Exit confirmation dialog when quitting</font>Fixed crash on server list</font>

And, you're not, by chance, running any Stardock stuff are you?

Also, is the Client for Microsoft Networks installed? (You can look under you Local Area Connection properties in "Network Connections" in the Control Panel to see if it's there).

Kirill, a guy on the cygwin mailing list had this to say: "The symptom is that I was trying to start a non-Cygwin program that I'd just built, and saw the above-mentioned popup. It didn't occur to me for a long time that the problem had anything to do with Cygwin, since neither the program -- nor the DLLs on which it depended -- used Cygwin. However, I *had* installed those DLLs by using Cygwin's "unzip" to unpack a ZIP file. I then noticed that if I simply did "chmod +x *.dll" on those DLLs, the problem went away. I figure "unzip" set the permissions on those DLLs to 0640, which seems reasonable from Cygwin's point of view ... unfortunately, though, NT requires those DLLs to be executable; hence the infuriatingly obtuse error popup." Sound applicable?

Pilgrim, of all of the DLL's that are in the root and in the bin/ subdirectory of DropTeam, are any of those also in your system path somewhere, such as in \Windows\system32 or in some other product's directory that has been added to your path? If so, which ones?

In heavy action with around 18 players on a server, DropTeam sends about 23 k bits / second down to your client on average. With fewer players it becomes dramatically less.

Yes, we can definitely do that.

Scenario authors can create any number of game types in their scenarios and give each of them its own name. Many of our scenarios in the base game have game types called "Objective" and "CTF" in them, but there's nothing magic about these names. Over time, when players create their own scenarios or when we release new ones, there will be other game types such as "Capture the Comm Station" or "Destroy the Bridge". So we can't reject the game type you have entered on the command line as "bad syntax" simply because the first scenario in your server's list doesn't contain that game type. We could, however, treat the game type names as case insensitive. This still wouldn't have helped if you had used a game type of "Objektive" but at least it would have helped you in the case of "objective".

This sounds like the same problem Kirill S. was having: see this thread. Want to try this potential fix on that troublesome machine? This is a way to restore ACL's for all system DLL's. At a command prompt you would do: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">CACLS %systemroot%\System32\*.dll /E /G BUILTIN\Users:R</pre>