Toby Haynes

HDR effects in DT make the bright sky box areas bleed over the landscape/objects/trees. Think of it as a more realistic form of light bloom. HDR won't radically alter the way DT plays. Having a better frame rate might. I play on an NVidia GeForce 6800GT which works nicely, although the card cost me about half the total value of the system when I put it together. Still, this card even today retails for over $350 so it's still not cheap, despite having been around for 30 months or so.

Voice comms are built into the game - check the key bindings. Just press and hold the key down to activate your mike. When you release the key, your message is replayed to the other players on your team. Good voice communication can make or break team tactics so it's worth making sure that your microphone is working correctly. If you start a standalone game and use the voice comms, you will hear your message replayed to you, rather than your bot team mates.

Sea Cliffs and Volcanic Deposits have four times more vertices for the landscape than the "normal" DT levels. To compound that, the vertices are also closer together, so you can see roughly twice as many vertices as well. Now the Demeter engine doesn't show you all those polygons (thankfully) but it does impose a heavier burden on the graphics card.

I apologise for the lack of updates recently. I've been having some home renovation done and the house is full of dust and junk. The renovations are a prelude to a new arrival in our house sometime in the September time frame and my game playing time has been somewhat truncated as a result. I will, most definitely try and get a Crystal landscape out for people to play with soon (but I'm off on vacation soon, so don't expect immediate turn around).

I'm extremely glad to hear that there is progress. DropTeam is one of the most interesting games I've played and I look forward to seeing what ever you have in store for us.

The balance seems to be better - three Thor ICs can still take out a few Dropships but it's not the total Air Superiority package that it was I also get the impression that the bots are a little less accurate - I've seen beams slicing the air where the Dropship was, although that might be an artefact of lag? Apologies for missing Sunday's action - I was at a barbecue (poor prioritisation, I know, I know!).

There are usually between five and eight players around at 2000GMT, sometimes as many as ten. Friday nights (around midnight GMT) are also popular - I've had a number of good games with four to six players at that time.

Okay - I've dropped the resolution down to 256x256 - it's a little texelated when you have your nose pressed against the objects but it looks okay. Czech Hedgehog v1.1 (smaller textures)

I assume you are talking about DropTeam? High-power lasers would heat (superheat?) the air along the waist of the beam. That could make a noise like thunder. Similarly, the laser beam would not make a noise striking the hull of the tank, but the heat build-up would be audible as the armour expands under the onslaught. And, of course, the subsequent explosion as the IC penetrates the subsystems would be ... err ... loud.

Having harnessed the awesome power of the Ion Cannon enough times, I think we could push for some better physics on these weapons. I've been digging around looking for the underlying principles of laser beams and I came across this article on Wikipedia about Gaussian beams. Now there are a lot of scary equations on there but essentially it all boils down to this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">power/ square metre = P0 exp (-k*r*r)</pre>

I think the problem is that the Ions are simply too powerful as they stand, mainly for the reasons below. So I think the numbers of IC tanks are right but they are unbalancing right now. I'm racking my brains trying to remember whether lasers follow an inverse-square law for power/distance. I used to know this stuff :-( Something about the dispersion of the beam... Right now the bots see too much. I don't mind them firing over intervening terrain - I do that myself (hull down on a powerful tank, mark the range, back out of sight and fire slightly above the tank, maybe following up with another round a little lower). I do get narced when I get taken out by a HEAT round when dropping in a Dropship some 4k away from the enemy tank. The Ion cannon makes that far worse because it has no limit to its distance (you can be blown up from 9k away without ever realizing that you were under attack). Infantry needs serious support to get anywhere in 1.2.6. I've taken engineering squads into buildings for captures using the heavy Thor carrier and the Paladins for rides. Arriving on jetpacks is a short and painful trip... I don't mind the accuracy of the bots in general tank-to-tank. Tank to Dropship is a little extreme. I can take out enemy tanks at 4-6km range with HEAT rounds while the tank is moving but I think I've only twice taken out a Dropship at that range with HEAT rounds and that was far more luck than judgment. No projectiles should work under water, period. The expenditure of energy required to enter water is enormous - bullets and missiles would tear themselves apart almost instantly. Ion cannon should work at very short range only - they would vaporise the water along the length of the beam. Maybe 100m tops. If the beam dissipation could be given one value for air and another for water in the scenario file, that would be perfect. The only weapons that should work under water are contact explosives (i.e. mines) and torpedos. Missiles fired under water should be able to exit the water but not re-enter.

On the drive-over part, there are four stages. Normal -> Broken -> Rubble -> Bits. Bits has no collision model at all, and can be driven over. So you can force holes in the defenses. I can easily drop the resolution on the textures to something smaller. I'll try 256x256 to see whether it makes them look too texelated.

Finally, after much hacking, I've got my modelling skills (whatever they are!) to meet up with DropTeam. I've also finally corrected the name of these objects - so no more Dragon's teeth and say hello to the "Czech Hedgehog". You can grab an example Mod "Obstacles" which features lots of these Czech Hedgehogs to drop around your objectives. The new trick is that these are destroyable - each one takes about the same as a SensorStation to knock down totally. As each one gets damaged to a specific point, it will change to a more damaged model. The "Obstacles" mod containing the Czech Hedgehogs Here's an image showing the new models in a mostly pristine state ... ... and here's the state after some heavy mortar fire has done its work ...

I wondered if anyone would notice It's a devastating option on CZ5. With well-placed Thor ICs, I managed to hold the Twin Hills Objective 1138 to 28. Think about that for a little while - I lost three dropships and six tanks in that foray in 30 minutes.

A bomber, carrying large bombs which could only be dropped would be fun... especially since the mines are a deployment time only option, we've not had too many options to drop on people's head

