Land Consumption

06-26-2006, 08:11 PM

LAND CONSUMPTION
v1.8

Description: When cast upon an area, Land Consumption factors in all living terrain in the area and then heals allies and damages enemies in the area depending on a factor of how much life was in the area. Once the spell effect occurs, all life from that portion of terrain is eradicated and that terrain is then blighted.
NOTE: Blighted terrain counts as 'dead' terrain, and as such this spell is not allowed to be cast on fully blighted areas of terrain, nor will blight nearby the target area count towards the amount healed/dealt as damage.

Background: This spell is made specifically for use in Spell Session #5 on wc3c (Here, duh!). It is fully written in jass and completely follows the JESP manifest (Check me on that!).

Quote:

New Stuff:
v1.1: Added a series of constants that allow anyone who uses the spell to choose whether or not the spell will revert terrain back to normal after the spell is cast. Allows user to change time before the revert via constants as well.
NOTE: This value was left FALSE so the spell still complies with the contest's theme, but the option is there for people who would like to use it (Seeing as the spell will be submitted as a demo map after the contest).

v1.2: Removed the custom effect to comply with contest requirements. (Just altered a constant and removed the import)

v1.3: You are now allowed to cast on blight, assuming there is SOME living terrain nearby, thus consuming it and only counting the terrain that was alive. This changes nothing about how living terrain is still the resource, except it makes it more manageable and allows you to consume less at a time if you so desire.
Basically, this makes it more flexible.

v1.4: Fixes many of the things Pipe mentioned in order to get it to comply with site regulations. Utilizes a PolledWait() instead of the TriggerSleep(), removed the confusing cache global variable, redid the prefix from lc_ to LCon_, and the biggest part, completely redid the blight sampler, using a rect and throwing out values not in the circle instead of using Polar Coordinates.

v1.5: Did another modification to remove the necesity of the SquareRoot() function call.

v1.6: Another modification to meet some more JESP requirements that I apparently didn't know about beforehand. The spell's trigger name and InitTrig all comply with JESP standards now. Also, most constants now take 3 new arguments, all allowing complete customizational potential to any of them. These arguments are as follows and are fairly self-explanatory.

JASS:

boolean IsLevelAffected, real effectperlevel, integer level

v1.7: I don't know what I was thinking before, but I fully updated all of the per level calibrations to take only one value, integer level.

v1.8: Updated to allow displaying of the debug messages via a constant as well as being able to make the spell heal/damage only (Or do both).

Special Thanks: All credits to anything I used are in the map, but I'll also do it here. Thanks to Vex for making JESP, and thanks to Wc3c for hosting another fun contest for me to partake in!
Thanks to Naak for the good suggestion!
Thanks to PipeDream for reviewing it!
Thanks to Anitarf for another review!

Attached Images

Nc_Pic2.jpg (105.5 KB)

Attached Files

SpellSession5_LandConsumption_v1.8.w3x (45.8 KB)

06-27-2006, 02:10 AM

PipeDream

Hi, PD here filling in for blu. This is one clean job, Rising. Some nitpicks:
- Please use at least 4 characters for the prefix. Because of the birthday paradox with only 2 there'd be collisions at 40 spells or so. Find and replace all is your friend.
- Simerror sound wouldn't hurt when conditions are not met
- Your blight sampler gives more weight to areas at the center of the spell. I think this is a bug, or at least something that should be optional. If you want to remain in polar coordinates, I believe you can fix this with the fibonacci series somehow, like a sunflower. However, a rectangular grid is easy; just toss out points outside the circle.
- TriggerSleepAction for the recover delay is a half dozen different bugs waiting to happen. Since it's a long delay PolledWait will be fine.
- Your test map has a gamecache global variable. Better remove it to avoid confusion, unless you intend to use it.

Could someone check that it follows JESP as advertised? Thanks.

Fix up the minor stuff and I'll approve it.

06-27-2006, 09:31 AM	#3
Rising_Dusk	On your notes, before I load up 1.4, I have a question. Which SimError should I use? The ones at wc3jass are both different, and Ive seen over a dozen different versions across different testmaps. I never used it because it feels like it's just two lines of code I could type up myself everytime. :P If you know of the version of the function I should use, I'll gladly use it to make it prettier.

06-27-2006, 01:15 PM

PipeDream

Try the "Vex no leak" version:

JASS:

//Needs a udg_SimError global sound variable
function SimError takes player ForPlayer, string msg returns nothing
    if udg_SimError==null then
        set udg_SimError=CreateSoundFromLabel( "InterfaceError",false,false,false,10,10)
    endif
    if (GetLocalPlayer() == ForPlayer) then
        call ClearTextMessages()
        call DisplayTimedTextToPlayer( ForPlayer, 0.52, -1.00, 2.00, "|cffffcc00"+msg+"|r" )
        call StartSound( udg_SimError )
    endif
endfunction

