yurch

To tell you the truth, I totally dig the availibility of those kinda tools (as buggy as they were), especially more powerful stuff like uscript. You could change the very basics and dynamics of weapon "interaction" if you really wanted to. I'm not sure of what level of ww2 simulation people are looking for, but I think our current gunnery/intelligence/crew coordination/communication is a bit too tight for comfort. I'm sure they would have loved a third person camera, a waypointed hud map, and perfect crew coordination back then.

For now, you can make a mod for it to look however you want. tracer000.png is the file used for the tracer visual. I use a green tracer (and a blue beam) myself, if you want something to just get started. I don't know how they look under HDR.

I use a mod of various graphical changes, and play with it regularly. I can connect to servers without problem, unless I go 'too far' with stuff outside what could be accepted mere client mods - such as adding weapons or objects to thor. Then it will crash if I forget to turn the mod off. I don't know if the opposite (server having mod, plain client) will cause crashes, but there is sure to be some odd behavior. If things stay this way, it may be possible to keep out the 'riffraff' without the mod by changing the inventory around so he'd need your inventory.XML to even spawn - be an easy way to send home the message that he needs extra files.

4) Track + Hill power slide. It seems nonstatic (or, non 'rolling') friction doesn't degrade the performance of tracks (or wheels?) on inclines - you can slide down a hill while climbing up it at an angle - with a inpressive net gain in speed. 5) Steering directional shifts. If you don't release a key before going in the opposite direction, the steering doesn't reset to center beforehand. For instance, if you turn left, release the left key, and turn right, the vehicle will turn right. If you hit right while still holding left, then release the left key - the vehicle will slowly go from a left turn to a right turn. Most noticeable and entirely reproduceable with hovercraft online and off, but all vehicles do so. This seems related to input rather than physics. I think steering should return to center a bit more gradually than it does now - hovercraft, for instance, can violently stop rotation on a dime. 6) Hermes disadvantage. The hermes is supposed to be slower (than other paladins) because it is heavier. It seems this is actually handled in-game by reducing it's wheel horsepower, which may have some undesireable effects. 7) Wheel inertia. I'm not sure what to call this, but you can cause a vehicle to change direction/rotation in mid air or upside down by violently moving the wheels about in different directions. While I'm sure this is possible in reality to some minor degree, you can actually right flipped shrikes and paladins using this with no wheel contact. Edit: 8) Hovercraft are much slower on top of water than on land. Are they using ground effect for propulsion? [ July 07, 2006, 11:35 AM: Message edited by: yurch ]

Is there a way to get rid of commander mode? Often when new guys come in, they feel the need to vote a commander - but in a 2 or 3 person team, it's often a hinderance instead of a help. So one guy is stuck commander, often when he's clearly needed to be killing things instead. Also, the voting bar/process is weird. If for instance, there are two people on the team, one votes me as commander, and I vote no, I end up as commander. The voting bar only goes halfway. I think if, say, 1/5th of the players vote for a map change, and the rest don't vote at all, the bar goes 1/5th of the way and the vote passes. I think the bar 'capacity' should change to reflect how many people are actively voting and how likely that vote is to pass - that bar should be 100% full unless somebody votes no. The minimum percentage requirement to pass a vote should be marked somewhere on the bar.

That's odd. The 76mm usually gets 50 rounds of HE, which is more than enough to down a tower. Is the demo different somehow?

Well, no. If we were designing useful weapons for the honor of the 102nd stratosphere-borne, then I'd say hell yeah, it'd be useful, along with an ATGM that could fire more than one missile at a time and a point defense for every unit. But you know, that whole play balance thing.

Naturally. I'm just saying kills are nonsensical for inanimate objects. Plus, ionizing a few turrets and a shrike shouldn't be worth more than killing a few Thors through kung-fu. After all, this guy is concerned with how he's doing... Stats, yeah, go for 'em.

When capturing, structures don't go all together in 'clumps'. In other words, you have to capture each individual tower no matter how close they are. This is inconsistant with how other structure groupings in the game work.

This happens to everybody. Most people don't want to sit around and wait till someone finishes them off. With more and more people figuring out how to switch places with bots, you're going to see higher kill counts at the expense of bots. When I'm pressed for time (IE, close in fighting), I'm satisfied with mission killing a unit and moving on to other units capable of shooting. I also consider a disabled engine under enemy AA a kill. Keeping track of plain kills and deaths when players can switch between bots at will and tanks can be completely disabled without 'dying' is kind of weird in the first place. Especially when turrets count. I'd much rather see a point system replace kills on the scoreboard.

