Home » Stars! 2.6/7 » The Academy » Another bug? Star base upgrade not being built..
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 04:25 |
|
|
[email | m.a@stars[/email] wrote on Sat, 21 April 2012 13:48]nmid wrote on Sat, 21 April 2012 05:46 | > Was it green after factoring in the minerals about to be mined?
|
Yup, particularly Bora.
Quote: | > Did you have any mines on the ground?
|
Plenty.
Quote: | > How many resources was the upgrade for and how many resources did your world produce?
|
The upgrade cost all the world's Resources but 5. In fact, I had to trim it so it dropped from "2 years completion" to green.
|
To clarify, you are saying that you had more boranium than was needed for the upgrade? AFTER considering the new mined minerals?
You skipped the question where I asked if you had enough actual minerals to build the base on ground zero, year zero...
Both aforementioned points are of course linked.
I think I read torben say that you had exactly the same bor as was required by the upgrade. to the single kt.
Was he perhaps talking about germ or did he forget to factor in the new minerals being mined?
[Updated on: Sat, 21 April 2012 04:44]
I know my minefields.. but I'm a chaff sweeper.
I used to curse when I got stuck in traffic... till I realised I AM traffic.Report message to a moderator
|
|
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 11:03 |
|
|
http://starsautohost.org/sahforum/index.php?t=msg&th=499 4
CC announced the existence of this bug in Jan 2012, in the game Dynamid3.
A number of us participated in the discussion and then forgot about it .
nmid wrote on Tue, 24 January 2012 01:37 | I often leave 50-100 or 5% extra resources for those special upgrades/tech breaks.
Been burned too many times, not to take care...
|
Oh well, testbed is created. I'll upload it for others.
http://dl.dropbox.com/u/25855891/testbed%20-%20dock%20upgrad e.rar
I'll try figuring out the reason behind the shortfall, but would appreciate if others gave it a look as well.
Three examples, in the same year.
-------------------------------------------------
2486 - .m1. weap scapping by .m2 at scott. 358 weap resources gained from scrapping. 3448 energy resources if that option taken.
(You can try with prop/energy as well, just regen and try with other set of scrappers.)
Queued up 2174 worth of production out of 2174 available resources, with the last green item being the starbase upgrade.
The planet production was worth 2174 resources. Margin of 0 resources.
At the end of the queue, I added one mine costing 3 res and one LF to check how much of the identified safety margin resources (0 res) go into the production. It should be 0% complete the next turn.
The item being scrapped is weap tech.
(Alternatively, the tech being scrapped is prop, so with 2 gates, an effective check can be executed, where we check if the idea of discounted refunds for untouched stacks occur. Energy scrappers can also be checked.)
If the discounted refund takes place on the entire stack of components, even if it's a simple addition to the existing stack. If so, the base should be incomplete.
1091/383/474/1580 total
1059/383/474/1580 total next year after scrapping weap
22/8/5/8 delta torp
21/8/5/8 delta torp next year after scrapping weap
46/19/19/184 gate
no change for gate after scrapping weap, of course.
Upgrade cost of 48 resources.
2487 -
starbase built.
mine built 32%. i.e. 1 resource extra generated somehow.
NOTE = This was the only planet that managed to complete the build. One reason I can think of is that this was the only planet out of the 3 tests that had pop growth. The other two examples had no pop growth.
69/10*11 = 75.9 from factories and 42.6 from colonist growth = 118.5, or 118 resource. I know that happens after production, but this is the only thing different compared to the other examples.
UNLESS you bring in player order.
m1 production happened before m2 scrapping
but in the other 2 cases, m2 production and m3 production happened AFTER m1 scrapping.
unlikely as the OoE suggests this isn't possible, but ...
Finally, could it be the amount of resources gained from the tech scrapping? This was the only race that didn't gain too high a gain from the process.. Perhaps if I try it with the prop/energy scrappers...?
Edit - Nah, Energy scrapping gained this race 3448 resources, but it still managed to upgrade safely...
So perhaps it's just something to do with the amount of resources?
Weapon was only 8 resource a torp, while in the lower two cases, we are talking about con and armor costing 24 resources..
------------------------------------------------------
2486 - Scrapping con by m1 at timbuktu. Gained 11373 resources of con.
.m2 had 3447 resources on planet.
(energy scrapping also possible, but low numbers thus won't be an effective check).
Queued up items worth 2447 as well.
Base upgrade consists of 16+1 armor, 1*4 torps, 1*2 shields.
1043/368/462/2087 for total
1027/368/462/2071 for total next year
(check - 16 resources saving. armr savings of 1 each * 32 items * 50% cost on stations = 16 resources. verified)
122/25/13/226 for upgrade
113/25/13/218 for upgrade next year
(8 resources, on account of 17 armr @ 50% cost @ 1 res reduced due to miniaturization per armor)
9/1/0/24 for armor
8/1/0/23 for armor next year
44/18/18/440 each gate
44/18/18/440 each gate next year
2487 -
...
I know my minefields.. but I'm a chaff sweeper.
I used to curse when I got stuck in traffic... till I realised I AM traffic.Report message to a moderator
|
|
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 11:41 |
|
BeeKeeper | | Officer Cadet 1st Year | Messages: 214
Registered: December 2007 Location: Devon, UK, GMT | |
|
So for the slow learners like me, can I summarise this as:
There are two issues, the first is where a SB upgrade is in the production queue but it will take 2 or more years to complete. If the original SB is destroyed before the new SB is completed the state of the replacement SB goes back to zero?
(I have checked this with a couple of test beds and it holds true whether the new SB is going to be 97% complete at the end of the first year or just 5%)
I would not class the above as a bug as you would not expect a new SB to inherit part-built ships from the previous SB (if it was destroyed) so should we expect it when production is of a new SB itself?
What I have not checked is whether any minerals used during the partial build of the SB are lost or returned.
The second issue is where due to miniturisation the owner of the old SB does not get the price for spare parts the dealer originally quoted - so to speak. This is a bit harder to understand as presumably the cost of the new parts may also reduced by miniturisation. But either way it is hard to see this as a bug either.
Both the above should perhaps be classed as "features" rather than bugs and the lesson in both cases is to leave a bit of a margin when upgrading SBs if it is essential they are built in one year.
[Updated on: Sat, 21 April 2012 11:43] Report message to a moderator
|
|
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 12:20 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
nmid wrote on Sat, 21 April 2012 10:25 | you are saying that you had more boranium than was needed for the upgrade? AFTER considering the new mined minerals?
You skipped the question where I asked if you had enough actual minerals to build the base on ground zero, year zero...
|
I answered what you asked.
I'm always taking into account surface minerals and future mined minerals, since Stars! does it too. I had no reason to limit my upgrades to what was already mined, disregarding that turn's mining work.
I'll add that at some point the SB was green AND there were a few kTs of excess Bora and plenty of excess Iron and Germ. I then tweaked the design and, as it stayed green, forgot to re-check minerals.
And yes, Torben did initially mix Bora and Germ.
And no, availability of minerals is not linked to this particular bug. Tech gains and their corresponding miniaturization are.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 13:55 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
nmid wrote on Sat, 21 April 2012 17:03 | CC announced the existence of this bug in Jan 2012, in the game Dynamid3.
A number of us participated in the discussion and then forgot about it .
|
Indeed. Only it was just guesswork then, and there was no hint of how serious the problem actually was.
Quote: | Rounding errors do exist in test1
|
There's no "rounding errors", only poorly understood math.
My test was a bit simpler than yours, and I got some pretty interesting results. Bystander's explanation holds and it explains how the bug works.
Here's my testbed (files available upon request):
* 2 almost identical NAS-JoaTs, one with Weap cheap, the other with Cons cheap. No ISB, no UR, no BET, no Random Events.
* Research "lowest field" with both until everything is at level 9-10. Explore a bit and colonize 1 planet each. REMOVE all mines from the colonies' Qs, leave Terra and Facs.
* Bring 5000kT of each mineral from the HW, then another 4000 extra Germ to ensure plenty of Resources. Set both races to Research only their Cheap tech, and only with their leftover Resources. Keep genning.
* Now we have 2 colonies with good Resources and mins, and zero minerals mined. That removes one variable. Use transports to trim all surface minerals to nice round figures with PLENTY of margin, say 3000kT each. That removes another variable. Clear their Qs. That removes more variables.
* Build a bunch of hi-tech scrappers. Note the cost of the initial SB. It's the same regardless of tech. Doh. Design a new SB for both planets for both races. I put some beams, shields, armor, caps, and a gate, and named it Stargate for reference purposes. The cost is a bit different for both races, but it doesn't matter. It even provides a 2nd set of valuable data.
* Note the total Resources and the Resources projected for Research. I got lucky and no new levels would be reached in the next 1-2 turns, so that variable was removed too. Note the "upgrade" cost as displayed inside the planetary Queues.
* 1st test: upgrade the starting SBs with the new, with and without scrapping. All goes ok. Spent minerals match the projected cost. Research too. As the initial SB cannot miniaturize, there's no bug.
* Set again surface minerals to 3000kT each. Set the scrappers too (ideally the same ones as before, if the last test was a regen without scrapping). Again note projected Research Resources. Clone the gate-SB with a different name, such as Stargate (2). Queue one at each colony, but not at the HWs. Projected cost is zero, right?
* Wrong! The Stargate has miniaturised, and the spent minerals and Resources match EXACTLY the difference in cost. Even a no-upgrade refit has a hidden cost, and this behavior is undocumented, contrary to what the helpfile says, and also wildly different to what happens when there's no miniaturization. We have a bug!
* Note the new costs, roll back to the previous turn and design an upgraded Stargate. Fill it to the brim with shields, armor, weapons... I used the same items for some slots, and upgraded others. I ended up with 2 very different designs for each race. It doesn't really matter. Queue the upgrade at the colony for each race, and test it.
* As expected, actual costs don't match projected costs. The difference again matches the miniaturization of the initial Stargate design. The miniaturization of the upgraded Stargate design doesn't seem to have an effect. There's no "margin" problem. There's no "rounding error". There's only miniaturization happening where it shouldn't.
And that's it. More complete tests can perhaps be made, but this is our bug. SB upgrades have become a risky behavior. Now we have to worry not only about having enough stuff to build them, but also whether some friend or enemy is going to give us tech, and what tech, and when.
...
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Another bug? Star base upgrade not being built.. |
Sat, 21 April 2012 14:16 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
BeeKeeper wrote on Sat, 21 April 2012 17:41 | any minerals used during the partial build of the SB are lost or returned.
|
Quite likely lost.
Quote: | due to miniturisation the owner of the old SB does not get the price for spare parts the dealer originally quoted - so to speak. This is a bit harder to understand as presumably the cost of the new parts may also reduced by miniturisation. But either way it is hard to see this as a bug either.
|
Miniaturization is applied where it shouldn't, when it shouldn't. Behavior of SB upgrades becomes random due to the differences when there's tech gain, depending on the tech too. It is (or was) undocumented and contrary to what both the Helpfile and the Stars! User Interface say. It is, by all definitions, a BUG.
Quote: | Both the above should perhaps be classed as "features" rather than bugs
|
The "killed SB kills upgrades" is already classed as such. The time to decide whether this new nasty has to be suffered as "feature" too begins now.
Quote: | and the lesson in both cases is to leave a bit of a margin when upgrading SBs if it is essential they are built in one year.
|
Wouldn't we wish. The "SB killed" case has nothing to do with costs. The "inverse miniaturization" is, by its very nature, too random, too contrary to commonly experienced behavior, and too far-reaching to be workarounded with simple measures like leaving a 5-10% margin, as Nmid's tests show.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | | | |
Re: Another bug? Star base upgrade not being built.. |
Mon, 23 April 2012 08:49 |
|
torben | | Petty Officer 3rd Class | Messages: 49
Registered: October 2007 | |
|
Hi Nmid,
nmid wrote on Fri, 20 April 2012 17:05 |
What's ur third party call on this?
Should we
1. regen or
2. Have a five year ceasefire on the planet and let it get back to strength. In the sixth, let there be another battle for it?
3. Continue on without any change.
|
I fully agree that this specifc bug (or whatever) needs to be investigated, but building testbeds and determining the root logic behind this isn't neccessarily as trivial as MA suggests (it may be though).
As I wrote Ashley, however, my call is option 3 in this specific case based on what I saw in MAs turn files.
Reasoning in short and as far as I dare to make it public (details can be exchanged by e-mail if you like):
I do not believe, that the base which didn't get built would have made a difference. I haven't run a simulation about it, but I even doubt that the base could have done significant additional damage on the one BS token remaining towards the end of the battle.
In the interest of fluid gameplay my ruling would be that you should live with it therefore.
A regen is thus out of the question for me, as the impact on the entire game is quite minor, given, that a regen changes other things as well, given the amount of randomness in a Stars turn. And it doesn't even ensure that the base gets built without modifying that turn (which would have to be done by a third party to be fair).
If both parties agree to a cease fire regarding that planet, I wouldn't complain, but I won't recommend it as at least I would look for other targets of opportunity and leave that planet to be cleaned up when possible. The war will go on, with or without that Planet I guess.
Torben
[Updated on: Mon, 23 April 2012 08:50] Report message to a moderator
|
|
| | |
Re: Another bug? Star base upgrade not being built.. |
Tue, 24 April 2012 19:33 |
|
|
Thanks for all your work Torben. I'm sure the Stars! community would be interested in any new developments you come up with regarding this...
It no longer affects the game though as we are continuing
Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri May 31 23:34:54 EDT 2024
|