ClaytoniousRex

The official DropTeam wiki is here. It is an effort pioneered by Poesel, strongly supported by the SquidLord, and hopefully soon to be supported by many others. Please visit the wiki and add anything you can that will help others be less confused than you once were.

Well, stuttering like that isn't normal so hopefully there's some way we can address this. The first thing we have to do in order to fix it is identify the cause of the problem. I'm guessing that pathfinding by the bots is what's eating you. If you're willing to test this hypothesis, then you can dance this little jig: 1. Do your normal 10 vs 9 game setup 2. Get a good few minutes into the game so lots of fighting (and stuttering) is going on 3. Order ALL of your bots to stop (give them all the STOP command) 4. Switch teams and order all of the other team's bots to STOP (A quick way to make them all stop is to window select them all and hit ALT-S). Continue driving around and fighting yourself and see if the stuttering has gone away. Keep giving stop orders to the bots if they get destroyed and drop again with new orders. If you have a good couple of minutes of stutter-free play, then we can probably say it is the pathfinding (and yes, we can probably do something about that). If not, then it's something else and we can dance another jig to test another hypothesis until we find it. Has this stuttering been present in all releases or is it new in 1.1.3 (or 1.1.2)?

It's uploading now. ETA: 45 minutes.

You might try the other forum that's simply called "DropTeam".

I'm a big fan of clean, open maps like this one. The road is nicely done and it's fun to start seeing some Territory maps. If it's OK with you, it would be nice to put this into rotation with the 1.1.4 release. We're finally able to rotate Territory and Objective maps together on the server so it will be fun to start playing some Territory games like this one online. The only small cleanups I can see that might be nice on this one are a little more flesh to the 2 bases. Maybe flattened, slightly improved ground and some more buildings for each one? Very well done!

You can get it here. You need to have the Dot Net Framework 1.1 installed for this to run. There are 6 steps to using this tool: </font> Simplify your model to only those faces that are supposed to count for penetration. For example, if you have unimportant flair elements on the model like the rim of a hatch sticking out or an antenna, etc., remove those from your model. You want the "core" shape that actually counts for this. Maybe there's nothing to do here - just depends on the model.</font>Flatten any transforms that you can. Don't risk confusing the utility with scaling and rotations - just flatten everything to identity in your model. If you're unsure how to achieve this with your modelling program, one sure-fire way to do it is to first save your model out to a very simple format which doesn't support any transforms such as .dxf, then load it back in. Now all transforms are definitely gone!</font>Mark every polygon in the model as either front, left, right, top, bottom, or rear. You do this by assigning a texture named Front to those faces that should count as front armor (it can be any format - Front.bmp, Front.png, Front.jpg, etc.). Ditto for Left, Right, Top, Bottom, and Rear. An easy way to do this is to assign your Front texture to the whole model and then go in and paint those faces that are something else. This way there's no risk of forgetting to include any faces (and it saves some work).</font>Save an ASCII version of your cob file. I don't know if Blender supports this or not so let me know if not.</font>Run CobDump and point it at your ASCII cob file.</font>It will create an output file with the same filename as your input file but with a new extension of ".out". This new file is the XML for the collision triangles. Paste them into your unit's .physicalobjectgroup file. This is a dumpy little tool (no pun intended). For some time we've been looking at allowing you to simply specify a model (.obj, .cob) etc. in your .physicalobjectgroup instead of listing out collision triangles. So, for example, you could just make a copy of your actual model, remove any "extra" fluff, paint the faces as front, rear, etc., and then in your .physicalobjectgroup just refer to that model. DropTeam would load the collision triangles literally from this model. For example, if you have MjolnirChassis.obj, you could create MjolnirCollision.obj with its faces painted, and in your .physicalobjectgroup you would only need to say: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><CollisionModel>MjolnirCollision.obj</CollisionModel></pre>

No, sorry Yurch, we couldn't fit anything more in for testing even though it was already implemented. Definitely in place for 1.1.4, though and seems to work fine.

Does this happen with 0 bots on each team, even without your own unit on the ground? Or does this only start happening once there are some units moving around and combat begins?

Yes, there are new tags for allowing squads to embark into things like buildings. The new tag is called CrewSlot (you can see examples of it in things like GovernmentBuilding.physicalobjectgroup), You just list some number of these and when a squad occupies the object, the squad members will go into these "slots" until they're all full. You should have the same number of these slots as your PassengerCapacity tag specifies as the max number of passengers.

