DzrtFox

Let's not over-complicate this. A lot of things are hard to do, but get done anyway. Also by small independent game developers.
Of course nobody expect a magic campaign generator that can produce quality campaigns like KG Peiper at the push of a button, but a basic map generator would not be that hard to code, and a simple system to assign types of missions, plonk down some deployment zones and objectives could definitely be done. It's all about scoping the project right.
In the end, it depends more on priorities than on whether it's too hard to do. The reason we don't have a campaign generator right now is that Steve clearly thinks other stuff would be a better use of the time. Which is fine with me. But the idea of a random campaign generator is good. It's one of the things I would get excited about in a new release. Having pixeltroops speaking with Australian accent isn't - no offense to the Aussies 
 

I'm a very long term lurker (well, since CMBB) but have quit playing and/or purchasing anything BF releases. It's not hatred, just disappointment with company policy, charging for performance patches, late deliveries, poor communication with the community, and massive amount of gate keeping I see here by people hostile towards anyone who questions company policy. I would love to see things go back to the way they used to be, but unless that happens myself and many others will likely be spending less money. The general attitude towards Battlefront I see these days is similar to mine, not exactly hostile, but not terribly impressed or looking forward to their products anymore. It's not really sustainable, one only has to look at the activity level on this site to see how much smaller their customer base has become. No need to stick your heads in the dirt.

Whoa, was this seriously 2 updates in a week's time?!  😀  Thank you for the update, Elvis!!  I think that's all that even the whiniest of us want to see, whether it's good news or bad.
I've said it before and I'll say it again...  you deserve a raise!  😀

You need to close that barn door before and not afterwards!
Steam (not a fanboy) does a few things rather well. These being: cost, exposure, and DRM (not too damaging). Going back to a series of walled gardens with diverse costing, limited titles, and DRM that mangles systems (or incompatible with competing DRM!) is a pipe dream. There are a lot of indie games that would die of obscurity without it.
I understand the larger publishers wanting to claw more money back but, that isn't a business plan. Execution is the only thing that matters. Steam executes. EA/Blizzard/etc. can't. Too many decades of easy money are wired into their DNA.
Apologies for being off topic.
 

The odd part was that CM1 had to go since it took so long to modify due to how models and data were stored.  Hence CM2.  Now we are two years into waiting for a patch due to how the models and data are stored...

As to complexity of the game, its no more complex than Graviteam or Il2.  And a completely valid point is legacy code being the issue.  Its seems to be the same issue over at eSims with Steel Beasts also.  But this game was developed around 2006/2007, not 1999.  That's not far from when Graviteam originally hit the streets.  They are just a small shop also. 
To me, the main difference is Graviteam eventually got in bed with Steam and eliminated a number of logistical issues with their game they were wasting their time with.  As soon as Graiteam went to Steam, updates started coming out more frequently.  BFC has chosen to build all that themselves.  Think of all the time Steve has stated he spent fixing the store that could have been spent fixing all these OOB issues.  Is that worth the piece of BFC's soul that Steam asks for?  I don't know.

I understand the point that you're trying to make. It has some validity when the design lends itself to rapid alterations. I just happen to be one of these "if it's not broke" Luddites and would rather not see any patches to a design this "complex". Sure, "content" tweaks are one thing. The current "mods" attest to how benign such alterations can be as the likelihood of impacting engine behavior is minimal. Altering unit responses under certain conditions and path finding are more fundamental and apt to cause a lot of problems with perceived 'fitness'. Some caution is warranted even if it means years...
 I suspect we are dealing with an older code base that is straining. There seems to be a lot of effort lately to consolidate core features after the fact. Perhaps to be better positioned for CM3... dunno. I'm an optimist that way.
You get to point where your process and discipline was excellent 20 years ago, good at 15, fine at 10, doable at 5 but, then very rapidly breaks as the years of Christmas's past all come home to bite you. It's always something that is at first perceived to be 'minor' that kills such a host.
I do understand your point. I would rather we deal with expectations and transparency as it's better to always be 6 months away over the course of 22 months than it is to always be 3 months late, or imminent, over the same period.

