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

[Wizzington]

It's more like "why should I care about passing welfare laws when my coal miners are dressing in silk and enjoying fancy cheese."

Which isn’t really something you'll see with wages pegged to minimum acceptable. That caps out at 15 for poor strata with era 5 social tech and 100% literacy.

 

[PDJR_Alastorn]

Since its not written i would like to ask. Will there be a change infamy cost for return states in this patch?

I am not complaining actually i like the patch notes. I just want to know because i really like to play ottomans, japan and for both of them return state is really matters.

So this one required me to do some digging in the jira database.
It was fixed, but was fixed by a tangentially related task which is why it didn't show in the changelog and patchnotes because that is made off of the git commits and not the Jira database resolutions.

 

[MrNibbles]

.... I have nightmares of this in ways you cannot comprehend.

.. one more time?

 

[Wizzington]

Agreed that it’s annoying to never see the AI colonize there, but I’d be a little concerned about AI Australia colonizing lots of stuff in Indonesia if this change were made.

I’ve been wondering if there should be another colonization law, which only allows colonization of bordering states. Would be nice in this case, as well as for the US, Canada, Russia, Japan, and a few other places as well.

EDIT: Just wanted to add that all of these changes are awesome, really happy to see this patch come out before holiday season starts.

1.2 will have a whole slew of changes here, with mechanics for claims on colonies, more countries starting with colonial institutions, etc.

 

[lachek]

I still don't really understand the rationale for this, there are in-game mechanics for poor people being unhappy with their low wages and forcing higher wages through legislative change - radicalization -> movements; why completely sidestep this mechanic by having wages raise automatically to an acceptable level?
It just feels wrong for a period which birthed the trade union movement for what I can only assume to be a simulation of collective bargaining to be handled in the background completely separately from the politics system.

The issue is that if buildings only ever raised wages when there was a labor shortage for the jobs they're hiring for, you would see wage rates sit just above subsistence level until you put every single one of your peasants to work in the factories, and then suddenly all buildings in the state would start to compete with each other for workers until their wages matched their productivity and no profit is gained at all. It's not a good experience for the player and feels very wrong (believe me, it is how it used to work earlier in development).

With the system tuned such that very profitable buildings will raise wages at least up to some threshold - we've chosen the radicalization threshold, the point where pops feel like they'd rather fight and die than accept their situation - there's a more gradual increase in wages as the productive workforce increases, which makes more sense when you see it in action. You will still see radicalization in the buildings whose margins are more pressed, or even failing, and there are many other sources of radicalism to create the effect you're after.

 

[PDJR_Alastorn]

.. one more time?

We said that the last 3 times... its just the lie we tell ourselves.

 

[MrNibbles]

MrNibbles doesn’t get a blue highlighter or any likes? Poor MrNibbles.

Might be because I wrote the post as admin instead of regular staff? Either way, all good

 

[MrNibbles]

Why can't I like your comment. I want to encourage this behavior!

Thank you.. but I would not encourage my trolling. There is a reason I don't post that much on the forums anymore. Me trolling the community was really bad some years ago.

 

[PDJR_Alastorn]

I like the Dev diary, and am excited to try it out.
A small suggestion if you’re already changing some town names. “Da Aar” in Cape Colony should actually be “De Aar.”

Also, is there anyway you could add some event that moves post-Confederation Canada’s capital to Bytown, which is then renamed “Ottawa?” It’s weird to keep seeing a Canadian state centred in Ft Douglas.

I fixed De Aar, or I'm like 95% sure I did.
I went the loc files with a spellcheck, and a really good podcast because someone had to.

 

[PDJR_Alastorn]

Personally it doesn't bother me if the US doesn't fully expand but seeing the random bit of Mexico surrounded by the US every game is painful IMO.

- Manifest Destiny now provide claims on the colonized split states of Mexico

 

[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.

 

[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.

 

[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.

 

[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.

 

[lachek]

If the wiki is correct, the pricing function is the following:

price = Base_price*(1+0,75((buy-sell)/min(Buy,Sell)))

Now lets says you have a market E with Buy_E=200 and Sell_E=300 and a market I with Buy_I=200 and Sell_I=100, a base price of 1 and a trade route exporting t goods from from E to I. Then the price difference is:

PD = price_I-price_E = 0,75((200-100-t)/(min(100+t,200)-(100-300+t)/min(200+t,300))=0,75((100-t)/(100+t)-(-100+t)/(200+t)) if 0=<t=<100.
This is definitely not linear in t!
In fact even in a single market the price is not linear in the traded volume for example in I we have
P_I(t) = 1+0,75((100-t)/(100+t))=1+0.75(-1+200/(100+t)) for 0=<t=<100. This is a constant plus a convex function in t, as 1/t is clearly a strictly convex function (on the positive half-axis).

So either the wiki is wrong or the price function is strictly convex in the trade volume for at least some volumes. In the above example the function gets linear for t>100. The min in the function is responsible for it being non-linear.


Regarding the second paragraph. If the function was really linear then averaging post-and pre-trade prices would give you exactly the area underneath the price difference function. I.e. the profit function as in Profit = (PD_PostTrade+PD_PreTrade)/2*Volume would be the antiderivative of the price difference function. This implies via the fundamental theorem of calculus that the price difference function is the derivative of the profit function. In particular the profit function can only be maximal, if the price difference is equal to zero. Therefore, you would not have a price inversion problem. Granted you do not differentiate continuously, but in a discrete way and currently do not search exactly for the optimum. Therefore, the volume would probably slightly overshoot the zero price difference mark. But this is not related to the function being strictly convex or linear.

Edit: Fixed a typo in the formula.

I think the wiki is wrong. I'll just copy/paste pseudocode here:

MaxPriceVariability = BasePrice * PRICE_RANGE
MaximumDifferenceFactor = BUY_SELL_DIFF_AT_MAX_FACTOR - 1
BuySellDifferenceRatio = Min( ( Max( Buy, Sell ) / Min( Buy, Sell ) ) - 1, MaximumDifferenceFactor )
PriceAdjustment = MaxPriceVariability * ( BuySellDifferenceRatio / MaximumDifferenceFactor )
FinalPrice = ( Buy > Sell ) ? BasePrice + PriceAdjustment : BasePrice - PriceAdjustment

It is true this makes it a piecewise linear function, and when the price in one market crosses the base price threshold that might make it the curve appear concave? It is likely also true that this means doing a straight average between pre- and post-trade prices could result in the wrong average based on volume traded no matter what, and doing some calculus might be necessary to find the true value. As a first pass we're going to attempt to use post-trade only prices for trade, since this is most likely to be correct anyhow.