Well, it's winter break and I don't really have much else to do, so I set out to start on another rpg that I probably won't ever finish.

Before I get too far in, though, I want to sort out the kills for cash issue:
It can only work if the players kill one unit at a time, and you also have to separate units with the same killscore so the system doesn't get confused.
I know for a fact that some heroes in the map will be using splash. How do I fix it to where it can detect when a player has killed multiple units at the same time?

I think a system where I simply placed a kills to cash trigger for each kill of a unit up to a couple thousand or so would work, but I fear it might cause trigger lag (there will be a good variety of things to blow up, and a technically infinite number of them XD). Would thousands of kills to cash triggers possibly cause trigger lag?

I also want to make enemies have a chance of dropping items when killed (sort of like how it was done in spellsword). Would this be difficult to implement, or is it as simple as it looks?

Any ideas?

PS: I put this in the right section, right? I tend to suck with that XD.

Have you looked further in the tutorial at Kills to Cash Perfect? It solves the multiple units problem, and then from there I'd use that in conjunction with a death-detection system, to detect WHICH units were killed, and award different points accordingly, of course, this could get glitchy if different players kill different units at the same time, but if you also factor in Kill Score, that can help limit some of the problems.


That system actually has a slight chance, because the method of finding a suddenly lost corpse has a 1/2 chance of not finding it, if you wanna do it, download this tests pack and check out Corpse Finder.

Post has been edited 1 time(s), last time on Dec 26 2009, 5:29 pm by Falkoner.

There's no such thing as trigger lag. The only reason triggers will slow down is because of wait blocks or the hyper trig reached the end of its cycle.

The system you described is the most accurate way of doing things, however, having thousands of those triggers seems unnecessary if you can get around it through another way. This will help you.

Ok, thanks Apollo. I've seen that wiki page before, Falkoner PMed it to me yesterday .

So if there's no trigger lag, what causes the infamous lag in maps like Astrogears?


And Falk, like I said in the PM, I saw the "Perfect" system, but I didn't really understand it very well.
So what I do is I track the "Most Kills" score, and whenever someone has the most kills, he gets paid, and the others are given a kill manually, so everyone is even again. But what's the "Scorekeeper" player for?

It could only be waits or hyper trig's next ending occurrence. Since I doubt any of those are actually in Astrogears, it is probably player lag. (From what I recall Astrogears didn't have any lag.)

I rarely experienced lag in astrogears either, but I've heard players complain about it a lot =/.

So, having several thousand triggers won't cause any negative effects with the map?

Well. There isn't a trigger maximum, but if there are too many triggers than it could clog up a computer's RAM. But with the size of RAM today (or even five years ago), that isn't really a possibility. It has to be just player lag.

Wrong, there IS trigger lag, since each trigger being run must be synchronized with other players, so while your computer should be able to handle it, over a battle.net connection, it causes some serious lag to have thousands of triggers, but more importantly, it's what the triggers are DOING that causes the more common lag.

Thousands of triggers WILL lag up a map, especially when a player leaves and on the initial map load, you'll see a lot more players lagging at map start in a map with thousands of triggers. Of course, chances are you're not going to get to the point where it's truly a problem, but it's always a good idea to go for the method that requires the least number of triggers.

The "Scorekeeper" player is used to stay ahead of the rest, but it was later thought of that it's not really necessary to have one, you just detect when players no longer are detected as having the most kills, since when you're tied for most, SC treats it as if you have the most kills.

Well yes, in that sense there is trigger lag. I was addressing the belief that triggers themselves will slow down if there are too many. This doesn't happen, and the only lag one experience is due to connection issues - which is the player's fault. If I went and bought Crysis and tried to run in it on my computer the fps would be so low that it would be unplayable. This isn't a failing of Crysis, but rather my computer.

Trigger lag happens when everyone in the game is unable to keep a connection based on the # of triggers running. The more triggers, the more chance of trigger lag happening.

Ok, thanks.

So what I do is I have a trigger that detects when an enemy player has suffered deaths and when someone has the most kills, and use that to determine who killed what? And then I have the other players receive a kill manually, so it wil be even again? And then I reset the deathcount for the enemy player?
Oh, and the comp player can be the "scorekeeper," right?

The only problem I can see is what if two players killed two different units at the same time? How would the comp know which player killed which unit? I suppose I could have a trigger detecting where the players were (if one of the kills is only found in one of the two areas, we know who killed it), and detecting whether or not the player has kills for the unit (we can't reset kills, but if the player has 0 kills for the unit, we know they didn't kill it)...