There is are 2 new optinal tags which are children of the GameType tag: Team0NumDropships and Team1NumDropships. So, for example you could do this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><GameType> <GameTypeName>Objective</GameTypeName> <Team0DeploymentRadius>30000.0</Team0DeploymentRadius> <Team1DeploymentRadius>0.0</Team1DeploymentRadius> <Team0NumDropships>10</Team0NumDropships> <Team1NumDropships>10</Team1NumDropships> <Team0InitialScore>1000</Team0InitialScore> . . .</pre>

A farm of mortar turrets (just plop the one from the Hurricane onto the turrets) ... now that would make an impressive show.

Heck, yes - can't believe we didn't even think to do that. I just posted a new topic in the Mod forum about the new tag in 1.1.3 and will try to post there with such changes for each release. That's deliberate. Not yet. When we hook it up, it will be the exact inverse of the current deployment. You will get a message that retreat is underway and will lose control of your unit for the required delay time before it finally disappears. Yes. Give them drop orders inside of a deployment zone. Or, if you don't want them to deploy at all for the moment, then select each bot's account on the tac display and uncheck the "Allowed to Drop" checkbox. This will make them not drop anything until you tell them to.

There's now a new tag that's a child of the GameType tag. It's called DeploymentZone. Here's an example: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><DeploymentZone> <TeamID>1</TeamID> <MinPosition>0,9240,0</MinPosition> <MaxPosition>5000,10240,0</MaxPosition> </DeploymentZone></pre>

One thing you're probably noticing quite often is part of the improved fire discipline of bots since 1.1.2. If a shot has almost no chance of penetrating the target, then bots won't take the shot. This is quite often the case with those 76mm AT turrets. They will point at an enemy unit and then track it without firing - they are waiting for a look at the rear armor or something soft enough for their 76 to penetrate before they will fire. This might be why you saw them finally start shooting when there was an Apollo to shoot at? For example, if you quickly mod up a 120mm turret, you should see those firing a lot more often. Ditto for an ion beam turret.

Roger, Dark. Alex, Yurch is talking about the minimap in the upper right corner of the screen. You can also CTRL left click anywhere on the 3D terrain itself to move the camera to that spot. Running in a window!? Stop it!

You're seeing these left over shadows on the tac display, Dark?

Yurch is right, putting other turrets and weapons systems on them is now trivial. They finally work like everything else. All of the weapons will work as they should, too. The turrets are actually full- blown bots now. Yes, we're definitely interested in allowing you to take control of them, and it is already working here in testing. Barring unforseen problems, this will be in the next release. Yurch, the turrets should definitely be firing at jammed units already in 1.1.3, though if they're not facing the jammed unit then a little time might pass before they "notice" it and engage it. This should only be on the order of 10 to 15 seconds in bad cases, and more typically much less than this. Doesn't seem to be working?

Those animation tags correspond to the various states the vehicle is in at any one time just as you said, such as idling, driving, etc. They do 2 useful things: </font> Make the model animate (but as you can see none of the current set of vehicles makes use of this one) - this could be used to make pieces of the vehicle move when driving, for example, or make a little radar attachment spin around, or whatever kind of mesh animation you wanted</font>Make the vehicle emit sound - so you can have a high rev sound for moving and an idling engine sound for the "idle" animation, etc.</font> The AnimationID specifies which state this animation corresponds to. It's an integer that specified one of these states: LOITER - 0 MOVE - 1 AIM - 2 SHOOT - 3 DIE - 4 BURN - 5 EXPLODE - 6 MOVE FAST - 7 MOVE SHOOT - 8 MOVE FAST SHOOT - 9 You would generally only want to use the few that see being used in the existing vehicles. The BaseModelName tag specifies a series of models that are to be used as an animation when in this state. Whatever you specify for this tag, DropTeam will go out and attempt to load that name with a 0.cob after it, then with a 1.cob after it, etc. until it stops finding matches. So, for example, if you had a 30 frame animation of a tank flapping its wings (?), then you might have these model files: MjolnirChassisFlap0.cob MjolnirChassisFlap1.cob MjolnirChassisFlap2.cob . . . MjolnirChassisFlap29.cob Then at runtime, those 30 different meshes would be swapped in for the original mesh at the rate specified in your animation's TotalTime tag to make an animation. I think the problem you're running into is that it's always looking for .cob files for these frames of animation. You have .obj, so it's not working. So there are only 2 ways to proceed. Either you convert your models to cob (or send them to me and let me try), or you wait for a code fix that makes the loader smart enough to look for .obj if the original model was .obj. Which do you prefer?

