Armata soon to be in service.

[Battlefront.com]

Again, the theory is as straight forward today as it was 10 years ago. However, we still don't see vehicles driving around with APS that can defeat top attack weapons, despite the painfully obvious need for them. Therefore, the leap between theoretically straight forward and practical employment is apparently fairly big.

As a software developer that has worked on pretty much the same game for 17 years I can tell you we run into this sort of thing all the time. It usually starts with a customer saying "it should be easy to do x", transitions to me figuring out how to work it into the existing game, and ends with Charles telling me that my design will take 2 years to implement

Steve

[panzersaurkrautwerfer]

In terms of armor, I don't see anything hard.  It's just a matter of making it thick enough and the rest is pretty simple.  

[Vanir Ausf B]

Again, the theory is as straight forward today as it was 10 years ago. However, we still don't see vehicles driving around with APS that can defeat top attack weapons, despite the painfully obvious need for them.

A large chunk of the US Army in CMBS is driving around with an APS that can defeat top attack weapons

[Stagler]

A large chunk of the US Army in CMBS is driving around with an APS that can defeat top attack weapons

 

clear 'murican bia...

 

nah just kidding

[L0ckAndL0ad]

The reason why Charles may not do something for CM really fast is because CM engine has a lot of limitations, and not as flexible. Obviously, I have no idea how it is coded, but you can't even do tooltips everywhere where it's needed, because you'd have to hardcode every each of them in, and you don't want to do that. Same with sub-system list and whatever. Which leads me to believe that it isn't very OOP-friendly and/or outdated. Also, BFC's and Russian MoD's budgets aren't really comparable, so all in all, the example is bad.

 

As for seeing vehicles in service with APS, there're Israelis, the ones that are fighting official ground war. US aren't in ground war now. Russia isn't officially. If they'll go, they'll be equipping APS, this is why you've put them into CMBS. Why even asking then?

Edited June 2, 2015 by L0ckAndL0ad

[A Canadian Cat]

Also, BFC's and Russian MoD's budgets aren't really comparable, so all in all, the example is bad.

 

Oh I disagree.  Steve is not saying that BFC's budget is comparable - that would be a poor comparison.  He is pointing out that just deciding what you want to do and imaging it as possible may not mesh with the reality of the current capabilities of an organization, equipment, budget and / or time line.  Any project that might be undertaken by an organization needs to match with in those parameters.  The size of the budget or the organization only changes how many and how big those projects are but it does not change the reality that projects need to be prioritized.  That prioritization needs to take into account how long it would take with the current staff and equipment and how much it would cost to add staff or equipment etc.  Or put other projects on hold. etc. etc.  The Russian or US defence department or their contractors are not immune to the realities of project management and budgeting.

[L0ckAndL0ad]

Oh I disagree.  Steve is not saying that BFC's budget is comparable - that would be a poor comparison.  He is pointing out that just deciding what you want to do and imaging it as possible may not mesh with the reality of the current capabilities of an organization, equipment, budget and / or time line.  Any project that might be undertaken by an organization needs to match with in those parameters.  The size of the budget or the organization only changes how many and how big those projects are but it does not change the reality that projects need to be prioritized.  That prioritization needs to take into account how long it would take with the current staff and equipment and how much it would cost to add staff or equipment etc.  Or put other projects on hold. etc. etc.  The Russian or US defence department or their contractors are not immune to the realities of project management and budgeting.

 

Can you be less generic, please? I don't follow what's your point really. I countered his argument about their development problems. Comparing BFC and MoD budgets in absolute numbers is crazy, but in terms of "grades" they can be compared. Military software development is practically AAA-grade, in terms of functionality and stability. Especially the one that needs to work at speeds of 0.05s. It takes a lot to do something like that. BFC isn't a AAA studio, therefore they can't even afford going for a better game engine that can allow OOP-friendly tooltips and scrollable lists.

 

For factual budget and economical discussion one may want to refer to one of my latest posts with budget numbers and start from there.

[A Canadian Cat]