Well, yes, if you technically "fire" a Thor sized projectile it is of a remarkable caliber. Courtesy of the Viper Trebuchet... A high velocity caliber larger than 120mm would be downright terrifying. 120mm AP is exceedingly dangerous on thinner atmosphere maps, and I'd say 120mm HEAT is one of the best overall weapons in the game. I think it'd be a bit of overkill, really.

¡En inglés, por favor! I'd love a 76mm apollo, but it seems this is more of a new chassis design request. Would a hover chassis really be the most appropriate for this?

You can specify drop unit type and location for the bots. Select thier name and hit the 'drop' button, which is next to 'observe' and 'orders' in the tacmap. The downside is that is much safer to let the bots choose the area themselves - ordering a drop in one location will mean the bot will do it over and over until the inventory is exausted. You have to specify an area if you want a specific drop type, unfortunately. The bots generally can't fight very well with anything but the thor. They can't drive at high speeds, rarely manuver properly, and lack the fire discipline to use shorter ranged weapons.

Not sure. It wouldn't quite work the way point defense works (thor certainly can't traverse that fast) and those ions are much, much further ranged. This is very static, and would be problematic with current units. A team could stop another team from dropping entirely by occupying thier drop zone. This really doesn't lend to stagnation, and I could argue it does the opposite. Air defense in this game is not very sturdy. I can scream in with a tempest and remove 70% of a team's AA turret coverage, with that number approaching 100% if the turrets aren't jammed. Needing less turrets to cover more area means less fiddling with jammers, fiddling with coverage, and waiting for dropships one at a time. It allows the AA coverage to be put back up with less hassle, allowing a team to bounce back. Usually nobody even bothers. I fail to see how a well covered area (nay, a region) is 'uncrackable' given that simple 20mm paladins are fast, cheap, and good at destroying the light turrets and sensor related objects. The big towers go down to a single 76mm paladin unloading it's HE, and automated AA never fires at anything jammed. Dropping a galaxy on a hermes pretty much gets you a makeshift dropzone no matter how many automated units are nearby. None of this will change with the new proposal, other then the fact the hermes will have to shoot out or avoid nearby sensors. The mobile sensor units will be more useful for attackers, who need to deny defenders from dropping by sniffing out thier usually jammed areas near the objective. Part of attacking is stopping defenders from dropping back in. If the bots had any semblance of accuracy or sense you could just park two of them in ion units a few thousand meters behind the action and they could burn dropship after dropship through focusing thier fire. I know I've done this with fellow players, and this is at double the range of the standard AA turret. This is a boring job to be relegated to, but it could be done with current game mechanics. I fire 120mm on any dropping ship I have a potential of destroying, and I have downed ships as far out as 6800 meters. Our dedicated units completely stop trying at 2000m or if the target is jammed. So you know, the two demo maps are somewhat unique as they have defensive towers directly on the objective. In many of the other maps, teams rely solely on deployable AA turrets for defense of the objective. Since the attacker points ramp up much faster than they decrease, attackers usually win these maps, despite defender deployment.

