ClaytoniousRex

This isn't in 1.1.3, but would be awfully simple to add to the inventory. Added to flyspray, probably for 1.1.4.

Latest, final version of Hub's scenario is now reflected in the original link above. Dark, that's a really good idea to get a 4th channel. In the long run, breaking it out into an unlimited number of grayscale images (instead of using the r,g,b,a channels from a single image) would be the most flexible of all. But using the alpha is a very clever way to get a 4th channel easily in the short-run, so we'll do it. Thanks for the idea!

Yes, still 75. No, which is only part of why the ridiculous plasma turrets (both AA and ground) have *finally* been replaced with sensible objects with real components and weapons (no more plasma bolts). Yes, pods are not jammed and are less evasive than dropships. They're completely vulnerable to AA fire. Their only advantages are that they are unlimited, small, and complete a drop faster than a dropship (and allow infantry to reload ammo, but that's not related here).

Here's the skinny on what's going on with foliage. Below is a screenshot of Hub's scenario with yellow grass: The grass in the foreground looks good while the grass in the background looks "funky". The reason for that is that the grass in the foreground matches the color of the terrain beneath it. The grass in the background is on a purple-brown patch of land, but the grass is still the same yellow. The "color" of the ground, especially in the distance, is supposed to represent how the ground looks, including the foliage on it. So if we switched instead to a darker brown kind of grass, then that brown patch in the background would now look good, but the yellow terrain in the foreground would now look "funky". When we had green grass, then it looked funky on BOTH the yellow and brown areas, because neither of them was green. So the basic problem is that the same terrain type mask, which is tied to the foliage, is covering both of these differently colored areas in the base texture. Now, minor variations in base texture color are a very good thing. But major differences in color, within the same "terrain type" as specified by the mask, when using foliage, lead to this problem. The best solution would be for the terrain type mask that has yellow grass associated with it to only cover the yellow parts of the terrain. Or, if you want browner grass, then make that mask only cover the brown parts of the terrain (and not the yellow parts). As long as that one terrain type covers both the yellow and brown patches, then you will never be able to have a foliage color that doesn't look funky on one or the other (or both) of them. Does this make sense?

Those are now in 1.1.3. Thanks, Yurch. Alex, if you should ever get into a hosed state, you can always force an update to make yourself current again (and repair the damage). To do this, edit your version.ini file and make it a lower number. For example, your version.ini file now looks like this: </font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">1.1.2</pre>

So you're wanting a new forum called "Scenarios" or something, with an individual thread inside of it for each scenario? Sounds pretty good.

A great new scenario by Hub. Download it here. Can't wait to play this one online. Feedback for Hub would be much appreciated. Edit: updated download link to Hub's latest version [ August 13, 2006, 09:43 PM: Message edited by: ClaytoniousRex ]

Yes, remap the "brakes" key.

The idea of scenarios like that is that you are taking control of the indigineous infrastructure. You go the expense, risk, and effort of using dropships in combat but the long term goal is often to pacify and take control of an area for longer term use. Having control of the planetside infrastructure allows you to use it once you've conquered the area. Once combat is settled, it's cheaper and better to use trucks rather than dropships. Mmmm ... I've decided not to get drawn into this after all. Suffice it to say that you can now make scenarios that feel more like chess to you. They might feel more like checkers to someone else (after all, they now have fewer options instead of more), but that's perfectly fine. The scenario author should have the power to realize his vision of what is fun and tactically interesting and with 1.1.3 he will have more tools for doing so.

