Staredit Network

In another help topic, wormer and I were discussing how to make a perfect system to change amount of minerals mined through deathcounts. However, there is one problem. When you refund something (unit, research, building...) it screws up the counter.

Here's a test map I made that gives you 1 mineral per chunk, however, if you cancel a unit or building, it will screw up.

Well I've just created a test map to point out how really the rate of harvesting must be to screw it all up. I've run harvesting from 10 patches with 30 workers on 5 game minutes and get 4488 minerals. Dividing this on 8 will give us 561 harvest. Dividing 561 on 300 seconds (5 minutes) we'll get 1.87 harvest per second on average. Even if we have four full harvesting bases it will be 1.87*4 less than 8 harvests per second. And triggers are running 12 times per second. That will be 8/12 = 2/3 harvests per trigger loop which is approximately 5.3 minerals. This is an average gain per trigger loop. If gain multiplie coefficient k = 1/8 (which is 1 mineral per harvest) then we get 5.3 - 5.3/8 = 4.64 < 5 minerals. If k = 2 (when harvesting doubles) we loose 5.3*2 - 5.3 = 5.3 < 6 minerals. And in general we loose 5.3*k - 5.3 = 5.3*(k - 1) minerals where negative number shows that we actually get that amount of minerals (loose -1 mineral for example means get 1 mineral ). Well and for n fully developped bases it will look like this: (1.87*n/12)*(k-1) minerals loose from one refund. If assume that refunds that give more than 100 minerals (as in that Phantom map you showed) dont taken into account... Draw colclusions with yourself...

By the way running those map with 20 workers gave me 3360 minerals, which is 420 harvests, which is 1.4 harvest per second and we have the formula like this: (1.4*n/12)*(k-1), which for n = 4 and k = 1/8 is equal to 0.4 gain per cancel and with n = 4 and k = 2 it is 0.46 loose of minerals per cancel...

Or... Am I wrong?

There's no point trying figure out average gains since human players will never conform to those rates.

Why not, if you have so many bases than it is hard to come in time with harvesting, only mabe 8-10 workers at one base. I think I can take this into account and count it again...

Wait a second, they mine 8 originally, not 1.

OK, so they would really need about 82 bases to set off the 100 min detecter (still ridiculous, that means approx. 2500 SCVs) and about 41 to set off a 50 min detector (1250 SCVs). Actually, in order to receive a perfect test, why not test for an hour with a single SCV mining a single patch? If we were to use a 25 min detector, this is cutting it a little closer, they only need to return 4 at the same time. However, in order to set it off every time they would need about 700 SCVs, still ridiculous.

Unfortunatly, if you watch SCVs mine, they tend to return mins in 'bursts'. It's not a continual flow like a single SCV mining. According to the second law of thermodynamics though (of course it applies!) if you take the average over a long enough of time and particles (SCVs) the force will appear to be about even, even though it's random. And we will get bursts, and burst will wreck the system. Perhaps test having a test with a CC the normal distance away from stacked mins, and a trigger that lets you know if a burst happens. I'll test various sensitivities after I do my H.W., and I'll also test how many mins you get back for canceling an SCV at the last second. Actually, I think you can do the last one. Just test canceling SCVs at the very last instant. Try the same for rines and lings and supply depots. See how many mins they give back.

Yes, thats why I divide 4488 by 8... Or I dont understand... Now I am too tired and have to go to sleep... That all will come tommorow...

divide by 8 to get the amount of harvests they do. Leave it at 8 to see where the system will screw up. I've currently got a clump tester which I'll leave running for a while. It tests the optimum conditions for clumps. It's been going for about 10 minutes, and the biggest clump is 40 mins so far.

It doesn't matter if you crunch the numbers the right way or not if the number you get in the end won't make your problem any easier to solve.

Well, we're taking different approaches. His is more realistic, but highly inaccurate. Mine is more straightforward, and just determines the worst possible scenario using triggers. And I got that 40 is the biggest clump you can get, unrealistically. I will now figure out how large the refunds are for units.

Wow, refund amounts are simple. 100% for units and upgrades, regardless of progress. 75% for buildings, regardless of progress. So therefore, the smallest refund you can get in the whole game is a marine or SCV, 50 minerals. I guess no matter what, the resource amount has to be divisible by 8, and can't be greater than 41, unless someone's trying to fool the system. And even so, he can't select more than 12 SCVs at a time, and he has to get at least half to hit the CC within 1/12th of a second. Which is pretty improbable, given the way units like to go to their target.

