13:16, 4th Sep 2015
IcemanBo: Read my replies in thread.

Proper ingame screenshot, please.

Post the triggers in the description or comments

Also, Negative food can end up giving VERY, TERRIBLE, AWKWARD, DESTRUCTIVE results.

Why do you decrease food used when you've already disabled supply?

Need to make sure the system does not leak with regards to using a unit location, will try and update sometime in the near future, shouldn't take too long.

Update:

• Zergling Double Up
  • Events
    • Unit - A unit Finishes training a unit
  • Conditions
    • (Level of Double Me Up (Captain) for (Trained unit)) Greater than 0
  • Actions
    • Set ZerglingTrainedUnit = (Trained unit)
    • Set ZerglingTrainerPoint = (Position of ZerglingTrainedUnit)
    • Unit - Disable supply usage for ZerglingTrainedUnit
    • Unit - Create 1 (Unit-type of ZerglingTrainedUnit) for (Owner of ZerglingTrainedUnit) at ZerglingTranerPoint facing Default building facing degrees
    • Set ZerglingTrainedUnit = (Last created unit)
    • Unit - Disabled supply usage for ZerglingTrainedUnit
    • Unit - Order ZerglingTrainedUnit to Attack-Move To (Rally-Point of (Triggering unit) as a point)
    • Player - Set (Owner of ZerglingTrainedUnit) Food used to (((Owner of ZerglingTrainedUnit) Food used) + 1)
    • Custom Script: call RemoveLocation(udg_ZerglingTrainerPoint)

As for why I decrease food used, that is only for every second Zergling that dies - while the food usage is disabled for the Zerglings, it is manually increased by 1 to give the effect that they cost half a food.

In the current Zergling Dies trigger you increase ZerglingCounter by 1. But I don't see where you reduce it, so when will the condition ZerglingCounter[(Player number of (Owner of (Triggering unit)))] = 0 run?

Wouldn't it just be easier to disable supply for the first unit and not the second one you create?

Trained unit = no food cost.
Created unit = 1 food cost.

Then you don't need the "a zergling dies" trigger.

Also you check if the rallypoint is set to a unit and then order the created unit to follow that unit.

LordDz said:

Wouldn't it just be easier to disable supply for the first unit and not the second one you create?

Trained unit = no food cost.
Created unit = 1 food cost.

Then you don't need the "a zergling dies" trigger.

Click to expand...

This would work but it'd be a poor method - you could selectively kill off all the ones which take up food supply and get an infinite amount of that unit which this method (assuming it's done correctly) would avoid

Also the triggers listed in the description are different from the ones in the map, the condition after the increment to the counter is

• ZerglingCounter[(Player number of (Owner of (Triggering unit)))] Greater than 1

rather than

• ZerglingCounter[(Player number of (Owner of (Triggering unit)))] = 0

at which point it's set to 0 if that condition is met (the condition would be filled every time two zerglings owned by that player dies reducing the food count by 1 it won't however account for removed units)

Still needs some efficiency cleanup (particularly on the unit dies trigger) owner of triggering unit can be stored in a variable

Ah bugger, I'm not sure how I made that error, thanks for the spot xD
I'll fix that right away.

EDIT: Would owner of triggering unit benefit from being stored in a variable? I think I only referenced it once, but will it make it more efficient when stored in a variable?

EDITED EDIT: Just saw the suggestion for following a unit if the Rally-point is set to a unit, that's definitely something I overlooked - I'll certainly look into adding that in, thanks ^_^

UPDATE:

• Zergling Double Up
  • Events
    • Unit - A unit Finishes training a unit
  • Conditions
    • (Level of Double Me Up (Captain) for (Trained unit)) Greater than 0
  • Actions
    • Set ZerglingTrainedUnit = (Trained unit)
    • Set ZerglingTrainerPoint = (Position of ZerglingTrainedUnit)
    • Unit - Disable supply usage for ZerglingTrainedUnit
    • Unit - Create 1 (Unit-type of ZerglingTrainedUnit) for (Owner of ZerglingTrainedUnit) at ZerglingTrainerPoint facing Default building facing degrees
    • Set ZerglingTrainedUnit = (Last created unit)
    • Set ZerglingTrainerPoint = (Rally-Point of (Triggering unit) as a point)
    • Set ZerglingRallyPoint = (Rally-Point of (Triggering unit) as a unit)
    • Unit - Disable supply usage for ZerglingTrainedUnit
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ZerglingRallyPoint Not equal to No unit
      • Then - Actions
        • Unit - Order ZerglingTrainedUnit to Follow ZerglingRallyPoint
      • Else - Actions
        • Unit - Order ZerglingTrainedUnit to Attack-Move To ZerglingTrainerPoint
    • Player - Set (Owner of ZerglingTrainedUnit) Food used to (((Owner of ZerglingTrainedUnit) Food used) + 1)
    • Custom script: call RemoveLocation(udg_ZerglingTrainerPoint)

