Science & Industry

I suck at math, but it's most likely that thing that does not allow you to build 10 paladins with 9 apocalypses.

if the round function is like any other, 2 refers to the rounding precision, meaning second decimal number. why I have no idea.

If that's the case then use a fix function that rounds down in all cases.

I'm trying to work this out using Excel, and hitting a brick wall...

Until now, I've just been approximating the result by adding a multiplier that spits out an answer that matches the in-game results, for a pre-set number of runs. I've got no idea how to formulate this, so that excel can adjust for varying batch sizes.

I'm backing-up my old HD at the moment, otherwise I'd post the formula I'm using atm...

The formula I'm trying during the back-up - based on the above - is spitting out hilariously wrong results; 2 instead of 100, 500 instead of 5000... :(

Maybe I'm misunderstanding this... I've been away from manufacturing since just before Teams were introduced... Did I read somewhere (in an old Dev Blog) that there was a materials-discount type thing, on bulk manufacture jobs?

I just used the Fuzzworks site to try something out, and it didn't seem so.

Large jobs get a 'discount' because the ceil function doesn't bump the material as much.

Say you have something with 2 of a material in it. 0.9 doesn't help there, as it drops to 1.8, then goes back up to 2 with the ceil

At 10 runs, you're saving 2 of the material, over doing 10 1 run jobs.

It's not huge, admittedly, but it's not inconsequential. And with many of the bonuses being smaller (2% from an array, for example) more runs would be needed.

And that's not the right function. you may get close to the right numbers, but it's not accurate.

Math.max(runs,Math.ceil((material.quantity*(1-(me/100))*facilityme[facility]*)*runs));

is what I'm using. though I should really stick the round in, to get round the floating point error (which is, admittedly, minor)

Thanks for the reply, Steve.

To be upfront, I haven't programmed since the days of Cobol and Pascal, so when I try to get my head around this I only have Excel as a current frame of reference, and my grasp of maths (outside of arithmetic) is terrible; so please forgive the following... and if you can clear it up, I'll owe you a drink next time I see you at the Glasgow Meet ;)

Firstly - yes, you were right that my formula was off (there were instances I hadn't yet bumped into, where ROUND was rounding down instead of up) - for example; on a single run of 6 materials at 0.9 eff., it was rounding the 5.4 result down to 5, instead of keeping it at 6. Swapping ROUND for ROUNDUP has fixed that. (I'd also typed one of the bits the wrong way round...)

Otherwise though, to use your example;

A 10 run production of 2 materials definitely comes out at 18 (using 0.9 as the BP efficiency), not 20.
and a single run, of the same, would have come out correctly as 2, and not 1.8; as the "ROUND XYZ, 0" function would have resolved that... (The 'zero' part of it forces the decimal part of the result to be rounded to a 'single integer').

I'm really struggling to understand the purpose of the CEIL/CEILING part, though... (in Excel, at least) I can't see any purpose in having it.

Excel doesn't (seem) to have any 'floating point' problem that I can see, and the ROUNDUP function resolves any problem with getting (incorrect) 'free' materials in everything I've tried so far.

I'm not currently producing at a POS though, so maybe the 2% might make a difference, but at the same time, I can't see why simply adding a " *0.98" modifier wouldn't clear that up...

My corrected formula, in case yourself, or anyone, can see anything wrong:

MaterialsRequired=MAX(Runs,(ROUNDUP((BaseMaterialQuantity*0.9)*Runs,0)))

On a completely separate note, I've been trying to fathom a way to approximate 'Job Install Cost' - I can ballpark-it to within a few hundred Isk, (using some time-consuming arithmetic), but the actual formula is beyond my Excel skills, and appears to have been written by Satan ;)