You can use any unit and just remove it right away. I recommend making a custom unit for each ability with an actor that has a very small scale. When the unit gets trained, remove it from the game.
It depends on which one is triggering an event more frequently. If there are no MarketGold effects occuring at all, the performance drop will be nil, while the periodic event will use memory regardless every 5 seconds. Conversely, if there are a lot of MarketGold effects occurring (more than once every 5 seconds,) the latter event will use more memory.
Either way, if you have a large number of units at any given time, you're going to experience performance drops. Just looking at the event structure, however, I would make this recommendation: Use loops instead of events. This will help limit the amount of memory used in event calls and should help improve performance.
Basically, have the trigger start with a single event at the beginning of the game (or whenever you want the actions to begin occurring,) then use a Repeat Forever or While loop combined with an if/then/else function and a Wait function to achieve the desired effect. In your case, I might use something like this (psuedocode):
You can check both. I think what you're looking for is the "Ground Height At Point" condition function.
For example, I used this function in one of my maps to destroy projectiles if they exceeded certain cliff height boundaries (0.5 higher or 2 lower than the cliff height at the point of launch.) This would keep the projectiles from climbing up cliffs or falling too far down.
To answer your first question, the Wait action is in there to prevent too many actions being queued up, which can cause lag and trigger malfunction. For example, if it just so happened that the game selected 10000 points on cliffs before finding one good point, bad things would happen. With the Wait there, it cycles the next loop into the next game tick so that doesn't happen.
As for checking a unit's height, you have to use the right function. I can't remember exactly at the moment, but one of the functions only checks the units height from the ground, not the unit's overall height.
Set a random point in the area to a local variable first. Then, check the pathing type at that point. If the pathing type is anything other than "Ground," the point is on some unpathable area.
I've made some major changes so I'm looking for feedback on the latest version:
Versions 1.3 & 1.4:
- Bars that are more heavily trafficked now become dirtier more quickly
- Rescaled the way employees become disgruntled over time
- Perdition Turrets no longer cause splash damage to neutral units (customers)
- Customer appearance patterns have changed
- Customers now move at random speeds
- Day counter has been added
- New "Cash Out" ability allows converting vespene into minerals
- Increased Perdition Turret range from 4 to 6
- Reduced Perdition Turret base damage from 16 to 12
- Longbolt Missile Turret now deals +6 damage against massive units
- Added new ability to cause "blackouts" for opponents
- Bars can now be upgraded with various Improvements
- Added Perks for high-level Improvements
- Prices on supplies now fluctuate from time to time
- Random events now increase with frequency as the game goes on
- Miscellaneous bug fixes and improvements
This is absolutely driving me up a wall. I have this dialog that shows several players as options. What I want is for buttons belonging to players that aren't in the game to be hidden. Well, sometimes it works, sometimes it doesn't. Here's my code.
So basically a certain player initiates the dialog. The button corresponding to that player is disabled. Then it cycles through all players, checking to see if each one is in the game or has a specific unit. If these return false, hide that player's button. And that should be it.
The "Player Owns A Bar" function:
PlayerOwnsABarOptions:ConditionReturnType:BooleanParametersPlayer=0<Integer>GrammarText:PlayerOwnsABar(Player)HintText:(None)CustomScriptCodeLocalVariablesActionsGeneral-If(Conditions)thendo(Actions)elsedo(Actions)If(NumberofLivingunitsin(Buck's Bar & Grille units in (Entire map) owned by player Player matching Excluded: Missile, Dead, Hidden, with at most Any Amount)) == 1ThenGeneral-ReturnTrueElseGeneral-ReturnFalse
I wouldn't call it "ethical" so much as "good practice" for future projects or programming... though I suppose you could make an argument for the unnecessary expenditure of another person's resources, as minuscule as that expenditure may happen to be.
I have to agree with Valve's approach (a la Dota 2.) Let people pay oodles of money for things that don't affect the game. Who cares how expensive it is? If someone out there really wants to pay $90 for an exclusive mytho-legend-rary golden half-monkey half-roshan courier, so what? They get the dumb thing they want for a price that, apparently, they were willing to pay, and Valve gets to keep Dota 2 free-to-play without selling game-breaking items. Everyone benefits. FREE MARKET ECONOMY.
In that sense, I disagree with what was said about the Eve online monocle thing. Was it a misinterpretation of the supply/demand curve? Maybe, but that sort of thing happens ALL THE TIME for all sorts of products. How the hell is anyone supposed to know how much to charge for things without a point of reference? If anything, the monocle now serves as one of those points-of-reference for this kind of business model. And in any case, the price can always change down the road to meet a decreased (or increased) demand. So I think their comments on the monocle were more of a commentary on the vendor rather than the market system.
For those of you who may be interested, FuzzYD and I had an interesting chat back in 2011 about sliding entire dialogs across the screen and came up with two methods for accomplishing this task. I haven't tested his recently, but since my method works and his isn't much different in principle, they should both be applicable today. This is a bit more advanced but is a fun little academic exercise at least.
Workaround: Make the unit's collision the smallest you want it to get and create several invisible dummy units of varying collision sizes. Depending on the size of the primary unit, have one of the dummy units occupy the same point.
0
@SuPa_Link: Go
A much better explanation than I was able to provide. Thanks!
0
You can use any unit and just remove it right away. I recommend making a custom unit for each ability with an actor that has a very small scale. When the unit gets trained, remove it from the game.
0
It depends on which one is triggering an event more frequently. If there are no MarketGold effects occuring at all, the performance drop will be nil, while the periodic event will use memory regardless every 5 seconds. Conversely, if there are a lot of MarketGold effects occurring (more than once every 5 seconds,) the latter event will use more memory.
Either way, if you have a large number of units at any given time, you're going to experience performance drops. Just looking at the event structure, however, I would make this recommendation: Use loops instead of events. This will help limit the amount of memory used in event calls and should help improve performance.
Basically, have the trigger start with a single event at the beginning of the game (or whenever you want the actions to begin occurring,) then use a Repeat Forever or While loop combined with an if/then/else function and a Wait function to achieve the desired effect. In your case, I might use something like this (psuedocode):
0
You can check both. I think what you're looking for is the "Ground Height At Point" condition function.
For example, I used this function in one of my maps to destroy projectiles if they exceeded certain cliff height boundaries (0.5 higher or 2 lower than the cliff height at the point of launch.) This would keep the projectiles from climbing up cliffs or falling too far down.
0
To answer your first question, the Wait action is in there to prevent too many actions being queued up, which can cause lag and trigger malfunction. For example, if it just so happened that the game selected 10000 points on cliffs before finding one good point, bad things would happen. With the Wait there, it cycles the next loop into the next game tick so that doesn't happen.
As for checking a unit's height, you have to use the right function. I can't remember exactly at the moment, but one of the functions only checks the units height from the ground, not the unit's overall height.
0
Set a random point in the area to a local variable first. Then, check the pathing type at that point. If the pathing type is anything other than "Ground," the point is on some unpathable area.
Here's a quick function to get you started:
0
@JacktheArcher: Go
Yes, please do! I'd like to have a video of it up soon... I just haven't been happy enough with previous versions to make a recording.
0
I've made some major changes so I'm looking for feedback on the latest version:
Versions 1.3 & 1.4:
- Bars that are more heavily trafficked now become dirtier more quickly
- Rescaled the way employees become disgruntled over time
- Perdition Turrets no longer cause splash damage to neutral units (customers)
- Customer appearance patterns have changed
- Customers now move at random speeds
- Day counter has been added
- New "Cash Out" ability allows converting vespene into minerals
- Increased Perdition Turret range from 4 to 6
- Reduced Perdition Turret base damage from 16 to 12
- Longbolt Missile Turret now deals +6 damage against massive units
- Added new ability to cause "blackouts" for opponents
- Bars can now be upgraded with various Improvements
- Added Perks for high-level Improvements
- Prices on supplies now fluctuate from time to time
- Random events now increase with frequency as the game goes on
- Miscellaneous bug fixes and improvements
0
@Cacho56: Go
By golly, I think you're on to something there! Thanks :)
0
This is absolutely driving me up a wall. I have this dialog that shows several players as options. What I want is for buttons belonging to players that aren't in the game to be hidden. Well, sometimes it works, sometimes it doesn't. Here's my code.
So basically a certain player initiates the dialog. The button corresponding to that player is disabled. Then it cycles through all players, checking to see if each one is in the game or has a specific unit. If these return false, hide that player's button. And that should be it.
The "Player Owns A Bar" function:
0
@Charysmatic: Go
I wouldn't call it "ethical" so much as "good practice" for future projects or programming... though I suppose you could make an argument for the unnecessary expenditure of another person's resources, as minuscule as that expenditure may happen to be.
0
@FunkyUserName: Go
I've noticed these as well.
EDIT: Ironically enough, I got it when posting this reply...
0
I have to agree with Valve's approach (a la Dota 2.) Let people pay oodles of money for things that don't affect the game. Who cares how expensive it is? If someone out there really wants to pay $90 for an exclusive mytho-legend-rary golden half-monkey half-roshan courier, so what? They get the dumb thing they want for a price that, apparently, they were willing to pay, and Valve gets to keep Dota 2 free-to-play without selling game-breaking items. Everyone benefits. FREE MARKET ECONOMY.
In that sense, I disagree with what was said about the Eve online monocle thing. Was it a misinterpretation of the supply/demand curve? Maybe, but that sort of thing happens ALL THE TIME for all sorts of products. How the hell is anyone supposed to know how much to charge for things without a point of reference? If anything, the monocle now serves as one of those points-of-reference for this kind of business model. And in any case, the price can always change down the road to meet a decreased (or increased) demand. So I think their comments on the monocle were more of a commentary on the vendor rather than the market system.
0
For those of you who may be interested, FuzzYD and I had an interesting chat back in 2011 about sliding entire dialogs across the screen and came up with two methods for accomplishing this task. I haven't tested his recently, but since my method works and his isn't much different in principle, they should both be applicable today. This is a bit more advanced but is a fun little academic exercise at least.
0
Workaround: Make the unit's collision the smallest you want it to get and create several invisible dummy units of varying collision sizes. Depending on the size of the primary unit, have one of the dummy units occupy the same point.