The map.

For those of you who don't know, this is a system that detects the HP of a ground unit by measuring the damage needed to kill it. The damage is dealt with the Direct Damage system. In this particular map, you can switch weapons (represented by a ghost and a marine) and the HP of your previous unit will be transferred to the new one.

There are two little examples in the test map.

On the left, you will see an arena with one marine standing between two options: 'deal 1 damage per loop' and 'deal 2 damage epr loop'. Pick one and your marine will get damage with the according speed until he is left with 1 HP. If that is not the case, something went wrong and you should report it to me.

On the right of the first test zone, you see a long box where the fighting takes place. Beneath that box is a small, 2x1 box with one unit in it. Move that unit in the small box to change your weapon. Use your SHOTGUN against Kerrigans and your ASSAULT RIFLE against Ultralisks. Kill all the enemies in the arena to feel good. I was too lazy to make health packs heal only a set amount of HP like 2 or 3, so I made them heal you to 5/5 in all cases... if you feel like, edit it yourself to heal 'realistically'; it's basically the same thing as changing the weapons.

Not only is this map a HP detection system, it is also the most effective scarab storage system (*). The amount of minerals is the amount of scarabs in the storage. You will see 8 reavers constantly being created/removed - they are the ones making the scarabs. On average, 4 such reavers produce about 0.9-0.95 scarabs per second, so the 8 reavers I have produce about 1.8-1.9 scarabs. Dealing 2 damage per loop to the marine is slightly more than the reavers can handle production-wise (each scarab deals 1 damage), but fortunately the storage will be fully depleted only after around 4000 trigger loops of such scarab use. I haven't tried dealing 2 dmg/loop and making a lot of weapon changes to see if such demand will deplete the system... but whatever. It's great that you can always add one or two reavers and you'll be in the safe zone for sure.

(*) Besides its applications, a system must not eat too much of the map's resources. This system in the layout you see uses 4+2*N locations (where N is the number of reavers you have) and requires two players (preferrably). There are ways to speed up the current speed of production by about 10% and the lifetime of scarabs by about 5%, but those eat up more locations and cause more lag (twice as many units are being created/removed). The two main ways of increasing the systems effectiveness are:
1. Creating/removing the reaver targets with the reavers. This creates twice as much lag but increases the reavers' average speed of shooting by about 10%
2. Not stack the scarabs, increasing the their 'useful' life time by 1 trigger loop of time. This requires a separate 'path' for every reaver's scarabs (to avoid scarabs blocking eachother on their way), thus increasing the amount of locations you use.
...so in short, perhaps there are situations when these tricks are useful, but in general they're not worth it.

OK, back to the main topic - HP detection. This system is far from perfect and as almost every system, is a compromise between two or more things. In this case, the smaller the error, the more time it requires. The map I displayed works with error=1/5, since the minimal detectable damage a unit can take is 1 and the maximum HP is 5. This means it will take a maximum of 5 loops to detect the damage. If I had, say a 100 HP unit with all the enemies having damages that are all multiples of 5 (i.e. 5, 10, 25, 50, 95, etc), then the preferred error would be 5/100 = 1/20, thus it would take 20 trigger loops to detect the damage. Of course, you could always increase the error to 1/10, thus lowering the time it takes to detect the HP and lowering the accuracy of the process. The error and time are all things you must choose wisely for your map.

A huge thanks to SelfPosessed for helping me out with this and for brainstorming it with me a few months back.

If you have any questions, me and SP will answer them to the best of our abilities.

Discuss.

Post has been edited 2 time(s), last time on Apr 7 2009, 4:24 pm by JaFF.

I broke the system somehow.
I've all the time the dealing damage display, my marine is in the upper part of his area, the ghost is in the playing field with 4/5hp. I saw that a ling died under my ghost. Mineral display is above 100. I was using 1 damage.

Fix please

So you were dealing 1 damage per loop to the left marine and switching weapons wehn the ling died, right? It probably had nothing to do with the marine that was getting 1 damage per loop - I just forgot to heal the ling constantly. Let me edit the map.

ADD: OK, I edited the map. Do waht you did to break it and tell me what happens.

