Toby Haynes

I'm running Ubuntu 6.10 AMD64 with a GeForce 6800GT driver version 8776 and it's fine. Have you tried an 8xxx series driver? Is 9631 out of beta testing yet?

Sadly I got sacrificed on the altar of Ikea that afternoon. Now I have a vast number of bits of wood to assemble into some strange structure. Still, I live in hope that I might make it next week.

With my software professional hat on, Linux tends to have better performance (compared with Windows) on all network-, socket- and pipe-related activities, sometimes by several factors. Since I long ago wiped any copy of Windows off any machine I own, I can't do a straight comparison any more. Now - I have seen bad lag on Linux too. But I don't seem to be seeing it as often as some people are seeing it on Windows. It does seem to be at its worst when there is lots of smoke around. My understanding is that the smoke has more effect than just blocking lines of sight. I believe it blocks ATGM-locks although that may be just my imagination. I do wonder whether the AI is going nuts trying to find targets when there are several smoke plumes around.

Clay has, I believe, just moved house. I'm also fairly certain that he's just as keen to get this fixed as we are.

I saw it yesterday on Haven in Territory mode. A Thor and an Apollo went aerial while I watched. The only thing I can think is that either the suspension is getting a bad value or the tanks are penetrating the buildings or landscape and are being abruptly pushed up to get them above the landscape.

Okay - only the demo server is visible again. But the log seems to suggest that there are three machines being contacted. I see this in the logs LOBBY: Pinging server 205.145.140.226:9967 LOBBY: Pinging server 69.59.160.204:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Received from 205.145.140.226 LOBBY: Retrying server 69.59.160.204:9967 LOBBY: Retrying server 77.179.38.91:9967 LOBBY: Pinging server 69.59.160.204:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Retrying server 69.59.160.204:9967 LOBBY: Retrying server 77.179.38.91:9967 LOBBY: Pinging server 69.59.160.204:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Retrying server 69.59.160.204:9967 LOBBY: Retrying server 77.179.38.91:9967 LOBBY: Pinging server 205.145.140.226:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Received from 205.145.140.226 LOBBY: Retrying server 77.179.38.91:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Retrying server 77.179.38.91:9967 LOBBY: Pinging server 77.179.38.91:9967 LOBBY: Retrying server 77.179.38.91:9967 Attempting to contact these servers by hand gives the following: toby@nexus:~$ ping 205.145.140.226 PING 205.145.140.226 (205.145.140.226) 56(84) bytes of data. 64 bytes from 205.145.140.226: icmp_seq=1 ttl=48 time=34.3 ms 64 bytes from 205.145.140.226: icmp_seq=2 ttl=48 time=34.8 ms --- 205.145.140.226 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 34.329/34.569/34.810/0.303 ms toby@nexus:~$ ping 69.59.160.204 PING 69.59.160.204 (69.59.160.204) 56(84) bytes of data. 64 bytes from 69.59.160.204: icmp_seq=1 ttl=114 time=78.2 ms 64 bytes from 69.59.160.204: icmp_seq=2 ttl=114 time=78.0 ms --- 69.59.160.204 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 78.001/78.109/78.217/0.108 ms toby@nexus:~$ ping 77.179.38.91 PING 77.179.38.91 (77.179.38.91) 56(84) bytes of data. 64 bytes from 77.179.38.91: icmp_seq=1 ttl=43 time=148 ms 64 bytes from 77.179.38.91: icmp_seq=2 ttl=43 time=148 ms --- 77.179.38.91 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 148.290/148.510/148.730/0.220 ms So everything is pingable but 77.179.38.91 isn't replying.

