Victoria 3 - Dev Diary #68 - Patch 1.1 Changelog (part 4)

[agaabrieel]

Looking forward to Monday. Sounds like a good chunk of the game's issues are either already sorted in 1.1 or being tested for 1.2.

When we get the war and diplomacy tweaks Wiz has been talking about, I think we'll be in a good place - and a lot sooner than I thought it'd be.

Same here. Some of these problems really killed the fun for me, so I haven't played in a while. Can't wait for 1.2 to finally dive deeper than ever in this game. Paradox games are always like wine, after all: the older the better.

 

[jkchart]

Amazing work, thank you and can’t wait to play the update!

 

[Baalzamon85]

There was nothing passive aggressive, and arguing about 'tone' on an Internet forum with a lot of people not having English as their first language is...silly at best.

People need to understand the difference between opinions on design and actual bugs. If you have game crashes , there it's quite objective what needs to be fixed.

What effects treaty ports or any other design mechanic is a highly subjective topic and you as a customer can't act like your opinion on what should be done is unequivocally the correct one(even worse not even propose an alternative) . It requires some basic form of humility even though it's on the internet, otherwise people won't listen to what you have to say.

 

[unmerged(148774)]

Does anyone know if the rulers start to die? I won't touch a game where my king lives for 110 years and gets a bunch of negative modifiers.

It was mentioned that it will be addressed in the patch.

Also, when people are fired or retired it is not an automatic death sentence. Lol.

 

[ScottyWired]

Great stuff. I'll have to have another short campaign to see the state of the game.

I still think Vicky 3 needs some time in the oven, but part of the Paradox fun is watching a title evolve over time.

 

[Sotek]

Does the OOS fix only cover exactly the hotjoin fix, or is it possible other OOSes are fixed?

 

[lachek]

Couldn't this be alleviated through changing/expanding the qualifications system though? So that the pools for certain jobs are smaller, allowing more granularity in wage changes? Non-game designer spitballing I admit.
Though I could be getting too hung-up on not having a good enough head-canon of what's going on with these wage increases, it is just really taking me out of it (as well as probably more importantly preventing the simulation of historically very profitable but also very exploitative industries)

Not a bad suggestion, but this would require us to have floating wage levels for every profession type in a building. At the moment, buildings only keep track of one "wage rate", which is the wage it would pay a (non-discriminated) Laborer, and other professions get paid some multiple of that. Under a system that relied more on Qualifications to determine labor competition than is the case currently, we would need for buildings to be able to pay e.g. Engineers a lot more than Machinists due to the increased pressure on that pool of workers. That is something I would like to explore in the future, but it adds a fair amount of complexity.

 

[lachek]

The fact that POPs don't seem to tolerate a slight decrease in SoL levels. Going from 19.5 to 19.3 seems to already be enough to make some POPs become radical, which shouldn't be like that.

