[Updated on: Sat, 21 April 2012 04:19]

Report message to a moderator

[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]

Report message to a moderator

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 -

Report message to a moderator

[Updated on: Sat, 21 April 2012 11:43]

Report message to a moderator

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.

Report message to a moderator

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.

Report message to a moderator

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.

Report message to a moderator

Report message to a moderator

Exactly! Nice new feature, huh?

Report message to a moderator

Report message to a moderator

BeeKeeper wrote on Sat, 21 April 2012 21:50

I'm still not convinced you can call this a bug.

Call it whatever you want. Until and unless it's fully understood/documented, it's a shortcoming that'll bite most players, regardless of experience and/or love of MM.

Regarding your apt analogies, should we allow the tradesman to charge us for the things not being changed at all?

Hey, the paint in all those other rooms looks like it came from all kinds of different makers, let me sell it at discount price and then charge you full price for not touching them at all!!

Report message to a moderator

[Updated on: Mon, 23 April 2012 08:50]

Report message to a moderator

torben wrote on Mon, 23 April 2012 14:49

building testbeds and determining the root logic behind this isn't neccessarily as trivial as MA suggests

I built my testbed specifically to test for the 2 particular cases of "upgrade errors" found in the Vanilla2012 game. I was able to confirm and quantify both, which leads me to support the miniaturization-related explanation. I didn't test for other cases, because I know no details of any other cases.

What did your testbeds show?

Not that it matters one bit for the bug-stomping, but did you testbed the battle itself?

Report message to a moderator

m.a@stars wrote on Mon, 23 April 2012 11:04

What did your testbeds show?

Unfortunalety not. A big sorry here, my job came into my way we have severe Problems with one of our databse servers which basically eliminated my spare time these days. Please give me a bit more time to let things settle down.

m.a@stars wrote on Mon, 23 April 2012 11:04

Not that it matters one bit for the bug-stomping, but did you testbed the battle itself?

No, time did not permit that either, my assessment was based on what I saw in the battle and what I know of the battle engine.

If you wish and if all of you have the time, I can do that as soon as I can, maybe I can put this in tomorrow.

Ashlyn? How much time do I have?

Report message to a moderator

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