I have a situation I'd like some input from the others on. It was suggested to me that bringing this up on the forum would be a decent method for determining scope and support/unsupport thereof for potential code changes.
Example Situation:
102 Research Labs
Proj 1-5
P1 = 30 Labs
P2 = 20 Labs
P3 = 50 Labs
P4 = 1 Lab
P5 = 1 Lab
You start P-6 using 2 Labs
What should happen?
a. P4-5 cancelled automatically?
b. One of P1-3 loses 2 Labs the others remain the same?
c. One Lab is taken from (2) random projects?
d. Error message stating Insufficient Labs and no research project (P6) started at all? Thereby.... no loss of funds either.
e. Check-box for you to indicate priority of "stopping" current projects (like the Insert Production order, but instead of insert before line 1..., it would be the line that relates to a particular research project
f. None of the above
Or... If you've another suggested response, add it
The reason I ask this is that I just had 90k in research projects cancelled along with 190 mass due to this coding system (answer a.).
I liken it to using factories, mines, or resource complexes.
If you try to exploit x with a # that is larger than available, or you try to start mining with a # you don't have available, should you worry about which Mine, Resource, or Factory (mass prod for example0 is going to be terminated? Or does it make more sense that your 'foreman' or is that foreperson
looks at what's available and tell you they can not do it? -- ie... insufficient labsRemember, just because maybe it has always been done that way does not make it necessarily 'right'.
Especially would like input from some of the older players.
The rules do not give you any real info on this subject and what little was listed on the Rules forum page on this subject is not worth mentioning
Larry Lawrence
phoenixhawk@lwlawrence.com
Which would allow you to correct your error.
Doug
This can be turned into a proper poll, cant it?
Currently the 'Set research project order' is not working consistently, if you start a new project and specify more research complexes than you have available it takes off complexes off other projects, if you change an existing project and specify more complexes than you have available the order just allocates all free complexes and does not modify existing other projects in any way.
Going for option D should in my opinion therefore also mean that when you start a research project the order should also only just allocate any free complexes and not mess with existing projects.
Thomas
You can then use the freed-up labs to start the new one, which will cost the usual 10K stellars
Basicly I agree with everyone else
I think I will vote for option 'd'.
I went to active a few dormant research complexes, using the activate order.
But I put in the number representing the number of complexes I wanted to activate, not the new total. It made a right mess of my research, but the projects that were abandoned due to insufficent complexes were not lost, the accumulated research was retained.
It became a matter of starting the project again at a later date. Did that not happen to your ongoing projects?
But out of your options I would favour "C"
| QUOTE (Auld Nick @ Feb 1 2006, 04:51 PM) |
It became a matter of starting the project again at a later date. Did that not happen to your ongoing projects? |
Nope.
Project w/190 mus lost
All other projects (including the one w/190 mus) were terminated.
I liken it to going into a McDonalds and ordering a cheeseburger and having them
take the cheese off "your" cheesburger and giving it to someone else
But at least in the "chessy example" above, you end up with a burger that you paid for rather than zilch
Larry
Uses up all available/spare complexes, but does not automatically remove complexes from a project.
| QUOTE (Phoenix Hawk @ Feb 1 2006, 08:59 PM) |
| Project w/190 mus lost All other projects (including the one w/190 mus) were terminated. |
If you lost actual mass, not just points, then email kjc about it they will probably fix that.
All research complexes provide research points into a joint research pool, usually 100 but perhaps less if starbase efficiency is lower.
Points from this pool are then allocated to individual research projects according to their share of total allocated research complexes across the board.
Simple example:
100 Research complexes at 100% efficiency produce 10,000 points.
You have 2 projects: A (40 complexes) and B (60 complexes).
A total of 100 complexes are allocated. A gets 40% of the total RP generated, B gets 60%.
You could also use A (2) and B (3) for the same result.
Complicated example: You have set A (40) and B (60), build another 20 complexes (for 120 total) and start project C; however due to a typo you start C (200).
Total desaster under current rules; under my suggested Pool-And-Quota rules this would neatly compute as follows:
12000 RP total in pool (100% of 120 complexes x 100 RP), 300 complexes allocated.
A gets a share equivaling (40 of 300) = 13,33%, which is 1600 RP (rounded);
B gets a share equivaling (60 of 300) = 20,00%, which is 2400 RP (rounded);
C gets a share equivaling (200 of 300) = 66,66%, which is 8000 RP (rounded).
Even more complicated, before the above update kicks in, your starbase comes under accidental attack and suffers some minor collateral losses. Efficiency is down to 68% and you lost 12 research complexes (108 left). Sounds difficult but truly doesn't make much of a difference:
7344 RP total in pool (68% of 108 complexes x 100 RP), 300 complexes allocated.
A gets a share equivaling (40 of 300) = 13,33%, which is 979 RP (rounded);
B gets a share equivaling (60 of 300) = 20,00%, which is 1469 RP (rounded);
C gets a share equivaling (200 of 300) = 66,66%, which is 4896 RP (rounded).
The advantages of this suggestion:
- Simple & fool-proof
- No complexes ever idle and no RP lost except if no project at all is going on
- Conversion at odd values (i.e. 3025 or 5678) possible
I fail to see any drawbacks.
The same system could be applied to mining and resources as well. I really think it's simpler and more user friendly.
| QUOTE (Phoenix Hawk @ Feb 2 2006, 01:43 PM) |
| I did..... They didn't. |
Then I suggest you give Mica a friendly nudge. Failing that lean on him a bit.
The old rule book is quite clear on this, and in my case I have a suspended research project that has been in this state for months without a problem.
When you set a Research Project to 0, by the Order Editor, it goes into suspension, and.... it is cancelled if it has "no" mass.
But that appears to only work if you the player does the settings.
This is part of the reason I feel the codes should be changed to register an error -- insufficient whatevers.
When the Computer automatically and indiscriminately decides to lower a project to zero, it is getting cancelled peroid. -- even w/190 mus conversion accomplished!
--- I did bring this full issue to Micas attention and he suggested I place it here for discussion -- I see his reasoning and agree or not, this does work out the details.
thanks!
Larry
| QUOTE (Phoenix Hawk @ Feb 3 2006, 08:05 PM) |
| When the Computer automatically and indiscriminately decides to lower a project to zero, it is getting cancelled peroid. -- even w/190 mus conversion accomplished! --- I did bring this full issue to Micas attention and he suggested I place it here for discussion -- I see his reasoning and agree or not, this does work out the details. |
What reasoning could he possibly have for canceling a project for mass. Okay so 190 mus isn't a lot but it could have easily have been 4900 mus...
The automatic system removing complexes or even pausing research is acceptable, although option D is perferable, but under no circumstance should it be allowed to cancel, even at 0 mass.
Being inconvenienced by an automatic system is one thing, being penalized by it is another. I understand that they only have limited time to spend on developing, fixing and improving the game. I'm sure most players will happily live with the inconvenience of having to reissue some orders to move complexes around, but few (none?) will be happy about cancelled projects.
The thing here, on the programming end is (imho)
==> who/what decides which projects gets stopped? <==
Mica does not go in and say "hey! cancel" or "stop".....
, that's internal programming. It could just as easily say "hey! not enough labs available"ex concept...
a. order -- start project xyz w/20 Labs
b. check if xyz exists
c. check how many labs are available
d. if (b = false) then
----- see if (# Labs avail <= # Labs requested)
----- if there is enough labs then start proj w/that # labs
----- if there is not enough labs, but > 0 Labs, then start xyz with that many labs
----- if there is not enough labs, and <1, then send error message
e. if (b = true) then .....
----- see if (# labs avail + current labs >= # requested
----- if enough Labs, then modify # in xyz
----- if not enough labs (ie > avail), but more than 0 can be added, then add to xyz-
----- if not enough labs and <1 lab avail, error message --- no other change
I realize that this is at best, a very simplistic version of pseudo-coding. Its only purpose is to attempt to show a process, not the actual code <g>
In my opinion, the reason Mica suggested-- correct me if wrong Mica
, is (3) folda. Better determination if this is actual a problem for people in the game
b. If a problem, the scope involved?
c. Help on determining the priority needed to fix this.
Naturally a spelling error would hold much lower priority <g>.
Larry
The second is annoying but we can live with it (or at least I can
) which is that the code shouldn't removed complexes, the same way starting exploitation of resources doesn't.Didn't mean to sound angsty
| QUOTE (ptb @ Feb 7 2006, 04:06 PM) |
| The way i see it is there is two related problems here, the first is crictially important, the code should not cancel projects. The second is annoying but we can live with it (or at least I can ) which is that the code shouldn't removed complexes, the same way starting exploitation of resources doesn't.Didn't mean to sound angsty |
Didnt take it that way, and btw...
I agree fully with the (2) problems as you stated them.
They would resolve the issues and make it more in-line with
how the other code appears to operate (continuitiy <g>)
Larry