For the record, there were two things that caused my troubles with 1.2.6. Firstly, I seemed to pick up unneeded libraries from somewhere - moving all the libraries out of Dropteam/lib and tweaking version.ini to force an update worked for that. The second part of the puzzle was the new OpenAL libraries seemed to cause problems: No ALC context was the error. Replacing the Dropteam OpenAL libraries with the standard Ubuntu ones solved that issue.

As this stands, I think it would be an interesting test for the bot AI pathfinding If I were to build a level based entirely on this sort of terrain, roads would be critical to establish reasonable routes through the landscape. I'm still toying with the algorithms too - the next thing to do is alter the size of the crystal faces according to the height of the terrain. Low lying areas should probably be fairly large and flat, with higher areas being composed of more smaller faces. Currently each face is calculated based on a smoothing algorithm over each Voronoi cell. I'm considering switching over to a best-fit plane for each face, so that it more accurately reflects the original landscape before crystallization. I may implement that and consider the effect.

I seem to remember someone asking for crystal landscapes as an idea for a scenario. Well, since I'm having technical troubles with 1.2.6 (although we are now at the "it works with no sound" stage) I've been putting my brain to use on the problem of creating crystal-style landscapes. Here's where I've got to as displayed in Geomorph.

Don't get me wrong, I really want the Dragon's Teeth in the base mod. Just be aware that the new variant (with various phases of destruction) is going to be much more fun, as waves of heavy mortar fire can now (slowly) punch holes in the lines of "Teeth". So those carefully placed teeth must be protected to keep the enemy out. I also think that the destructable "Teeth" should be far more numerous in the inventory

I have GPU Particles off. I'll send you some more data by email and we'll see if we can work this one out. Thanks!

1.2.5 was fine, but 1.2.6 has definitely triggered some problem. This problem is persistent and happens all the time, so hopefully diagnosing it won't be too insanely difficult. I've got as far as sticking a debugger into the mix. I can get the game up as far as the loading screen for a scenario - which generally gets to the "Press RETURN" prompt. Then either immediately or within a couple of seconds the process goes down (could be core-dump causing the delay). </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Loading DDS file >../data/BuildingFriendlyTexture.dds< Loading DDS file >../data/BuildingEnemyTexture.dds< Program received signal SIGSEGV, Segmentation fault. [switching to Thread 4144490688 (LWP 14423)] 0x080ff8be in std::vector<std::string, std::allocator<std::string> >::_M_fill_insert () (gdb) bt #0 0x080ff8be in std::vector<std::string, std::allocator<std::string> >::_M_fill_insert () #1 0x081e6dea in osg::TemplateArray<osg::Vec3f, (osg::Array::Type)10, 3, 5126>::TemplateArray () #2 0x082b8207 in std::vector<unsigned int, std::allocator<unsigned int> >::~vector () #3 0x082bc6b6 in std::vector<unsigned int, std::allocator<unsigned int> >::~vector () #4 0x0822b3be in std::_Rb_tree<std::string, std::pair<std::string const, std::string>, std::_Select1st<std::pair<std::string const, std::string> >, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >::find () #5 0x082261a3 in std::_Rb_tree<std::string, std::pair<std::string const, std::string>, std::_Select1st<std::pair<std::string const, std::string> >, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >::find () #6 0xf74658cc in __libc_start_main () from /chroot/lib/tls/i686/cmov/libc.so.6 #7 0x0805f441 in ?? ()</pre>

I'd hold off the Dragon's Teeth until the destroyable variant is complete. I'm mostly done with the modelling now - just the fourth phase (small pieces of rubble) remains to be completed. But I'm a bit stuck with testing these - see the 1.2.6 release thread :-(

Sadly, I'm staring at memory corruption error message right now. After a bit of fiddling (pointing the LD_LIBRARY_PATH at my 32bit libraries) and putting the DropTeam libraries first in the list of searched locations, I'm still crashing when starting a scenario. It gets through the scenario setup and crashes within a few seconds of displaying the landscape for the first time. The landscape is all messed up on screen too - large sections are missing, making it look like something from Tron. Here's the last lines from a standalone game. </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">... COB: Loading texture >../data/gs-mapBurned.dds< GUIMANAGER: Preloading objects complete Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) PROFANITYMANAGER: Loading ../data/Profanity.xml GUIMANAGER: STATUS MSG: Nexus6a has joined the Water team Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,)</pre>

Yes, it did! For the curious, here's what I did. To test it out, I copied UrbanHouse3.physicalobjectgroup to my own mod directory(Nexus6Playground), renamed it UrbanMorph.physicalobjectgroup and then altered the RubbleObjectFilename to point at UrbanHouse.physicalobjectgroup. Oh - and then made UrbanMorph a deployable object by adding the following item to Inventory.xml. </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> <Item> <Name>MorphHouse</Name> <ImageFilename>PanelMines.png</ImageFilename> <ObjectFilename>UrbanMorph.physicalobjectgroup</ObjectFilename> <Limit>64</Limit> <Firepower>1</Firepower> <Armor>3</Armor> <Speed>0</Speed> <CommanderOnly>true</CommanderOnly> <PrimaryWeapon>NA</PrimaryWeapon> <Role>Area Denial</Role> <FullyAutomated>true</FullyAutomated> <IsPodDelivered>true</IsPodDelivered> </Item> </pre>

I care! Seriously, licensing does matter. The Nexus6-LICENSE is a community-orientated license which allows commercial use too - so Clay et al can pick up the bits they like and add it to the product, while we can continue to tinker with the efforts of the modders here. I would encourage anyone contributing anything to DropTeam to consider licensing their work under this license (or a similar AND compatible one).