ClaytoniousRex

Hi, kj. See a few posts down in this thread. There are direct links for the libs you need in that thread (you can drop them into the lib subdir of DropTeam).

Classification is used primarily by the bots so they know the difference between HE, HEAT, and AP (so they can choose the right one for their target). Do you mean ExplodeFactor inside of InternalComponent?

In the meantime, you can use a model that is a single triangle that is 0.0000001 meters in size. Can't wait to try it, Poesel!

Yes, send a chat message that looks like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">/showfps true</pre>

Correct! Sorry to make it so difficult!

Good to see you again, Caseck! Almost all of your comments line up with what LtCol West is requesting, too. We're in crunch mode here so my posting time is a little limited these days, but yes, yes, yes to another list of good ideas. Please keep them coming whenever you have time. Stay safe, Caseck!

Adz, that is a very well thought out, detailed post. I think you're right on target. The only thing I would avoid is forcing dropships from the pool to fly NOE from the map edge (and fail if that's not possible). They could just as easily climb to high altitude and then scream down into the local battle area. But the much bigger idea that you've outlined - a proper pool of local forces vs. those at longer reach from the Liveship - is excellent. There's probably no need to ever explicitly drop directly from the Liveship; the local pool should simply continually refill itself according to the Liveship's station up to whatever limit is specified by the scenario author. So rather than dropping a Thor from the Liveship and wait 5 minutes, you just wait (or more likely do something else useful) for 5 minutes until the next available Thor has been brought down from the Liveship into the local pool. Then you can drop it normally. The next step is to start breaking this down into smaller pieces which can be released individually. We'll post more about that as the pieces emerge. There's no doubt that crash pods sound like fun (and just are a cool idea in their own right) but there are some serious gameplay implications there. Giving anyone free reign to drop instantly, anywhere, would wreck any hope of having a tactical engagement. If air defense were still effective against them, then they wouldn't cause a serious problem.

Well, 120mm HE doesn't seem useless at all to me, but this sounds like fun anyway so I'm trying it out.

Put <NumDropshipsTeam0>0</NumDropshipsTeam0> and <NumDropshipsTeam1>0</NumDropshipsTeam1> into all of the .scenario files and fire up your server! I'll play. Also, it's quite a simple thing to make the objective "mutual" like that. I would be happy to hookup a scenario or 2 for you in this way. Do you want to pick a few and then run them for a while?

Right, you would have to include another object inside. At the moment, it does not do "inner" and "outer" but I don't think the hit would be too bad. As for the rest, yes those are all true. You might really want a properly implemented ForceField object type to make all of this really work instead of hacking it in with a "normal" object. Visual feedback would be really important. Sure, it's just a question of polygon count. If you want poor yllamana to be able to play, then you have to keep that count low. For collision detection, you can use CollisionSphere instead of CollisionBox. There are some examples in the power storage building I think.

Thanks, Gordon!

Contacts are what's used for collision detection with the terrain. The boxes and triangles are used for objects colliding with objects, but contacts are used for objects colliding with terrain. Each of these is a 3D point in the local coordinate frame of your model. That point can collide with the ground. So you want to create just enough of these to describe the rough shape of your vehicle. Unlike collision boxes and triangles, this can be a really rough shape. A contact without a name is just a point that can touch the ground. Some of them have special names that give them more meaning, though. At the moment this includes LeftTrack and RightTrack. When contacts with these names touch the ground, they actually move across the ground at the vehicle's track speed. In other words, these are the points on your tracks for a tracked vehicle. These are what make a tracked vehicle actually move.

That's right Poesel, no need to muck with any images when using CollisionModels. The images were only needed to specify which triangles are front, left, etc. Your CollisionModels already do that explicitly.

The manual patch is now ready. Email me with either your product key or your username/password and I'll send you a link to download it.

Hi, Raynor. Can you please email the file called DropTeam.log from the \bin subdirectory to me? Also, how are you starting DropTeam?

Yes, we have a manual patch for Windows users with similar problems on the FTP site. We'll prepare one for Mac and let you know where to get it.

