It may not be what you feel vanilla xcom is "about", but that is definitely the way it was intended to play.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.
P.S. Are you the same Volutar who created MCDedit? If so, I praise you! You made my Tactical Lightning mod possible. :)Yes it's me. I was just rebuilt Kobalt's MCDView to be runnable under win64, and went slightly further. ;)
I'm a supporter of a tool outside of the actual game.yeah, it's starting to look like that's the best option. Implementing it in game was certainly easiest since all the data (and UI) is there ready to go, but it could go into an external tool and have nice little widgets for tweaking variables. I wonder if I implement it as a web page it could get included in the wiki (https://www.ufopaedia.org)...
The Big Sot (I think) made such a tool, it's called Ruleset Viewer and one of its functions is exactly what this thread is about.Ah, good point. I hadn't tried it since we fixed those syntax errors in the requirements lists in the FMP ruleset (which at that time prevented the manufacturing analysis from working). Ok, so I'll clean up the code for the second version -- the one that adds the information to the sell button -- and leave the external tools to other people :).
It is bundled with the new MapView.
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.
adding the possibility to list produced items when there are more than 1 would be great, on the same screen where it lists the required items.I'll take a look at that once I get this wrapped up.
Is there a way to select the denominator, like per unit, per day, per hour.There could be, but I fear it would clutter the UI. The units are per month since that is how the finances in the rest of the game are measured, and is the most relevant to a player who is trying to figure out whether they will have enough money at the end of the month to cover expenses.
It would be neat to see the economy of scale factored in and see profitability change when you incorporate how much cost a month engineers have on the overall numbers as you add or subtract engineers. Now i want to see the graphs..... This would make it not as static as one criticism put it.The numbers do change according to the number of engineers you have assigned, and you can see, for instance, the profit going from negative to positive as you cross the critical theshold for assigned engineers for the (profitable) item you are producing.
Something about the last two numbers don't make sense to my feeble brain. If you use 70 engineers to produce 100 shouldnt it output the same number as using 70 engineers to produce infinite? Unless 100 took more than a month?
Also does it take into account facility cost? If there is a monthly cost for running a workshop?
What mean "Remaining materials cost"?
remainingMaterialsCost = (manufactureCost + usedItemsValue) * (amountTotal - amountProduced)
manufactureCost: the number listed in the ruleset that you are charged per item produced.monthlyNetProfit = (saleValue - (manufactureCost + usedItemsValue)) * itemsPerMonth
- (salaryCost + livingCost + workshopCost) * capacity
saleValue: the money you get from selling the item. this is 0 if the "SELL" button is not toggled onremainingNetWorthChange = (producedItemsValue - (manufactureCost + usedItemsValue)) * (amountTotal - amountProduced)
monthlyNetWorthChange = (producedItemsValue - (manufactureCost + usedItemsValue)) * itemsPerMonth
- (salaryCost + livingCost + workshopCost) * capacity
The main difference being the use of producedItemsValue in the two equations, which is the combined sale value of all the produced items.Here are the equations that make up the main business logic of this change:Code: [Select]remainingMaterialsCost = (manufactureCost + usedItemsValue) * (amountTotal - amountProduced)manufactureCost: the number listed in the ruleset that you are charged per item produced.
usedItemsValue: the sale price of any other items required to manufacture this item (like alloys)
amountTotal: the number you specified to manufacture when you started the job
amountProduced: the number of items you've produced so far. this will be 0 when you first create the job and non-zero when you look at a manufacturing job in progress
Could you add the Agragate_Net_Profit for all ongoing base finances to your bottom line on the finances screen? That way it will add your production profits to your final budget total?that might take some discussion -- changing what one of the chart lines means will undoubtedly cause confusion, but adding a new line might not be very useful. Anyway, let me run the next version of the manufacturing screen by everyone.
Monthly cost: -35K * (4 / 50) - 34K = -36.8KThis brings up a good point. In order to calculate *manufacturing* profitability (as opposed to isolated *job* profitability), I don't scale the cost of the workshop maintenance to the amount of workshop space that is used. This is because unlike living space, which is shared among other purposes, there is no other use for workshops. Even if we're not using some workshop space, we're still paying for it, and it affects the calculation for monthly profit. The profitability wiki page (https://www.ufopaedia.org/index.php?title=Manufacturing_Profitability) implicitly does the same thing since it assumes all manufacturing capacity is fully utilized. If I scaled the workshop maintenance, it would give an unrealistically positive view of how much profit you'll be making per month.
int _totalLivingSpace, _totalLivingQuartersMaintenance, _totalWorkshopMaintenance, _producedItemsValue, _usedItemsValue;
void ManufactureInfoState::initProfitInfo ()
{
Ruleset *ruleset = _game->getRuleset();
const RuleManufacture *item = _production->getRules();
_totalLivingSpace = 0;
_totalLivingQuartersMaintenance = 0;
_totalWorkshopMaintenance = 0;
for (std::vector<BaseFacility *>::const_iterator i = _base->getFacilities()->begin(); i != _base->getFacilities()->end(); ++i)
{
if (0 != (*i)->getBuildTime())
{
https:// don't count unbuilt facilities
continue;
}
RuleBaseFacility *rbf = (*i)->getRules();
bool costAccountedFor = false;
if (rbf->getWorkshops())
{
_totalWorkshopMaintenance += rbf->getMonthlyCost();
costAccountedFor = true;
}
if (rbf->getPersonnel())
{
_totalLivingSpace += rbf->getPersonnel();
if (!costAccountedFor)
{
https:// don't count the cost twice for facilities that provide
https:// both workshops and living space
_totalLivingQuartersMaintenance += rbf->getMonthlyCost();
}
}
}
_producedItemsValue = 0;
for (std::map<std::string, int>::const_iterator i = item->getProducedItems().begin(); i != item->getProducedItems().end(); ++i)
{
int sellCost = 0;
if (item->getCategory() == "STR_CRAFT")
{
sellCost = ruleset->getCraft(i->first)->getSellCost();
}
else
{
sellCost = ruleset->getItem(i->first)->getSellCost();
}
_producedItemsValue += sellCost * i->second;
}
_usedItemsValue = 0;
for (std::map<std::string, int>::const_iterator i = item->getRequiredItems().begin(); i != item->getRequiredItems().end(); ++i)
{
_usedItemsValue += ruleset->getItem(i->first)->getSellCost() * i->second;
}
}
https:// algorithm based on profitability calculations done on
https:// https://www.ufopaedia.org/index.php?title=Manufacturing_Profitability
int ManufactureInfoState::getMonthlyNetProfit ()
{
Ruleset *ruleset = _game->getRuleset();
const RuleManufacture *item = _production->getRules();
static const int HOURS_PER_MONTH = 24 * 30;
int numEngineers = _production->getAssignedEngineers();
int manHoursPerMonth = HOURS_PER_MONTH * numEngineers;
float itemsPerMonth = (float)manHoursPerMonth / (float)item->getManufactureTime();
float percentUtilized = 1.0;
int itemsRemaining = _production->getAmountTotal() - _production->getAmountProduced();
if (!_production->getInfiniteAmount() && itemsPerMonth > itemsRemaining)
{
https:// less than one month's amount of work left; scale the costs accordingly
percentUtilized = itemsRemaining / itemsPerMonth;
itemsPerMonth = itemsRemaining;
}
int saleValue = _btnSell->getPressed() ? _producedItemsValue : 0;
int salaryCost = ruleset->getEngineerCost() * numEngineers;
int livingCost = (_totalLivingQuartersMaintenance * numEngineers) / _totalLivingSpace;
return (saleValue - (item->getManufactureCost() + _usedItemsValue)) * itemsPerMonth
- (salaryCost + livingCost + _totalWorkshopMaintenance) * percentUtilized;
}
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);
}
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.
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?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.
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.
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.
@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 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.
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
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);
}
For me usedItems cost isnt really that importantgood point -- it only factors into net worth, not (directly) into the change in monthly funds, which we're trying to highlight here. I'll clean up the algorithm, do one more set of screenshots, and get ready to submit the pull request.
Sorry for a late reply, but does it display just straight up millions (+$7M), or decimal fractures too (not sure whats the term, probably sounds stupid :) ), like +$7.4M$ or even +$7.44M?It could, and the PR hasn't been accepted yet, so it' s not too late. The code currently intentionally simplifies the number to avoid cluttering the UI and to avoid locale formatting concerns. When I wrote it, I felt the simplified number was appropriate since the numbers on the finance graph aren't exact anyway. I do like your example though -- precise to two or three significant digits regardless of how many significant digits there are to the left of the decimal point. I'll have to look into locale formatting, though. In some locales that would be "+$7,44M".
On the other hand... there are enough total conversions (like PirateZ) that it may be difficult to automatically know what is profitable or not. I have spreadsheeted a few items by manually crawling the .rul and it is painful, that I can attest. I would very much like to have this functionality in the game for specifically this reason. ;)
Grog, $16 per workerhour, Rum, $24 per workerhour, Counterfeit Money, around $32/workerhour net earnings when workshop's at full capacity. See? Case closed :) Compund items, like craft, could be even more profitable, but will such module track all components to their basic costs? Even these that in turn are made from their own components?We discussed what the calculation should be earlier in this thread. Originally I did have the number tracking used materials and facility maintenance costs, but we decided it was much clearer and simpler to just answer the question "how much will my available funds change per month if I assign this many engineers to make this many items." It gives you information regardless of whether you're selling. I.e. it will tell you how much your funds will change if you manufacture items for use as well. You can compare the number you see here to the difference between your income and expenditure graph lines to figure out how easily you can afford to make something. No, not absolutely required, but not useless either.
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.With respect, and recognizing that I'm putting in my two cents several months later, I disagree. One of the things that attracted me to this game 20 years ago was the economic model. If money isn't an obstacle, you buy every scientist, soldier, and weapon you can and wade in to the melee. But because of limited funding, it pays to consider how you can make your research pay off in more ways than just better weapons and armor for your soldiers. Is there anyone who has ever played this game and not wound up in a dead end where they built more than they could support?
With respect, and recognizing that I'm putting in my two cents several months later, I disagree. One of the things that attracted me to this game 20 years ago was the economic model. If money isn't an obstacle, you buy every scientist, soldier, and weapon you can and wade in to the melee. But because of limited funding, it pays to consider how you can make your research pay off in more ways than just better weapons and armor for your soldiers. Is there anyone who has ever played this game and not wound up in a dead end where they built more than they could support?
One of Sun Tsu's maxims was, "Make war support war." May I suggest that an interesting possible extension would be adjusted sale prices based on previous sales? Once you have flooded the market with Laser Cannons, the sell price drops (but recovers over time without any sales) which allows the economic player a chance to manipulate supply and demand, as well as having to think about another profitable item to sell and support his forces.
... but I can't remember a situation (in vanilla) where I would have financial problems later than the first two months or so.Lucky you, but since you remember financial problems in the first two month, you at least understand the point.
That would be nice, but then again, who is buying this stuff?I realize personal possession of military arms is almost unheard of outside of the United States (excepting places where only an idiot doesn't have an AK, like Afghanistan) but I think that if Laser Rifles and Laser Pistols were available for purchase, they'd be flying off the shelves.
Lucky you, but since you remember financial problems in the first two month, you at least understand the point.
I realize personal possession of military arms is almost unheard of outside of the United States (excepting places where only an idiot doesn't have an AK, like Afghanistan) but I think that if Laser Rifles and Laser Pistols were available for purchase, they'd be flying off the shelves.
The power supply for a UFO that can travel a bare minimum of 47 million miles (...)
Well... Yes and no, because in the beginning you don't have much to produce anyway, so the point is kinda moot.Solarius, I don't appreciate the *sigh*. I don't think you would appreciate it if I did it to you.
*sigh* Have you read my post? I've already explained why exactly all of this is impossible if you want to maintain the alien war a secret.
Solarius, I don't appreciate the *sigh*. I don't think you would appreciate it if I did it to you.
I don't see where anything from the original Xcom suggests that the war is a PERMANENT secret.
We had cell phones and digital cameras in 1999. And even if we didn't, when a UFO lands and aliens start killing people, SOMEONE is going to take a shot with their ancient Brownie camera. That photo will go viral in about 2 seconds.
I've visited Roswell New Mexico. There are people who still believe that there was an alien landing there in 1951, 64 years ago. And that's with no evidence at all. Are you seriously suggesting that an alien landing in a major city and people killed by the dozens can be kept secret?
And I can't make anyone do anything about it, so I don't understand why you are being so defensive.
I recognize that this will not be a mod, but will involve changing the basic code. So the question of if it will get done can only be answered by who will do it. OK, let's take it as a given that you want nothing to do with it. Does that mean it cannot be discussed? Does that mean no one else can take it on?
If you have complete veto over anything that is discussed on this board then I am wasting my time. I was hoping for the minimum response of, "That's interesting. I won't do it, but you are welcome to get after it."
Because then at least I can discuss with people who are interested and perhaps come up with something that is playable, economically not unrealistic, and adds to the game.
Right, I wouldn't. Still, I feel justified seeing as I've explained beforehand that the alien war is being kept secret, yet it was ignored.OK, we've managed to trade insults. You agreed you wouldn't like the *sigh* coming your way and I responded as I did because I took it the way you agreed you would take it. Can we stop now?
Well... It's not in the actual game, but to my knowledge it's been canon since forever that the war is secret, no matter how pointless it is.
Now you're just insulting me, because it's obviously not what happened. Moreover, you did this while claiming that I insulted you, which is also untrue but whatever, I don't care. Not cool, man.
Well... Yes and no, because in the beginning you don't have much to produce anyway, so the point is kinda moot.
OK, we've managed to trade insults. You agreed you wouldn't like the *sigh* coming your way and I responded as I did because I took it the way you agreed you would take it. Can we stop now?
I had no idea there was any such thing as a "canon." Frankly, I had no idea there were other moding groups or bases. I don't really care about canon, especially when even you agree it's pointless. I'm interested in a fun game, and anything that makes it more fun is fair game. If there's anyone who thinks they have a copyright on it, they are welcome to slap me down. Doesn't seem likely since this "canon" wasn't part of the original game. But what do I know?
I bought the game in 1994 and have enjoyed it ever since. When I learned that OpenXcom existed, I just had to find out if it had gotten better. And it has gotten better, which doesn't mean it can't be improved further.
I don't have the slightest interest in creating an alternate canon. But if something can be added to the game to make the economic aspects more interesting than, "make and sell all the Laser Cannons you can", then maybe someone else will edit the canon. That's how OpenXcom came about, isn't it?
I guess real "Alien War" would be a great alternative approach, I'd play that. It would probably require a lot of new mechanics though, like actions undertaken by governments, regular battles and so on. Well maybe not necessarily "require", but they would be cool, no? Because if it's a real war, let's have a real war! (Though not total war, the aliens don't want to destroy us - that much is said in the losing outro.)I'm not up to that much of a mod. I was a C programmer through most of the late 70's to early 90's, but Carpal Tunnel Syndrome did me in. Since 1994, the only programming I have done has been in scripting languages, with the exception of teaching myself Python a few years ago. I know nothing at all about GIT, YAML, SDL, or even the "canon."
I usually try to invest in quite a bit of extra production capabilities, because why not?
I must admit, though, that by the time they paid off their initial costs, I don't need the money anymore. Setting up a proper manufacturing section in a radar base takes several months, after all.
- The random variation (The one which doesn't reflect player's sales) could be applied once every month: This should be frequent enough to have an effect, without the player having to re-check prices every 3 days in case what he's building has suddenly dropped price without warning.
- The effect of player's sales should probably be applied on each unit (sell 1: 100$, sell 3: 100$+98$+97$), otherwise the player would be encouraged to hoard items and sell large amounts at a time.
- The items which can be bought could also have prices affected by player's demand. If the price of large rockets rises every time you buy one, you are rewarded if you adapt, rather than stick to all-rocket equipment.
- This could also apply to recruitment costs: This would create a situation of diminishing returns, where the more scientists you recruit, the more expensive it is to recruit more.
For soldiers, the scale can be harsher, to dissuade meat shield tactics. Dead soldiers can't be put back on the market, so the offer/demand system will make it more and more expensive to replace your casualties.
Faceless Government Bureaucrat: Now that you have your bases, we'd like you to build some equipment for the government, strictly on the QT. We'll pay you for them at the posted rate. Here's the list.
Xcom Commander: [scans the list] Great, we can make a lot of profit off Laser Cannons. You'll be getting about 1000 per month from now on.
First, we need a base price level for each item that can be manufactured. Suggestion: Calculate how many engineers could work on something using a single workshop, producing as many of those something as possible for a month. Total up all the costs of production. Divide by the number of items produced in a month. Multiply by 1.2. That's your Base Sale Price for the item. It's fixed and never changed.
Second, the month research gives a new item to be produced and sold:
Current Sale Price = Base Sale Price * (3 + .2 * random number)
Next each month the actual sale price of an item is recalculated as follows:
Current Sale Price = Current Sale Price * .95 * .95 for each time the item was sold during that month.
So what happens? A newly discovered item is worth a lot of money, but that price degrades by 5% each month, and by 5% more each time the item is sold. It will eventually drop below the value of other items which can be manufactured and sold.
- The effect of player's sales should probably be applied on each unit (sell 1: 100$, sell 3: 100$+98$+97$), otherwise the player would be encouraged to hoard items and sell large amounts at a time.
Soldiers.. that's a bit different since casualties can be high..
My opinion on variable prices :
- The random variation (The one which doesn't reflect player's sales) could be applied once every month : This should be frequent enough to have an effect, without the player having to re-check prices every 3 days in case what he's building has suddenly dropped price without warning.
- The effect of player's sales should probably be applied on each unit (sell 1: 100$, sell 3: 100$+98$+97$), otherwise the player would be encouraged to hoard items and sell large amounts at a time.
- The items which can be bought could also have prices affected by player's demand. If the price of large rockets rises every time you buy one, you are rewarded if you adapt, rather than stick to all-rocket equipment.
-
The recruitment can be cheap at the very beginning when people volunteer to join XCOM, but when you need more people, it becomes more expensive to print the nice XCOM recruitment posters, locate possible candidates and get them to defect from their current engagement/job to work for you.
I find it funny, these attempts to paint X-Com as something which is affected by free markets in the slightest... Especially since the project has all the cash it needs (as opposed to wants - resources are limited so the commander won't go completely crazy, also because that's how Western government organizations work).
Implying they didn't want to get Laser Cannons in the first place...
What might make more sense are random changes to the prices, to represent variations of the market globally instead of pretending that xcom is the main driver. But that's not really what the thread is about any ways. If you'd like varying prices, that's a great suggestion, in another topic where the details can be discussed...
With this setup, 196 Engineers could work on scanners at the same time. That gives you 141,120 Engineer hours per month. (720 hours * 196 Engineers.) At 220 hours per scanner, this group would make 641 scanners every month. That costs $34,000 * 641 or $21,794,000 for supplies plus $5,000,000 for engineer salaries, plus $360,000 maintenance on the Workshops and Living Quarters, or $27,154,000. Dividing that by 641 means it costs you an average of $42,362 to make a Motion Scanner.Unfortunately these engineers will only be able to produce only 360 motion scanner. Why? Because 196 engineers is less than 220 and that means you'll need 2 hours to produce one motion scanner.
I must remind everyone here.
UFO: EU does not care about extra hours. It's a problem caused by truncating floating part in a number.
however, in that particular case, the formula indeed changes nothing - it only comes into play when you have more engineers than required workhours to produced a single item, so 440 engineers would be able to make 2 scanners/hourIncorrect. It changes many things.
I must remind everyone here.
UFO: EU does not care about extra hours. It's a problem caused by truncating floating part in a number.
Unfortunately these engineers will only be able to produce only 360 motion scanner. Why? Because 196 engineers is less than 220 and that means you'll need 2 hours to produce one motion scanner.
This is one specific reason here (https://openxcom.org/forum/index.php/topic,4194.msg56922.html#new) because of which I used simulation instead of direct calculation.
In short: the most profitable thing is to assign a divisor of man hours needed of engineers. In this case the most profitable is 110 engineers, not 196 and thus 3 and 3 living quarters and workshops. Until you get 220 engineers, assigning more to that project is a waste.
But an alternative is to just do a recalculation based on smaller number of engineers.Yeah, well, that's natural. If you perform const / X, result becomes less and less different from last as you increase X.
Let's consider 1 Workshop, 1 Living Quarters, and 50 Engineers. 46 Engineers could work on scanners at the same time. That gives you 33,120 Engineer hours per month. At 220 hours per scanner, this group would make 150 scanners every month. That costs $34,000 * 150 or $5,100,000 for supplies plus $1,250,000 for engineer salaries, plus $45,000 maintenance on the Workshop and Living Quarters, or $6,395,000. Dividing that by 150 means it costs you an average of $42,633 to make a Motion Scanner. This isn't a whole lot larger than the earlier calculation. There is, of course, some loss due to math issues, but less than when having 196 engineers working. (After the 5th hour, 230 engineer hours were used, and 10 of those were wasted.)
would make 150 scanners every monthYour calculations are not done properly. If you want to account for wasted hours, you are going to do this:
Your calculations are not done properly. If you want to account for wasted hours, you are going to do this:I'm not sure just how your calculations produce a significantly different result. Yes, I recognize the functions and the purpose is to simulate the odd math that XCom: EU is using. But I don't think the "max" function is valid, because it guarantees you will make at least 1 product, even if the number of hours assigned isn't sufficient to make one.
Product_made = max(floor(720 / (ceil(man_hours/engineers_assigned))), 1)
Floor - rounding to zero (5.4 ==> 5)
Ceil - rounding to one (5.1 ==> 6)
Max - maximum, duh. (0.5, 1 ==> 1)
720 - amount of hours in an average month (24 * 30). It's 744 in case of 31 day month.