Well I have spent 60 or so hours on my map and have reached a snag. I cannot think of a solution that would not require an additional 4,800 repetitive triggers.

I am currently working on a purchasing system. All costs are in ore. There would be a unit for sale at a pre-determined amount from player 5 6 or 7. These 3 players have the ability to set the cost of the unit by sending a civilian to a location 100, 250, 500, 1000, or 5000 up to 4 times. Each time the civilian goes to the location a respective power up is created to visually display cost. There is no specific order or combination required. As an example, a unit could be for sale for 100 + 250 + 100 + 5000 (=5450 ore.) Total cost of the unit could result anywhere from 100 to 20,000 ore all based by the players 5 6 or 7 selection.

To give you as much info as I can, each power up (flag, larva, crystal, etc) representing a cost, spawns in its own location. There are 4 of these power up locations for players 5, 4 locations for player 6, & 4 locations for player 7.

I have spent a few days considering my possibilities of how to turn a power up unit into a resource cost, and the only feasible solution I can come up with is by using death counts.

Here would be a small example of how I would select the death counts based on power-up. Of course each location would need a trigger for all 5 different power ups.
If player 5 brings 1 psi emiter ($100) to location 1.
Add 100 cave deaths for player 5
If player 5 brings 1 flag ($250) to location 2.
Add 250 cave deaths for player 5
If player 5 brings 1 psi emiter ($100) to location 3.
Add 100 cave deaths for player 5
If player 5 brings 1 crystal ($5000) to location 4.
Add 5000 cave deaths for player 5

With these triggers I now have reference for cost. Every death of cave player 5 has would = the total cost of the unit. Now with a total cost system its just a matter of setting the rules for the buy. The triggers would look something like

Conditions:
Bring("Player 1", "Terran Civilian", "Location 10", Exactly, 1);
Deaths("Player 5", "Cave", Exactly, 100);
Accumulate("Player 1", At least, 100, ore);
Actions:
Set Resources("Player 1", Subtract, 100, ore);
Set Resources("Player 5", Add, 100, ore);

Conditions:
Bring("Player 1", "Terran Civilian", "Location 10", Exactly, 1);
Deaths("Player 5", "Cave", Exactly, 150);
Accumulate("Player 1", At least, 150, ore);
Actions:
Set Resources("Player 1", Subtract, 150, ore);
Set Resources("Player 5", Add, 150, ore);

Conditions:
Bring("Player 1", "Terran Civilian", "Location 10", Exactly, 1);
Deaths("Player 5", "Cave", Exactly, 200);
Accumulate("Player 1", At least, 200, ore);
Actions:
Set Resources("Player 1", Subtract, 200, ore);
Set Resources("Player 5", Add, 200, ore);

etc..

Conditions:
Bring("Player 1", "Terran Civilian", "Location 10", Exactly, 1);
Deaths("Player 5", "Cave", Exactly, 5450);
Accumulate("Player 1", At least, 5450, ore);
Actions:
Set Resources("Player 1", Subtract, 5450, ore);
Set Resources("Player 5", Add, 5450, ore);

I am confident this system would work. Where the hesitation lies is the vast amount of triggers it would require. Player 5,6 & 7 each have their own selling location and players 1-4 each have their own purchase location for each selling spot. So if I follow this line of thought, at purchasing increments of 50, Player 1 buying from Player 5 would require 400 triggers (increments of 50 to max of 20,000.) Player 5 has 4 people they can sell to resulting in 1,200 triggers total for Players 5 selling system. With 3 sellers, this would require 4,800 triggers. I honestly don't know if I have the patience to edit 4,800 triggers in notepad. God forbid I mistype on one trigger, don't know if I would ever find it.

I hope I have been descriptive enough for you to understand the current layout and potential issues. Does anyone have advice to simplify this process? Thanks for your time!

Buzz

I think you should read up on Binary Count-Offs, from what I can see they are the solution to your problem, or at least a way of lessening your trigger amount. Also, so you don't have to make all the triggers manually, you can do them very quickly when using Binary Countoffs if you also use Macro Triggers

Here's a few tutorials on Binary CountOffs:
SeN Wiki
Copying With Binary CountOffs
Math with Binary Countoffs
Maplantis Wiki

Hmm I dunno if that will work in this scenario. He can use it to convert the death count into ore for the seller, but the binary countoff doesn't help when he has to use "accumulate" when a player wants to buy something.

100, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750, 800, 850, 950, 1000, 1100, 1200, 1250, 1300, 1350, 1450, 1500, 1600, 1700, 1750, 1850, 2000, 2100, 2200, 2250, 2350, 2500, 2600, 2750, 3000, 3100, 3250, 3500, 4000, 5000, 5100, 5200, 5250, 5300, 5350, 5450, 5500, 5600, 5700, 5750, 5850, 6000, 6100, 6200, 6250, 6350, 6500, 6600, 6750, 7000, 7100, 7250, 7500, 8000, 10000, 10100, 10200, 10250, 10350, 10500, 10600, 11000, 15000, 15100, 15250, 15500, 20000.

Unless I missed some, that's a total of 79 possible outcomes. That would be 79 triggers per player, per seller (not 400). After you make the initial 79 for Player 1 buying from Player 5, copy/paste them into Word or Wordpad, find and replace Player 5 with Player 6 (and if they use different buy locations, change that, too), and put those into the map. Do it again with Player 7, and presto, you have all the triggers for Player 1 done in 5 minutes.

Once all those are done, you can find and replace Player 1 and the locations for the other players, and that should only take another 5 minutes. The initial 79 triggers should be the only time-consuming part.

EDIT:
Less time-consuming solution in Khaos's or my below posts.

Post has been edited 1 time(s), last time on Sep 5 2009, 9:59 pm by DevliN.

What I would do is simply subtract 50 ore from the player (if they have it) and the price, and repeat the trigger at a rate of 12 times per second, until the price is 0. Then transfer control of the unit for sale. Obviously you should make it so you can't change the price while this is happening, and some way to refund the cost if the player does not have enough ore to pay for the total cost.

Unless I'm reading this wrong, that is.

EDIT:
Hmm I misread your post at first. That's probably a better way of doing it.

Each time the seller adds an amount to the price, it should add that many deaths to a unit owned by all the players. If a player decides to buy it, it'll subtract from the deaths of that unit, subtract ore, and add deaths to a separate refund unit. If the ore and unit deaths are both 0, he wins the unit. If the ore is 0 and the deaths are at least 1, he gets his ore refunded (which is basically subtracting from the refund deaths and adding ore to the player).

That would work.

Post has been edited 2 time(s), last time on Sep 5 2009, 9:54 pm by DevliN.

No, because you can have another trigger be a pre-requisite to the buying one saying that the player needs at LEAST a certain amount of ore to purchase it. For Example, have the beacon owned by neutral, and the buying trigger says that the buyer must own the beacon as a condition. The have the pre-requisite trigger say, "Seller has suffered at least X deaths of price, buying has at least X amount of ore, give beacon to buyer. It'd probably be possible to use dual countoffs both to determine the price, and if the buyer has enough to pay the price.

Yeah, a second countoff would be necessary, otherwise you're still using 79 triggers for just the prerequisite.

Great discussion so far guys. To help clarify one question, the price will not be dynamic mid-sale. Meaning the seller cannot change the price once the unit is posted for sale. If they want to change the price, they can use a cancel option available that will cancel the entire sell, and then the seller has to re-create their sale.

im probably not getting what your trying to explain, because a solution i thought of is rediculously easy if its what your talking about.

You say your using powerups, why not have a dark archon that can mind control these and have those act as your cash system? I've seen this done in a Monopoly map.

So, player 1 mind controls gas sac owned by player 12. Then, if player 1 bring any gas sacs to location (anywhere outside of a small area your using to accumulate these powerups, an inverted area would work well here), move all gas sacs for player 1 to location "checkout counter".

Now you can move those powerups back to their original location so you allow a large range of money combinations.

This limits you to 2 locations at a minimum if you recycle it, or 1 + X where X is the # of players you have, if you want to use different "checkout counter" areas for each of them.

This would also cut down your trigger amount by alot.

Conditions: Current player brings exactly 1 egg sac ($100) to location "outside checkout counter"

Actions: Add 100 deaths of "price total (unused zerg building)" for current player
Give control of all egg sac($100) owned by player 1 at location "checkout counter" to player 12
Move all egg sac (100) owned by player 12 to "cash register"

Now just repeat this for however many powerup variables you have and your set.....sorry if this sounded stupid to you, its probably not what your asking for, but i thought id throw it out there just in case.

The difference between this and Monopoly, though, is that Monopoly has 8 choices (the 8 mineral/gas units) and when one is mind controlled, it moves to the location so you can only choose it once. If that system were to be implemented into this map, there would be 20 units to MC, and still 79 (or whatever) outcomes.

The question at hand isn't how to set a price, but instead how to transfer a unit to a player after a price is set and the player pays that set price.

Basically all you have to do is move the player's minerals into two deathcounts A and B. Then subtract the unit's cost from A and if A is 0, transfer B back to the player's minerals. Otherwise transfer A to the players minerals and give them the unit