I am not sure what to say.  My point was not a specific one. Steve tried to use an example from his experience to show that just because you want something and can conceive how it will work doesn't mean you can get it without sacrificing something else.  You responded by saying the MoD's budget is way bigger than BFC's plus some seemingly snide comments about design issues that had no relevance and claimed is example was wrong.  I was just pointing out that the size of the budget is not the issue - the issue is a question of what is achievable and what other projects can be done at the same time.  The fact is we don't really know from the outside what the trade offs might or might not be. 

 

To me it seem that all Steve is saying is your optimism is running high and you seem to have set you expectations on the high end of possible outcomes.  You seem to be saying he is being a negative Nelly and your expectations are spot on because - say so.  You guys have kind of degenerated into a pointless space.  It seems unlikely that Steve will get you to think more critically about what you are expecting and it seem equally unlikely that you will convince Steve his concerns are baseless. 

 

In the end we will need to watch what happens over the next five to ten years I would think.  Either way I really hope you guys are not still trying to get the last word on this in this thread in 2025

[L0ckAndL0ad]

Well, that's the problem. When there's no specific point, one can't counter it. This is why I'm jumping into exact systems and engineering ideas behind them. Specific stuff.

 

You are a programmer yourself, right? And you can clearly understand things I was referring to ("collision mesh" calculations in APS algorithms, OOP-friendliness, etc), so I was hoping that we're at least on the same page in terms of basic concepts of engineering behind such systems. I, myself, see no real problems in terms of programming these things. Same with engineering solutions, I've already explained them the way I personally understand them or would've done them myself. Even proper hardware latency can be achieved by doubling detection range, like I've already said.

 

But coming and saying some generic stuff like "we don't know if they can afford to allocate resources to do everything at the same time", is what? An attempt to look into their management issues? They obviously have people who are tasked with prioritizing and resource allocation management. Hundreds of people involved. Hundreds of factories and R&D centers. Like, is there anything about them that gives out any warnings that they're doing it wrong? Without looking into specifics, you can't go anywhere further with this.

 

And as of my "optimism", I don't understand, again, what the problem is. I know exactly what can be expected, in terms of worst case scenarios. I see quite a few things that I already dislike about newgen vehicles. What I do like is a general movement in the right direction with them, and yeah, it is quite optimistic so far. It's not like I'm being delusional and fanatic about it or something, I'm quite a sane and clean minded person, you don't have to tell me that I have to "think more critically". I already do.

 

As for Steve's concerns about A/K/B development, you are really wrong, I share quite a lot of them, I've agreed with him on quite a few points so far.

Edited June 2, 2015 by L0ckAndL0ad

[Alan8325]

A large chunk of the US Army in CMBS is driving around with an APS that can defeat top attack weapons

And it can stop the Frogfoot's Kh-25 with minimal damage to any components. Awesome tech, that APS.

[Battlefront.com]

The reason why Charles may not do something for CM really fast is because CM engine has a lot of limitations, and not as flexible. Obviously, I have no idea how it is coded, but you can't even do tooltips everywhere where it's needed, because you'd have to hardcode every each of them in, and you don't want to do that. Same with sub-system list and whatever. Which leads me to believe that it isn't very OOP-friendly and/or outdated. Also, BFC's and Russian MoD's budgets aren't really comparable, so all in all, the example is bad.

I'm puzzled. Do you really not understand rather simple and straight forward points, or do you willfully twist them so that you don't have to discuss the implications?

Ian put it well, but I'll go further. You have once again made a rather easily challenged "faith based" presumption which amounts to an extremely naive and horribly flawed concept of how products go from design to practical implementation. In response I related to Battlefront's experience with such things. You chose to completely, and thoroughly, miss the the point or deliberately dodge it by speaking of CM development issues that you haven't any capacity to talk about credibly. So let me restate this so hopefully even you can understand the simple point.

Customers often think of things which are "simple" in their minds. They very often go further than that and explain to us how "simple" they are. If I had a dime for every time a customer told us that "it's easy! All you have to do is this and that and we'd have it! Because you aren't, you are either incompetent or hate us" I could retire right now. What customers, and apparently you, don't understand is that WANTING something is not good enough.