The following is a long winded musing on the dynamics of sensors, jammers, and AA and their effect on play. Usual rules for yurchposts apply. Read/ignore at your own risk. I think AA is underpowered in this game. I’d stop there, but that wouldn’t exactly be worth the price of admission. Sure, I could probably sex it up with the promise of making the game better and whitening teeth while you sleep, but that’s not really how I do things. Some of our objective maps feature a hill (twin peaks, haven) as the objective. Fighting that occurs on this hill is close ranged, awkward and generally very fatal, which is quite favorable to attackers. Since attackers are deciding where the attack takes place, this usually results in localized attrition or at the very least long delays with attackers in range of the point counter. Defenders should obviously be fighting the attackers at arms length around the hill, but this never seems to occur. Why? Because attackers are literally falling out of the sky. There’s too little time to gun them down in the open when they’re already closing from a bit further than 2000m. (the maximum range AA available on either of those maps) More will come in while you’re busy struggling to keep 20mm off your flank. The advantage of having AA is apparent. On ice fields (which I’m starting to consider one of the more strategically oriented maps) the Cobra missile defense tower (with a radius of 5000m!) is an imposing and well respected unit despite never firing on ground vehicles. On this map the attackers lack their drop-in advantage, and actually get torn up pretty bad if defenders begin using aggressive strategies from the first example. To counteract this, attackers would need to set up an AA network of their own. I think this illustrates the difficulty of our current system quite well: At least one player would have to get into a command track, and dump AA turret after another in widening radius, with corresponding jammers for each turret. Failure to include the jammer will get the turret destroyed in very short order either by chance enemies in the area or by the ever present ctrl-m mortar carriers in that map. A turret in enemy LOS can be destroyed fairly easily out to 6000m, by 20mm or ion fire in particular. Allowing an enemy into the area will often mean replacing a significant portion of the turrets. My initial reaction is to increase the AA range of all (or nearly all) units, simply to drive up the volume of covered area, placing a greater emphasis on ground movement. This comes with its problems, of course, the main one being what to do with the commonplace ‘jammed turret’. I have come up with what I think is a solution that allows greatly increased range, but it changes many of the dynamics of how turrets, sensors, and jammers work. Here are the rules: 1) A turret does not immediately show up on the tacmap when placed, like a jammed turret does now. The radius should show up as you’re placing it. If possible, show the effects of terrain on the radius. 2) Sensors and turrets act in conjunction. Allow turrets to fire intelligently with sensor information, be it leading units that are out of LOS (so a shot is already in flight before a unit clears the corner and/or ground/AA turrets can arc over hills) shooting projectiles, or a better accuracy deviation. AA turrets should become more proficient at hitting distant air targets that are spotted by sensors, either through general accuracy, increased range, or both. 3) Turret positions flash when they fire on targets, in a manner much like the counter-battery computer on the artillery. If possible, flash their AA coverage on the tacmap as well. This includes the hermes autogun. This is a compromise between having permanently jammed turrets and completely revealed turrets. The flash should have a substantial fade time for the user friendly factor. This could be described as short bursts of detectable radar usage or other such emissions from the turret for targeting. While not totally newbie friendly, it certainly is an improvement over the jammer/AA combo with no death message that is used near universally. 4) Sensors have a dual function. The first being their current function, (short-range seeing through terrain) with the second being a longer range line of sight restricted version of the first function. Sensors may not be jammed. They probably should not show up on the map until they are in LOS, however. If a team wants to hide it in a hole for the AA usage alone, that is their decision. Bots definitely need to fire on spotted sensors. 5) The most controversial: Sensors unjam targets, including dropships. If this is done sensors should remain unjammable. This puts an automated stop to weird strategies like the ‘jammer highway’, and adds a bit of danger to the hermes-viper combination. Turrets still cannot fire on jammed targets without assistance of a sensor. 6) AA turrets become more ineffective over distance. To assure takedown, sensors or redundant turrets will need to be deployed. 7) A 20mm sensor paladin or shrike as a patrol vehicle, because keeping stationary sensors alive could obviously prove quite difficult at times. This would also be unjammable, and for gameplay reasons, a fairly soft unit. This would effectively be the opposite of the hermes. 8) One of the current buildings (like the one opposite the AA tower in ice fields) could serve as a longer range sensor station. I would love for some of the other structures besides the AA tower to have some strategic value. 9) Since the air defense towers feature 3 turrets, mixed variants featuring both missile and point defense would make a great deal of sense. 10) A smaller defender deployment radius for the objective gametype definitely needs to be enforced. How is this set for standalone games? The deployment radius does not seem to apply for the objective gametype. If anyone sees glaring problems or omissions with this, please be sure to say so. Allowing AA to have an improved coverage volume allows for better placement, as well as less hair-pulling to actually cover enough area to allow some manuvering. You obviously can’t dig pits for 10 positions, especially while on the attack. At the same time, air defense shouldn’t be an all or nothing deal. If a player (or several) want to risk dropping expensive units inside the known ineffective range of an AA turret, that’s up to him.

Something is returning flags the moment they are being dropped in some maps (in some areas), preventing flag handoffs and generally being a nuisance. The maps that this happens on all appear to have some occurance of water. Perhaps there's something about the water volumes that does this? Unfortunately, the only server that does not run primarily CTF is Gnostic Ascension; which only runs Ice and Raid. Is anyone out there capable and interested in a Objective/territory only server?

Naturally, since I can't leave well enough alone, I've started swapping firmwares around and have already caused the deminse of several innocents. Will hollar if dropteam (or other things) does somethin' wierd again.

This is why I waited so long to report it, have been trying to figure out something solid to report for what's been going on. I don't want to report problems that are on my end only. Not easy to get the server to drop me in exactly the same way with any reliability. Usually this lockup is only a problem for the computer running dropteam, but I thought this other potential is worth bringing up. A fair number of games get played here, everything from BF2 to asteriods, with no problems with any of 'em. Last time I got this hangup, dropteam was the only thing running on the network. Usually my rig is the only one to do any torrenting. Now I'm curious, does dropteam do something more rare or unorthodox compared to other programs? Not from an accusatory point of view, I'm just curious. That thread has not improved my opinion of the router much, but it's what I got for now. This activity is too rare and sporatic to be worth me messing with firmware. Unfortunately, both my neighbors have linksys routers, and I think even the same model. Comcast will drop us on occasion under heavy downloads (the modem will visibily wink out in those circumstances), which I suspect may be what the overload outage was. I'm not necessarily sure that was the fault of the router. At any rate I don't think dropteam is putting that kind of strain up. Edit: I'd like to add that I've not been happy with comcast's modems/service. We've had all manners of unfortunate stuff happen to us, everything from a (now replaced) modem that would die (overheat?) at the drop of a hat, to Comcast service personel whacking at our cable box with a sledgehammer. I am not making that up. [ June 30, 2006, 10:27 PM: Message edited by: yurch ]