To sum it up, we can use 2 refund detectors, the first one detects whether they have 41 or greater minerals, and if they do, gives regular money back. The second detects wether their minerals are divisible by 8. However, the problem still rests, what if they return mins, and cancel a structure at exactly the same time.

i dont see the point of it tho, you could just increse all costs x8 to get the same effect

that is pretty cool is there any way you cud make it mine mor than eight a time?

Sorry to burst your bubble, but this has been done before...

http://www.staredit.net/index.php?download=4601

No, that's what we've started with. We're trying to figure out a way to prevent it from being screwed up when a building is refunded.

And of course you could make it mine more than 8 at a time! You could make it mine a hundred at a time, or 8000 at a time.

And I didn't know he had published an experimental map for this. He published a phantom map using this, and basically said 'figure it out for yourself'.

And increasing the costs wouldn't look quite as good. Not the effect we're looking for.

And my sample map does the same this using much less triggers.

And here's my final idea for this... If it isn't divisble by 8, then we take the minerals in multiples of 25. That way, they can mine up to three chunks at the same 1/12th of a second period as they cancel a building, which is plenty. With 200 SCVs mining stacked mins right next to the CC I never got more than 5 chunks per 1/12th of a second. And I doubt that people will be using that many SCVs at once, and if they are, whatever... They need to get a brain and realize that using up 100% of your max supply on SCVs is an idiotic idea.

ADDITION:
Here we go, V2! It works surprisingly well. I want you guys to see if you can break it. (I mean by doing something ridiculous, not by opening it up and manually changing the triggers).

I have a feeling that noone exept me and Laser Dude dont understand what is going on...

First I would recommend to look through this topic, where it all begins.


Yes it is but there is no failsafe system for refunds.


Yes, but mabe the problem is not worth to slove it at all, because it happens one time in thousands. This is what I was figuring out. And by the way it is better than nothing, at least we know what to wait for...

Let me repeat the reasoning. It is very simple. Lets assume we get R minerals in S game seconds. Then, as far as hyper triggers fire 12 times per second we get A=R/(12*S) minerals per trigger loop on average. When the system fails it is meant that it is unable to distinguish harvested minerals from refund minerals. That way the system recognizes refund minerals as like they have been harvested and changes that number by multiplying A on a coefficient K and we get A*K minerals instead of A. That way Delta=A*K-A=A*(K-1)=R*(K-1)/(12*S), which is showing us the amount of lost (or get, it depends if K > 1 or K < 1) of minerals per refund.


Well, my calculations are made first of all for not intended refunds, and not for the people who want to break the system.


But you cant set different costs for different players, which can be usefull for example in the Phantom map


That is good. Another failsafe sytem This way if you get amount of minerals from refund not multiply 25 you'll count rest of them as like they have been harvested By the way, Dude, you must have made a mistake in your map, because of clearing 'Switch 01' which is used nowhere esle, I think there should be 'Switch 02'.

I like upper bound failsafe more than this, because it will still work if you change unit costs. All you have to be aware of are low costs. I think the upper bound of 6*8+1=49 would be the best solution for the classic balance, because it is 6 chunks at one time and still a little bit less than 50 minerals cost. Oh well, you'll say Scarabs and Interceptors. Is it worth this? It is so little chance of canceling these units when SCV brings the mineral and even if you trying to break it all you mabe will have a chance of harvesting 30 more minerals in the best case (if youre using limited variant of 1 mineral per chunk). I think you'll have no time for this during the game (especially during the late game when Scarabs and Interceptors become avalible). And if your harvest increases so much the worse for you. I bet you cant even click as fast as 12 times per second.

And you'll ask what about gas? There you could set up upper bound of 25, because harvesting rate there is much lesser than for minerals. Although it needs some testing...

Also final settings for the bound depend on what map you're creating. Is it a 'Fastest' map with stacked resources near your base or what costs of units you actually have in your map.

My opinion is that the problem could not be finally solved, because there is originally no distinguish between refund and harvested resources. All we can do is to check multiplicity of 8 and set up upper bound or get minerals by multiplicity of 25 and assume that the rest of them are harvested. But there is no point to be upset because these cases are VERY rare and almost not controllable and suggested failsafe systems are enough for that purpose.