So far, this seems to work for following a unit when the Rally Point is set to a unit, and I believe this optimizes the location? I'm not sure if I need to do another Custom Script to remove something or not, always open to suggestions for optimization, thanks so much for the feedback so far ^_^

Hello Wazzz,
it's nice to see more submissions but I have big concerns:

• The system is much too simple. Most users can create their own system fairly fast.
  What is done is mostly creating a unit when a specific unit type is trained.
• There exists no config. Systems should have a config and a description how to use it. It is all hardcoded.
• The death trigger should not be part of the system.

For reference I advice to read the Spell Submission Rules,
but also to look at other approved GUI spells/systems to get an idea of how it looks like.

NeedsFix

Which death trigger shouldn't be there? If you mean the Marine death trigger, then that makes sense, it doesn't contribute anything.
It does go beyond creating a unit when a unit with a specific ability* is created, however - it manually increases the food by 1 allowing units to cost 0.5 food which is otherwise impossible on account of food being an integer.
The trigger for registering when the unit dies is necessary on account knowing when to reduce the population - the process involves a counter which serves to ensure players only lose 1 food for every second unit with this ability that dies.

I'm not entirely sure what you mean by a config, though. I should be able to provide a description on how to use it.

What the system does:

1. UnitisTrained
2. If TrainedUnit has ability
-- Double the Unit
-- Disable costs for both units
-- Set Food = Food + 1
3. When 2 units with this ability die
-- Set Food = Food - 1

• Again. It is much too simple for a system submission for our section.
• It does not support multiple unit types at the moment.
• It makes no sense to have things like "1 food" hardcoded, because you can't except each unit to cost 1 food.

Sorry, the concept is too far from an approval at the moment.

It also sets the duplicated unit to respond to Rally Points appropriately :O)

I have found most people have not seemed to develop this concept in their own practicality, figured it might help some people.

Mods usually just don´t care whether or not a resource is useful, it just has to be complicated. If you want the trigger approved I suggest you complicate it. I am clueless when it comes to triggering cause I have adhd and I often find easy simplistic triggering task in we to be very frustrating. It would be nice if mods considered whether or not a resource is useful to be the deciding factor in approval.

Not many people would know how to this right away, I don't see why this isn't approvable. Sure it's simple, but it is original/unique meaning the first of its resource genre to be submitted right? If not then link the first, I just think that this is quite a nice idea so units can cost decimals/reals instead of integers. He did it nicely too, even put in the rally point consideration.

Edit: The concept is indeed approvable iceman, but I think he needs to fix a few hardcoded value's. The only thing that is hardcoded still is 1 food, and more then one unit type however there's much more "simple" resources in our section then you seem to consider. . . I won't link them because I don't want to offend anyone, but it should be easy enough to spot.

Okay, so let's discuss this a bit more.

Em! said:

Mods usually just don´t care whether or not a resource is useful, it just has to be complicated. If you want the trigger approved I suggest you complicate it. I am clueless when it comes to triggering cause I have adhd and I often find easy simplistic triggering task in we to be very frustrating. It would be nice if mods considered whether or not a resource is useful to be the deciding factor in approval.

Click to expand...

This is just not true. Usefulnes is a factor for approval.
Sure, it's easy to attack mods and say this and that, but please argue when you make statements like this.
For example you could make your own review here and argue pro/contra why this is useful or not.
Also ensure to read spell rules, and check out our standards in databsase.

Dat-C3 said:

Not many people would know how to this right away, I don't see why this isn't approvable. Sure it's simple, but it is original/unique meaning the first of its resource genre to be submitted right? If not then link the first, I just think that this is quite a nice idea so units can cost decimals/reals instead of integers. He did it nicely too, even put in the rally point consideration.

