Ssnake

Hm. The tank range, we rearranged all entries in two columns as it became too many vehicles. Some other problems have been reported with that as well, so maybe this is another glitch.

With Sean's permission (and the original file) I could do that. But I'm not sure if I can do that with a self-executing flash video.

If you can tell me the email address which you gave when making the purchase, I can still find your ticket. Or any other detail that you remember, with the exception of the credit card number - I have no access to that.

The TOW missiles in the M3 in the TI view seems very 'hot':

I wonder if a texture is wrong? Or maybe it is using a different missile type?

Most likely, the texture simply is missing.

The limitation seems to be that the Blue AI units wont do anything, only the units you control will.

The computer-controlled units will certainly open fire on the dismounting troops, just not the cars.

Guys, it's important to understand that these cars are an intermediate solution before we implement multisidedness and more autonomy to noncombatant units. That will be a major undertaking, so here's at least something to bridge the gap for the moment.

Civilian vehicles - no matter which side - are being ignored from either side's computer-controlled units. That's the very point of them, that they are not distinguishable as combatants ... UNLESS they are dismounting fighters which, however, you can see only the moment when they actually unload them. Until then it could just be a group of people sharing a car.

By default they are all filled with troops - "insurgents", if you will, although they actually are all in uniform - UNLESS the mission designer adds a "Damage ... Troops". The challenge would then be to figure out which of the cars is carrying those invisible troops. Do you indiscriminately spray all vehicles to find out which of them has fighters in them? Or do you wait until you can observe hostile activity? What if a red and a blue car dismount troops simultaneously at the same spot and they start shooting each other, will you put a 120mm HE in the middle to silence them all, or try to sort friend from foe and apply lethal force more selectively.

Welcome to the sucktitude of modern, asymmetrical conflicts.

I'd rather have multiple sides and better pathfinding. Parked vehicles should have the capability to start moving at any time.

It was around the time when 2.460 was released, or close to release.

Ssnake, can the civilian cars (hatchback and saloon etc.), be added as neutral objects in the map editor.

Interesting idea, but it isn't possible, I'm sorry.

Well, the lead vehicle is seeding "bread crumbs" which the trailing vehicles try to follow. If the first vehicle veers off the road and then manages to recover, the training vehicles in their attempt to follow the bread crumbs instead of the original waypoints might sense an obstacle enroute to the next breadcrumb that the leading vehicle didn't experience because it was in a slightly different position to begin with and by definition wasn't attempting follow a trail.

They will then try to avoid the obstacle, and hilarity ensues.

So, if the lead vehicle manages to stay on the road better, then more bread crumbs will remain on the road, with less chances for aberrant maneuver.

In any case, having one or two route nodes behind the corner and not at its apex will at the very least help them to extricate themselves from the forest faster.

Remember, the node gets deleted from the queue as the unit approaches the waypoint, and not just when it is more or less exactly on top of it. With very close and sharp turns this means that the node gets deleted even before the vehicle has started to turn, and if the next waypoint is a long way down the next road the vehicle must obey the order to go in that direction. This inevitably results in going off-road.

Gah. Care to update it?

http://www.youtube.com/watch?v=yaayj7G_if0

