Difference between revisions of "Changing Minerals Mined"

Latest revision as of 00:34, 21 March 2015

With Binary Countoffs and Death Counters, it is possible to change the standard mineral and gas Input stream. While hyper triggers are not necessary, they are highly recommended for unnoticeable effects. A demonstration map can be found here.

Introduction

This system uses 3 death counters. They will henceforth be referred to as "DC1", "DC2", and "DC3". DC1 is a death counter, which, at all times will measure the amount of resources the player had the previous trigger run. DC2 is a temporary death counter. It keeps track of how many minerals were in the bank, as well as DC1's status, while the minerals that have been mined are counted. DC3 is a counter who's purpose is to keep track of how many minerals the player has gathered since the previous trigger run.

Counting Previously Owned Ore

First a dual transfer is made. Since all conditions must be met in order for a trigger to fire, this will empty whichever is lowest, and leave the higher one with the difference. The ore, as well as the value of "DC1" are transferred into "DC2". This will take the amount of ore that the player had previously, and put it into "DC2". Any additional ore will remain, since "DC1" will run out before the ore does.

Counting Newly Aquired Ore

This is the simplest part. Since we have already removed any previously owned ore, the remainder is all either ore that has been gathered, or leftover deaths, caused by spending money. There are two ways to deal with spent money, which will be explained later. For now, we will deal with ore gained. Simply transfer from ore, into "DC3". Since we know that it has been gained by multiples of 8, we only need to use binary values of 8 and above. Also, it is recommended that you either set DC1 to 0 at this point, or do something else to the remainder. We can also, at this point, confirm that no transactions have been made, and check for any remaining minerals. If a transaction has been made, there will be minerals leftover.

Returning Previously Owned Ore

There is nothing complex about this stage, except one important thing to remember. You must transfer the value of "DC3" back into the ore, at a 1:1 ratio. This is because we do not want the player's money in his bank to change between trigger runs. Also, you must transfer the same amount into DC1. This will set the stage for the next trigger run, when the player's resources are recounted.

Returning Newly Mined Ore

Now is the important part of the system. This is where we give back the resources a player has mined. You make a transfer from "DC3" into Ore, and "DC1". If you leave this at a 1:1 ratio, nothing will happen. The map will appear regular. However, if you change the ratio, say 1 DC3:2 Ore, and DC1, you will find the player mining 16 minerals per chunk. It is recommended that you use multiples of 8 for the last DC3 countoff, and the amount received per chunk for the ore returned, and DC1 value. Then double the values as you would for any binary countoff.

Summary

First The ore and "DC1" are transferred into "DC2". Then, the remaining ore is transferred into "DC3". "DC2" is then converted into ore and DC1, and finally, "DC3" is converted to ore and "DC1" at the transfer rate.

Use Alongside Triggers

Generally, when this system is being used alongside triggers, any time you add or remove ore for the player, you should also add or remove an equal amount of "DC1" along with them. The system will not apply the transfer rate, and will act as it should.

Dealing with Transactions

Hereinafter, a "transaction" is any use of money in which the player spends or receives money, not through ore, without the possibility of deaths being added or subtracted. There are two methods in which to solve these. Both have advantages and disadvantages.

Method 1

Method 1 is very simple. All that is done is confirming whether the minerals gained in between trigger run is divisible by 8. If there are any minerals left over after counting newly acquired ore, then a transaction has been made. The transfer rate is not applied that trigger run. One disadvantage is that if a player makes a transaction in which he has earned a number divisible by 8, it will be put through the transfer rate. The disadvantage to this system is that the ore the player has gathered that trigger run will not be changed. Hyper triggers are necessary for this system to run. Mainly because without them, that much more ore will not go through the transfer rate.

Method 2

This method detects whether the player has gained more resources than humanly possible in the timeframe between trigger runs. The tested value with 200 stacked resources at mineral distance, with 200 SCV's is 40 ore per trigger run. If the player has received more than the max ore, they have made a transaction. Then ore is counted back at a certain rate. 25 minerals at a time works for default stats. The disadvantages to this system are that it doesn't work for a variety of maps, and it doesn't work well for small prices.

These two methods can be combined, and mixed around for more effective results.