ok, price is set, now set that players minerals to that #
then have as a secondary condition that ' current player accumulates at least xxxxx amount of minerals '

as far as the mind controlling only once bit, its fairly easy to move back the powerup to the location it started at and to change the owner of it back again after its been mind controlled, meaning you could do it as many time as you want to raise the death counts

this ensures that the player has the minerals to pay for it, and allows you to set the payment to whatever outcome can come around with death counts.
then 'subtract xxxxx amount of minerals for player y' and 'give 1 (unit) to player y owned by player z at location 'for sale''

this seems like a fix to me, and with FAR fewer than 4800 triggers....but the way you guys are talking about it im guessing im still missing something or just not understanding an aspect of it

Here is a map that does (i think) what you want.
It's well commented. Read the triggers.

Make SCVs to get money, use the civilians to set the price.
[attach=4454]

Attachments:

Unless I'm reading this incorrectly, the issue with this is that if you have the accumulate condition in each trigger for the total cost, you'd need one trigger per possible amount to spend (hence my comment on needing 79 triggers per player per seller just because of the accumulate part). The only way to get around this is with Khaos' suggestion.

This way he can use a binary countoff-like method in multiples of 50:

• Player has at least 5000 ore and cost death count is at least 5000, subtract 5000 ore and 5000 death counts, and add 5000 death counts to the refund unit.
  
• Player has at least 1000 ore and ditto for the cost death count, subtract 1000 ore and 1000 death counts, and add 1000 death counts to the refund unit.
  
• Player has at least 100 ore and ditto for the cost death count, subtract 100 ore and 100 death counts, and add 100 death counts to the refund unit.
  
• Player has at least 50 ore and ditto for the cost death count, subtract 50 ore and 50 death counts, and add 50 death counts to the refund unit.
  

When the player's death count for cost is exactly 0, the player wins the unit (after a certain amount of time) and set refund unit's deaths to 0. If the player runs out of money and the cost death count is at least 1 (or in this case 50), start subtracting refund death counts and add that back as ore for the player, rejecting the sale due to lack of funds.

EDIT:
Attached is a map using these above triggers. It works well and I recommend using this method. There are a few things to note:

• These triggers assume that only 1 player is setting a price at a time, so rather than having 1 "Cost Deaths" counter, you'd need 1 per player. And rather than just adding deaths to Player 1's "Cost Deaths" (when adding to the cost of a unit), you'd need it to add to all 4 death counters.
  
• I have a switch called "P5 Earning" that sets when Player 1 actually gets the unit that was purchased. I assume that there will be 3 separate locations for 3 separate buyers (i.e. Location 1 = Buying P5's unit, Location 2 = Buying P6's unit, Location 3 = Buying P7's unit), so you'd need to make "P6 Earning" and "P7 Earning" switches that set when this happens.
  
• I have a unit called "Cost Count" that tracks total added cost units (so you can't choose over 4 total). I mention this because of the following note.
  
• I originally had a reset space, but decided that would be pointless for a test run. I suggest you include one in case someone wants to start over. If you do, obviously make it set the "Cost Count" deaths to 0 along with removing the powerups.
  

Any more questions or if anything is confusing, let me know.

Post has been edited 5 time(s), last time on Sep 6 2009, 11:42 am by DevliN.

Wow you guys are amazing! I appreciate the time everyone has spent helping me solve this dilemma. Delvin that map example was more than I could have asked for. Thank you! I am confident I understand how to make this work now and will muddle through it over the next week or so.

To give you guys an update, I spent last night changing the price set maximum from 4 selections to 5. I knew at 4 selections it wouldn't have been quite 400 possible outcomes, but I wasn't pleased with only 79 possible prices. I don't want the seller to feel limited on a small list of potential prices. With the addition of the 5th price selection, the price can swing somewhere from 100 ore to 25,000 ore. I haven't taken the time to do the math and identify how many outcomes are now possible, but I am sure it would not feel limited.

I will take the approach of the binary count offs as listed in the two examples as my purchasing system. I will pop in here from time to time and let you know of my progress and any snags. Thanks again for the advice everyone!

Buzz

Link to my unanswered question of where to put purchased units.

Cool. Well if you were to just copy the triggers from the example map, all you'd have to change is the "Cost Count" condition from "at most 3" to "at most 4" and that will change it to the 5 maximum selections. This system should also work for any outcome (though if it gets higher than 30000, you may want to add a "Player has at least 15000 ore and cost death count is at least 15000" trigger as well to exchange it faster).

I'm glad we could help you. Definitely keep SEN updated on what you're making.