ClaytoniousRex

Try deleting DropTeamSettings.dat from your home directory. This will make it start with new, default settings. If you're on Windows, your home directory is probably \Documents and Settings\Jack (or whatever your username is). If that still doesn't do it, then send me your DropTeam.log - it should show us what's happening.

You can do that right now by dropping .ogg files into the Music subdirectory. DropTeam will play them on a random shuffle as background music. Some more personal opinions about what makes good DT music here.

We have this set of models laying around that we licensed quite a while back but haven't yet had the chance to use in scenarios: These might help with your urban scenario for the campaign. All models in that picture are included, even the pipelines, wall sections, power towers, chemical tanks, and various small things like rubble and trash piles that you can't really see in this screenshot. I'd be very happy to make .physicalobjectgroups out of these for you guys if you would like to put the to use in your new campaign.

Drago, can you please send the file called DropTeam.log from your \bin directory to support@tbgsoftware.com? Thanks!

Risasi, if the requirement to have an internet connection for network login is standing in the way of a bunch of honest players' attempts to play, then let us know. As tanki says, we can rig something up for you so that you can play.

What you're not seeing with those mortar shells is the penetration of the fragmentation from the blast, which is very high close to the blast but falls off exponentially with distance from the blast. Those low penetration values for artillery only apply to the round itself doing its own kinetic penetration. The effects of the warhead's detonation aren't related to those base penetration values of 100 at all. The light, medium, and heavy mortars (as well as fire mission rounds, etc.) all have very different characteristics for their fragmentation. Their fragmentation is their primary means of dealing damage, not the direct impact of the round itself. Poesel, I'll try to think of some way to convey their effects to you so you can model it on your chart. And BTW, that script turned out wonderfully! Congrats, Poesel - very nice!

The next update will be ready very soon. It is 100% geared toward fixing lag and client-side performance problems; all new features are being held back for this update. It also includes a couple of smaller fixes such as effective brakes for wheeled vehicles. Yes, there were some major disruptions here due to other projects (some DT related, some not) and personal things such as the move that Iceman mentioned, but we're just about back on track now. I'm glad someone else hears them, too. I thought I was going crazy! Bnej, you're right about the importance of single player and about DropTeam's single player being so very far behind its multiplayer. One of the things that we've been working on for a few weeks now is a complete rewrite of the AI system in DropTeam. This is a major undertaking but is obviously important enough to warrant the time and effort involved. It's required not only to make single player DropTeam as fun as it always should have been, but also to make the WW2 version realistic enough to be fun.

That message means that your video drivers are out of date. Tell us what kind of video card you have and we'll point you to a URL where you can go to get current drivers. Those supplied by Windows Update are *not* the most current drivers (you need to go to your video card vendor's website).

Be sure to send your product key in that email, 8ball.

It could be that He really does love marines, Imperial Grunt! But more likely it's as Toby said. Looking into it...

The new demo starts out at version 0.9.98 out of the box. If you're at version 0.9.94, then you have downloaded the old demo from last year instead of the new one. The old one does not update to the new one. You need to download the new demo from one of the links on the DropTeam Demo Page. Sorry to force a new download like that, but the old demo was simply too far out of date to do a proper update to the new one. It looks like many of the mirrors are still hosting the old demo under a name like "Multiplayer demo" or something like that. That one is obsolete. You want the one called "Final Demo" if they have an option (depends on the mirror).

This is definitely corrupt data. A new download is the best fix.

Hawk, do you mean you are double clicking the installer and getting this problem, or you are double clicking DropTeam after installation and getting this problem?

Email your product key to support@tbgsoftware.com.

The HoverChassis is probably never going to work well for an air unit, not because it's badly designed but simply because it's the wrong tool for the job. The HoverChassis models a set of 4 "jets" that interact with the terrain underneath the chassis. Think of fans creating thrust through ground-effect. As any one of the "fans" gets closer to the ground, it generates more upward thrust. So the whole basis of the HoverChassis is interaction with the terrain beneath - like a ship on water. For an air unit, you would have to hover very high above the terrain. If you make the jets react with the ground at great distances then your chassis will become unstable. Imagine trying to balance on long columns on thrust that extend hundreds of meters down to the ground. It's very hard not to tip over. You could move the columns of thrust farther apart, which is what you did with the thruster spacing tags, but then you have columns of thrust that are hundreds of meters to either side of the chassis. This means they will interact with objects and terrain "out there" away from the chassis, leading to strange behavior. So I think the only way to get good results with the creation of an air unit is to treat it as an air unit, not a hover unit. That means the AirshipChassis, of which the Viper is one example, is your best bet. I understand that you want an air unit that's easier to control and easier to fly NOE than the Viper. Now *this* is a deficiency of design - the Viper is simply too hard to control as it is now. So for your new air unit, you should probably use the AirshipChassis (like the Viper), and lay out for us developers exactly what you would like to see fixed or added so that it is easier to control. This means that for a while you will be stuck with the code as-is while developing your new unit, but over time we should be able to implement code improvements based on your feedback that make your new unit behave the way you want it to.

This editor is for DropTeam, not for TacOps. Are you still interested in getting it working?

