Hello everyone! Common Sense and 1.12 have been released, and our expansion sales continue to shatter previous records! With the expansion and patch now out, we're going to shift into a different gear with our dev diaries for a while, talking about other things than upcoming features. Some ideas we've had is to discuss our design process, how we handle feedback from fans, and reflections on different parts of the game and where we want to see them go in the future.

Today, however, we're busy working on a hotfix for 1.12, so I thought I'd tell you about that, and also a bit about why there will always be bugs on release of a new expansion.

Let's deal with the hotfix first. From what we've seen, 1.12 has been a smooth launch for the majority of users, with a low bug count in new features, but there were some serious technical issues on certain hardware setups.

The hotfix is expected to be released today or tomorrow, and at present contains fixes for the following issues:

Hotfix 1.12.1 (AS OF WRITING OF THIS POST, THIS IS NOT YET OUT)
- Fixed a bug where the AI would declare suicidal wars due to incorrectly calculating defensive call acceptance
- Spain can no longer form Andalusia and vice versa (preventing endless nation forming loop for prestige)
- Forts can no longer take control of other provinces with forts (capital, mothballed or otherwise)
- Fixed a bug where the AI would accept concede defeat as the only concession even when they had 100% warscore.
- Fixed a bug where single player games started with the 'Only host can save' setting would be unable to be loaded.
- Fixed a bug where some AIs would constantly mothball and unmothball forts (this could cause serious performance hit on lower end machines as well)
- Fixed a bug where the AI would continously march back and forth between two provinces in a fort's ZoC
- Fixed exploit where you could give away ally's provinces even if not occupied in coalition war.
- Fixed a bug where rebels would spawn at very low morale when there were hostile units in their spawn province.
- Fixed an issue with steam workshop removing supported_version from .mod files
- Fixed an issue where .mod files would be printed with garbled data, resulting in CTD on launch
- Fixed an exploit where you could give away the provinces of your war allies even if they were not occupied (you should only be able to give away your own unoccupied provinces)
- Unit movement lock can no longer be bypassed by issuing another move order.
- Fixed artillery models for several different unit packs to have the correct infantry model accompanying it.
- Lowered cost of diplomatic annexation from 10 to 8 dip points per development (since there's more ways to decrease adm cost)
- Autonomy from diploannexation is now 60 (down from 75)
- Fixes issues using the MacBook trackpad when interacting with the map on OSX.
- Fixed a CTD in AI province conquest weight calculation
- Fixed a CTD related to rebels in uncolonized provinces
- Game no longer crashes when forcing nations with subjects to revoke claims.
- Save games saved in 1.12 no longer cause CTDs in 1.11 (only applies to saves made after this hotfix is applied)
- The '+' key should now increase game speed correctly on US/UK keyboards.
- Fixed issue where foreign Separatists defecting to your country caused your country to act as if it was just released.

Note that we are only considering important fixes and tweaks for hotfixes, so if you have a bug you think should be hotfixed, take a moment and ask yourself whether or not it can wait until the larger bugfixing patch that we'll be releasing later in June.


Why do patches always have bugs?
This is a question we get a lot, along with 'Do you even test your games?', and 'Do you even play your own games?'. The answer is, yes, we play our own games, and yes, we test our games. Loosely calculated, about 2400 man-hours of QA has gone into Common Sense, and before a launch every feature is tested thoroughly. Over the course of the development of 1.12 and Common Sense, approximately 1200 bugs have been fixed by the team.

So why, then, do bugs still get into the release? There are two sides to this, and the first one is math.

As of Tuesday night, we had around 20000 concurrent players. If we assume that those 20000 people each play 2 hours that night, that is 40000 hours of play. In order to have equivalent QA test hours to only 2 hours of play on a release night, we would need a team of 30 full-time QA. Scenarios that only happen once every 10000 games will realistically never happen for our QA, and when you factor in that those 20000 players have 20000 different hardware setups... you can begin to see why things like the game not launching on a single core computer (we do not have a single core computer in QA because they haven't been making them for over half a decade) or the engine upgrade breaking mac trackpads (we did not have a mac trackpad in QA, we now do and will use to test future versions) happen.

That's one side of the coin. The other side of the coin is priority.

It's always our ambition to release new expansions without bugs in the new features, and for this reason we consider newly introduced bugs higher priority than older ones. We haven't always done a great job of this in the past, but 1.12/Common Sense had a much lower bug count in new features than previous expansions. There were however, a couple immediately apparent issues, particularly the fact that movement locking did not work at all. You might reasonably ask yourself how such a thing slipped through QA. The answer: It didn't.

The movement locking bug was introduced in the very last build we made for release, as a result of fixing another bug where ZoCs would create weird movement paths. It was only found after the build was done and smoke tested (smoke testing is basically a thorough 'does the game actually run' test that we do on anything we release to the public). Given that we had no other serious known issues at the time, I made the call that the issue was not serious enough to warrant spending another half a day making a new build and testing that build. QA found the issue, I chose not to fix it because the time spent making a new build could be better spent working on our back log of older bugs, and I figured that we'd have to make a hotfix anyway due to the risk for technical issues appearing with the engine upgrade.

The simple fact of it is that we are probably never going to have a launch that doesn't introduce at least one or two serious technical issues, because we do not, and cannot test the game on the thousands and thousands of different hardware configurations that will be playing the game the moment we set the patch live. The measure of a successful launch, in my book, is not that there are no bugs, but rather that there are no serious bugs which could reasonably have been caught by our internal testing.

Do I expect this explanation to change much? Not really, because I think people like easy explanations, and 'Paradox does not even test their expansions' is a much easier explanation than 'In a complex piece of software you will always have some bugs no matter how much QA you do', 'Fixing bugs can introduce new bugs' and 'Not all bugs are worth grinding development to a halt in order to fix'.

Nonetheless, for those who wish to know, there it is.

 

[harvesarmy]

I do not believe they will do /will want to do any event chaining, since it would require reworking tons of events. Automatic delay of popping of rebel units would be problematic (and might be deemed unrealistic), anyway it might conflict with plain revel popping.

I think that slower sieging should not be that hard: if sieging unit is rebel and there is no fort do not win siege after 30 days but say 180 days (even if progress is 100%); it can not be done by sieging ability through. But I agree that they probably wont do it that way.

If we are going to do a timer then I would have them occupy at the same pace, but if you don't clear them out within say 6 months then you would get the modifier.

 

[CrisisCauser]

Yup, update is live. 240 Diplo to annex 30 development Nevers as Burgundy.

 

[Kazum]

It is not in the launcher but game properties -> betas has the final versions all the way back to 1.4

I have been told so on reddit as well, thanks. I am really happy to see that option.

 

[Erixter]

Mods still dont work for me. Is it because they need to be updated to 1.12.1?

Thanks

 

[Heoga]

I'm a software tester myself so fully appreciate the process, the hard work you do, and that there will always be bugs. (Development = old bugs out & new bugs in) I'd be interested in knowing whether, beyond unit testing, you have scripted tests or does the dice rolling system mean you have to fall back to interactive work for further tests.

 

[Silmarion]

Awesome! Thanks for the timely hotfix!

 

[grommile]

Hi wiz, since you are fixing the dip annex cost, can you look at the problem with increased coring costs affecting anex cost?

That is not a bug. That is intended behaviour that existed in recent previous versions. You are not supposed to be able to bypass Hostile Coring Cost modifiers using diplomatic annexation.

 

[unitedbyfakes]

Will we see a fix for the greyed out play button for some people down the line I appreciate all the hard work but I'd actually like to play the game again

 

[Thrake]

We're looking at it. I don't think it's nearly as bad as people think, but we definitely need to explain the ZoC protection against rebels and possibly make some tweaks (a timer before rebels cause siege effects in provinces or the like).

"Typical" rebels (those you get warnings for) are OK. You know they're coming and there are many ways to counter it. Now however, we have event spawned rebels. They can cause all sort of troubles. I had for exemple catholic zealots spawning on an island with mothballed fort, I had troops right next but came a few days too late so occupation turned it catholic; I had then to attack with amphibious penalty, besiege the fort (120 men garrison...) and convert it back.

I mean, event rebels, OK. Rebels occupying, OK. Rebels converting, or increasing autonomy, or enforcing bad province modifiers, OK. But it worked better when I had a chance before they enforce their bad effects on provinces.

 

[TheDarkMaster]

Perhaps rebels should not be able to enforce their demands on provinces until they have occupied the fort that controls it?

Still leaves the issue of areas that don't have forts in them. Especially if you can't actually afford to build forts.