There's another thread going on talking about CoPlay, which is the ability for many people per side to engage in a single battle. Do we have the design experience to implement this? Yes. Do we have the engineering expertise to implement this? Yes. Do we have the budget for it? No. And why don't we? Because we don't have the income sufficient to allocate those sorts of resources to that narrow a feature. To put it into terms you should now understand, we can not "afford" it (i.e. we have the money for it, but not without harming our chances of fiscal survivability).

So that is a case where the customer request is one that we could, in theory, implement but in reality can not. There are other cases, however, where a customer says something is "simple" and it is beyond the capacity of their computers to handle. For example, Fog of War terrain where the mesh of the terrain can be obscured/altered so that the player has to experience the uncertainty of terrain he has not yet explored. The concept is dead simple, the implementation is beyond the technological capabilities of probably all our customer's computers. Certainly almost all of them. This means that even if we did go ahead and develop a theoretical solution it would be impractical. Wanting it doesn't mean it is possible.

Further, there are cases where the customer says something is "simple" but it really isn't either in concept or in terms of engineering or in terms of the average computer's ability to handle it. To this I refer to the long standing request to have the player's battle space interact with a non-playable environment on 2-4 edges of the playable space. Not just visually, but in terms of flaking fire, maneuver threats, etc. I've argued with customers about this 16+ years and some simply are incapable of understanding that it is not "simple", therefore they continue arguing for something which is practically impossible to produce.

So on and so forth.

Which means that your ability to program an intercept vector means absolutely nothing.

As for seeing vehicles in service with APS, there're Israelis, the ones that are fighting official ground war. US aren't in ground war now. Russia isn't officially. If they'll go, they'll be equipping APS, this is why you've put them into CMBS. Why even asking then?

How naive. You can't go from having a system on paper to putting one onto a battlefield before the war is already decided. It doesn't work that way these days. The US has been at war for 13+ years and it has not deployed an APS system. Not Trophy, not anything home cooked. And I'm not talking about one that can defeat top attack weapons since, of course, that's not a credible threat to US vehicles. So obviously there are other considerations that have prompted the US to not put these systems on their vehicles. The US couldn't put them on overnight even if it wanted to.

Now, why did we include APS for specific vehicles in Black Sea? Mostly because we thought it would be more interesting to go with the theory that the US rushed them into service AND was able to do so. I don't confuse a fantasy wargame with reality, neither should you.

Steve

[Battlefront.com]

And you can clearly understand things I was referring to ("collision mesh" calculations in APS algorithms, OOP-friendliness, etc), so I was hoping that we're at least on the same page in terms of basic concepts of engineering behind such systems. I, myself, see no real problems in terms of programming these things. Same with engineering solutions, I've already explained them the way I personally understand them or would've done them myself. Even proper hardware latency can be achieved by doubling detection range, like I've already said.

Here it is in a nutshell... our average customer thinks just like you. "I programmed X and therefore I know you can make feature Y for Combat Mission AND it will be good AND it will be commercially viable". Unless the customer is in the business of making computer games that are similar to the one being commented on, then the customer hasn't a clue what he's talking about and is therefore unqualified to draw conclusions from his personal experiences.

The concept of aiming a gun at a fast moving aircraft is pretty straight forward. Charles has programmed that in a simulation, in fact. Yet the programmer for Sgt. York that I once knew couldn't get the thing to hit targets reliably enough to have a viable product, despite Billions being spent on trying to overcome the problem. So for Charles to tell him "hey, I did it therefore there's no reason you couldn't do it too" is not only an unsound statement to make, it is also one full of hubris. Or naiveté, depending.

Using your logic, because the concept was simple and the programming "straight forward", then the Sgt York should have been an easy success. Yet it wasn't, which means there's a major flaw in your logic whether it is applied to Sgt. York or to T-14. That doesn't mean Russia can't produce such a system, I'm simply saying that your personal experiences in no way has any bearing on knowing if it does or doesn't.

 

But coming and saying some generic stuff like "we don't know if they can afford to allocate resources to do everything at the same time", is what? An attempt to look into their management issues? They obviously have people who are tasked with prioritizing and resource allocation management. Hundreds of people involved. Hundreds of factories and R&D centers. Like, is there anything about them that gives out any warnings that they're doing it wrong? Without looking into specifics, you can't go anywhere further with this.