Post has been edited 1 time(s), last time on Apr 6 2009, 12:22 pm by JaFF.

yes, it was the ling. I just watched the replay. And it didn't happen in the new map.

Sweet. I just tested the scarab stacking with 10 and 20 scarabs and it works. Basically, no matter how many scarabs you move from the storage, they will be stacked under units AND EVEN BUILDINGS. Why random suicide can stack scarabs is still beyond me (I found it by accident), but I'm not complaining.

Also of note is how the scarabs move from right to left. It is imperative that the closest target for the random suicide computer to be to the left of the storage area, otherwise everything messes up.

I really REALLY hope this causes people to finally use the system. The hardest part of Direct Damage was storing scarabs, and this makes it braindead easy.

Kudos.

Nah, a popular and decent map that uses this system must be made to make more people use it. What has been done by now is not enough.

Gracias.

Me and Viet-x were planning on using this system to make generic items, like a gem. Having its wireframe different colors depending on what gem it is, eg: Green = Emerald, Yellow = Topaz, Red = Ruby, Over max blue = Sapphire, then detecting the gem with damaging system. (My idea btw)

I have thought of damage for detecting hp a long time ago.

Ideally, you would want to detect the hp of a unit without armor causing any inconsistencies in hp damage. Using 1 damage would help to cut armor out of the detection process, but the problem is that hp detection would take way too long using units with hp in the thousands. Since you can only heal in increments of 1% (which 1% should be close enough when dealing with high amounts of hp), you need to set the hp detection unit (damaging unit) to do 1% damage + armor. This method will take at most 99 trigger cycles to detect the hp.

Example: Marine has 3500 hp and 5 armor, attack it with 40 damage wraiths

To solve the armor issue if a player has made any armor upgrades, simply give the unit to a neutral or computer player, thereby resetting armor back to the original amount.

You would need fast attacking units like a wraith being constantly added and removed to attack every trigger cycle to speed up the detection process. If you wanted to use scarabs with direct damage, make sure to factor in explosive damage.

If the damaging unit is used elsewhere in your map, you could give the hp detection unit upgrades/lack of upgrades to match 1% hp + armor

An alternative option for high hp (organic) units, to get even more precise hp transfer, would be to set the damage to .5% or even smaller, then after setting the nearest 1% hp, have a medic heal the organic unit to the nearest .5% or so. The drawback with this method is that it would take twice as long (199 trigger cycles for .5%) PLUS the time it takes for medic to finishing healing.

For even faster, but less accurate hp detection, you could use 2% of unit's hp (49 trig cycles) or 3% (33 trig cycles) etc...

Since it takes a short while to detect hp, you could just swap out your unit on the map, for and invincible one, cover it up with explosions, or hallu puffs, whatever looks decent.

I've been thinking on how to potentially decrease the amount of locations for the storage system without sacrificing lag or too much speed. Some maps, especially RPGs, are location starved, so a little less efficiency (needs more Reavers) may be worth the number of saved locations.

Small Modifications that have no effect on Speed:
1) Get rid of the remove scarab location unless you're keeping track of the # of scarabs. They'll die on their own. 1 location saved.
2) A burrowed unit could be used as a center point for the move to storage area and the stack location as well, saving two locations.
3) Make the "target" locations a single giant target location that encompasses all of the targets. This will save 7 locations, more if there are more Reavers.

Dealing with the Reaver, is SLOWER:
1) Have the Reaver area be one location with targets scattered throughout it
2) Create the number of Reavers you want and continually move the Scarabs away (to stack, then storage)
3) When there are no more scarabs in the Reaver location, remove them and create new ones

It'll be slower of course as the Reavers which fire slower will slow down other Reavers. However, instead of 1 location per Reaver, it has 1 that encompasses all Reavers. That's a lot of locations saved. IF the speed difference isn't that big, I think it's totally worth doing.

1) Good point. Currently I am keeping count of the scarabs with it, but it can be done in different ways also.
2) Yeah, true as well.
3) That will make the system slower in the current setup. A 'Target_N' location is needed to know where I took the scarab from, thus to remove the reaver as soon as he shoots his scarab. This would be impossible with the 'Always' condition... unless I have one 'scanning' location that goes through all the targets, thus enabling me to detect which reaver shot the scarab. However, assuming the 'give' lag is equivallent to the 'create' lag, this will increase the overall lag by 100%.