There are already a few changes in 1.1.3 that are relevant to this (1.1.3 will be released this week). </font> Scenario authors can simply turn resupply off for their scenario (and of course a scenario author is already perfectly able to not put any ion towers in the scenario if he doesn't want them)</font>Reinforcement zones are now working. You can drive onto the battlefield via these zones without dropping (the scenario author specifies where and how many of these zones exist for each team - they are usually on a map edge)</font>Each team has a limited number of dropships (specified by the scenario author - can go all the way down to zero for one or both teams at his discretion)</font>Infantry and deployable items are delivered via disposable drop pods (drop pods are unlimited).</font>Bots can be told not to drop until ordered to do so</font>Dropships maneuver much more aggressively, taking evasive action and burning into the drop zone as quickly as possible</font> There are some really important repurcussions to that last one. Dropships that streak toward the drop zone have to burn hard in order to decelerate before dropping their payload. They do this last phase of deceleration at nap of earth, but it takes several seconds to counter all of that momentum and slow down enough to drop. This means dropships are far more difficult to hit at long range than before, but in some cases are even easier to hit up close than before. This means that dropping right on top of enemy units is nearly suicidal unless done in numbers or with some kind of cover, etc. Dropping in a safe drop zone at long range from the enemy, however, is far safer than before. There's more to say about this in another thread when 1.1.3 is ready. The reinforcement zones make some initial recon and probing by the attacker much more doable. You might well want to drive in under jammer cover and carve out a drop zone or two before using dropships. You might even want to send in your best 1 or 2 players before anyone else deploys and units at all. Most importantly to this thread, the scenario author is now capable of having no point defense at all if that's his wish. As in my earlier post, we're still looking at changing point defense to only be effective against lower velocity, larger rounds (artillery and ATGM's), but since it's hard to tune that in a way that makes it still possible to roll it back, that won't happen in time for 1.1.3. There's plenty of other stuff in 1.1.3, but those are the main changes that are relevant here.

Have you selected your new Mod on the "Mods" tab of the main screen?

The most important one, which is that the user have the same Mod as the server selected, is already in 1.1.3. The others are still unaddressed. Where is your server located, Poesel? What kind of connection is it on?

Wendi, you might even consider creating models along the lines of what Yurch has proposed for some new unit types. This way you can use his game design ideas along with your modeling ideas so you can focus your energy on the look while letting him worry about the game design implications of the new units. Teamwork, dontcha know.

Just juggled them around a bit. We'll try to do this periodically.

We don't bash Hobbits around here anymore. We've reformed. Well, what do you think, Poesel? Are you still working on a wiki or should we just start pouring content into this one?

Just some quick notes: Yes, model all objects separately. So model the chassis as its own object. Ditto for the turret, the gun, the wheels (if any), and each gun. By "object" I don't mean mesh. An object can be comprised of any number of submeshes, etc., but they all need to be attached as children to some common parent. You can save that parent out of Blender as a .cob file. Each mesh must have a single texture across the entire mesh (you can't paint individual faces with their own textures). If you need more than one texture for your vehicle, then use separate meshes for the separate parts with different textures. As for poly counts, for all of the objects on a vehicle, it's best to keep it < 3,000 if you can. This isn't a hard rule - the final count is up to you. Just remember that the higher the poly count, the more players with low end machines will have trouble using your new designs.

I like it very much, Ja. The concept of a wrecked ship with working defenses is very cool. The red fungus has already turned out better than I thought it would from your first screenshot above. You know, you should be able to put some AutomatedGun objects on the wreck so it can really have its own defenses. Have you tried that?

Out of 92 HEAT rounds fired into a Shrike: </font> 48 brewed the Shrike up on the first hit</font>24 immobilized (engine kill) on the first hit</font>12 killed the driver on the first hit</font>8 failed to kill any internal component on the first hit (but see below)</font> In ALL cases, multiple internal components took severe damage even if not quite yet killed (for example even in those 8 failure cases the Shrike had reduced mobility due to engine damage, etc.) In 92 hits there wasn't a single case of "no effect". So 1st shot is a kill 52% of the time. 1st shot is a mobility kill 39% of the time. That's a 91% chance of putting the chassis out of action on the first hit. You could do the same thing to the turret instead of the chassis if you wanted to. Spall is a specific subset of fragmentation. Spall is the separation of layers of ceramic or other layered materials into the interior of the vehicle. In addition to spall, there is also "complete" fragmentation, fragmentation from damage caused to hits within the interior, as well as whatever the projectile brings along with it. We also assume that spall liners, less brittle armor, and other innovations don't add up to a perfect "silver bullet" that completely nullifies all fragmentation effects. Agreed, which is why we do model fragmentation damage. Mmmm - I thought you were saying you didn't want us to. It is already quite extraordinary for these rounds to pass through harmlessly. They just don't make the entire vehicle burn on the 1st hit every time, either. The paper analogy was in answer to the question of momentum being transferred (the wall of concrete). You're right that there are other, unrelated physical effects that would make my big piece of paper stop being a piece of paper (and I probably had important code on that paper, too, damn it). But I was only answering the momentum question, not really exploring how a piece of paper would behave if hit by AP... But if you're advocating that we also model bow shock for AP, I'm all ears. What kind of effects would you like to see? Remember, the most obvious victim - the crew - is rather well insulated from it in this particular environment. This is the final answer to the question of whether an AP round should transfer all of its momentum to the target? Well, OK, since the can will not go flying at the flachette's full speed, but instead will only be knocked off the fence, I'll accept that final answer since it brings us both into agreement. Some of the projectile's momentum will be transfered to the can. In this example, I dare say a small fraction, since the flachette will continue well past the can into the distance with most of its original reach. At any rate, the can won't act like it's been hit by a wall with many times the flachette's mass. And neither do we, which is why we've gone to so much trouble to simulate all of this junk. I don't think anyone here is advocating that 120mm AP is so amazingly perfect in all situations that it simply always kill everything it hits, are you? If that is true, even the modern world is wasting a lot of resources on other types of ammunition and weapon systems. And if that is true, games like this one are going to be a lot less interesting to play. Do you want your target reticle with 120mm AP loeaded to be The Finger of God? A Finger that points both ways? Not very interesting.

Other rounds could have this factor, but there aren't plans to add them to any of the other existing rounds now. It would only be used for other high caliber AP around the size of the 120 or bigger (so if you were to create some new, high caliber rounds you could use this value). The 10% is multiplied with the target's armor thickness and a coefficient. So for the Shrike the final kinetic burn chance is about 1%. For the Thor, the final kinetic burn chance through the thick frontal armor is about 30%.

Condensed version of the previous post for anyone without the patience: If you want 1-hit kills on Shrikes with the 120, use HEAT. On rare occasions you will need a 2nd hit (but the 1st one really ruined his day already).

Nothing. 120mm AP goes straight through all internal components without stopping, doing damage as it goes. This is one of its main strengths relative to smaller AP rounds. This would only be true if the target stopped the projectile completely, thereby absorbing all of its momentum. Targets never do this because AP is very good at cutting through things that are in its way. Imagine that the target's armor was as thin and as weak as a sheet of paper and a 120mm AP round went through the paper. How much of a shock would that be to the target? Not very much, since the round would continue through mostly unmolested, retaining its momentum rather than giving it to the target. Ditto with a shot that ricochets without penetrating - all of the round's momentum has not been transferred to the target (the round is still flying!) This is why in real gunnery it is standard to use HEAT or HE on light targets instead of AP (among other reasons). With a sufficiently light target it's possible to do little damage to the target because the round will simply punch straight through and keep going. Conversely, the heavier and thicker the target is, the more traumatic AP is going to be against it. This is very important in DropTeam! One of the quirks of AP is that, once you penetrate a target, its going to hurt heavy targets more than it hurts light targets. The heavier the target's armor, the worse internal fragmentation damage is. Internal fragmentation applies damage in crazy patterns within the target's interior, not just in a straight line along the AP round's flight path. So when you punch through a Thor's frontal armor, you've made a horrible mess inside of the vehicle. Conversely, when you punch through a Shrike's very thin front armor, there is not nearly as much (or as deadly) fragmentation within his interior. Yurch has previously mentioned the "10% burn factor" of AP rounds. This is not simply a 10% chance of setting the target on fire when hit by AP. This is modelling of igniting the target's armor by the almost instantaneous heat build-up from kinetic friction when an AP rounds manages to punch through the armor. The base factor of 10 that the 120mm AP round has is a starting factor which is used with the target's armor thickness to arrive at a final chance of igniting the target. The higher the target's armor, the higher chance of igniting it due to kinetic friction. So once again, since your AP round passes through the Shrike's thin armor without even slowing down much, there's little chance of igniting the Shrike in this way. Conversely, if your AP round penetrates the thick frontal armor of a Thor, scraping its way through centimeter after hot, digging, scraping, centimeter - then you have a *much* higher chance of igniting that armor due to kinetic friction! Bottom line: AP is not as lethal against light targets as it is against heavy targets. Even bottomer line: Use AP on tanks. Use HEAT on Shrikes. Use the right weapon for the right job. A tool that is good for one purpose is not automatically good for all other purposes. It is not true, in DropTeam or in reality, to make the blanket statement that AP is more deadly than HEAT. Whether this is true or not depends on what is being hit. In DropTeam's damage modelling, total overpenetration of a target is not modelled. This means that even if an AP round has sufficient penetration to go entirely through a target and continue on beyond the target, it doesn't. The round stops inside of the first target that it hits. This reduces the workload of physics that your poor computer is already crunching, and it is a mostly harmless simplification. The one place that it causes a significant problem, though, is in the case of tires and other objects that are attached to a chassis. In these cases, the fact that your AP round completely stops if it happens to hit a Paladin's tire, without passing through the tire to also hit the chassis, is really bad. Even if we don't model the projectile continuing through and on to a completely different target, we definitely should at least model overpenetration between tires and other "child" objects of the same target. This is a very easy thing to do, and it will greatly improve the performance of AP rounds against wheeled vehicles. Right now, when shooting at the sides of a wheeled vehicle it is very easy to hit the tires instead of the chassis, making it sometimes very hard to finally get a kill. DropTeam does not currently model shocked crew members within a vehicle that has taken fire. You're absolutely right that it should, though. All of the pieces are already there (the way infantry stand around dazed after a blast is actually already there for the tank crew members, but not currently used). Will get it in ASAP. 20mm is supremely more effective at point blank range. At medium range, the 76 will pick you apart while your 20mm's are bouncing off of his glacis. If you're armed with a 76, and you're in a knife fight with a 20mm, then he has already won the fight by getting you on his ground.

We would have to create a tool or site for this. There's nothing for it right now.

We're getting some real documentation ready for you. Won't be long.

I'm going to be a terrible salesman but a good friend: DropTeam is most fun when played online. Single player is simply not as good. Single player is rapidly getting better with improvements that are underway right now and we have a pretty good track record of getting these kind of enhancements done in a timely fashion. When I say single player is improving, I really mean it - no vaporware here. I would say, right *now*, single player is fun for learning how to play and for experimenting with ideas but once your skills improve, the AI doesn't give you much of a challenge. However, I would also say that this won't be true for very much longer - the AI is improving dramatically and within a month or two single player will finally start to approach online multiplayer.

Believe me, I really would love to feed your particle habit. Unfortunately, these shaders won't help. What you really need is more generalized XML tags to work with so you can generate particles in reaction to events.