Well, yes --- you see, at 0:17 the Challenger turns into the forest because the route node was placed in front of the corner (at least that's how I'm interpreting this, I haven't seen the map view, but I bet this is how the route will look like).

As the vehicle approaches the corner and comes close to the node, it is considered as "reached" and gets deleted from the nav queue. The next waypoint is way down the road to the left, at nearly 90° - well above the 30° threshold. Now the challenger veers off the road to approximate better the route direction, and hence wanders off into the trees which are all obstacles, and therefore make navigation even worse.

What may help is this method of mine to let vehicles drive safely on roads.

1. Make sure to use the Shift+Click method when placing routes that are supposed to stick to roads. The Route nodes will then snap to the road so you don't have to rely on a certain margin of error that the computer-controlled crews will accept for waypoints
2. When a route approaches a sharp bend, end the route 50m before the corner. Create a new route with "slow" speed setting.
3. Otherwise I tend to place nodes close to corner points, but slightly "behind" the corner (in travel direction).
   Computer-controlled vehicles will attempt to stay on roads for as long as the direction to the next node isn't more than 30° off to the direction of the road itself. So as the unit approaches the corner it will turn into the corner a few moments before it actually is at the corner itself, which usually avoids situations where they otherwise might overshoot.

With these simple rules to place your route waypoints you should be able to defuse most situations.

It's impossible to say without looking at the exact place where it happens. Time acceleration obviously increases the risks because it increases the time steps of the simulation in order to run faster, so the pathfinding solutions inevitably involve a bigger margin of error.

I'm not saying that improvement is impossible, but it isn't trivial to make it better so don't expect wonders, quickly.

No Centauro tutorials are available at this point. It's still "work in progress", similar to the CV90/35 in SB Pro PE 2.460.

The Tank Range problem is known, but can't be changed on short notice.

No. You can (and should) install 2.538 with NO version of SB Pro PE present, as explicitly stated in the opening paragraphs of the release notes.

Well, these vehicles don't make a conscious decision to "just cut a corner". For whatever reason, they leave the road to avoid a collision with a perceived obstacle (maybe because they were driving too fast when approaching that corner). Once that they are off-road, they try to get back on it, but then there's the problem that there's always a tree blocking the direct route to the road, so they try to go in the direction most closely to the next route node which may already be hundreds of meters down the road. Often they then drift off even deeper into the forest until they come close to the route node, at which point they are forced to drive towards the road in near-perpendicular direction. Which then usually brings them out of the forest and back to the road, so the algorithm works ... as long as there is sufficient traction, of course.

Unit-wise, I like the new variety. The Chally is nice - it takes a good beating, but I'm surprised that the CHARM3 rounds aren't more powerful.

Believe me, when we took a serious look at it, we were about as underwhelmed as you are. I think that our estimate is about as good as it can be in SB Pro while relying on publicly available data and, shall we say, pretty educated guesses. From the facts that we know and reasonable assumptions from what is missing, this is what you get. And we already made one big change in the way how we're calculating the performance of APFSDS rounds. Since 1997 Al has used kinetic energy loss (with some modifications) to determine the performance of KE rounds WRT to velocity decay. We learned in the meantime of course that penetration performance of APFSDS rounds scales more with velocity itself and not the square of it, so we're using a much better regression formula. And we are now taking into account the different materials (steel, tungsten, and uranium) which behave differently in the various velocity regimes.

So, overall steel penetrators will now behave noticeably worse at medium and long ranges, dU rounds will perform noticeably better at long ranges, and tungsten rounds will be somewhat better at long ranges as well. To that extent the CHARM3 already profits from our transition to the Lanz-Odermatt model.

If I can make some suggestions (getting my flak jacket on now), I'd suggest adding sidewalks around the larger buildings, and add light poles too.

There are two types of light masts. And you could use the single lane concrete road to simulate a sidewalk. Not perfect, but it might just work.

Around the smaller buildings, I'd add junk.

Yes, but I think that junk needs to be added procedurally. Manual placement is too labor-intensive.

Also, I'd suggest maybe splitting the objects selection screen into folders, to help organize the pile of objects.

You can count on that.

It's one of the things why I had second thoughts about releasing the Centauro. You may recall that in mid-July I said I wasn't sure whether we should add "a fifth playable" vehicle to this release but those who participated in the discussion all said that I shouldn't pay attention to the voice of reason.

The Centauro is still work in progress - please accept it as that.

Don't use the "Remote" option. Use the programming type "Direct" instead.

"Remote" is to be used only if you cannot program the CodeMeter stick directly (e.g. because you only have internet connection where you can't plug in a USB stick). In that case you need to create a Wibu Control File first, and upload that in this dialog box (with the button "Select..."). In return you would get a file that you can then take home to where the CM stick is plugged in.

Thanks everybody for the compliments and well wishes.

I thought we had that fixed. It's a bug.

"Couldn't initialize programming engine. HIP ProgrammingError 9006"

SOrry about that. I have no idea what that means. If the error persists, please contact Support@CodeMeter.com for further instructions. Keep me CCd so I know what's going on.

Notice that there is a checkbox "Is Snow" next to "Is Water" or "Is Wadi". There you can set the depth of the snow cover, and determine also which roads shall be open and which will be under snow.

If you see aberrant behavior, it's a good idea to test this with a few variations. To name an example, someone reported the Javelin to be broken and then it turns out that they are all at the same range where the missile crews switch to direct fire mode, and then don't fire because the warhead isn't strong enough. A second test with larger dispersion of the tanks would have shown the missile to fly.

I ask for your help here not because we're lazy, but because it helps us to be quicker and more accurate in our initial replies. We have a limited amount of time to investigate your reports (keep in mind I also have to handle the license updates and support other forums, and Volcano is just working part-time on SB Pro), so if you can help us a bit to sort wheat from chaff everybody will benefit from it.