Edit: The concept is indeed approvable iceman, but I think he needs to fix a few hardcoded value's. The only thing that is hardcoded still is 1 food, and more then one unit type however there's much more "simple" resources in our section then you seem to consider. . . I won't link them because I don't want to offend anyone, but it should be easy enough to spot.

Click to expand...

Let's summon a tree next to a trained unit, it will be a unique system, too.
This system summons a second unit next to the trained unit.

And the fact that the system tries to mimic the 1st unit behaviour, with this Rally-Point check,
does not automatically mean that the main idea-concept is more worth or upgraded now.

Also, yes it simulates 1/2 food usage, but this system-wise usage does not necessarily makes it useful for gameplay.
You also can use 1 food for 10 units, but then it won't affect any other gameplay scenarios than in that system when for example only 1-9 units die. Only after the 10nd death the 1 food usage will be given again and affect gameplay.

image is ugly

IcemanBo said:

Okay, so let's discuss this a bit more.


This is just not true. Usefulnes is a factor for approval.
Sure, it's easy to attack mods and say this and that, but please argue when you make statements like this.
For example you could make your own review here and argue pro/contra why this is useful or not.
Also ensure to read spell rules, and check out our standards in databsase.

Click to expand...

Here is my argument. The system works as intended. Simplicity is irrelevant.

No counter argument, just follow your rules and if the system does not meet the sites standards then nothing I say matters.

Warcraft 3 is limited to a 300 Population cap at most, and it's an effect from Starcraft that I've seen people try and do

#Wazzz, you need to change the preview image to in-game. This image is inappropriate or i'm reporting the content as disrespectful towards such people.

Wazzz said:

Warcraft 3 is limited to a 300 Population cap at most, and it's an effect from Starcraft that I've seen people try and do

Click to expand...

No it's not. You can easily remove the cap.

If you can easily remove the cap, then how? I've not seen any direct methods beyond making units use no population.

Here is my argument. The system works as intended. Simplicity is irrelevant.

Click to expand...

Nope. If I make system that calculates "3 + x", and x can be configured by the user, I also get a system that works as intended.
But it doesn't change the fact that it will never be approved because it has a too simple concept.

My example is a bit extreme now, but it demonstrates the way I'm thinking here.
It currently does nothing special or really useful and is too simple.

it's an effect from Starcraft that I've seen people try and do

Click to expand...

You must understand, that we can't approve very hardcoded and too limitting resources.
I appreciate that you want to contribute something useful to community,
so I give some suggestions how it can be improved in my eyes.

- Make it support multiple unit types, not only one.
- Make the food usage flexible for each unit type, not hardcoded to "1". *

* Or what you could do is a general food-regulator system.
It would allow the user to define custom food usages for any unit type. (in type: real, not integer)
This system would ensure the wanted food usage for all units of a type in game, and not only trained ones.

Additionaly you could demonstrate the system with the Zergling example.

It does support multiple unit types, though, you just need to apply an ability to the units you want to have the effect.

* Or what you could do is a general food-regulator system.
It would allow the user to define custom food usages for any unit type. (in type: real, not integer)
This system would ensure the wanted food usage for all units of a type in game, and not only trained ones.

Click to expand...

This sounds very interesting, I did recently do something with regards to income in my map that, through the use of modulo, increases your gold by a small trickle every 0.1 seconds, effectively emulating a real value

Alternatively I should be able to make the food usage flexible for each unit type, but what do you have in mind? I think I understand what you mean, but just for clarity, are you saying have it that instead of two units costing 1 food together, it would perhaps take into consideration the original food cost of the unit produced and have them cost that much together?

Like, for example, if you wanted to make a more beefy unit cost 1.5 food rather than 0.5? I'll look into it ^_^

UPDATE:
Turns out it was sooooo easy to do that, just had to change one thing and while I was at it I added a variable for the Dying unit so I'm not constantly referencing Triggering Unit.

• Player - Set (Owner of ZerglingTrainedUnit) Food used to (((Owner of ZerglingTrainedUnit) Food used) + (Supply used by ZerglingTrainedUnit))

Okay, I've updated the map now but I think there is something else I want to do with it. For now, it demonstrates that only when a second unit dies you will lose the population - so if you lose on Hydralisk which is costing 3 Food at the moment, then you will not lose 1.5 Food.
I can fix this with the use of modulo I believe ^_^