Thanks. That animation link is intruiging - I can think of a number of neat effects using that (although I'm not sure we are ready for Heavy Mech warfare ). I'm in two minds over this one - so two variants. A fast reconnaissance with light weapon systems and a slower multi-weaponed beasty intended to cause havoc from above (heavy artillery bouncing bombs anyone?). Anything slower than the dropships will be instantly wiped out by the bots who are quite decent with 120mm AP shells at distances around 1000m or less. The slower one needs sufficient punch to make the risk of being hit worth the effort. I do like the idea of using 14mm systems as a manual antimissile system. I'll have to give that a try if I manage to get this one off the ground . One thing I did realise when playing Desert Mesa (with the Thor perched on top of a mesa) was that the very top of tanks are quite vulnerable. That leads me to think that 20mm or 30mm cannon from the air would be devastating for almost all vehicles. Fitting auto 90mm AP turrets to this thing would be extremely amusing but somewhat unbalancing

It's possible it was connectivity-related - but at all times I could see the Demo server so if they are co-located, that's very strange. Anyway Landis is up and playable right now, so I'm happy

Thanks for the kind comments. Yes - it's a little spacey as it stands. On the other hand, its design is closer to an attack helicopter than a fixed wing plane. Only the rotors are missing - given that DT is an antimatter-propulsion scenario and this would have to operate in vacuum as well as atmosphere, I wondered whether such control surfaces made sense. Rotating jets down towards the ground (Harrier jump jet style) for low speeds would be extremely cool. I have no idea whether the game engine could hook up to such an idea though - maybe if Clay or MadMatt sees this, they could comment. It's easy enough to "cut" the jets off the model, so it's not a difficult modelling problem if I revisit this later. Yes - I've left space on the surface of the model for any cannons/machine-guns/missile launchers, rather than build them into the structure. It strikes me that any futuristic weapon system should have some field-of-fire rather than just locked to the direction that the craft is pointing. Something like this would have to have an anti-ATGM/SAM system otherwise it would have zero survivability. Of course, that might present an option in game allowing good players to use it to penetrate SAM defences. Whether that is desirable or not is another matter. Fury sound good. I'll browse through some mythologies and see what else jumps out. A dragonfly was used as inspiration for the original sketch (although those with sharp eyes will note that I've stretched the "tail" on the model much further than the sketch shows it).

Very interested in seeing what you can do, especially if you can simulate something close to that gunship concept! </font>

Well - assuming that TBG has the SciFi Forces MegaPak, they have plenty of options to draw from. There are some seriously large calibre weapon systems in there, plus something which looks like an oversized turret minigun which looks destined to chew through aerial units

Landis is missing. Delta Pavonis is missing. What happened?!

If you want to practice shooting and driving, I recommend Slug Fest. The ground has plenty of flatter areas for driving at moderate speed and there are enough hillocks and valleys to make it interesting and give you something to hide behind. Some tips for driving: </font> Watch your speed!</font>Cornering at speed is dangerous, especially with the Shrike.</font>To turn a vehicle quickly, turn in without the accelerator. Once the vehicle is almost through the turn, press the accelerator down to pull the vehicle out of the turn. Some opposite lock may be required if the back slides out.</font> For driving practice, play in CTF modes - you need to cover lots of ground when carrying the flag! The Paladin-L or Shrike are ideal flag carriers, although the Apollo L can be used if you have a posse of tanks.

Imperial - is that a unit you actually have the model for or just a screenshot? I can probably knock something like that up in Blender given a couple of hours (low-poly version) and then look towards putting all the details together later (high-poly overlay for baking). Let me know if you are interested.

I find that the mouse is absolutely required for accurate shooting. Nothing else comes close. I'm sitting here surrounded by input devices - there are pedals at my feet, a steering wheel with six buttons in front of me and a four axis joystick on my right. For DropTeam, I've tried various combinations and I still keep coming back to keyboard and mouse. The main reason is that there are a fair number of commands to be used, especially on the tactical screen where there are lots of Alt-v/Alt-h/Alt-m to be used. That requires keyboard and mouse and makes it awkward if you are using a steering wheel for driving. So - my advice is stick to the keys and mouse. Driving with keys is never totally satisfying but practice will allow you to flick the vehicle between the trees and still nail that annoying person shooting at you.

I'll be around sporadically but forces beyond my control insist that I will be absent for the next two Sunday outings. Have a merry Christmas and I'll be back blowing up tanks in 2007

You're right - Delta Pavonis is AWOL. Maybe it saw too much destruction and opted to spend the rest of existence in meditation. Or maybe it just needs a kick.

Yes - that one was fun Thankfully there wasn't too much smoke on that level (except from the bot dropships plummeting from the sky above our Hermes...).

