ClaytoniousRex

The Location tag is a 3D vector so the 3 components in there are the x, y, and z location of the object. The x and y axes are the ground plane and the z axis is elevation. If you place a building without the optional PlaceOnGround tag then the z component of the coordinate will be ignored and the building will be placed at the elevation of the terrain of the corresponding x,y point automatically. The facing tag is the only one that controls the object's orientation. It is completely independent of the Location tag.

The problem is, indeed, that both of you are using the same account. We are going to allow 2 registrations per product key as discussed here but we have not yet made this change to our account server. In the meantime, until we do make that change, we can give you a 2nd account to use. Send me an email with your product key, current username, and the username and password you want for your 2nd account and I will set it up for you.

Hub has created a new mod called "Light Weights". You can get it here. He's also created a Paladin variant called the Paladin FSV: which you can get here.

Konstantine, if you're losing with a 76 vs. a 20 then there's only one answer: YOU'RE TOO CLOSE. You're fighting within HIS weapon's optimal range. Force the fight back out into YOURS. At medium range his shots won't be able to penetrate but you can keep punching holes in him.

The fundamental problem here is the display technology for the computers we're playing on, Monk. If we all had display resolutions that were an order of magnitude higher than what they are right now then we wouldn't have to do things like this. As it is right now, looking at a distance of several kilometers the human eye is able to distinguish the shapes of things like armored vehicles but on our low-res computer displays such an object is smaller than a single pixel so you can't see it. Therefore, objects in simulations like DropTeam are modelled at an increased scale just so that you can have engagements at realistic ranges. This extra scaling is a good thing because it makes distant objects visible as they should be, but for small objects such as infantry it gives an unfair advantage to the observer. The only tactic available to infantry when fighting AFV's is to remain unseen until that climactic moment when you're close enough (or in the right position with longer ranged weapons) to expose yourself by firing on the AFV. If we allowed observers to see the infantry at a longer range than they really would be able to see them then this advantage would be negated and infantry would be nearly useless. All we're doing is making things visible at the actual range that they should be visible. There's nothing incorrect about that. Working on it. It's purely a matter of artistic resources to throw at the problem. It will be there eventually. DropTeam's AT grenades have an effective range of 300 meters (this is the max distance the AI will attempt to use them at). They can actually fly farther than that depending on the scenario's gravity, but hitting anything would be very difficult. Yes, that's a great idea for another squad type. Yes, I hope to see this not only for infantry but also for the command track to designate targets for really large orbital weapons, too.

You can also do this to go straight into the scenario without fussing with the lobby. First, edit ScenarioList.dat in your \data directory so that your new scenario is at the top of the list. Then run this from the command line in the \bin directory (assuming Windows) </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">DropTeamP4Release.exe -enterlobby false -hostmode standalone -cachetextures false</pre>

mp3 is patented. To legally release any commercial software that decodes mp3 you are supposed to license the mp3 technology. Plenty of software out there breaks the law in this respect and every once in a while they get sued, but only if they dare to actually make enough money to be noticed. Anyway, the chance of getting caught isn't the issue for us as much as the principle. So we use ogg instead, which is full featured and complete free (free in the IP sense, not just as in free beer) as explained here. Yes, there are free converters out there and even lots of commercial ones with 15-day free trial periods, etc. I don't remember the name of the one I finally used because I only used it one time to convert my entire library over.

The "detail textures" option I was talking about makes the terrain stop rendering its detail textures - so the terrain rendering goes from 3 or 4 passes to just one. This one change alone might get you up and running at a decent rate on that Intel chip. I'll see if we can make it an option once again (even if only on the command line). I'm pretty sure we can.

It certainly is. You really have to think about what you're asking that machine to do. You can't physically *feel* with your stomach and head the awful events beginning to take place like you can in a real vehicle, and you are NOT driving grandma's Buick on a nice, smooth interstate. You're exactly right, Poesel. Has anyone tried driving with joystick(s) or, better yet, those funny driving rigs? [ July 14, 2006, 11:44 PM: Message edited by: ClaytoniousRex ]

We had to fire the forward and turning QA guys due to budget constraints here at TBG Software. I think you'll find that all of this track foolishness is unique to network play. In standalone the tracks should be correctly simulated - not only fixing the "backwards" problems but also correctly showing the actual speed of each track (instead of simply locking one or the other). In addition to the tracks being animated backwards (which is now fixed for the upcoming 1.1.0 release), in order to save precious bandwidth, your network client is actually trying to figure out what the tracks are doing based on how the vehicle's orientation is changing. The server (which does the real physics) knows what the tracks are really doing - the client, on the other hand, is making a lot of guesses. That's why you see one or the other track locked in a turn. Try it out in standalone to see the difference.

