ClaytoniousRex

OK, well let us know if it's still not up and running after your kernel upgrade.

Dark, quit the foul language. Below is a snippet of the terms you agreed to when you created your forum account; please adhere to them.

Tanki, that error means you don't have GLIBC 2.3.4, which is required by DT. You would have to upgrade GLIBC (which means upgrading everything). On a P4 with a Geforce 6600, using the XFCE window manager under Suse and dual boot into Windows XP, the same box gets on avergae 10fps faster in Linux than in Windows XP. XFCE is a very thin window manager. Using a fat pig like KDE or Gnome might well slow it back down closer to what you get in XP, but I haven't tried it.

Yes, I see what you mean. Maybe we can extend it out to about that range for the min spec players. I'll do some testing and find out.

I think that Yurch's design is meant to address what is currently a serious obstacle to tactical armored combat, which is a team's inability to protect itself from rear and flanking drops by the enemy. Particularly in Objective games, without the Bacchus, the attacker can execute excellent maneuver, gain advantageous positions, and do a good tactical attack, but no matter how clever he is the defenders can always simply drop behind him or on his flanks. Enemy units appearing out of nowhere in your rear ruins any plan you might be working on. Some longer range air defense would finally give an advancing team a way to cover its rear and flanks from enemy drops, though it does nothing at all to protect from enemy advance through cover over land into those areas. And if the enemy manages to maneuver into your rear or flanks, well then that is good tactical combat. But simply dropping there with one mouse click? Not very tactically interesting, but very effective (and with the Bacchus, it would stop being so effective). Don't you think the game of tactical maneuver will be improved if teams have a way of preventing the enemy from dropping all around them? Or do you think this is already possible, and the Bacchus goes too far in making it even easier? Or, if I misunderstood your question and you meant more generally what does an air defense vehicle have to do with tactical armored combat - well, air defense has been of paramount tactical importance for some time now. Air defense AFV's that are integrated into armored units are a very old thing: we've seen everything ranging from the M6 Linebacker with stinger missiles to the older VADS vulcan systems and ZSU, all the way down to the German Wirbelwind, etc. - you know the list. Compared with the modern battlefield, but even more importantly in this setting where the enemy deploys via dropship right onto the battlefield, I think that air defense in DropTeam is drastically underrepresented, don't you? Maybe not. Do you find that you don't need something like the Bacchus in order to protect your advancing force from drops? If so, can you share some of the tactics you're currently using that are working well for this? If a new, more powerful AA unit isn't needed in order to fill this role, then that's exactly what we want to know! Or, are you simply saying that you don't think a team should be able to protect itself from drops? Would love to hear more about that, too, if that's what you mean! (This would be pretty surprising, though, since you're a fan of more classic maneuver). The Bacchus cannot be sensor jammed. Not only that, but it is always visible, even if not in LOS. So if the Hermes player intended to go around the rear and do some butt slapping, he was a fool to bring a Bacchus with him. The bots are quite good about avoiding the Bacchus, so hanging around to kill the same dumb bots isn't a worry. And finally, Galaxies are a very poor defense against a tank, unless the player using it is both by himself and has forgotten how to use his coax. In this case, that player is not much of a threat with or without the Galaxy. It has no bearing on the Bacchus one way or the other, at any rate.

How does it do that? They will both see foliage in their gunner's views, which is the majority of the problem here. Do you mean that the target in the middle distance might be hard to see because of the foliage around it? I don't think this true of any of the AFV's, though it theoretically could be if a scenario author were to make some remarkably large foliage. However, it could well be a problem for infantry, especially if they're prone. In most of these cases, though, the detection rules (which force them to be invisible even if the client has foliage turned off based on terrain type) should take care of that already.

A section under the "Mods" area on the Wiki would work well for that. You could collect the mods that folks post from here and link to them from the Wiki. That would be a great help for everyone who wants to try things out!

It's a sticky problem. There are really only a few permanent solutions: </font> Raise minimum system requirements so that everyone has it on at all times - fewer players online</font>Model the effects of it not only for bots but also for players who have it turned off - very hard to define programmatically (a random chance of "not seeing" a target? reduced weapon accuracy? all quite imperfect)</font>Make it transparent while in the gunner's view - no physical justification for this, but would address the problem</font> Poesel, that approach would actually be too strong a penalty - you can often catch sight of a target even through the foliage and eventually fire on it. It's just painful and annoying to do. Actually, a variation on #1 in the list might be possible. Even on min-spec systems, maybe we could render only the foliage in the immediate area (the annoying stuff in your face in the gunner's view) but not the other trillion blades of grass in the distance for users who have foliage turned off. If this is feasible, it's probably the best solution.

The idea isn't to permanently remove the ability to deploy mines after the Deployment Phase, but only to disallow it for the moment until proper artillery-deployed mines (along with the improved detection and marking features) are added later. Would you rather leave them as-is until that later work is done?

OK, but in order to prevent any gimmicks being introduced, we need to know what it is about the Bacchus that is a gimmick. Could you please explain what it is about it that makes it a gimmick?

Detectability and marking on tac display are definitely good ideas, so we'll get to that soon. The current use of mines in an offensive role is just too silly without these features, so in the 1.1.4 release the changes below are now in place for mines. After 1.1.4, when we've done detection and tac marking, we will probably add artillery delivered mines. </font> Mines can only be deployed during the Deployment Phase.</font>Mines can only be cleared by the Cutter.</font>HE blasts move them around a bit (when the blast is big enough to dig earth) but don't clear an entire minefield anymore.</font> On a related note, the number of Cutters available in the default inventory has been increased, too.