1) Yes, but only on another object. Once the armor is penetated on an object, subsequent concave shapes that cause interior armor will be ignored. But all is not lost - see below. 2) Yes. Your collision models (or explicit collision triangles) need not have anything to do with the actual model that's visible to the user. So to implement your force field, you would need to make a new object which is a child of the chassis. You could use something benign like a Gun - doesn't matter. Make it a sphere (or whatever shape your force field should be) that surrounds the chassis. Mount it with a hinge joint with HiStop and LoStop set to 0.0 so it can't move. Give it whatever armor values it needs and voila, you have a force field. Projectiles which penetrate the "force field" will now continue through to hit other objects (such as the chassis, turret, gun, etc.) if those projectiles have enough penetrating power to punch through the force field. They will hit other objects with reduced penetrating power after having passed through the force field object, just as they do after going through, for example, a tire and into the chassis.

Sorry for the slow replies lately, gents. You can delete the CollisionTriangles because you're using CollisionModels instead. You only use one or the other; they're two different ways of specifying the set of collision triangles for the model. You do need CollisionBoxes, though. This is a set of boxes that roughly describe the volume and shape of your object. The boxes are used for coarse collision detection, while the triangles are used for fine-grained collision detection. They both need to be correct for your new vehicle to work properly. You can use as many boxes as you need, and you can use the <Angle> tag to have rotated boxes if you need them (see the crashed starship wreck for an extreme example). The idea is use as few as possible (to keep performance up), but use enough to accurately specify your vehicle's shape so collision will appear correct to the user. Also remember that you have a set of boxes for each PhysicalObject. So, for example, the chassis should not have a CollisionBox that covers the turret; that one should be in the Turret's PhysicalObject tag.

This error is caused by running the script from the wrong location (the wrong working directory). How are you running the script?

To get the latest version, run the updater. If you're on Windows, go to Start/Programs/Battlefront/DropTeam/Game Updater. If you're on Mac OS X, then there is an Update icon in the same folder as your DropTeam icon - double click it to update. Once you've updated, let us know if you're still having this problem.

...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. 1.1.5 is a small bug-fix release. Fixes in 1.1.5: </font> Fixed intermittent server crashes</font>Fixed client CTD</font>Fixed rare inability to drop</font>Decreased accuracy of mortars</font>Fixed bots' incorrect ability to target sensor jammed objects without line of sight to them</font>Increased Objective game type's scoring rate - teams gain or lose points more quickly when the objective changes hands</font>Fixed Mac sound mixing problem</font>

You've probably started a chat message, as aittam says. Press ESC to cancel the chat message and all keyboard input should go live again. (You should see the word TEAM: at the bottom of the screen).

This comment by bjarmson deserves its own thread, so here it is. The system for victory conditions in DropTeam is already far more flexible than any of the current scenarios are making use of. For example, we can already place more than one objective location in a scenario, so that teams could be vying for control of more than a single point. Also, these types of victory conditions can be mixed with others - such as those from the Territory and even CTF game types. By combining multiple victory conditions together in this way, you can define whole new goals for either or both teams. So from a technical perspective we're ready to roll out some new "more complex" goals for some scenarios. Would anyone like to post some thoughts on exactly what you would like to see?