Well, then again, we could get into really tricky stuff, like detecting when a player starts loses minerals, and keeping it in a DC, and if he refunds, then we give him a regular amount or not depending on the amount in the deathcount.

And my test was on a ridiculous situation. It was assuming they have 200 SCVs mining on a money map with 200 stacked mins. And my failsafe detects whether they have a divisible of 8, then counts off money in variables of 25. It would work for interceptors, but I'm not sure of the cost of scarabs.

So you're just trying to fix the bug where they build something (such as a command center) and mine, say, 24 minerals, so instead of converting those 4 mineral chunks to 4, they go to 24?

I can't seem to get what you're saying. But if in V1 (at top) you start building something, then cancel it, you'll receive a different refund than you should. In V2, it gives you back a normal amount. The reason this is so important is because if someone uses this system to give more mins, if they cancel a structure, they'll get back more than they spent. Which is a major exploit.

Well, what I meant was something much more common...
When you build a building, and return a mineral at the same time, it doesn't detect the minerals returned because you actually lost money.

One thing that may be worth looking into is the constructing score.
If you could somehow match how many points you got from constructing something, then when the score went up, you could fix your money accordingly.

As for the player cancling their own building, the only thing that comes to mind is have a deathcounter constantly updating on how many of those buildings you have, and when you lose one and no one else killed it, setting the minerals accordingly.

1. My system in V2 allows for them to return mins at the same time because it returns them 25 at a time. Therefore, they can return up to 3 chunks at the same time as they cancel something, and the system won't screw up.

2. I don't beleive there is a constructing score. There is one post game, but that cannot, like kills, be detected or changed, either way, you could just as easily detect minerals being spent, compare that to how long it takes to do something of the same cost, then forget about it, but that's way too complex.

3. You cannot detect half-built buildings, units, or half researched upgrades.

Either way, I think the current system works fine as is. Feel free to try and confuse it.

ADDITION:

Thanks. Fix'd.

You can detect half built buildings. I'll break the map tomorrow.

Since when? How?

Either way, you still can't detect half-built units, but at least that helps with the buildings part.

We were trying to fix the same thing when you cancels a building but what you're saying is true and you'll get you 24 minerals because they actually decreased. Well, it is another bug...


But there is another bug in your system:

For example if you cancel Zerg Extractor than you'll get 38 (or 37, dont know cause 50*75%=37.5) minerals back, then you'll substract 25 and detect the rest 13 minerals as like they were harvested... And even more, canceling Engeneering Bay (125 minerals) will count as 19 harvested minerals. Then just imagine you tripple them...



Dude you're wrong there actually is constructing score which you can detect and change and do with it whenever you like. It is Buildings score. I'm curious when those score are actually added, when you start build, when you finished or during the construction? If the score is added at start (and before or along with minerals substraction) then, first of all, you can fix the bug which Lethal_Illusion mentioned (when you starts building), and if that score is returned in the same amount when you cancel a building then you can fix the second bug... You should not even remember all history of building you just watching for Buildings Score changes. It seems very interesting... But there is another problem, could you cancel multiply buildings at once?



It is easy to do since locations are centered on half-built buildings as like they have already been built but they dont detected by Bring condition. It is very similiar to hallucination detection. But this seems to be a little bit complex...


I am thinking exaclty the same way and asking again is all these worth it?..

ADDITION:
Unfortunately Buildings Score is added AFTER the building is finished.

ADDITION:
There are two problems with half-built buildings detection.

First of all we have to somehow cycle through them to detect the same second half-built building. And the only solution I see is giving them to the other player which in the best case would make blinking making it hard to cancel the construction and in the worst case you'll need an extra player for each player running this detection in order not to shuffle buildings between players. Of course you can cycle through first player's buildings then trough second's and so on one after another but this would decrease productivity which is very important when detecting minerals.

The second problem is productivity. Each moment the location is on the single building and when you cancel a building you'll have to wait when the location moves to it to detect, but minerals are not waiting. And more buildings are being built at the same time more likely you dont detect building refund (or built on the other hand) in time. Of cource you can use multiplie locations but first it would complicate the issue and second you never know how many buildings the player would be actually building at once.

Thats why I think this method is not appliable in our case.

Didn't say it was practible.