Yeah, trust me, it gets complex, and honestly, usually there's really no big problem with sometimes getting the wrong thing, since with HyperTriggers the likelihood that two people are gonna kill units at the same trigger loop is so small, it's more work than it's worth, also, as I said, the scorekeeper isn't necessary(although as long as the comp doesn't get any kills, you CAN use it), if you don't wanna use it, you just detect when only one player is has the most kills, and not all of them.

Kills to Cash Perfect is not really that perfect. In the original concept, only one player could get money per kill run. I say kill run because you can only get money based on how fast you can kill units, not per trigger run. In this map, I made it so multiple players can get money at the same time. It's a tad bit slow, but you can pretty easily vamp up the kill speed using lots of flame traps. Be warned, this increases the rate at which you will reach the weapon limit. Stacked defense 5 way, another map I made demonstrates the ability of the system to accurately give kills, and fairly quickly too.

The main limitation with this setup is that it's limited to one unit. However, you can pretty easily set it up so that a hydralisk gives 2 minerals, a zealot gives 5, and a zergling gives 1. If you include air units, you'll need to include a way to kill said air units. Marines attack with a cooldown of 15, as do hydralisks. Archons do splash damage, and can hit multiple times, but attack with a cooldown of 20. They also have a much smaller range. Due to the nature of the "most kills of x" you can actually do multiple units at the same time in the same area. There's no reason you can't kill a zergling and a hydralisk at the same time, especially since they will be burrowed. Non burrowed units are of course a special case. Trying to kill an archon and a zealot at the same time may cause unit unplaceable errors or cause the unit not to be moved. There are ways around this, of course, but again it's pretty serious triggering, and will lead to a pretty slow kill cycle unless done properly.

As for your question of "how does it know when 2 players killed the unit?"

Lets say player 1 and player 2 have killed the same unit. Player 3 is the computer. Currently all players have the same kill amount, so they ALL have the "most kills" condition true. Player 1 runs the trigger which gives player 2 and player 3 a kill, and himself money. Now player 2 has the most, and can give player 1 and player 3 a kill, giving player 3 the most once again. If you look at my triggers, you'll see that you can give both player 1 and 2 money at the same time, but you have to use player 8 so that the trigger to give a unit to kill runs at the end.

In RE: to trigger lag, SC is programmed terribly, and due to some stuff that I don't understand (like why a unit slows down when a burrowed unit is centered under it), creating/removing/moving/ordering lots of units causes computers to process the information slowly. For example, my computer has a 1.6 GHz single core processor with 1 GB RAM. There is no way I can play Astrogears, even though starcraft's recommended requirements are a 400 MHz processor and 64 MB of ram.

Ok, thanks Rockz... so can you explain to me how your system works???

I didn't understand most of what you said at all, and it didn't look like you said anything about how your system was actually set up, or what it changed...

That wasn't my question.
I asked how the system would know which unit was killed if two players killed two different units, for example, if one player killed a zergling and the other killed a drone. The comp would detect deaths for both, and both the player's scores would go up. How would it know which player killed which?

The player who killed the zergling would have 50 kill score, the one who killed the drone would have 100.

What if Player 1 killed two zerglings and Player 2 killed a drone?

The question should be:

And my answer would be: who gives a crap? A tiny error that hardly ever happens isn't going to be a huge issue, and I wouldn't even worry about your original question, although it can be solved by separating which units are where, and detecting where players are when the kill is made, it's silly to make your systems so perfect..

Under kills to cash perfect, there is no way to determine which unit was killed, only who killed the unit, since I detected "Most kills of any unit". If you detect most kills of zergling instead, you can detect when a player kills a zergling, but you'll have to set up a system which kills zerglings, hydralisks, and any other unit you have.

I'll go ahead and attempt to explain it here:

this is the basic trigger setup.
current player has most kills of unit x
then
Add 1 kills for everyone else (there is no action for this, you have to create units and manually add the kills. This is also why it's so confusing)
Add cash for current player

My method separates this trigger into almost exclusively player 8's ownership, so I can control when everything is done. Normally all of player 1's triggers run, then player 2's, etc... By sticking everything on player 8, you can give multiple people cash on the same kill run.

So instead of running the kill trigger at the beginning, run it after everyone else.

Current player has most kills of unit X
then
Add 1 deaths of cantina for everyone
Subtract 1 deaths of cantina for current player
add cash

If two people have the most kills, then they will both have 1 death of cantina, and everyone else will have 2 deaths of cantina. That's why you detect player 8's deaths of cantina (which will have the number of people who got minerals this kill run) and ensure that you subtract it all out except for one, then create a kill for everyone with a death. If you take a look at the map, and figure out exactly what's happening, it will help you understand how to improve the system.

So you're suggesting that I combine both systems?
Well, there is a way: I was thinking count the deaths on part of the enemy, so it can tell which unit died. Your method sounds simpler though .


I don't think I get it though... if Player 8 owns all the triggers, wouldn't "current player" cause the reward to be given to player 8 instead of the killer?
I'll try and play the map, that should help...

I suppose I could post the exact triggers, but that wouldn't do any good, since the map is already posted, with comments, and so long as you follow the triggers, it should make sense. Think it through logically, and give (in your mind) player 1 a kill, then follow which triggers run. Do it again with player 1 and 2 both getting a kill, and again with player 1 getting 5 kills, player 2 getting 3 kills, and player 3 getting 1 kill.

There are two distinct methods to detect kills: Kill score and most kills. The most kills method will never fail, but it's slow. The kill score will fail with splash, and it's nearly instant. The kill score method can be augmented using deaths, but it will still fail if player 1 kills an infested duran, and player 2 kills an Alexi Stukov, and both ghosts have different cash rewards, and player 1 killed the ghost which was lower in the trigger list. There's a lot of "ifs" involved for when it fails, but so long as you keep the foes limited to unique units for the foes (player 7 has terran, player 8 has toss, for example) and you only kill the same unit at the same time, it will do fine.

I urge you to read the kills to cash page in the wiki, as this has been well documented, and has all been done before. The only thing which hasn't been implemented (to my knowledge) is the most kills of unit X approach. However, you make a good argument to the "deaths" to see which unit died. That is indeed a possibility, and I think it would be pretty simple. I don't feel like editing my map right now, but I think you should be able to copy the trigger under "all players" and add in a death condition, and change the rewards, then remove 1 death from the foe. So long as you give the units to player 9 and don't allow player 9 to be killed in game, it should work for any unit, albeit one at a time.

Post has been edited 1 time(s), last time on Dec 27 2009, 2:34 am by rockz.