Another option for your Mjolnir would be to go ahead and give it Thor-like armor thickness in addition to its already excellent sloping, an ion beam for the coaxial, heck, even an AutomatedGun for point defense on the turret or chassis. In short, go ahead and make it Bad to the Bone. Then copy a few of your favorite scenarios (DeadGulch, Raid, whatever) and rename them DeadGulch-Mjolnir, Raid-Mjolnir, etc. Then set the team inventories in your new scenarios so that one team has only 6 or 10 of these fearsome Mjolnir's and nothing else. The other team has our usual full inventory that we're all used to. Could make for an interesting new asymmetric game?

Right now.

...is now available via Update. You should be prompted to update automatically the next time you run DropTeam. Important: If you were not already up to version 1.1.0 and had customized controls then you need to go BACK to the default keyboard or default joystick controls and recustomize your control set with this release. If you don't do this then many new commands from the 1.1.0 release won't work for you. Some of these are discussed at more length in their own forum topics to explain how/why they work. Fixes in 1.1.3: </font> Infantry can now occupy buildings and fire from within.</font>The inventory of Dropships for each team is now limited (can be changed per scenario)</font>Teams can deploy via Deployment Zones instead of Dropships. These zones are shown as dashed boxes on the Tac Display. Just click your drop location inside of one of them in order to deploy this way instead of using a Dropship.</font>Dropships now fly evasively.</font>Infantry and deployable items are now delivered via disposable drop pods instead of Dropships</font>The Galaxy cannot fire its point defenses until it has landed</font>Smarmy "plasma turrets" have been completely replaced with real objects that work like everything else - they have a chassis, turrets and proper weapons (76mm for the AT turret and Cobra missile launcher for the AA turret) - it's now very easy to Mod new kinds of turrets</font>Internal components for all vehicles have been properly grown to fill much of the empty space within.</font>AP rounds are now able to properly overpenetrate through subobjects of a target. For example, a tire will no longer stop a large AP round from also going through and hitting the chassis.</font>Fixed occasional "invisible" enemy vehicles when they are upside down and burning</font>Fix bot failure to notice jammed threats</font>Included Yurch's improved dots for minimap and counterbattery indicators</font>Scenario authors can now turn off Galaxy support for a scenario</font>Fixed craters appearing on network client when they're not actually there</font>Fixed extracting dropships hovering forever above water if the target unit is underwater</font>Fixed destroyed units being returned to inventory when extracted</font>Slug Fest victory condition fixed</font>Fixed server crash when infantry embarked Paladins</font>Fixed rare crash if empty voice chat packets were sent</font>Allow Gunner and Ammo components in vehicle chassis. If present in both chassis and turret then both must be functional to count as working</font>Fixed Archipelago bridge entrances</font>Network clients must now have the same Mod selected as the server they join</font>Thor now carries more ammo</font>Infantry can reload ammo at drop pods</font>

It's still mostly vertical. They go subsonic at a random horizontal offset from the DZ (so it's not always toward a map edge or anything else).

Yes, other rounds that penetrate the building have a small chance of damaging infantry within, but it's miniscule compared with HE. It almost is - infantry inside of hard cover vs. infantry out in the open - sucks to be the latter. If you're assaulting an occupied building with infantry (you already know what I'm going to say because I say it all the time), then you should coordinate with a team mate who can fling some HE at the building. HE hits onto occupied buildings do still stun the infantry inside so you can use those brief periods of suppression to advance closer to your goal. Unfortunately, not yet. Yes, it is still that way. Right now we're playing with waiting for the entire squad to form up close to the entrance before allowing them to embark. Most of the buildings only allow a single squad inside. Some of the larger ones allow 2 squads, but they have to be on the same team.

The next scenario would start with the inventory still left as it was at the end of the last scenario. That's what I meant in that first bullet item in the list above. That's the main thing you wanted to keep from one scenario to the next, right? Are you also thinking of things like buildings that were destroyed previously are still destroyed, or other dynamic things like that?

Should have also mentioned this, in relation to the 2nd point above: Since dropships now follow an erratic, evasive path, it's no longer safe to choose a drop location just outside of the radius of enemy air defense. If you do this, there's a significant chance of wandering into the enemy air defense radius. To be safe, give enemy AA an even wider berth than its radius.