I am sure this question has been asked and answered before but I am unable to find any tutorial for resource sharing on staredit, sen wiki or yahoo with keywords Binary Countoff, Shared Resource, Resource Sharing.
I Found a Tutorial by Tuxedo Templar for Binary Countoff but I dont know how to apply that to resource sharing

Post has been edited 1 time(s), last time on Aug 16 2010, 10:47 pm by Warlord_Master.

Well, a work around could be to use the Custom Score.
Each minerals a player has adds score to Custom Score of Player 1, and the gas adds to Player 2.
Then set all building's cost to free and whenever you detect a building is constructed, scan the amount of score a player has and deduct the cost of the building (or destroy if not enough resources).
Don't forget to show leaderboard.

If you want to use the actual resources instead of scores, the quickest thing I can think of is:

Let Comp be a non-human player who cannot gather or spend resources, "resource" be either ore or gas and "Force" the force (or forces) in which all human players are in.

Copy those two triggers for X=1...n where n is the maximum amount of resources they could have.

I made that up off the top of my head; feel free to correct me if I made any mistakes or forgot something.

Don't use custom score, use death counters, like explained in Tux's tutorial.

The idea of resource sharing is to subtract everyone's minerals and add it to the a "pot" counter and then distribute the pot count among all players.
I've never done it myself so, I might not use the most efficient method, but here's what I'd do:
The adding to the pot is pretty straightforward:
Make a trigger for each value of 2^n for n = 0 ... 10 that subtracts 2^n minerals for the player if he has at least 2^n minerals and add the same amount to the pot.
Then use P8 (whose triggers fire only after all of P1-P7's triggers have run) to distribute the pot:
Make a trigger for each value of 2^n for n = 0 ... 13 and for each number of active players that adds 2^n minerals for the player force if the pot has least 2^n * [nr. of active players] minerals and subtract 2^n * [nr. of active players] the pot.

You could also create more triggers instead of just 0-10 / 0-13 for n when you think there's times that players own more than 2048 minerals / total pot size could become bigger than 16k.

It doesn't sound like you're considering when a player spends resources, unless I'm reading that incorrectly. I believe you would need a second death counter (or reuse the first one) to check the difference for when a player's resources are smaller than the pot (i.e. they spent the resources). Based on whether the difference from the original pot value is positive or negative would determine how big the pot should be on the next trigger cycle.

... Unless the pot is intended to remain completely virtual and not affect the players' actual minerals/gas, which would be rather pointless.

All minerals of all players go into the pot and then are distributed evenly among the players. When someone spent their minerals this money won't go into the pot.
Keep in mind everything is done in a single trigger loop thanks to binary count-offs.

There are multiple different ways to do this. One would be using the minerals as the actual data to manipulate, and the other is to use death counts to store the amount of minerals.

Here is the basic rundown assuming you understand how to use binary countoffs to transfer data types:

You have a singular deathcount that will represent the minerals: DC1. Using a binary countoff, transfer DC1 into the following: Player1Mins; Player2Mins2; Player3Mins (you can have more than three players if you wish); DCReturn. Now transfer DCReturn back into DC1. At the beginning of each trigger cycle you need to set the players' minerals back to 0 so that you can constantly update the players' minerals using binary countoffs.

In order for players to actually spend the minerals you will have to compare the amount of minerals each player has at the end of the trigger cycle to the amount of deaths in DC1. You can do this with a binary countoff that subtracts units from each datatype until one reaches 0. When one is zero (in this system only the minerals should be 0 ever), you can tell how much was spent by the amount left over in DC1. I suggest making a deathcount containing the amount in DC1 for each player so that you can compare the amount in DC1 to the player's minerals without directly messing with DC1.

Once you have your remainder of DC1, you do whatever you like with it within your triggers, and you can use it to detect when the player spent any amount of minerals. I would probably use this remainder to set the rest of the player's minerals lower by the amount remaining. You can do this with yet another binary countoff that subtracts DC1 and the remainder until the remainder is 0. Your next trigger cycle would then distribute the new amount of DC1 into all the other player's minerals.

Possible bugs

• If two players buy something within a trigger cycle then the team could spend more money than they have.
  • Fix: If remainder of DC1 is 0 then undo any purchase (though this means two people can't spend enough money to where they each spend exactly half).

I suggest just ignoring this possible bug.

Note: I didn't take into consideration of mining minerals. rockz's map should be better than what I just described anyways

Post has been edited 3 time(s), last time on Aug 17 2010, 1:36 am by CecilSunkure.

http://www.staredit.net/?file=2292
With the wiki hard to use, I couldn't find the old article. If you can find a static copy of maplantis, you can read all about this map in the thread.

The basic concept is 4 triggers. The first trigger makes a copy of your minerals. The second trigger determines if you gained minerals. The third determines if you lost minerals. The final restores your minerals.

http://www.staredit.net/?p=oldwiki

And sorry for my sucky proposition. It looks like I've lost some of my sc1 mapping skills. ;o

Just to address Cecil's possible bug, buying something "within a trigger cycle" isn't possible. All triggers execute sequentially according to player number instantaneously as far as the game is concerned. Any non-trigger actions will not occur during the trigger cycle.

Also, what is wrong with Nude's method? Resource accumulation happens so often in a normal game (where mining is involved) that there's almost no point to check whether minerals have increased/decreased. Simply keeping the pot distributed Nude's way should work fine. The only real problem I can see would be the redistribution, since 1/4th, 1/3rd, 1/2 or 100% would have to be redistributed to the players depending on how many are in-game, and even that only really amounts to copying a bunch of triggers.

From what I can see, Nude's method does have a problem which Roy mentioned. It's best shown with an example:
instant 1, player 1 mines 200 minerals, p2-4 have none. After P8 trigger runs, P1-4 will now have 50 minerals each.

Player 1 and player 2 spend their 50 minerals, so now only 3 and 4 have 50 minerals each. But at the end of the next trigger cycle, the resources are divided up again, and now each player has 25 minerals, even though it was P1 and P2 that spent their minerals.


Also payne's suggestion for "detecting when a building is created" is actually VERY difficult to get to work flawlessly, especially if you have to deal with multiple buildings of the same type being built at once, and non-instant build times. I have a limited version of this working in my DSNight Fixed map, where when you select 2x mineral mode, the special buildings all cost 2x as much as the listed price. This is done by detecting when a player has started to build the special, and deducting the appropriate amount of $$ from them (or destroying the building if they don't have enough) - it also handles the case where a building is cancelled.

DCs fire once every two frames. If two players spend money within those two frames, then the bug might occur.

What you really mean, Cecil, is "between trigger cycles", not "within". Vrael is correct in that triggers are essentially run instantaneously. But if you have coded your triggers such that the calculations for the current trigger run depend on the results from the previous run, then if the players have acted since the previous trigger run, you could end up with bad results.

Isn't that the idea of shared minerals? Everyone has always the same mineral count.
I think what you're aiming at (and maybe even warlord_master) is shared income, where players share the resources they gather, but not the resources they spend.
My method is clearly not meant for "income sharing".

You can use the same method of comparison I described above with DC1 and each player's minerals at the beginning of the trigger cycle, and use the difference to determine whether minerals were gained or lost, and adjust the "pot" (DC1) accordingly. I suggest doing this instead of the comparison near the end, like I previously described.

What I described would be a fully functional shared resource pot that would allow for spending of minerals, and for income of minerals.

Full description:

This map has shared resources for one force regardless of player number using the absolute least amount of triggers possible (128). It's for both resources, independent of player availability, uses 3 DC's and has no resource limit. Copy and pastable to any map given the DC's aren't interfered with. The only bug I can think of is what Cecil mentioned with multiple players spending resources at the same time in a rare circumstance that enables them to spend more than they should.

Shared income would require less triggers, I'll make one on request.

Attachments:

Post has been edited 2 time(s), last time on Aug 17 2010, 10:09 pm by yoonkwun.

To clarify things: in the case that more than one player buys something, each player gets his re-calculation separately, so the team will only be able to spend more money than "they have", if the cost of the summed up bought things in that very trigger cycle is greater than the team's account has. Am I right in this assumption?

Correct. If you use hyper triggers, then players would have to buy everything within 2 frames. If you don't, you'd have much longer. Also, minerals won't go into the negative, so if 2 players buy the same thing, it will drop down to 0 if they can't fund it entirely. If they can fund it entirely, no issues.

If they were so determined they could detect that situation and save the amount of debt and keep trying to subtract until the debt is paid. Interest-free loan!

It's possible to partically fix the problem of simultanious purchase with actually having "negative" number of minerals stored in DC1. Just let it zero level for instance be 2^16. Everything less than 2^16 should be considered internally by the distribution subsystem as "negative" amount and will transfer to player's minerals as zero. This way, at least even if you managed to spend more than possible you have to make up for it.

P.S. Sorry, Nude, you're the first I didn't see your post.