It's glorious imagery. When DropTeam was still in alpha, dropships used to appear a few kilometers out from the edge of the map and fly into the drop zone, nap of earth. They would kick up boiling clouds of dust as they skimmed over the hilltops, doing a pretty decent job of staying just a few meters above the ground (there was the occasional catastrophic collision with a tree that we never bothered to fix). It was usually much harder to see the enemy coming or to know exactly where he was going to drop... ... but it took about 2 minutes to drop from the time your dropship first arrived. I basically couldn't get anyone to play with me. "Uh - I hit that drop thingy but I still don't see my guy. I'm going to get a coffee..." Sonic booms with massive contrails and vapor emissions, however, is undeniably a wonderful (and best of all, *doable*) idea. In addition to improved effects, I've been thinking for some time that drops need to take longer than they currently do. It shouldn't be as bad as the 2+ minutes that I described above, but it should be less accurate as Yurch has requested in other threads, and dropships should take longer to enter the scenario than they currently do. It is simply too easy to drop with rapid, pinpoint accuracy right now.

That's hilarious, konstantine! It's always the Aussies. The first guy in the private beta who bothered to get his headset working was Mace. He lives down there where the blood goes to your head, too. Almost everyone else quickly followed suit. Once you see (hear?) it in action you quickly realize how essential it is.

It's always been Mechwarrior 2 for me. Never liked the game much but the soundtrack was great. Good to see that in your list, Jalinth! For those less fortunate than Jalinth who don't have a separate laptop for playing their music, DropTeam will shuffle and play any music that you drop into the \sound\Music folder (must be in .ogg format)...

Now that the 1.1.0 (infantry!) release is nearly complete, we can finally cleanup these scoring issues. I completely agree that points for kills should be tallied based on damage caused to the enemy instead of simply by the "final killing shot". This would not only take care of scuttles but also "assisted" kills, etc. If we had just listened to Rune it would have been this way from the start... We will also look at cleaning up turret/mine scoring at the same time.

Remo, do you other servers besides the demo server or is your list completely empty?

Mmmmm. I will have to think about what else we could turn off. We used to allow you to turn off detail textures on the terrain. Maybe we can bring that option back.

Here is the other thread. It's now sticky.

Are you at < 5 fps as a network client or only in standalone? Playing on the network requires a lot less CPU.

Hi, Tylinol. We do most of our work in Calagari Truespace which is why you see .cob model files used so much in the game. However, our engine is capable of reading a variety of other model formats including .x, .3ds, .obj, .lwo, etc. so getting models out of Blender and into DropTeam shouldn't be very difficult. That's very exciting! If you need any kind of help please feel free to say so and we'll do what we can to support your effort. First class support for Blender would definitely be a boon to the mod community since Blender is free. They're read directly from the model itself not from anything external. So, just make your textures look good in Blender and they will look the same way in the game. The animation support that you see in the .physicalobjectgroup files is a way of animating in the old, original Quake 1 style: a series of static meshes that are replaced at each "frame" of the animation. This is OK for very basic things but in your case, for making walking mechs, there's something much better now. As of the 1.1.0 release which includes infantry, DropTeam now supports real bones and skinning. So you can rig a character, animate its skeleton using IK or motion capture, and export that animation into DropTeam. DropTeam will do real animation of the skeleton and realtime skinning for the mesh. This is definitely the way you will want to implement your mechs but you will need to wait for the 1.1.0 release in order to try it (which is hopefully only a few days away!) So in the meantime, you might want to start getting your mechs rigged as characters with bones and skin and animate them so that when you have 1.1.0 you can immediately start exporting into DropTeam.

Yes, that's right. Put your username and password into the fields and then go over to the "Network" tab and join a game. You don't need to register a new account each time. There is no "Login" button.

Email me with your product key and username and I'll check your account and, if necessary, reset your password.

If you're on a 32-bit system then install libslang, or alternatively you can throw it into DropTeam's lib directory yourself as described here.

We're open to specific suggestions on tools you would like to see. Exactly the kind of thing that needs to be tweaked for such a mod. For example, I was thinking along the lines of only allowing waypoints to be placed during the deployment phase (this would also apply to the new commander visuals). This is the planning and marking of maps before the battle. Once deployment ends they can't be changed. Only players in vehicles with radios or who are physically close to other players are allowed to chat (voice or typing) once play begins. We're always looking for your input! It's still an open question as to whether a mod like this is a community effort or something done entirely by us. We're willing to make the required changes to the game engine either way.

Email me for a direct link, adz.

Great post, Jalinth. Yurch also posted some an excellent tactics guide a while back here.