With the obvious fixes already posting in the 1.1.5 release, I want to elicit input on Bigger Questions. This includes those recently posed by bjarmson but dating back even to the earliest Yurchposts. Combat in DropTeam is often frenetic, fast-paced, and downright chaotic. For the player who likes to stand back, take stock, formulate and execute a plan, it is sometimes hard to catch one's breath long enough to do so. Before we talk about "fixing" this, here are some things that are "not broken" about it: </font> The above description sounds like real combat. It really is hard to catch your breath and execute plans in the midst of combat. Combat is chaotic. The goal is not to make the game unrealistically prozaic.</font>Knocking the enemy off balance and seizing initiative is an important part of tactics. Therefore, it should not be impossible to do this. Any "improvements" that make it impossible to be overwhelmed or confused are not a good idea. When the situation falls apart and the enemy is coming at you from all directions, this means the enemy has done a good job and you rightly should be at your wit's end. But this shouldn't happen all the time.</font>The level of chaos on a team is highly dependent upon the players composing that team. Some of the "fixes" required are not game-related or technological but merely a matter of the same people learning (drilling) to play effectively together.</font> Having said that, it would be nice to reduce the current level of chaos a bit (but only a bit!) So we're asking for your thoughts (and votes) on the best ways to do this moving forward. Some of us have already posted ideas on this subject scattered across different threads in the forums, so consider this topic a "consolidation" topic if you like. It's OK to repeat what you said elsewhere here or even just link to it. The most effective way to do this is to first identify the primary problems that cause unwanted chaos. Once we've identified the problems, then we can sensibly discuss solutions (sometimes a single solution can address many of the problems together, but this only works if all of the problems are on the table for us all to see). Here is my list of the primary "bad" contributors to chaos. I call them "bad contributors" because, again, not all chaos is bad. There are some other contributors to chaos not mentioned here - I consider those "good". Here's the difference: "bad" chaos contributors are those things that cause a team (or a team's plan) to fall into disarray that are not caused by mistakes made by that team and are also not caused by the enemy team doing something clever to make them happen. So here is my initial list of "bad" chaos contributors: Dropship Deployment This one might already be mostly, if not completely, fixed, but here it is. If one or both teams have free reign to drop almost anywhere on the map with short notice, then no amount of tactical maneuver is going to matter. No matter what you do, the enemy can always drop on a flank or behind you and ruin (or at least significantly alter) your plan. Dropships raining down all over the map creates such total chaos for both teams that only the most micro-scale tactics are possible: yes, you can find and use hull down positions, flank or outmaneuver individual enemy units, use the right weapon against the right target, etc. But you can't execute a broader, team-wide tactical plan because the overall situation is simply too fluid. On the other hand, dropship deployment is fun and, when properly limited, very tactically interesting. The key here is "properly limited". We do want a fluid battlefield (but with only the right amount of fluidity). A while back I posted the story of how dropships worked while DropTeam was still in early alpha - it literally took a couple of minutes (at least) for a dropship to arrive and deploy a new unit. No one wanted to play this game. It wasn't only boring for the guy doing the drop; it was also boring for the other team waiting for opponents to appear. There were other problems, too, but for now just believe me when I say you don't want this option. The right way to balance over-zealous dropping is by providing teams with adequate air defense assets to prevent "willy-nilly" dropping by the enemy, but not so much air defense that a team can easily dominate the entire scenario over the long term (temporary domination is OK as long as there are ways to counter it). A team should have enough air defense to properly protect its flanks and/or rear, in at least a wide enough area that they can properly execute broader tactical plans without fear of enemy drops right amongst them. Particularly in Objective games, it's vital that the defender have some ways to channel the attacker. Without this, the attacker has an infinite number of axes of attack which is an almost insurmountable challenge for the defender. Also, the attacker has no way of properly attacking since the defender can drop behind him at any time. The right amount of AA fixes this for both sides. The new Cobra AA turrets went some of the way toward solving this problem and I think Yurch's Bacchus went the final distance. As I see it right now, there finally seems to be a good balance between a team's freedom to deploy with dropships vs. the other team's ability to limit that freedom. Now that we've all had some time to play with the AA turrets and the Bacchus, does anyone agree or disagree with this? Bots Getting the bots to follow a plan is like trying to herd earthworms from Texas to Montana. The best compendium is here: http://www.battlefront.com/discuss/ultimatebb.php?ubb=get_topic;f=48;t=000254 Of that compendium, my feeling is that platoons are the most important single feature, even if only implemented for bots at first. For the purposes of this thread, it's best to simply cast your vote "Yes to bot wrangling!" rather than expand upon the details of it - use the original thread for that. Defensive Tools This one is highly scenario-dependent, but often defenders don't have sufficient tools at their disposal to mount a proper defense of a static location - they don't have enough ways to prevent the attacker from deliberately turning the engagement into a chaotic, point-blank brawl. The defender needs ways to channel the enemy (but, as always, not too many of them). One easy solution is to give them a greater variety of turret types (such as heavier, more lethal AT turrets than those that can be delivered by dropship - something like a 120mm AT turret that can only be placed during the deployment phase, or even proper bunkers with heavy AT weapons that can only be placed during deployment). Another possible feature that might be nice to give to the defenders is a way to modify the terrain during the deployment phase directly, just by clicking, without having to use Cutters or anything else. This would model in depth preparation and digging in that has occurred prior to the beginning of the scenario. The technical challenge here is how to properly limit this feature (1,000,000 meter gorges in the earth all around the objective would be - uh - unfun). Those are the main 3 from my perspective. What else do you see that needs to be added to this list, and how do you propose to address them? [ September 02, 2006, 09:10 AM: Message edited by: Grappler ]