Personally I've never used SimError, so, shrug.

06-27-2006, 02:37 PM	#5
Rising_Dusk	Updated, redid the blight sampler, redid everything per your request. I didn't add SimError() though, to be fair I didn't feel adding more configuration requirements in the form of a global was worth the whopping nothing that changed. I guess it's use really boils down to how adamant you want to be about my using it. Personally, I find it useless. >_>

06-27-2006, 03:10 PM	#6
PipeDream	That's fine with me, as personally I wouldn't make it an error at all to cast on blighted ground. Looks good, approved. You had already met all "regulations" per se, it was just an inch more of polish. One final comment: using d^2 < radius^2 instead of SquareRoot(d^2) < radius would be marginally more efficient.

06-27-2006, 08:01 PM	#7
Rising_Dusk	You da' boss, mon. Updated with your final comment completed.

06-27-2006, 09:31 PM	#8
Tim.	Right, I'll check the JESP and move this asap.

06-28-2006, 12:06 AM

Anitarf

You have two issues in regard to the JESP standard.

- You use "Land_Consumption" as your spell's codename in the init function/GUI trigger name, but "LCon" in all other functions. It must be the same everywhere, check the JESP documentation, it's clearly explained.

- The spell must allow for any number of levels, meaning, most of the calibration functions (mainly damage/heal/duration stuff, not needed on sfx calibration functions) should take a level parameter so you can define those values based on the spell level for the hero.

06-28-2006, 12:53 AM	#10
Rising_Dusk	I'll adjust for the first one, it makes sense and I must have overlooked it initially. Anyways, I'll update in a few minutes. EDIT: Updated per your requests, Anitarf. I probably went overboard on the levelup thing though, they all take three arguments now, so they're fully compatible with whatever a person could possibly want, literally.

07-01-2006, 12:22 AM

#11

Anitarf

They're not really in the spirit of the JESP standard, or commons sense, for that matter. You are not supposed to pass data like bonus-damage-per-level to them, that would mean that if someone wanted to change those values for his spell, they would have to go change it in the spell code, which is what calibration functions are designed to prevent.

The users of a JESP spell shouldn't have to alter anything but the calibration functions to adapt the spell to their needs. A calibration function should look like this:

JASS:

constant function LCon_TargetRadius takes integer level returns real
    return 300.0+50*level     //The radius of the area for the spell.
endfunction

...and should be called by your code like this:

JASS:

local integer level = GetUnitAbilityLevel(GetTriggerUnit(),LCon_HeroAbility())
...
local real radius = LCon_TargetRadius(level)

The idea is that the calibration function is given all the information, and the user then decides what to do with it. He can choose to ignore the level argument entirely and just return a constant value, he doesn't need a special boolean to decide if the level should be considered or not. He especialy doesn't need a special boolean that he needs to change somewhere in the spell's code, that makes no sense.

As an extra bonus, you can also pass the intelligence of the hero as an additional argument, so users can calibrate their spell to have intelligence-based damage/radius/duration; however, the JESP standard doesn't require this, it is sufficient to pass the level of the ability to the calibration function.

Also, the density of the checking grid is 20, that's not a particularly round number, something aligned with the terrain grid would be expected, like 128 (the size of one medium terrain grid) or 32 (small terrain grid). If this was calibratable, all the better, users would have an easier job at getting the feeling for how many points get picked and how much damage per point picked they should set.

The targeting options for the damage could be a calibration function too, right now the spell is "hardcoded" to affect all enemies. What about if users would want to change this to ground-only, or non-mechanical only, or non-undead only? It's not as simple to set as changing a few numbers in the damage equation, so it wouldn't be a noob friendly calibration function, but it's still simpler for an average user if there's a calibration function for it than if there isn't.

Also, polled wait leaks, so you should use a timer instead.

If there are any more uncertainties, download an existing JESP spell as a reference.

07-01-2006, 12:51 AM

#12

Rising_Dusk

Quote:

Also, polled wait leaks, so you should use a timer instead

For the love of...
PD told me to use it instead of what it was before...

I'll get to work on it.
There aren't any uncertainties, I just am starting to get the feeling that noone will use the spell anyways, so why bother? :/
*Sigh* I'll update it, give me a day or so.

07-01-2006, 09:10 AM	#13
Anitarf	Well, it's not that a big issue, I'm just not sure how flexible the JESP standard is when it comes to leaks. I know it can be bothersome to work with timers, but unfortunately they are the only really good way to wait in wc3.

07-01-2006, 09:44 AM	#14
PipeDream	Polled wait is fine for this application. The leak is not a strike against approval as it is not a problem with his code and everybody should be running vex map opt on releases. As for sampling, 20 is ok and beyond nyquist for 32 and 128, so whatever. I see no reason to not approve this in its current state.

07-01-2006, 11:09 AM	#15
Anitarf	My main problem were the calibration functions. Fix those as suggested and you have my approval.