David, anyone, please help me out!
If anyone fancies trying to figure it out, here's the sample I've got so far:
| CODE |
Corrected data below |
Most of them come out at around 0.1% per complex not covered by commands but only around 0.1% and only most of them... That's not good enough
take the sample
| CODE |
928 907 9 100 99.3 0.7 |
907 active complexes, of which 9 are command gives an efficiency drop. So it would seem that it's not "1 command per 100 other active complexes" as I think most of us have interpretted. It must be either:
1) 1 command per 100 other complexes (active & inactive), or
2) 1 command per 100 complexes, including command (possibly even including active & inactive).
Richard
AFT
On a sudden inspiration I went back and corrected my figures taking off any complexes that had been built between calculating the efficiency and displaying the complex list (d'oh!) Plus another error corrected.
This is more like it. Now we have:
| CODE |
total active command %before %after %drop 640 633 4 100 76 24 757 709 7 100 99.1 0.9 855 834 8 100 96.6 3.4 928 907 9 100 99.3 0.7 3 3 0 100 99.7 0.3 [corrected] 8 8 0 100 99.2 0.8 [corrected] 1657 1637 16 100 96.3 3.7 8 8 0 100 99.2 0.8 102 102 1 77.9 77.8 0.2 164 157 1 46.6 44 2.6 194 124 1 43.2 42.1 1.1 |
So in all cases but one with 100% workhours, we have [efficiency - (excess complexes * 0.1)]
If there is insufficient workhours the 0.1 is (almost) multiplied by the effieciency due to lack of workhours. Need to figure that out.
The the only other odd one out is where there is more than 1 command missing. Then it works out just over 0.1 each complex (0.103004292) so there is obviously something else going on there.
(sorry for wasting your time, I only continued in the thread so you could see I've solved it mostly. Still got those few little loose ends to tidy up. (but as least it looks like I mostly got it right in the first place in my pcalc, the problem was putting the wrong number of complexes into it)
(Archangel -
)Sorry to spam you all, move along now. Idiot at work...
Therefore, 9 commands would be sufficient for up to 900 complexes, but not 901 - you would then need to build a 10th one for 100% efficiency?
cheers
weenie
| QUOTE (Frabby @ Nov 27 2004, 09:08 PM) |
| I may be totally wrong on this, but I was under the impression that certain complexes do not count towards the command complex requirement, namely those that do not require employees, i.e. caves, domes, bunkers. |
If they don't it throws my numbers right off...
| QUOTE (Frabby @ Nov 27 2004, 09:08 PM) |
| I may be totally wrong on this, but I was under the impression that certain complexes do not count towards the command complex requirement, namely those that do not require employees, i.e. caves, domes, bunkers. |
Adding an echo to this - I've been operating under this impression also. Example; 1-dome complexes operating at 99% efficiency (and presumably 100% with) without any employees...
| QUOTE (Ro'a-lith @ Nov 27 2004, 09:53 PM) |
| Adding an echo to this - I've been operating under this impression also. Example; 1-dome complexes operating at 99% efficiency (and presumably 100% with) without any employees... |
If domes don't require employees what's effecting the efficiency?
| QUOTE (Frabby @ Nov 27 2004, 09:08 PM) |
| I may be totally wrong on this, but I was under the impression that certain complexes do not count towards the command complex requirement, namely those that do not require employees, i.e. caves, domes, bunkers. |
All those complexes count toward the command complex requirement. Even domes need command complexes.
| QUOTE (Steve-Law @ Nov 27 2004, 03:43 PM) |
| If there is insufficient workhours the 0.1 is (almost) multiplied by the effieciency due to lack of workhours. Need to figure that out. |
I get efficency = before - (extra complex * 0.1 * before) which matches your results, and the values we get mean that the "almost" is within rounding errors (of either display or internal calculations)
As for the case when there is more than one missing command complex i'm stumpped, tried all sorts of ideas but nothing simple seems to fit.
Don't suppose you have other cases of more than one missing command complex?
| QUOTE (ptb @ Nov 29 2004, 11:08 AM) |
| Don't suppose you have other cases of more than one missing command complex? |
I don't (that was only one I'd taken over, mine will only ever be one less just as new complexes pass the boundary). I was hoping some others could provide a wider sample...
Obviously though this is just pie in the sky without more samples. There are probably loads of different methods to get the result, doesn't mean any of them are right.
Anyone got any more examples please? (where a starbase or outposts in more than 1 command centre short of requirements)
What follows is the content of an email that is still lying in my 'Drafts' section intended for you. I have elected to replicate the content here for all to read, so that we can hopefully generate some more discussion on the ideas that I have presented. It is also hoped that the text makes sense to all readers.
| QUOTE |
HI, This mail has been lying in my Drafts section waiting for completion for some weeks now. The content of the mail does not take into account the current discussion on the forum. Hi, Before I answer your question can you please answer mine. In the first example you state that "834 (active complexes) with 8 command complexes. Efficiency 96.6%". How do you know that the answer is in fact 96.6% so that you are able to estimate the calculation at all? I have noted a number of aspects with these calculations, so if you do not mind, allow me to be very pedantic about my interpretation of the rules first. 1: Work Hours In general: Active complexes require: 500 hours per week (10 personnel at 50 hours/week) Closed complexes require: 50 hours per week (1 personnel at 50 hours/week) Exceptions to this are: Domes, Bunkers and Caves require no work hours. 2: Command Complexes The requirement here is 1 per 100 other complexes. Per the rules as contained in the document 'Starbase Rule Book' no distinction is made between open and closed complexes. 3: Work Hours Slave - 50 hours per week Employee - 50 hours per week Maintenance Bots - 200 hours per week 4: Wages Outpost Starbase Slave - nil nil Employee - 2 1 Troop - 2 2 That sums up the rules as I understand them. Now a number of different minimum requirements are needed Viz. (all Numbers are per week) Required Wages = (Employees + Troops) * (location is Outpost ? 2 : 1) Required Work Hours = Total Complexes * 500 - (Closed Complexes * 450) - ((Domes + Bunkers + Caves) * 500). Available Hours = (Employees + Slaves) * 50 + (Maintenance Bots * 200) Required Command Complexes = (Total Complexes - Command Complexes)/100 + 1 - (((Total Complexes - Command Complexes) % 100) ? 0 : 1)) This last equation probably needs some explanation. In the first place the floating point values are not stored, in other words Required Command Complexes should be defined as an integer. Now if we constrain ourselves to work only in integral results we will see the following behaviour. For values 0 <= x <= 99, x/100 returns 0, hence (Total Complexes - Command Complexes)/100 + 1 will have a minimum value of 1 for this range. Clearly for 0 complexes we will only need 0 command complexes. For values 100 <= x <= 199, (Total Complexes - Command Complexes)/100 + 1 also has a minimum value of 2 for this range. As you can see we are out by 1 for group of 100. The second part of the equation addresses this instance by taking the result of x modulo 100. If the result is zero then 1 is subtracted. (I assume you know the use of the C/C++ ternary operator '?'.) Using the two number ranges above we will then have For x = 0 then x % 100 = 0 and the equation becomes 1 - 1 = 0. No problem with the result here. For 1 <= x <= 99 then x % 100 is never zero, so no deduction is made. There is still no problem with the result. For x = 100 then x % 100 = 0 and 1 is subtracted. Hence we still only need 1 command complex (2 - 1 = 1), everything is still good. For 101 <= x <= 199, then x % 100 is non-zero and no deduction is made. Here 2 command complexes are required per the calculation, which agrees with the rule as stated above. I could use the above facts to construct a formal proof by induction, but I think that the examples provided are sufficient for the purpose at hand. However, what follows is a bit more subjective in interpretation or implementation. In my previous email, I tried to demonstrate with the graphs that your equations grew more punitive as the number of complexes increased, particularly if there was a small difference between the available resources versus the required resources. Let my try and explain my theory in a more direct fashion. Suppose a required resource needs 4 items. Suppose also that only 3 items are available. In simple terms there is only 3/4 or 75% of the requirement satisfied. Or, in other words, the efficiency cannot exceed 75%. Suppose now that a required resource is 400 items. Suppose that only 399 items are available. Now the ratio of satisfied demand is 399/400 or 99.75%. In this last equation we have a 0.25% shortage of this particular resource. However there is no mathematical foundation for the presumption that the effective efficiency is altered by the same amount. Certainly there is none that I have been able to reasonably derive. Actually, maybe that is a bit too strong, as the fundamental question is whether independent shortages affect the net efficiency in an additive manner or a proportional manner. Let us build a model to compare the two cases. Suppose we have 1 Command Centre 100 Active complexes (none are caves, domes or bunkers). 10 Closed complexes (none are caves, domes or bunkers). 90 Stellars are on hand. 100 Employees 100 Slaves 200 Maintenance bots. I do not know how many troops are required to keep 100 slaves in line so this value is not taken into account at this stage. This will not affect the model as presented in a material way though. From the above it is clear that: Required Command Complexes = 2. Required Work Hours = 100 * 500 + 10 * 50 = 50,500 hours. Available Work Hours = (200 * 50) + (200 * 200) = 50,000 hours Required Salary = 100 * 1 = 100 Stellars OK we have the following ratios. Available Work Hours 50,000 -------------------- = ------ = 99.00990099% Required Work Hours 50,500 Available Command Centers 1 ------------------------- = --- = 50.0% Required Command Centers 2 Available Stellars 90 -------------------- = --- = 90.0% Required Stellars 100 Using your original calculations we would have: Penalty due to shortage of work hours = 1% Penalty due to shortage of command centers = (200 - 100) * 0.1 = 10% Penalty due to shortage of wages = 10% Additive accumulations of the above would yield a net Starbase effectiveness of 79% (per your equations). Suppose we calculate the Command Center ratio using different units of measure. Now each command center can efficiently manage 100 complexes, then we could view the ratio as 100/110 = 90.9%. Suppose that there were in fact 20 closed complexes then the ration would be 100/120 = 83.3%. The point I am trying to make here is that although 2 Active Command Centers are actually required to properly support 110 complexes is; that it is much easier for a complex to manage 110 complexes with some level of success than it is to manage 120 complexes. i.e. The impact on efficiency should be relative to the degree of shortage rather than the absolute shortage of command centers. |
Regards to all
(Aha - there's that reply 
)Thanks. I'll deal with the easy stuff first and let the rest digest...
| QUOTE |
| In the first example you state that "834 (active complexes) with 8 command complexes. Efficiency 96.6%". How do you know that the answer is in fact 96.6% so that you are able to estimate the calculation at all? |
Because that's what is says on my turn report. All the samples I've used are taken directly from starbase/outpost turns.
| QUOTE |
| 1. Workhours |
Okay but there's another exception. Research complexes require 2500 workhours.
| QUOTE |
| 2. Command Complexes |
As pretty much proved and seemingly generally agreed, requirement is actually 1 command per 100 active complexes (including the command centres themselves).
Yes one part of the rules says "1 per 100 other complexes" but another part says "1 per 100 complexes". The numbers support the latter.
The rest of the rules assumptions appear to be correct (as I understand them as well).
And then I get brain-freeze
I'll print it out and digest over a cup of tea, but how about you apply your theory to my samples above? (Use the second set of (corrected) samples.)
(Note that the %before is where there is also a lack of workhours. As the turn reports this drop first I'm assuming it also applies this drop first. And as I'm only concerned with efficiency drop due to lack of command centres in this thread I'm just taking the employee efficiency figures as read.)
Geoff
| QUOTE |
| I don't bother with the maths, just build another Command Complex when starbases efficiency drops below 100% because you have not got enough |
The whole point of this discussion is to ensure that Steve's calculator is correct and accurate.
Also for those into building Linear Programming models, these calculations are both necessary and need to be properly understood.
| QUOTE (HPSimms @ Nov 30 2004, 01:57 PM) |
| I don't bother with the maths, just build another Command Complex when starbases efficiency drops below 100% because you have not got enough |
LOL. And in one fell swoop you've rendered all our hard work completely pointless
(I just wanted to *know*!
) | QUOTE (Steve-Law @ Nov 30 2004, 03:03 PM) |
| And in one fell swoop you've rendered all our hard work completely pointless |
The best kind of hard work is always the pointless kind (or as my teacher said anything thats fun is also pointless)
Where there is more than one command complex missing, the 0.1 formula works if you use total complexes instead of active complexes.
| CODE |
640 633 4 100 76 24 ~~~ ~ -- (640 - (4 * 100)) * 0.1 = (640 - 400) * 0.1 = 240 * 0.1 = 24 |
instead of e.g.
| CODE |
757 709 7 100 99.1 0.9 ~~~ ~ --- (709 - (7 * 100)) * 0.1 = (709 - 700) * 0.1 = 9 * 0.1 = 0.9 |
Surely this can't be right? Is this in fact a bug? lol?
What we need is more samples. Please...
| QUOTE (Steve-Law @ Dec 1 2004, 10:44 AM) |
| Surely this can't be right? Is this in fact a bug? lol? What we need is more samples. Please... |
Would be a really weird coincedence if it's not just a bug.
| CODE |
| Efficency Mod=1-CCP*(RCCF- CC) CCP=Command Complex Penalty=.1 RCCF=Required command complexes Factor=Total Active Complexes / 100 CC=command complexes |
so
640 633 4 100 76 24
Mod=1-(633/100-4)*.1=.233 ?
what starbase is that for ?
Steve can you double check those numbers, just in case
)| QUOTE (ptb @ Dec 1 2004, 02:09 PM) |
| Steve can you double check those numbers, just in case |
The dodgy sample has the right numbers (I will check again when I get home) but if I remember it was actually forwarded to me by Lee (who no longer plays) and could well have had something cut out (like scrapping 3-7 complexes at the start of the turn or something). It did show the weekly update section then nothing until the actual starbase report sections. i.e. no pre-production, production etc. I will check the standing orders section as well...
(It was a "here, what do you think" for Basilisk before I took it over)
| QUOTE |
| CODE Efficency Mod=1-CCP*(RCCF- CC) CCP=Command Complex Penalty=.1 RCCF=Required command complexes Factor=Total Active Complexes / 100 CC=command complexes so 640 633 4 100 76 24 Mod=1-(633/100-4)*.1=.233 ? what starbase is that for ? |
Exactly now when using the Total value we get
Mod=1-(640/100-4)*.1= 1 - .24 = 0.76 (or 76%)?