I am a software developer also, so I understand as much as anyone that predicting release dates is an almost impossible task.  You nearly always hit unexpected roadblocks in this business that are almost impossible to account for until you get down & dirty in the code.  I am like Steve in this aspect - I tend to always give a very optimistic "best case" date when I start a new project, and I very very rarely actually hit that date. 
The difference is that once a week, I inform my bosses of any challenges I'm encountering and update my estimated completion date based off of the latest information I have.  If I made a habit of saying I will have something complete before the beginning of March then completely going silent until almost the end of April, I wouldn't have a job.  It takes literally 5 minutes to give an update, and it shows the people who provide my livelihood that I am a) actually making progress and b) have enough respect for them that I will keep them in the loop as to what's going on.
I am very glad to see that Elvis will be taking this role on.  Honestly if it wasn't for the outstanding support he provides for this company, I would have completely moved on long ago.

I am a software developer also, so I understand as much as anyone that predicting release dates is an almost impossible task.  You nearly always hit unexpected roadblocks in this business that are almost impossible to account for until you get down & dirty in the code.  I am like Steve in this aspect - I tend to always give a very optimistic "best case" date when I start a new project, and I very very rarely actually hit that date. 
The difference is that once a week, I inform my bosses of any challenges I'm encountering and update my estimated completion date based off of the latest information I have.  If I made a habit of saying I will have something complete before the beginning of March then completely going silent until almost the end of April, I wouldn't have a job.  It takes literally 5 minutes to give an update, and it shows the people who provide my livelihood that I am a) actually making progress and b) have enough respect for them that I will keep them in the loop as to what's going on.
I am very glad to see that Elvis will be taking this role on.  Honestly if it wasn't for the outstanding support he provides for this company, I would have completely moved on long ago.

Different type of profession but still relevant for the discussion:
I am a pilot flying about 200 passenger per leg from A to B.
There are a LOT of variables at work in the process getting passengers and their luggage from A to B safely and in a timely manner.
There are a few cardinal sins to be made when things do not go as planned and get people angry quickly in my experience:
-Not giving any information at all
-Making promises you can’t make true.
-Lying about the situation
I often see that we are affraid to bring bad news and then try to make plans to keep people happy as long as we can, or just decide not to give information in order to avoid discussion.
This doesn’t work and frankly, people are perfectly capable to accepting bad news.
Its all about how the flow of information is managed once things go wrong that define wether those 200 people disembark with respect or outrage in the end.
- Addressing people frequently even though there isn’t any news is very much appreciated.
-Giving a timeframe helps people feeling respected even though you might have to adjust that timeframe once in a while.
I am not saying I am a guru, but these are important lessons we get taught as captains and I feel its quite applicable to whats going on here lately.
Just my two cents, really.

Fair enough but it is still a bit aggravating that a hotfix hasn't been released separately. Because there is a piece of code included in SF2 that works just fine and clearly fixes this behaviour.

I am not a person then it seems. 😉
Sorting out the issues with tentative icons, mortar acquiring issues, Bren fire rate issues, also yes some TO&E things (purchasing Vickers detachments giving you Headquarter detachments instead, whole formations missing in QB that exist in SD, formations missing their vehicles and so on). Then yeah sure after all that infantry under artillery fire behaviour would be good.

I don't understand how TO&E has anything to do with patch 4 issues. I mean I am glad they are trying to fix issues in this area but really all people have been asking for is a fix for infantry under arty fire leaving cover. An issue that was introduced what two years ago? Two years is a long time for a fix. I really feel the TOE should have been tackled separately.

If I may - there's nothing wrong with loose ETAs as long as they are in the future. Push the ETA out further before you slip past it. The worst that happens is that you deliver "early" as in something intended for a month(s) down the road is out next week instead.
It's easier to be forgiven for delivering sooner. Sure, you'll have someone bitch that you said June but actually released it April 30th. But most will forgive.
The reverse isn't true as these, now, 23 pages of posts attest to.
All the best. Always.

There is nothing wrong with giving out ETAs and nothing wrong with missing them if something comes up, but when it becomes obvious you are going to miss your ETA you should inform interested parties. To not do so is a Dick Movetm

I don't really understand how a standardized WW2 TO&E got intertwined with a fix for this bug when it's been known about for over 2 years and Engine 4 users have already had to endure the wait for CMSF2 before the fix was supposedly "just on the heels of its release".
I'm assuming this is for a future module or modules, but what about the people who already paid for Engine 4 (or SF without updated campaigns)?  Couldn't this have waited a little while?