For those of you who don't follow the Modding forum: Yurch has created an interesting new unit type called the Bacchus. It's a powerful air defense vehicle. I'm posting about it here in the main forum because we are going to include it in the upcoming 1.1.4 release and I would like to invite everyone to comment on the implications a unit like this has on gameplay. If you see any serious problems with the introduction of a unit like this we would like to hear them now, but please also include specifically what it is that you would like to see changed in order to address your concerns if you have any. Some data on the Bacchus: </font> It's a variant of the Paladin that carries a SAM missile launcher</font>The SAM launcher fires automatically (like the air defense gun on the Hermes)</font>It does not provide point defense - it does not shoot down any projectiles or missiles ever. It only shoots down dropships and pods.</font>The missiles have a very long range, so just a few of these things positioned well can lock out the smaller maps from dropping completely, and can lock out most of the bigger maps.</font>Since the Bacchus uses loud active sensors to do its job of impressive air defense, it cannot be sensor jammed and it is always visible to everyone. You can see it on the tac display, on the minimap, and on the 3D planetside display (always with a red pipper).</font> Remember, you now have deployment zones even if the enemy does lock you out of dropping with units like this. A vehicle like this represents a new kind of strategic asset - one that is mobile and player controlled. This is a very interesting development! After some beta testing with it, we've learned how to manage it pretty well, but the first few games were learning experiences. Since it is always visible, and it is not very well armored, any decently coordinated team should be able to take them out in order to clear a DZ. The big difference, though, is that the introduction of the Bacchus greatly increases the chance that you will, in fact, need to work together in order to clear a DZ. In the past, this was only sometimes necessary (depending on how the enemy deployed his AA turrets and what kind of static AA was available on the scenario in question). So, in summary, our feeling here is that the unit is pretty well balanced but does definitely introduce a high impact change to how the game is fundamentally played - dropping wherever you like "willy nilly" is now even less feasible than it already was. As far as tactical gameplay goes, I see this as a Good Thing, but would like to hear all of your opinions on the subject before we commit 1.1.4 to the update system.

I understand. Mmmm. You may have to just do the slow DSL upload one time to get it onto a fast server. From then on, you can always get it elsewhere from your fast server (assuming you can keep the thing for a while). There is another way that will require just a little bit of hacking, but will allow you to get everything via wget. If you want to try it then email me for info.

Ha, good timing Poesel. See the previous forum topic before this one for instructions on how to install on a headless server (you just unzip some stuff from the CD - no need to run the graphical installer). The download link gives you 1.0.0. Once you install it, you can update it to the latest 1.1.3 from the command line like this (assuming DropTeam is installed at /usr/games/DropTeam): </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">cd /usr/games/DropTeam/bin LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../lib/ ./SpaceVikings -update true</pre>

Luckily, the non-sse compile is almost complete. Email me for a download link.

Did the kitty say "sse" in flags?

If you're already sure that your CPU doesn't support SSE then yes, you're right - stop here. If you're not sure, then </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">cat /proc/cpuinfo</pre>

And in case you need them, here are the steps for a manual install (this is what we do on our colocated headless servers, for example). This assumes you copied the CD to ~/DTCD and are installing to ~/DropTeam, so substitute as needed. </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">cd ~/DTCD/DropTeamInstall mkdir ~/DropTeam cp InstallData/LinuxBinaries.zip.bz2 ~/DropTeamBinaries.zip.bz2 bunzip2 -f -q ~/DropTeamBinaries.zip.bz2 unzip -o ~/DropTeamBinaries.zip -d ~/DropTeam/ rm -rf ~/DropTeamBinaries.zip.bz2 rm -rf ~/DropTeamBinaries.zip unzip -o InstallData/data.zip -d ~/DropTeam/</pre>

And don't do that, Squiddy - yikes. If it comes to that then let's just do the manual install which is pretty simple (but won't work if files like that have been - ah - "improved" in any way).

R key cycles through all available weapons, so you can have 2 coax, or multiple weapons that aren't even really mounted coaxially at all. If you just want a separate ATGM launcher that's perfectly fine. There's not any support for a Copperhead style round right now. The only guided weapons supported are missiles.

And no need for any of that LD_LIBRARY_PATH in your global environment. The runLinuxInstall script sets what it needs already.

Run it from the root of the CD, not from down inside of InstallData. There's a symlink to runLinuxInstall up there at the top level already; just cd to that top level dir and do a ./runLinuxInstall from the top.

Oni, it doesn't run on the integrated Intel graphics controller that some of the mini's have (but it does run on the ATI 9200 that other mini's have). War, there are lots of folks who can help you in all sorts of interesting ways. What do you need?

So to summarize, the SquidLord is trying to not only install from his own local copy, but also while remotely connected to the Linux box through a session of X. You could probably also balance a plate on your head throughout the install and maybe only allow yourself to use one hand for both keyboard and mouse. I jest, O Lord of the Tentacled People... That failure means that the truetype font for the installer wasn't found. What directory are you running the installer from, and how exactly are you running it? This error is probably caused by the install process's working directory not being what it expects to be, so the fix will probably simply be a matter of running it from the right place. After that easy fix, we might then have a harder issue to face, which is that the installer is a nice graphical installer that uses OpenGL. We'll have to see how that gets forwarded to your cygwin X server (she might simply poop in the night). Luckily, this is Linux, and the install program is just a lot of unnecessary fluff. Let's try to resolve it based on your answer to the question above but it continues to be difficult we can simply (and very easily) do the install manually from a shell and get you going.

There is no music during actual gameplay. Unless I am eventually overruled, there never will be. DropTeam will, however, stream your own music files during play if you want to provide your own soundtrack. See here for details.