The fact that dropteam doesn't let me out properly is the only thing I can really be sure of. I'd like to be rid of that... it doesn't always seem to kill the entire network. The modem's some (probably godawful) RCA DMC325 given to us by our provider, and the linksys is a BEFSR41. The modem does not go out, I'm suspecting it's the router or my system flooding it with requests or some nonsense like that. The seemingly dropteam related outage(s) is the only one this network has had for at least a month, with the exception of us overloading it once with a 350+ combined kb/s torrent(s) download over several computers, which was practically on purpose. It's pretty solid.

I've had this through the demo, but I've never managed to figure out what's causing it. Whatever it is, it only happens while playing dropteam online, and I get dropped from the server. I will get a 'server is not responding' message, and from that point on, there are no internets to be found in my house. I lose connection to everything on my computer (aim, irc, even webpages), and this often also happens to the other users on my network - and they aren't even playing. This is most bizzare. During this, dropteam "locks", as I can't exit or attempt to disconnect from the server, but I can still move the camera around, ect. Network functionality is usually gone until long after the dropteam process is killed and/or I give up and unplug the network. Needless to say this is very annoying, especially when the other members of my household network are involved. I'd love to find a solution for it. It's rare, but I just got a rash of it again recently. I'm on a winXP machine, on a cable connection over an oldish 4 port linksys router.

Well, none of this really intends to change the overall damage potential of the 20mm, this is more about likelyhood of hit. 20mm is a fairly nasty weapon for ambushes.

I'd like to point out some things about the 20mm weapon systems and make some possible suggestions. First off, the 20mm AP and HE are fired three at a time, with a reload time of 1.2 seconds. The burst appears to be evenly distributed along that reload time. This gives the 20mm a rate of fire around 150 RPM (3/1.2*60) AP is fired at more than twice the velocity of HE, and has one tenth of the deviation. However, the 20mm AP (and AP only) shots appear to be handled by the engine as a 5 round 'clump' or 'packet'. This is also in accordance with the muzzleflash, which appears 15 times. This would put 20mm AP at 750 RPM, which is fairly impressive for a single barrel weapon mounted on a ground vehicle. This raises many issues. 1) While the RPM may in fact be 750 RPM, the shots are fired in clumps, removing the benefits of such a high fire rate. Examples include the probability of scoring a hit while firing on high velocity or small objects, and the ability to circumvent point defense systems. It appears all 5 shots of the 'packet' are stopped at once by point defense ions. 2) This puts the ammo count of 20mm AP effectively at 200*5 = 1000 rounds. 3) This 'packet' effect does not occur for 20mm HE, which causes at the very least inconsistancies with using the same firing animations and sounds. I would imagine that the 'clumping' is to help performance in netcode or processing department. With this in mind, wouldn't it just be easier to appropriately increase the stats of each single projectile and only fire one instead of five? We aren't getting the benefit of the high ROF in the first place, with the only meaningful difference I guess being multiple hit effects being played when a clump hits a target. If the benefits of a higher ROF are desired, perhaps bursts can be changed to a 4 or 5 round? (or, decrease burst time?) Additionally, an ammo count of 201 (or 102) is actually more appropriate if we're firing 3 round bursts - it's divisible by three and the last shot doesn't end up making all those muzzle flashes and noises for the remaining divided burst. Lastly, I've been playing with a low frequency of particle sparks coming from 20mm penetrations (less than 25). For the most part it looks good, and I would recommend it for later.

Problem is, without the death (un)incentive players may feel the need to use every single turret up in deployment phase. It's annoying to fight against, but even more annoying when you need turrets somewhere else...

Turret deaths are kinda a mixed bag. While I think there should be some incentive not to place them bunched up in dumb areas, it's not like there's much incentive in the first place to really take care of them either. They're terrible in most situations, I find the ground varient better for attack than defense. Online, when you leave the team, the turrets are now transfered to team (blood or water) control, I guess removing the potential for death count entirely. In light of this they probably shouldn't count as kills or deaths.

I'm fairly certain AA kills and mine kills do not count. Not sure about ground turret kills. Losing a turret, however, counts as a death.