Toby Haynes

Welcome back! If you have Windows, I think the answer is yes for sorting out a lot of the fiddly parts of the scenario design (building positions, etc). If you are on Linux or Mac, DropTeam can be run in a special editor mode. I've been trying to write a Perl wrapper to communicate with DropTeam in this editor mode but so far I've been running into problems with the file signalling. If I get it working, I'll announce it on the modding forum. My aim is to get it to the point where you can add, move and delete objects. From there, we'll see what else can be done.

Thanks for all the comments. I hope it plays as well as it looks - I gave each of the play modes a thorough going over with the bots but sneaky human players may be able to exploit it in ways that the bots miss. One piece of advice for people playing this level - all the facilities near the Dam are linked, so the two AATowers which protect units on the dam can be hacked with Cutters from either end. That said, the positions can be well defended by determined defenders, so the attackers will have to work to pull off the steal. I learned some new tricks putting this level together - note that the roads are now properly centred on the flat areas (compare this against SeaCliffs where the road had a tendency to seep over one side. I'll be putting out new versions of Sea Cliffs and Volcanic Deposits in the next week or so using the new tricks to tidy up the roads. Volcanic Deposits could also do with a few more buildings than it currently has. And I will also be publishing the source code to my erosion/road/map tools soon too. Really. Honestly! I'll try and get the Howto instructions written up and then it should be ready for a first release. I need to test it out on a 32bit system first but that is the last hurdle.

Yes - the water stays in the same place. That actually was a concern so I made sure that the Dam was quite a bit higher than the water on both sides so that this wasn't quite so obvious. The water volume is really just a box defined in the XML file. If I can work out particle emitters, I'll put some leak points in the dam to simulate water flow But for now, what you see is what you get.

Ah - now that's funny. Actually I live just a little north of Toronto at Richmond Hill. The british accent is just a disguise Cheers!

For the record, I was seeing pings around 120- 150ms to the Library server from here in Toronto, Canada. Not bad, but Delta Pavonis has around 65ms ping from here.

It's about time I released another map - here's the level that I used to write the tutorial over in the Wiki. In the name of shameless self promotion, you can read it at http://dropteam.johalla.de/moin.cgi/The_Nexus_6_approach The new level is available at http://tjwhaynes.googlepages.com/dropteamresource I've put three modes together for this level - Objective (get/hold the Dam defences), CTF (with bases in the east and west sides of the valley) and Territory (there are four bases to control). WARNING: as it stands, it uses the Hopewell environment map. This is not shipped currently with DropTeam - I have sent the files to Clay and hopefully they will be part of 1.2.2. Follow the instructions on my web page and you should be able to play the level. Just to give a flavour, here are a few screenshots.

I lost several cutters clearing those mine fields - they were very nicely placed. I keep messing around with the tactics for the city level. This time I think the balance of air defence, seizing turrets and ground defence worked out really well. I also have a new tactic for removing enemy AA turrets (no - I'm not telling you what it is ) which made the difference this Sunday between partial air control and total air superiority. All in all great fun. I know that the mines have been removed from in game due to their potential for abuse during play. I'd really like to see a vehicle that can lay mines (maybe a hovercraft mine layer...) so that static defense can be rebuilt against hordes of cutters clearing them away. Limiting the mine ammo for the level might make a lot of sense.

You can get the SeaCliffs scenario off my web page directly - try comparing the files and see if something strange has happened. http://tjwhaynes.googlepages.com/dropteamresource Linux/Mac/Windows?

Good battles again today folks. Apologies for breaking off after three rounds with no sign off but I had an important phone call to field. Thanks to all who played - fun fun fun!

No one is stealing my marshmallows! No one! Expect to roast in the hail of plasma artillery! (I'll be there, if anyone doubted it )

I'd say that most front-wheel drive cars understeer, rather than oversteer. Oversteer in a car quickly leads to the car spinning - most people can't correct for oversteer safetly. Certainly my car (Acura RSX, front wheel drive) understeers when I apply power in a sharp corner. The result is that the car drifts wide of the intended line. Oversteer would step the back of the car out and would require less steering lock or reverse lock to correct. The behaviour of the paladin is certainly understeer. As Clay points out, using the throttle in the corners causes significant understeer. Given the power of the engine on these vehicles (which is, as far as I can tell, much greater than domestic vehicles) that is entirely correct. The reason for understeer when accelerating through a corner is complex. Think of a tyre having longditudinal friction (i.e. in the direction of travel) and transverse friction (sideways). Longditudinal > transverse for most (all?) tyres. However, the amount of friction the tyre can deliver sideways is dependent on the amount of friction being delivered longditudinally. As the longditudinal friction is increased, less lateral friction is available, leading to sliding and understeer. For a mathematical description of the physics of tyre friction, try looking up the Pacejka Magic Formula on Google. For example: http://www.racer.nl/reference/pacejka.htm Cheers!

You know - that's really odd. I thought I hit the same issue - all the Hopewell skybox files were gone. i.e. I saw this at the end of the DropTeam.log file: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">... Warning: could not find file "HopewellFrontSkyBox.png" Warning: could not find file "HopewellBackSkyBox.png" Warning: could not find file "HopewellLeftSkyBox.png" Warning: could not find file "HopewellRightSkyBox.png" Warning: could not find file "HopewellTopSkyBox.png" Warning: could not find file "HopewellBottomSkyBox.png"</pre>

You've made my day too. When testing new scenarios, I might load and reload and reload ... Now I can actually put the changes together more quickly, which means ... MORE SCENARIOS

I would agree - it does feel a little soft. Maybe that's actually accurate but it does feel like driving an ambulance. However, it does feel more like vehicle suspension than the previous system so I'm going to give it the thumbs up.

Actually, Slugfest uses the wrong environment map (it uses Archipelago). So it shouldn't stop you playing SlugFest but I would like to get TheDam using the Hopewell skybox and Hopewell environment map because its a more consistent backdrop than any of the others (and I've not yet got to designing skyboxes).

For those who have been following my wiki entries, the tutorial is almost complete over at: http://dropteam.johalla.de/moin.cgi/The_Nexus_6_approach I'm in the tuning phase now of preparing the new scenario for release but the skybox I was using (the Hopewell set) does not appear to have an environment map available. This surprised me, because Slugfest needs it. So I've created the environment map using the instructions in the CreatingScenarios.pdf file. However, I can't really claim that these are my files - they are copyrighted to the DropTeam game. Hopefully Clay will add them to the next release. Here's the snippet from TheDam.scenario that works with these files. </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><SkyBox> <FrontFilename>HopewellFrontSkyBox.png</FrontFilename> <RightFilename>HopewellRightSkyBox.png</RightFilename> <BackFilename>HopewellBackSkyBox.png</BackFilename> <LeftFilename>HopewellLeftSkyBox.png</LeftFilename> <TopFilename>HopewellTopSkyBox.png</TopFilename> <BottomFilename>HopewellBottomSkyBox.png</BottomFilename> </SkyBox> <EnvironmentMapBaseFilename>Hopewell</EnvironmentMapBaseFilename> </pre>

Damn - I shouldn't give my secrets away

This cries out for ambient occlusion texture baking. This technique sets the model up with a broad hemispherical light source and works out the appropriate shadows. These shadows are then baked onto the model and exported. http://vegastrike.sourceforge.net/wiki/HowTo:Radiosity_baking_in_Blender It saves trying to do the lighting by hand and can give much more realistic results.

Well - the SeaCliffs and Volcanic maps were designed and built on an Athlon64/3400+ with 1Gb of memory and an NVidia 6800GT 256MB card (yes I know I should get more main memory). So your system isn't so far away from mine (except I run Ubuntu Linux AMD64 native rather than Windows XP 32bit). Glad to hear that the driver update solved the issue.

I agree - the tracers really add to the feeling of mayhem. It also makes it easier to work out where the fire is coming from and that aids tracking down those pesky 20mmAP shooters Ah yes - the turret flood attacks. I like the way the command vehicle can be used to overwhelm an improperly defended area. I used to shun the command vehicle as a drop once, EMP and Fire attack and leave option. Now it can be extremely effective as a supporting role - on at least one of the Sunday games I was dropping turrets near enemy tanks as they engaged our own tanks. Even if the turrets were destroyed, it was often enough to turn the battle.

See if Volcanic Deposits causes the same issues - it too is a 1024x1024 heightfield like Sea Cliffs. Most of the other maps are 512x512.

1.2.1 seems to have fixed the issues. Some players were having trouble with lag but it was fine for me and Junglist.

1.2.1 is definitely better I'll post more in response to the release notes but it feels more intense as the tracer rounds rip passed and the suspension system is different (a change for the better too).

Actually, to me that is one of the reasons why I put money down for DropTeam in the first place. I've messed around with the Demeter terrain engine several years back and wondered if anyone would ever make a game using it. Seeing a tank game emerge was a welcome surprise. Discovering that such a game would be extensively modifiable was the icing on the cake. To then discover that the development team was as keen to push the game on as well was a major bonus. I really do feel that there is enormous potential for DropTeam (and that is not to say it doesn't already stand on it's own feet).

That means that one of the libraries that the application needs in turn needs other libraries. The linker sorts out all the required symbols and loads the appropriate libraries. Two libraries can even depend on each other and the linker will still get it right