Are you asking for maps with a short line-of-sight? Lots of undulations to hide tank/infantry in?

I'm a bit surprised that you are having difficulties. I'm running on a 6800GT 256Mb at 1280x1024, everything turned on, 2xAntialias and the frame rate is fine for me. My CPU is an AMD64 3400+ which was quick when I bought it I'll test my frame rate...

Some hacking around switching libraries around and ... whoa! A fix! For those of you who also run Ubuntu AMD64, I give you the following recipe. I have a 32bit chroot environment installed as well as the 64bit, so I always options when faced with 32bit binaries. I moved the libopenal.so* libraries out of DropTeam/lib into a safe place. I then copied the 32bit version of libopenal.so into DropTeam/lib and created symbolic links in that directory to it to satisfy the requirements of the SpaceVikings binary: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">cd wherever/you/installed/DropTeam cp /chroot/usr/lib/libopenal.so lib/ cd lib/ ln -s libopenal.so libopenal.so.0 ln -s libopenal.so libopenal.so.1</pre>

Everything was fine ... until I upgraded to the latest Ubuntu release. The sound is now playing back at half-speed - it's an octave lower than it should be. That makes the whole game feel .v.e.r.y. .s.l.o.w... Now Dropteam was the first thing I tested that had sound after the upgrade. It also appears to be the only app I have that has this issue although I have plenty more to check before calling it the only victim. Doom-3, QuodLibet (music player using GStreamer), the desktop sound effects all appear to be fine. Looking at the output in the DropTeam.log file, I see the following: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> SOUNDMANAGER: Using default capture device SOUNDMANAGER: pCaptureDevice = 0x85744d8 SOUNDMANAGER: Error after opening capture device SOUND CONTEXT ERROR: ALC_INVALID_ENUM SOUNDMANAGER: Playing DropTeam.ogg as ../data/sound/DropTeam.ogg SOUND MANAGER: Allocated 54 voices</pre>

Tanks can currently have one manual turret with multiple weapons (Thor 120mm plus coax 20mm). Some vehicles have two separate non-coaxial weapon systems (Paladin EWV and SAM units) where I assume that the second weapon system is a bot running autonomously. I've not pulled the XML apart for the vehicles to see what ticks - until recently I've been concentrating on scenarios. Right now, I'm working on improving my modelling skills to try and realise some of my ideas for the next scenario. Particularly, I'm trying to work on building high poly objects and then baking the details (texturing, ambient occlusion, etc) into a low-poly mesh. This is similar to the process for the Doom-3 models but without the tangent mappings (although if DropTeam ever supports them, I'd have that option). I'd be happy to knock a tank model together but I know there are already some examples out there. If any tank developed by the community makes it to a playable state, PLEASE would someone write it ALL up on the wiki so that those of us who follow on can learn from the process. I've looked at this page on the wiki but clearly there is more to getting a finished vehicle. http://dropteam.johalla.de/moin.cgi/Designing_3D_Elements

I'd be interested to know whether anyone has tried to build an OGRE type tank yet? I would love to see a Superheavy packing a 230mm main turret (maybe with limited range of motion), four corner-mounted 90mm bot turrets (which could be independently damaged), two SAM bot units for air suppression and two anti-air guns for anti ATGM suppression. There was a fair bit of discussion about heavies but I've yet to see one I can play with?

The model looks good. Is this going to fly in a horizontal position or would it fly forward with the nose down a bit (more like a helicopter)? If it is using the dynamics model for the Viper, then the latter I guess. I wouldn't want it to be stratospheric - 5 stories off the ground sounds reasonable (that's about the height of the spikes on the CommStation. 30mm would be fine as it would give the weapon a longer range but what about the rate of fire? To be a low-flying terror in the skies, maybe a burst of 10 rounds with a reload time of 3 seconds? Jamming is probably going to be absolutely required for this object as I assume it's armour is going to be weak. This would definitely be cool. Carrying passengers is definitely underutilised in game, maybe because it requires REALLY good coordination between two human players. I assume it would have to park to allow players on board. Dropping infantry off at 5 stories up would be fine too - these guys seem to survive jumping off cliffs without trouble