I went into the specifics of Sgt. York how many times now?

 

And as of my "optimism", I don't understand, again, what the problem is. I know exactly what can be expected, in terms of worst case scenarios. I see quite a few things that I already dislike about newgen vehicles. What I do like is a general movement in the right direction with them, and yeah, it is quite optimistic so far. It's not like I'm being delusional and fanatic about it or something, I'm quite a sane and clean minded person, you don't have to tell me that I have to "think more critically". I already do.

 

As for Steve's concerns about A/K/B development, you are really wrong, I share quite a lot of them, I've agreed with him on quite a few points so far.

True, but here's the issue. If a glass has a certain amount of water in it, but neither you nor I know how much water is in it, why are you so sure it is mostly full just because some guy is thirsty? Or that there is sufficient water to solve his thirst? Especially when your "logic" of why the glass has sufficient water is so easily refuted by counter arguments and evidence to suggest that it isn't.

Your position is, by any reasonable standards, "optimistic". Some would say "wishful thinking" and I have characterized it as "faith based".

Steve

[Kraft]

And it can stop the Frogfoot's Kh-25 with minimal damage to any components. Awesome tech, that APS.

Just use light mission it wrecks the tank completely.

https://dl.dropboxusercontent.com/u/82932123/test%20air%20support.btt

Edited June 4, 2015 by Kraft

[John Kettler]

Steve,

 

While we're talking about the grim realities of real world computer programming, I have a question as it relates to the CMx2 Engine. Back when quite a few of us were wailing and gnashing our teeth over the inability to retrofit ever improved new CMx1 features into earlier games, you kept telling us that this was because the games were hard coded and very difficult to modify. I almost got the sense that you were talking about Charles handcrafting code for each game and in such a particular and specific manner that it was technically difficult and fiscally impossible to go back and put in the new features. In describing the radical improvements the new CMx2 Engine would bring, I distinctly recall reading that it would free BFC from the limits of the CMx1 Engine and enable changes changes to be done in software, rather than hard coded and such. It seems to me, though, that the same sorts of ugly code limitation problems have risen again, as seen in the vexed matter of elevated weapons. I find it bizarre that the code apparently can't accommodate a military design feature which has been around for decades. The M901 ITV, for example, entered service in 1979, nearly four decades ago.  Did the game engine look better initially than it turned out to be? Could you explain what happened, please, or ping Charles and then let us know what he said?

 

Extending the argument to the T-14 Armata, were it in the game, would it suffer from the same elevated weapon issue as the ITV, Krizantema, BRM-3K and other weapons with remote eyes and weapons, or just eyes of one sort or another? After all, the crew is in the hull, which would seem to make the entire turret an elevated weapon, right?

 

kraft,

 

My Mac can't read .btt format, whatever that is. Any chance you could post a pic or something?

 

Regards,

 

John Kettler

Edited June 4, 2015 by John Kettler

[L0ckAndL0ad]

I'm seriously busy nowadays, will respond later.

 

In the meantime, very high res pictures of IFV turrets on T-15 and Kurg-25

 

https://img-fotki.yandex.ru/get/6201/8955119.b/0_9c9d6_11c12796_orig.jpg

https://img-fotki.yandex.ru/get/16183/8955119.b/0_9c9d5_e604b45e_orig

[Sublime]

kettler i do recall steve recently made a comment about mast mounted weapons and such saying they could still probably fudge such a thing by putting what the game thinks is a pair of eyes at the top of the mast...

[John Kettler]

LOckAndLOad,

 

I'll say. Got halfway through the first, whereupon my computer stalled! What is that huge green thing behind the AFVs? 

 

Sublime,

 

Thanks. I vaguely recall some statement to that effect, but I don't understand why the Game Engine (which BFC bought outside, I believe) wasn't built able to handle such things to begin with. 

 

Regards,

 

John Kettler

[BTR]

LOckAndLOad,

 

I'll say. Got halfway through the first, whereupon my computer stalled! What is that huge green thing behind the AFVs? 

 