Whining has more to do with no information, let alone a simple revised ETA, being provided. It's not rocket science - revise a slipped March deadline by providing a *timely* update of... July or October or early-2020 [pick a date]. Posting every other month that we're almost there isn't an effective way of communicating with your customers.
It's not that complicated. What you want to avoid is the mishandling of expectations. Said expectations being set initially, not by the customer, but by the developer.
It's not difficult... post an an update before you blow past the last one. Otherwise, you mangle expectations.
Anyhow, it is what it is. It's obviously more effective to be reactive rather than to be proactive with deliverables.
Plus, it's lot more fun to be wading through 22 pages of my useless posts than it would be to reference a locked thread of *timely* updates from the developer.
Now let's back to eating our young...

LOL - I did not say this is easy and this is to be done for the current patches. This is just an investment going forward. The more modules or new games introduced, the more problems the beta testers will have to cover everything. And it will harder and harder to deliver patches that won't break game 1 or 3 to refer to Elvis' post.
Sure, this will impact the developers to create the API / CLI needed. But, the developers don't necessarily have to write the tests. The super individuals with the positronic memories (sorry Star Trek 🤣) may write them inside a common framework for testing automatically each changes on each games.
Based on my own experience, the time gain is prodigious and allow to concentrate on the future instead of repeating over and over the same tests of the existing.
But, yeah, you are completely right. I do not know the complexity behind TO&E database or the rest of all the CM software. You are the experts and you know what you are doing. This is just my experience and I can tell you that my testers are very happy of the automation framework we have built.
Anyhow, a big THANK YOU for all the beta testers working hard to deliver those patches.

I don't really understand how a standardized WW2 TO&E got intertwined with a fix for this bug when it's been known about for over 2 years and Engine 4 users have already had to endure the wait for CMSF2 before the fix was supposedly "just on the heels of its release".
I'm assuming this is for a future module or modules, but what about the people who already paid for Engine 4 (or SF without updated campaigns)?  Couldn't this have waited a little while?

In my opinion (that and a dollar won't get you a cup of coffee anymore, maybe a thimble of coffee though) BF has been tying too much into each patch.  I think they said the same thing further up in this thread and that future patches would be more limited - but then again maybe not.

I don't really understand how a standardized WW2 TO&E got intertwined with a fix for this bug when it's been known about for over 2 years and Engine 4 users have already had to endure the wait for CMSF2 before the fix was supposedly "just on the heels of its release".
I'm assuming this is for a future module or modules, but what about the people who already paid for Engine 4 (or SF without updated campaigns)?  Couldn't this have waited a little while?

I don't really understand how a standardized WW2 TO&E got intertwined with a fix for this bug when it's been known about for over 2 years and Engine 4 users have already had to endure the wait for CMSF2 before the fix was supposedly "just on the heels of its release".
I'm assuming this is for a future module or modules, but what about the people who already paid for Engine 4 (or SF without updated campaigns)?  Couldn't this have waited a little while?

I would have thought after 12-13 years of building and patching these games that someone at BFC would have figured out a more methodical way of doing at best, or figured out the effort to do it at worst.

If you have all this complicated changes, and they are trying to implement them in the game, then the logic thing is to write it down, get it approved and then implement it according to the approved document. I can't see why this isn't the logic way. It doesn't have to be a single document, you can create one per force or per year, I don't know. Then have testers check the units against those documents. Lack of knowledge by the testers can't be an excuse, you have to give them the tools to know if something is wrong. That or hire professional historians as testers.
But I'm a bit confused about what the standardization that has been thrown around means? Is it that units where created using different methods in each game and they have now decided to use a single method across the games even tough units are composed differently in terms of men?

Again... beating a dead horse....
Roadmap
deliverable A         date X deliverable B         date Y deliverable C         date Z Don't need to know details.
Absolutely prefer periodic updates  that are better than quarterly. We seem to be no farther ahead than we were when SF2 was released in December...
This wouldn't be a problem if this was known months ago. I'm not sure what to make of an update that is even less informative than the previous one issued last Jan/Feb.