UPDATE AGAIN:
I fixed this with the use of modulo.
Here is the new Zergling Dies trigger code:

• Zergling Dies
  • Events
    • Unit - A unit Dies
  • Conditions
    • (Level of Double Me Up (Captain) for (Triggering unit)) Greater than 0
  • Actions
    • Set ZerglingDyingUnit = (Triggering unit)
    • Set ZerglingCounter[(Player number of (Owner of ZerglingDyingUnit))] = (ZerglingCounter[(Player number of (Owner of ZerglingDyingUnit))] + 1)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ((Supply used by (Unit-type of ZerglingDyingUnit)) / 2) Greater than 0
      • Then - Actions
        • Player - Set (Owner of ZerglingDyingUnit) Food used to (((Owner of ZerglingDyingUnit) Food used) - ((Supply used by (Unit-type of ZerglingDyingUnit)) / 2))
      • Else - Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ZerglingCounter[(Player number of (Owner of ZerglingDyingUnit))] Greater than 1
      • Then - Actions
        • Set ZerglingCounter[(Player number of (Owner of ZerglingDyingUnit))] = 0
        • Player - Set (Owner of ZerglingDyingUnit) Food used to (((Owner of ZerglingDyingUnit) Food used) - ((Supply used by (Unit-type of ZerglingDyingUnit)) mod 2))
      • Else - Actions

It does support multiple unit types, though, you just need to apply an ability to the units you want to have the effect.

Click to expand...

Like, for example, if you wanted to make a more beefy unit cost 1.5 food rather than 0.5?

Click to expand...

^These both, unit type and food usage should be done in a configuraton trigger, not via adding certain abilities to the unit.

what do you have in mind?

Click to expand...

I suggest hashtable to solve mentioned issues above.
(Feel free to open a thread in forum in case you have problems with hashtable.)

• Use proper variable names. Our standard is: "PREFIX_DescribingName".
  E.g. if the name was FoodSystem, then "FS_Unit", "FS_Player", ...
• Responses usesd more often shoul dbe stored into variables. For example the "OwnerOfUnit".

It is good that you moved away from the hardcoded "1" food usage, but I really would suggest to focus on making
a system that handles basicly this as mentioned in my post before, and then making the Zergling only an example.
Because for this submission you anyway will have to do kind of this system to make it work, so I think it might be just senseful to make it as standalone system.

I changed the preview image.
Just upload a new one within the next spell update if needed.

Wouldn't a configuration table require users to muck about with Triggers within the code to add what units they wanted to have the effect? As it is, all that needs to be done is to add an ability to any desirable units, which I have seen other uploaded systems do effectively.

Also, I am not quite sure why people seem to like hashtables a lot, what would they do in this circumstance that has not already been achieved? I've not really had any experience in handling hashtables myself so I am somewhat unknowledgeable of them.

User will need to create a new ability for each new custom food usage.
2 units for 1 food is one ability. What if he wants 3 units for 1 food?
Furthermore it is something good that user does not have to work much with object data. (adding abilities)
It is much easier just to define it in a configuration trigger without any unneeded ability.

The user interface for config could look like this, for example:

Also, I am not quite sure why people seem to like hashtables a lot, what would they do in this circumstance that has not already been achieved? I've not really had any experience in handling hashtables myself so I am somewhat unknowledgeable of them.

Click to expand...

The thing is here, if there are multiple unit types.
When a unit dies/enters the world you need to check if the unit type is registered in your system. (so, if you need certain actions, or not)
But if the amount of unit types is dynamic, how do you check it?
You would need to loop through all your registered unit types to find out if the one is registered or not.
With hashtable you have the possibility to directly read it out if a unit type is registered or not with only 1 check.

You can try to solve this first without hashtables if you want, to better understand.
When done, we can talk how it would look like with hashtables to compare.

Ah yeah, I was pondering how I would go about handling the situation where a user would want more than two units for 1 food earlier, and didn't much like the notion of needing a new ability for each one.

Hashtables sound really nice for efficiency, I might have to learn them
Not sure if I'd be able to come up with a solution without them, but I might be able to figure something out.

Okay, and really!, just feel free to ask around in forum, people are often so helpful, in case there are problems with code.

Haha, will do, thanks ^_^

I'll give it a go a bit later and see what I can come up with