In-game manufacturing profitability view

[redv]

In the profitability wiki page is assumed that entire workshop placed for manufacturing of the calculated item.
Moreover, assumed that this item will be manufactured whole month.

But this is not true in general case.

[redv]

Fixed version:

Code: [Select]

int ManufactureInfoState::getMonthlyNetProfit()
{
static const int HOURS_PER_MONTH = 365 * 24 / 12; https:// Also you can use HOURS_PER_CURRENT_MONTH instead

const RuleManufacture *item = _production->getRules();
int numEngineers = _production->getAssignedEngineers();

https:// how many manHours will be consumed for this task per average month
int manHoursPerMonth = HOURS_PER_MONTH * numEngineers;
if (!_production->getInfiniteAmount())
{
int manHoursRemainig = item->getManufactureTime() * (_production->getAmountTotal() - _production->getAmountProduced());
manHoursPerMonth = std::min(manHoursPerMonth, manHoursRemainig);
}
https:// how many items will be manufactured in this month
float itemsPerMonth = (float)manHoursPerMonth / (float)item->getManufactureTime();
if (itemsPerMonth < 1.0f) itemsPerMonth = 1.0f;

https:// final calculation
int saleValue = _btnSell->getPressed() ? _producedItemsValue : 0;
int consumedValue = item->getManufactureCost() + _usedItemsValue;
int salaryCost = _game->getRuleset()->getEngineerCost() * numEngineers;
float livingCost = ((float)_totalLivingQuartersMaintenance * numEngineers) / _totalLivingSpace;
float workshopCost = ((float)_totalWorkshopMaintenance * (numEngineers + item->getRequiredSpace()) / _totalWorkshopSpace;

return (saleValue - consumedValue) * itemsPerMonth - (salaryCost + livingCost + workshopCost);
}

Upd: changed to _producedItemsValue

[pilot00]

Manufacturing items for sale is not what vanilla xcom about. Literally, it's just side effect of the "selling" feature of the game. AFAIK xcom2012 doen't have that at all. Hell, it's the game about fighting alien invasion, not getting billionaire.

I would have agreed if 2012 was not about surviving the first two months on a predetermined build path and then steam roll the game by giving you virtually limitless cash via the battleship dlc. 2012 did more mistakes than the original.

Nope. It's not INTENDED to be played like that, but still it CAN be a helper. But paying too much of attention on "profit" would heavily bias the main purpose of the game.

And who sais that? If you dont manage your income you cannot progress. By your reasoning you should not expand your operations either because lets face it, you dont need more income, merely do the missions till you have enough research to go the final...(according to your logic)

That said, the harder level settings do in fact necessitate a manufacturing base up to a point to speed up your base construction to cover the globe and the salaries of the science team. More so if you lose soldiers and therefore equipment left and right (which happens all the time). I remember many many runs where the only thing that kept me going was having a workshop base chucking out alien aloys (didnt knew that the laser cannon was the most cost effective back there) to keep my finances stable. Dont get 2012 as an example because 2012 is a textbook game with clear steps on what/when/and how to do it to win with things like finances and interceptions been there for no reason at all.

[volutar]

And who sais that?

Vanilla says that. There's no automatic selling, nor cheating "profitability".

If you dont manage your income you cannot progress.

If you can't progress, it's your problem and your failure. Game shouldn't help you to win. It's easy enough already. Most of people were completing this game without manufacturing-selling, just by selling the loot. If I remember correctly, Meridian doesn't do that.
"Autoselling" is cheating enough thing already.

[myk002]

Keep in mind that this is not just for manufacturing for profit.  It makes clear just how much money you are spending on manufacturing when you make anything at all.  So even if you regard manufacturing for profit as an invalid strategy, information that converts a job specification into a dollar amount is always useful.

[x60mmx]

Volutar, considering the fact that the game is easy for people experienced with X-Com, what harm is a purely optional tool for streamlining an aspect of the game?  It's not like people on the forum are using it to win, because they surely have already beaten the game many times over.  I can't say I'm interested in it, but some people are obviously into really working this angle of the game, let em have it.  If it were going to be a core feature implemented in Open X-Com I would be at the front of the picket line with you, but this is far less egregious than many of the OP item/craft mods available in terms of cheating or helping the player win.

I get your dislike for it, I don't care for it either.  I also do not think it deserves the venom.

Respectfully. 

[myk002]

@redv: I like your version of the algorithm -- very clean.  But what does the final number mean to the player?  What are they supposed to do with a value that is scaled by workshop utilization?  That number is not directly related to the actual change in funds the player will see due to manufacturing at the end of the month.

I think the the net change of funds due to all manufacturing-related costs and profits at the current base is what the player really needs to know.  Say you have one living quarters, one workshop, and 10 engineers and are manufacturing (infinite) motion scanners for sale.  In the scaled algorithm you have above, we'd show the profit as $123K.  However, the change in funds due to manufacturing at this base would really be $97K due to the unused workshop space.  Things get worse if you aren't actually allocating all your engineers, or have some engineers assigned to other projects.  If you have 50 engineers but only allocate 10 for this job, the scaled algorithm would still calculate $123K but the actual change in funds at the end of the month (due to manufacturing) would be -$910K!  I think it is important to consider *all* manufacturing resources and liabilities at the base when calculating profit since it really does affect the final result.

I'm willing to be convinced otherwise if people think differently, but don't you want to know whether your actual funds value will increase?

[pilot00]

Vanilla says that. There's no automatic selling, nor cheating "profitability".If you can't progress, it's your problem and your failure. Game shouldn't help you to win. It's easy enough already. Most of people were completing this game without manufacturing-selling, just by selling the loot. If I remember correctly, Meridian doesn't do that.
"Autoselling" is cheating enough thing already.

And what does a players prefered strategy have to do with how the game is supposed to be played? If I wanted a boxed up game without alternatives id be playing the 2012 version, not sitting here 20 years after playing the original.

Just because there is not a UI button that makes an already (in vanilla) existing action simpler, not easier, simpler, it means that the original doesnt support said function and that the game is easier now....Sorry mate your logic is at fault here. Manufacturing bases have been around x-com since the games release for this exact purpose. How is this not supported?

Whats the difference between having to press the button and do it automatically, than having to do the process of manufacture and sell manually 1 million times?If I want to do it ill do it, the button existing or not is not gonna stop me. And since the game does allow me to do it with or without the button yes it is a supported action and no its not cheating. If they wanted this behaviour out of the game, they would make everything to not generate profit from manufacturing.

If you can't progress, it's your problem and your failure. Game shouldn't help you to win. It's easy enough already. Most of people were completing this game without manufacturing-selling, just by selling the loot. If I remember correctly, Meridian doesn't do that.
"Autoselling" is cheating enough thing already.

It doesnt help you win, but it gives you the avenue to take different paths. Thats what mass production in the game is about. In all three X-Coms actually. Just because people complete in X way it doesnt mean that completing it in Y way is cheating. Especially when the tools to do so are there and established by the developer. Hell people completed the game with alloy armor rifles and explosives only, should using anything else be considered cheating too?

 I think your thinking is a bit one dimensional   

[redv]

@redv: I like your version of the algorithm -- very clean.  But what does the final number mean to the player?  What are they supposed to do with a value that is scaled by workshop utilization?  That number is not directly related to the actual change in funds the player will see due to manufacturing at the end of the month.

I think the the net change of funds due to all manufacturing-related costs and profits at the current base is what the player really needs to know.  Say you have one living quarters, one workshop, and 10 engineers and are manufacturing (infinite) motion scanners for sale.  In the scaled algorithm you have above, we'd show the profit as $123K.  However, the change in funds due to manufacturing at this base would really be $97K due to the unused workshop space.  Things get worse if you aren't actually allocating all your engineers, or have some engineers assigned to other projects.  If you have 50 engineers but only allocate 10 for this job, the scaled algorithm would still calculate $123K but the actual change in funds at the end of the month (due to manufacturing) would be -$910K!  I think it is important to consider *all* manufacturing resources and liabilities at the base when calculating profit since it really does affect the final result.

thanks @myk002
This algorithm calculates profit for this and only for this production task per average month. Therefore takes into account only resources given for this task. Nothing more.
May be i have 1 workshop, may be 10. May be i use all space in workshops, may be the space is wasted. May be executed another production tasks on this base, may be not. May be assigned all engineers, may be engineers are idle.

Who knows? In all cases this algorithm always will be calculate the same profit for this particular task and for this resources.

You want take into account free space in the workshops.
OK. But why not take into account idle engineers, idle soldiers, feree space in research labs and stores, hangars.
Why not? These factors influence on profit per month too.

[redv]

Another example.
What if i start 2, 3, 4 production tasks with 0 assigned engineers. In this case will be many free space in workshops.



Question is, how many times you will count the same free space for all tasks?

[Jstank]

Maybe I used the wrong language. I wasn't referring to net worth but only projected net liquid assets.

I agree it would be pretty unstable since your always changing around your production cues. But it might just give you an estimate of your end of month balance assuming you don't change your production.

[volutar]

I think your thinking is a bit one dimensional   

You may think as you want. You also may pervert OpenXcom as you like, by forking and changing it the way your imagination wants.
"Autoselling" button is making life easier already, but making whole new stat screen, with number of consumed resources in a month (including money), is too much.

I would insist on keeping this screen clear from additional data, because adding A, as consequence would need of adding B, and so on. You are free to add all you want in your own version.

And moreover, I would insist on removing manufacture categories from the "add" screen. Not just because it's "not vanilla", but because it clutters the screen, lessen the height of the scrollbox, and needed by rare players with modded game.

[pilot00]

You may think as you want. You also may pervert OpenXcom as you like, by forking and changing it the way your imagination wants.
"A

Well now, I have been in forums for enough ages to recognise a lost cause of a civil and open minded discussion when I see things like the ones in the Italics. Believe what you will then but take note of one thing: This is not a crusade.

[myk002]

@redv: you're right about the cost being misleading when there are multiple jobs.  Hopefully this will address that concern.  I didn't include other base expenses in the number, though, since the idea here (faithful to the wiki article) is to figure out whether your *total manufacturing resources* are turning a profit.

I understand what you are trying to show with the algorithm you have, I just think we're trying to answer slightly different questions.  You're showing whether the *allocated* resources are turning a profit, and I'm showing whether the player's *investment* in manufacturing resources is turning a profit.

Here's a comparison between the two options.  The first screenshot shows a base that is manufacturing items for use -- that is, it's not selling them for profit (not that this particular item would be profitable anyway, but that's not the point.  it's just here to clarify the "all bases" line).  The next two screenshots compare redv's output and my proposed output for 0 allocated engineers, and the next two compare the output for the maximum number of engineers.

You can see that when all resources are allocated, the calculated value is the same for the two algorithms, but they differ more significantly as more workshop space is left empty.

I think both options are confusing for different reasons.  redv's option shows profit that may not actually result in funds at the end of the month.  My proposed option will give you the accurate funds change for the base due to manufacturing, but has to combine the calculations for all jobs at the base for the numbers to be consistent (that's why it's "this base" and not just "this job").

[redv]

+8K good catch!



Yes, the algorithm has a bug.
Because resources consumed always before the beginning of production.
And because often possible situation when this production task cannot be finished in one month.

Fixed fixed variant:

Code: [Select]

int ManufactureInfoState::getMonthlyNetProfit()
{
const int HOURS_PER_MONTH = 365 * 24 / 12; https:// Also you can use HOURS_PER_CURRENT_MONTH instead

const RuleManufacture *item = _production->getRules();
int numEngineers = _production->getAssignedEngineers();

https:// how many manHours will be consumed for this task per average month
int manHoursPerMonth = HOURS_PER_MONTH * numEngineers;
if (!_production->getInfiniteAmount())
{
int manHoursRemainig = item->getManufactureTime() * (_production->getAmountTotal() - _production->getAmountProduced());
manHoursPerMonth = std::min(manHoursPerMonth, manHoursRemainig);
}
https:// how many items will be manufactured in this month
float itemsPerMonth = (float)manHoursPerMonth / (float)item->getManufactureTime();
https:// for how many items will be consumed resources in this month
https:// (because resources consumed always before the beginning of production;
https://  and because possible situation when production task cannot be finished in one month)
float consumedPerMonth = itemsPerMonth;
if (manHoursPerMonth == HOURS_PER_MONTH * numEngineers)
{
consumedPerMonth += 1.0f;
}

https:// final calculation
int saleValue = _btnSell->getPressed() ? _producedItemsValue : 0;
int consumedValue = item->getManufactureCost() + _usedItemsValue;
int salaryCost = _game->getRuleset()->getEngineerCost() * numEngineers;
float livingCost = ((float)_totalLivingQuartersMaintenance * numEngineers) / _totalLivingSpace;
float workshopCost = ((float)_totalWorkshopMaintenance * (numEngineers + item->getRequiredSpace()) / _totalWorkshopSpace;

return saleValue * itemsPerMonth - consumedValue * consumedPerMonth - (salaryCost + livingCost + workshopCost);
}