The average SoL metric you see in the top bar is great as a general overview of how things are going for you as a nation, but actually terribly misleading on its own when trying to determine where Radicals are coming from and how to address it. The reason for this is that Wealth changes between pops, especially across class boundaries a lot more than it changes on average, generally speaking. To take one example, Britain starts to import Grain from you, raising Grain prices across the nation. This massively benefits the Aristocrats that own the land the farms are built on, because they rake in the profits - but the pops who work the farm and has to buy that Grain are not getting paid any more than they used to (unless their Standard of Living drops below the minimum they'd accept, as per the parallel conversation in the comments). As a result, Britain importing Grain from you might cause average SoL to increase because overall your buildings' effective Productivity has increased, putting more wealth into circulation, but simultaneously this could have drastically increased the wealth gap in your nation, leading to more Loyalists among some pops but also more Radicals in other parts of the population.

Visualizing this better by breaking down SoL trends in different parts of the population is something we're investigating at present, but for the moment I can say that this system works exactly as intended: even minor drops in SoL will cause a one-time increase of Radicals and vice versa.

 

[lachek]

It's late, so perhaps I missed it. But is the issue of rebellions getting rebellions that becomes independent when first rebellion is crushed, fixed?

Fractal rebellions and uprisings should also be fixed, yes! Countries created due to civil wars should no longer be able to have their own civil wars.

 

[Amorenkaire]

Couldn't this be alleviated through changing/expanding the qualifications system though? So that the pools for certain jobs are smaller, allowing more granularity in wage changes? Non-game designer spitballing I admit.
Though I could be getting too hung-up on not having a good enough head-canon of what's going on with these wage increases, it is just really taking me out of it (as well as probably more importantly preventing the simulation of historically very profitable but also very exploitative industries)

One way to explain the extrapolation of wages to expected wages is labor disputes and the fact that peasants don't immediately go from rural hillbilly country to the cities as soon as a wanted poster is put up in New York City.

Employees dissatisfied with their wages have plenty of options to turn to before becoming radical terrorists or separatists that's not currently modeled even before the advent of socialism. And many times factories would be trying to attract "skilled" workers, not just people they need to train. Which sadly isn't factored but you can imagine why they peg to a certain minimum standard is wanting more of those than another.

 

[lachek]

I see the trade changes and it looks like you 'fixed' circular trades while leaving the ability to raid someone else's market by buying high and selling low (i.e. the price inversion problem). Now we have no workaround to re-import goods being effectively stolen from our markets when fixing price inversions would've killed both birds with one stone.

There have been many discussions around how trader price determinations affect trade volume and whether that is strictly correct or if it actually upsets the economic system as a whole, with good points made on both sides. The reason we opted for the system of average pre/post-trade prices we did was because we figured trade is strictly a transfer of value between two agents where the optimal volume both depends on and affects those prices, whereas in the rest of the economic system, demand and supply are not actually directly price-dependent as such. By applying the full burden of the transactions on the price prior to resolving all those transactions, we figured we would artificially decrease the optimal trade volume. However, the argument could also be made that trade creates Buy and Sell Orders which affect prices, and by using a different price algorithm for traders than production buildings and consumers we're in effect letting traders (and tariffing nations) extract value off trade to the detriment of domestic industry. That case is sufficient reason for us to experiment with it, to ensure we're not destroying the trade system's dynamics or the market balance in the process. But we aren't sufficiently convinced that we're just going to change the algorithm, give it a quick go to make sure it doesn't crash, and push it into a patch without a lot of playtesting and balancing. That is especially true since we did find an actual bug when investigating and fixing circular trading, which might also impact the player experience of regular trade as the volume calculation has now been fixed.

So no, I don't agree that putting our efforts towards experimenting with the trade algorithms while under extreme time pressure rather than fixing obvious bugs would have been time better spent. We can agree to disagree on that point, even while we can both agree we're looking forward to more intuitive and well-balanced trade in the future.

 

[lachek]

Does the OOS fix only cover exactly the hotjoin fix, or is it possible other OOSes are fixed?

It is possible, since OOSes are often the result of bugs or dangerous use of threading, which could have been resolved in the course of other fixes. OOS issues are very highly prioritized so where we haven't fixed them explicitly, it's usually due to them being very rare or that we're no longer able to replicate them on the latest builds.

 

[durbal]

There have been many discussions around how trader price determinations affect trade volume and whether that is strictly correct or if it actually upsets the economic system as a whole, with good points made on both sides. The reason we opted for the system of average pre/post-trade prices we did was because we figured trade is strictly a transfer of value between two agents where the optimal volume both depends on and affects those prices, whereas in the rest of the economic system, demand and supply are not actually directly price-dependent as such. By applying the full burden of the transactions on the price prior to resolving all those transactions, we figured we would artificially decrease the optimal trade volume. However, the argument could also be made that trade creates Buy and Sell Orders which affect prices, and by using a different price algorithm for traders than production buildings and consumers we're in effect letting traders (and tariffing nations) extract value off trade to the detriment of domestic industry. That case is sufficient reason for us to experiment with it, to ensure we're not destroying the trade system's dynamics or the market balance in the process. But we aren't sufficiently convinced that we're just going to change the algorithm, give it a quick go to make sure it doesn't crash, and push it into a patch without a lot of playtesting and balancing. That is especially true since we did find an actual bug when investigating and fixing circular trading, which might also impact the player experience of regular trade as the volume calculation has now been fixed.

So no, I don't agree that putting our efforts towards experimenting under extreme time pressure with the trade algorithms rather than fixing obvious bugs would have been time better spent. We can agree to disagree on that point, even while we can both agree we're looking forward to more intuitive and well-balanced trade in the future.

I understand those points, but the fundamental problem is that the math you're using is incorrect. Using the arithmetic mean to get the mean value of the pricing function is incorrect since that only works when the function is linear while the pricing function is not. The correct mean value needs to be calculated through integration or a better approximation method as @Tempscire explains here: https://forum.paradoxplaza.com/foru...oncerns-about-trade-gdp.1558055/post-28653780. This incorrect mean causes the price inversions. If you guys are still not sure there's more information in that thread or I'm sure many people participating in that thread can explain further.

 

[lilunxm12]

Has mostly what I want, but one critical fix missing.... Civil wars shouldn't generate infamy
Taiping rebellion always generate 100+ to make cutdown size available to enemies

 

[tahlaskerssen]

There have been many discussions around how trader price determinations affect trade volume and whether that is strictly correct or if it actually upsets the economic system as a whole, with good points made on both sides. The reason we opted for the system of average pre/post-trade prices we did was because we figured trade is strictly a transfer of value between two agents where the optimal volume both depends on and affects those prices, whereas in the rest of the economic system, demand and supply are not actually directly price-dependent as such. By applying the full burden of the transactions on the price prior to resolving all those transactions, we figured we would artificially decrease the optimal trade volume. However, the argument could also be made that trade creates Buy and Sell Orders which affect prices, and by using a different price algorithm for traders than production buildings and consumers we're in effect letting traders (and tariffing nations) extract value off trade to the detriment of domestic industry. That case is sufficient reason for us to experiment with it, to ensure we're not destroying the trade system's dynamics or the market balance in the process. But we aren't sufficiently convinced that we're just going to change the algorithm, give it a quick go to make sure it doesn't crash, and push it into a patch without a lot of playtesting and balancing. That is especially true since we did find an actual bug when investigating and fixing circular trading, which might also impact the player experience of regular trade as the volume calculation has now been fixed.

So no, I don't agree that putting our efforts towards experimenting with the trade algorithms while under extreme time pressure rather than fixing obvious bugs would have been time better spent. We can agree to disagree on that point, even while we can both agree we're looking forward to more intuitive and well-balanced trade in the future.

Can we please get a bit of clarification then?

This thread about price exports being broken is a CONFIRMED BUG by the Paradox team : https://forum.paradoxplaza.com/foru...invalid-low-export-price-calculation.1556171/

"We're aware that there's issues with price determination for trade routes, and are looking at how to fix those."

What I don't get is if the "circular" fix would adress this issue (and price inversion, amongst others) or it won't. Because if it won't then what I get from what you are saying is that it's not worth the effort fixing a bug. Trade being riged and broken is extremely important. For me basically makes the difference of playing or not playing this game.

Also, I don't think changing an algorithm needs to be the only solution to the problem. It's a problem that can probably be addressed in different ways. As a player all I care is enjoying the system and feel immersed. Victoria 3 immersion is about deeply engaging into the economy and politics of the game. Trade in it's current state breaks such immersion by not following logical conclusions and not giving a player ways of counteracting it. Either one of those needs to change imo.

 

[Kyoumen]

- "Devout Scandal" no longer has a sentence starting with a lowercase letter

Finally, the game is playable!

 

[lachek]

I understand those points, but the fundamental problem is that the math you're using is incorrect. Using the arithmetic mean to get the mean value of the pricing function is incorrect since that only works when the function is linear while the pricing function is not. The correct mean value needs to be calculated through integration or a better approximation method as @Tempscire explains here: https://forum.paradoxplaza.com/foru...oncerns-about-trade-gdp.1558055/post-28653780. This incorrect mean causes the price inversions. If you guys are still not sure there's more information in that thread or I'm sure many people participating in that thread can explain further.

The pricing function is linear, ranging from 0.25 to 1.75 of base price and reaching those bounds when sell / buy is 2:1 and 1:2 vice versa and progressing linearly based on the ratio between buy and sell orders in between. Not sure where the claim to a concave pricing function is coming from, this is pretty well outlined in both tooltips and the defines file (the PRICE_RANGE and BUY_SELL_DIFF_AT_MAX_FACTOR defines in particular).

The price inversions are rather originating from traders optimizing their volume based on an average of pre- and post-trade prices, but then applying the full brunt of this volume as Sell and Buy orders in the respective markets. This essentially lets them execute a number of profitable transactions "before" the final market prices are actually set, leading domestic market agents to have to buy or sell at (probably) unfair prices by comparison, particularly when one market is much bigger than the other. We'll try to address it like I said, but please understand that even if a different algorithm was to work better and look more sane at large volumes, there's no guarantee this will magically solve all problems without causing new ones.

 

[tahlaskerssen]

The pricing function is linear, ranging from 0.25 to 1.75 of base price and reaching those bounds when sell / buy is 2:1 and 1:2 vice versa and progressing linearly based on the ratio between buy and sell orders in between. Not sure where the claim to a concave pricing function is coming from, this is pretty well outlined in both tooltips and the defines file (the PRICE_RANGE and BUY_SELL_DIFF_AT_MAX_FACTOR defines in particular).

The price inversions are rather originating from traders optimizing their volume based on an average of pre- and post-trade prices, but then applying the full brunt of this volume as Sell and Buy orders in the respective markets. This essentially lets them execute a number of profitable transactions "before" the final market prices are actually set, leading domestic market agents to have to buy or sell at (probably) unfair prices by comparison, particularly when one market is much bigger than the other. We'll try to address it like I said, but please understand that even if a different algorithm was to work better and look more sane at large volumes, there's no guarantee this will magically solve all problems without causing new ones.

Maybe giving ways of counteracting this behavior or limiting it could be a solution without needing to change the whole system. Usually it's better to cure than to treat the symptoms, but maybe not in this case. If players had more ways of limiting exports per good or setting tariffs on exports per good could help to fight it.

 

[Amorenkaire]

Maybe giving ways of counteracting this behavior or limiting it could be a solution without needing to change the whole system. Usually it's better to cure than to treat the symptoms, but maybe not in this case. If players had more ways of limiting exports per good or setting tariffs on exports per good could help to fight it.

Game design, like medicine, suffers from limited time to do things, and so it's not outlandish to compare it to a triage system.

There's a known major issue with trading. A rebuild of the formula 'might' fix the issue and create a better experience in general, but that comes with additional code and QA hours to test every knock on effect it might have. And it's impossible to measure how this new system would function compared to the original system was meant to.

Sorting out computational bugs, however, might require less code hours, and less QA time because it just needs to check to see if it's improved the current system by fixing it's most egregious but. Freeing those code and QA hours for other ideas and tasks desired for the post release road map.

It's possible they'll change the trade formula to something better down the line, but for now it was a question or a quick fix to a bug and some general design issues lingering now, or dealing with the issues until 1.2 at the earliest if not 1.3 or 1.4.

 

[lachek]

Maybe giving ways of counteracting this behavior or limiting it could be a solution without needing to change the whole system. Usually it's better to cure than to treat the symptoms, but maybe not in this case. If players had more ways of limiting exports per good or setting tariffs on exports per good could help to fight it.

I hear you on that ultimately it does come down to the player experience of the system, but if we do have a fundamental balance issue in the economy system - which is not unlikely to be the case - doing a proper fix early in the game's lifecycle is definitely preferable to a smoke-and-mirrors solution. We also want to take care to not give countries full control of every nuance of their trade policies without pushback, since it's completely contrary to both modeling the international market forces that lead to economic imperialism and the political interests of your pops. I have no doubt we'll find a solution to the balance issues we currently have with trade, we just need a bit more time.