1) This gives me an idea: if we detect which reaver shot the scarab, we can always center a location on it and remove/create, without increasing the lag at all if we use different grid units near the reavers.
2) Refer to above.
3) Then the fastest reavers will have to wait for the slowes ones. My rough guess is that the maximum possible speed decrease would be 100%, as the fastest reavers take 1 or 2 loops to fire while the slowest may take up to 4.

I'll consider these things. Perhaps I'll make a separate version of the map.

Post has been edited 1 time(s), last time on Apr 7 2009, 6:53 am by JaFF.

If you need to detect which reaver shot the scarab, why not spread them out and center a location on a scarab when its shot, remove the reaver closest too it with the same location, recreate it, repeat.

Jaff:

Small Modifications:
3) The way you did your triggers, it won't. You create Reavers based on if there are no Scarabs in the Reaver location, not the target.

Large Modifications:
Gridding is a NONO, it LAGS (mobile grid) or costs too many locations (location grid). Cycling is bad too. See Pigy's idea, above which is better. I also expanded on it below.

Pigy_G:

That should work. I like it.

1) Have a large location that encompasses all of the Reavers, but open in the middle of it
2) Put a wierd unit/building in the center of the large location, say a Zerg Egg
3) Move Scarabs from stack to storage
4) Center a small location on Scarabs at the large location
5) If there is a Zerg Egg at the small location, no Scarab has been fired, don't do anything
6) If there isn't a Zerg Egg at the small location, Scarab has been fired
7) Move the Scarab from the small location to the stack area
8) Center the small location on a Reaver at the small location
9) Remove and Create new Reaver at the small location
10) Copy the triggers 4-9 X times, where X is how many Reavers you have

Post has been edited 2 time(s), last time on Apr 7 2009, 1:49 pm by SelfPossessed.

IMPORTANT UPDATE

After the above discussion, I have edited the map. The two most significant changes are:
1) About 30% increase in scarab production. All I did was rearrange the triggers slightly, there was a silly mistake in the order of execution. Now, the amount of scarabs you'll have on average will be around 115 instead of 85.
2) Now, the system uses only 4 locations with any number of reavers.

Re-download the map from the first post please.

That's an odd way of doing things.

Perhaps you're right. However, detecting HP is just an application of the true treasure - the Direct Damage system. if you don't like the HP detection aspect of the map, treat is as an awesome scarab storage system.

We're making this thing nice and compact now. Couple comments.

1) The large location for the storage may not be practical in certain maps (really map specific). For those maps, they can use a burrowed unit at the right most part of the scarab path, center on that, and move scarabs there.
2) You could eliminate the stack location by having a burrowed unit on the storage location to the right of the path, center on that, and moving the Scarabs there. That's 3 locations now.
3) The moving from stack to storage can be part of the constant trigger. Just move all. Tux's test suggested that if there are no units there, doing a move won't cause any lag. That will reduce the trigger count significantly.
4) The scan location can theoretically be any 2x2 location. That way, if the map has a generic 2x2 location that is reused constantly (I do stuff like this all the time), this system can use it too. That reduces another location as technically, it isn't system specific and the location would exist anyways. Down to 2 locations!
5) It's also possible to make the Reaver area larger vertically if horizontal room is a problem. Just enlarge the target location and make a new row of Reavers below it. This would require a 2x2 rather than a vertical strip location to not accidentally select the wrong Reaver.
6) For displaying the # of scarabs, you can use binary countoffs and minerals.

I decided not to use any burrowed units as static grid for this map, even though I knew it's possible. If someone uses the system, they can always edit it to their needs. My goal was to get the message across and show the general working of the system.

Well I've noticed that every time I am down to 1 life and switch weapons it calculates and sets me to 2 life.

Uhhh. I never noticed that, but whatever. My goal was to make a simple and effective storage system and find a quirky application for it. I'm too lazy to fix any bugs within the application systems; bugs within the storage system are a different matter, though.

Reup please!