They are 12 megapixel photos of T-15 and K-25, revealing never before seen details, like the GRAU index of APS munitions printed on them for example. 

[John Kettler]

BTR,

 

There was enough of the DL (about half vertically on the first pic) to see the T-15. No problem there. Instead, I was trying to understand what that huge curved thing behind and rising above the T-15 was. My first impression? It was perhaps a pontoon. Being able to read the GRAU index number is nothing short of spectacular. Also, these (magnifiable) pics are so good I should contact the AFVs' COs and tell them to make sure these guys clean their periscope lenses!  These pics go way beyond the level of the super detailing pics guys used to shoot from my AFV modeling days

 

Regards,

 

John Kettler

Edited June 6, 2015 by John Kettler

[BTR]

That curved thing is a Topol. 

[L0ckAndL0ad]

Alrighty, let's go.
 

I'm puzzled. Do you really not understand rather simple and straight forward points, or do you willfully twist them so that you don't have to discuss the implications?

Ian put it well, but I'll go further. You have once again made a rather easily challenged "faith based" presumption which amounts to an extremely naive and horribly flawed concept of how products go from design to practical implementation. In response I related to Battlefront's experience with such things. You chose to completely, and thoroughly, miss the the point or deliberately dodge it by speaking of CM development issues that you haven't any capacity to talk about credibly. So let me restate this so hopefully even you can understand the simple point.

Customers often think of things which are "simple" in their minds. They very often go further than that and explain to us how "simple" they are. If I had a dime for every time a customer told us that "it's easy! All you have to do is this and that and we'd have it! Because you aren't, you are either incompetent or hate us" I could retire right now. What customers, and apparently you, don't understand is that WANTING something is not good enough.

There's another thread going on talking about CoPlay, which is the ability for many people per side to engage in a single battle. Do we have the design experience to implement this? Yes. Do we have the engineering expertise to implement this? Yes. Do we have the budget for it? No. And why don't we? Because we don't have the income sufficient to allocate those sorts of resources to that narrow a feature. To put it into terms you should now understand, we can not "afford" it (i.e. we have the money for it, but not without harming our chances of fiscal survivability).

So that is a case where the customer request is one that we could, in theory, implement but in reality can not. There are other cases, however, where a customer says something is "simple" and it is beyond the capacity of their computers to handle. For example, Fog of War terrain where the mesh of the terrain can be obscured/altered so that the player has to experience the uncertainty of terrain he has not yet explored. The concept is dead simple, the implementation is beyond the technological capabilities of probably all our customer's computers. Certainly almost all of them. This means that even if we did go ahead and develop a theoretical solution it would be impractical. Wanting it doesn't mean it is possible.

Further, there are cases where the customer says something is "simple" but it really isn't either in concept or in terms of engineering or in terms of the average computer's ability to handle it. To this I refer to the long standing request to have the player's battle space interact with a non-playable environment on 2-4 edges of the playable space. Not just visually, but in terms of flaking fire, maneuver threats, etc. I've argued with customers about this 16+ years and some simply are incapable of understanding that it is not "simple", therefore they continue arguing for something which is practically impossible to produce.

So on and so forth.

Which means that your ability to program an intercept vector means absolutely nothing.

 

We get the "usual Steve" behavior, mkay.

 

Obviously, I do not understand anything. And I haven't said this:

 

BFC isn't a AAA studio, therefore they can't even afford going for a better game engine that can allow OOP-friendly tooltips and scrollable lists.

 

But then again, there's another giant problem with your statement. Customer's "wants"  are optional for your product. They ARE NOT the core (i.e. tactical combat mechanics) of the product that the customer is looking to get. So, when talking military software, we're talking about things that are the core functionality that just HAS to be there. Or it won't get sold in the first place. Why bother with Afghanit, if they can just buy latest Arena off the shelf? The difference is in core functionality that they're looking for.

 

 

How naive. You can't go from having a system on paper to putting one onto a battlefield before the war is already decided. It doesn't work that way these days. The US has been at war for 13+ years and it has not deployed an APS system. Not Trophy, not anything home cooked. And I'm not talking about one that can defeat top attack weapons since, of course, that's not a credible threat to US vehicles. So obviously there are other considerations that have prompted the US to not put these systems on their vehicles. The US couldn't put them on overnight even if it wanted to.