Now we have contacts and collision boxes. The last step was to position the turret and gun to form a complete vehicle. The turret that Poesel originally created looked like this: Notice that it is floating up in the air above the x-y plane. This is because Poesel had saved the turret model already in position for where it should be mounted on the ApolloN's chassis. This is a bad plan! All models should be positioned at their own origin. So for the ApolloN's turret, I moved the turret down onto the x-y plane and centered what should be its rotation point at the world origin, like this: This needs to be done because each object exists in the world as its own entity with its own position. If the turret were already hanging up in the air, what would it mean if you tried to position it at a certain point in the world? Or to look at it another way, consider what would happen when you mount this turret on a completely different chassis? Would it make sense for it to somehow have to already be in the correct position for both the ApolloN and for that other new chassis? Now that the turret is sitting at its origin, we again use the 3D modeller to position it. We load up the ApolloN chassis along with the turret and then visually place the turret where it belongs: Again, we simply read this position from the modelling program and type it into the Origin and Anchor tags for the turret in the XML file. Then we do the same thing for the gun: And with that, we now have everything we need to go for a spin: Soon, I'll hookup the collision triangles and armor mappings and post that here, too. [ December 11, 2006, 12:15 AM: Message edited by: ClaytoniousRex ]

Poesel asked for some help getting his new Apollo-N chassis into the game. This post lays out the process that I followed to make it a working unit, so this might be helpful to those of you creating new objects. Poesel had already figured many things out: </font> Modelling the new chassis and turret in a 3D modeller and exporting them to the OBJ format (I think he used Sketchup and Blender). As you can see in this example, he still needs to texture his new models (they are just solid colors representing armor values at the moment). For help with texturing with Blender, you can start with Toby's post in this thread. Some tips on OBJ export are in threads like this one. General help on creating models for a new unit are on the wiki. DropTeam aside, creating realtime 3D models with textures is a substantial skill set that takes time to develop. Teamwork is a good idea here. </font>The basics of creating a .physicalobjectgroup file for his new unit (specifying that his new models for the chassis and turret be used, etc.) Search this forum and see the wiki for a start on this.</font> The main things he was having a problem with were: </font> Contacts (see this thread and this one )</font>Collision Elements (see this thread and this thread and the wiki.</font>Object origins and positioning</font>Armor mapping</font> This walk-through shows the process I used to address these remaining issues with the Apollo-N (but I haven't done armor mapping yet - will do that shortly and post). This is only the way I do it - creative folks here will doubtless have better ways of doing some or all of this. First, the contacts. For this, as for most things, I simply use the 3D modeller itself to lay these out visually and then read off their locations and type those into the XML for the .physicalobjectgroup. Here's how I layed out the contacts for the tracks on the Apollo N: Those are simply small red cubes that I positioned with the 3D modeller (in this case, I was using Truespace but whatever package you're comfortable with is fine). Just use whatever your modeller's interface is for positioning objects and place them at the locations for the contacts for the tracks. Here's a tip: take advantage of symmetry to only position those for one of the tracks, then mirror them all to the other side. Now that the contacts are visually laid out on the model, I simply select each one and read its coordinates, then type those into the XML file for each Contact tag. Now that the tracks are finished, we can do the rest of the contacts (for the remainder of the chassis). We do the rest of these together because there's nothing special about them. The LeftTrack and RightTrack contacts actually had meaning but the rest of these are simply points on the chassis. We lay them out and type them in just as we did with the tracks, but this time we use "Hull" as the names of the contacts. That takes care of the contacts. Now we need to create CollisionBoxes. Again, we just use the 3D modeller itself. Create some cubes and scale them into a configuration that covers the volume of the chassis, like so: The goal is to use as few boxes as possible but still cover a good approximate shape of the underyling object. Here's another view with the chassis itself removed so you can see just the boxes: Notice that it's OK for the boxes to be a rough approximation of the underlying shape. The more detailed collision triangles will be used for accurate collisions when needed. Also, notice that the left and right tracks each have their own collision boxes. This is is required for tracked vehicles, as explained in the thread linked to above. Continued in next post...

To enter a building you just have to move close to one of its entrances and stop moving. The entire squad is then "sucked into it", much to ImperialGrunt's chagrin. He has rightly pointed out that needing to explicitly press a key to enter would be better since you are sometimes accidentally sucked into a building while sneaking close to them. The B key exits the building, but entering is automatic.

I wish you had, too. But just having the "holy moly" at the bottom is priceless.

You can only give extract/scuttle orders when one of the selected units is an automated item such as a turret. So, for example, if you have window selected a large group, and a turret is one of the items in the group, then you would see most of the commands on the command menu grayed out (because the turret can't accept most of them). So if you want to commands like move, for example, make sure you are selecting only objects that can move when making your selection.

Run Start/Programs/Battlefront/DropTeam/Game Updater. After you do this for the first update, future updates will happen from within the game without needing to run this external updater.

Managed to stick a couple of ATG's up Phantom's tailpipe tonight, so naturally I had to share. Video below. As always, download it to view it, don't try to stream it (and DivX is required): Video

We all hope daylight brings good news, Iceman. The main thing is that you and your family are OK! Keep us posted when day breaks...

We're bringing up another server on the west coast now. It's at an excellent data center so, depending on your location, it should offer less lag for many of us.