Now, why did we include APS for specific vehicles in Black Sea? Mostly because we thought it would be more interesting to go with the theory that the US rushed them into service AND was able to do so. I don't confuse a fantasy wargame with reality, neither should you.

 

I'm not naive, this is a pure reality that you're obviously not aware of. The question is only in numbers. Russia did employ Drozd in Afghanistan. They did SLAT bars on tanks. They did BMPs that can't swim due to additional armor side plates. (T-55D, T-62D, T-62M, BMP-2D etc). If US and Russia will be fighting on land, they'll get everything they have, including APS. The question is just how many.

Edited June 6, 2015 by L0ckAndL0ad

[L0ckAndL0ad]

Here it is in a nutshell... our average customer thinks just like you. "I programmed X and therefore I know you can make feature Y for Combat Mission AND it will be good AND it will be commercially viable". Unless the customer is in the business of making computer games that are similar to the one being commented on, then the customer hasn't a clue what he's talking about and is therefore unqualified to draw conclusions from his personal experiences.

The concept of aiming a gun at a fast moving aircraft is pretty straight forward. Charles has programmed that in a simulation, in fact. Yet the programmer for Sgt. York that I once knew couldn't get the thing to hit targets reliably enough to have a viable product, despite Billions being spent on trying to overcome the problem. So for Charles to tell him "hey, I did it therefore there's no reason you couldn't do it too" is not only an unsound statement to make, it is also one full of hubris. Or naiveté, depending.

Using your logic, because the concept was simple and the programming "straight forward", then the Sgt York should have been an easy success. Yet it wasn't, which means there's a major flaw in your logic whether it is applied to Sgt. York or to T-14. That doesn't mean Russia can't produce such a system, I'm simply saying that your personal experiences in no way has any bearing on knowing if it does or doesn't.

 

Again, going for specific core functionality from the beginning of the project (= making a completely new APS Afghanit) vs trying to fit some additional functionality on existing system (= trying to modify APS Arena so that it could intercept top attacks) are two different paths, and the second one is much more difficult. And if one can't afford doing drastic changes to be able to go that second path, then he'll most likely fail.

 

I went into the specifics of Sgt. York how many times now?

 

I meant A/K/B specifics. You've missed the question, so I'll repost it:

 

But coming and saying some generic stuff like "we don't know if they can afford to allocate resources to do everything at the same time", is what? An attempt to look into their management issues? They obviously have people who are tasked with prioritizing and resource allocation management. Hundreds of people involved. Hundreds of factories and R&D centers. Like, is there anything about them that gives out any warnings that they're doing it wrong? Without looking into specifics, you can't go anywhere further with this.

 

 

True, but here's the issue. If a glass has a certain amount of water in it, but neither you nor I know how much water is in it, why are you so sure it is mostly full just because some guy is thirsty? Or that there is sufficient water to solve his thirst? Especially when your "logic" of why the glass has sufficient water is so easily refuted by counter arguments and evidence to suggest that it isn't.

Your position is, by any reasonable standards, "optimistic". Some would say "wishful thinking" and I have characterized it as "faith based".

 

Again, too generic.

[John Kettler]

Business Insider published a piece the first week of June which talks about the prominent use of ceramic armor on the T-14 Armata. Am passing the word for anyone interested. Came across the article just now.

 

http://www.ibtimes.com/russias-armata-t-14-tank-feature-ceramic-armor-plates-report-says-1954906

 

Regards,

 

John Kettler

Edited July 21, 2015 by John Kettler

[Stagler]

Like a phoenix from the flames glorious Armata thread arises once more!

[Codename Duchess]

Dr. Dmitry Gorenburg in an Oxford Analytica brief  says that program costs have increased to 2.5 times the projection from the State Armaments Program for 2020.  He also says that production capability from Uralvagonzavod will only allow about 300+ tanks by 2020, vice the thousands some have claimed.  I haven't cross-checked these myselves, but given the nature of fancy acquisition projects, this doesn't surprise me at all.