034 Alchemist [400] v1.0.5

[ZERO]

That feeling when your using a graphing calculator to determine the increment for an ability to level by....

The new standard of ability leveling perhaps? Smaller global function memory usage 100% linear incrementation (or non linear (I could have an ability level up however I want with simpler var changes now)).

Remember that every time I am making a new race I am always looking for ways to improve the code to all future races and to make things like balance changes faster and easier.

[ZERO]

Nothing like waking up to programing multi dimensional array cleaners in the morning. Well I was going to need some new functions sets like this sooner or later.

Reprogramed the code used to calculate wards (used for many things that you would not think are wards, basically finds all clients of a defined team or all teams within X range of a point and then hits a call back method individually for each time one is found.) as there is only 1 call back function there was no way to do different things until now.

With the new code I can now for example have different wards with different things done to clients all while using the same code and functions. This makes code easier to read and debug by reducing as much as possible duplicate code.

[ZERO]

It is from where your standing. It will take 2 to 0.5 seconds it will last 3-10 seconds once activated. Area slightly larger than shadow hunter ward radious right now. All variables are subject to change as we balance it.

You can make 2 per round. You can activate them at the same time if you have 2 planted. Pressing the activation button will always trigger the first one and then the second one.

You will be frozen for that 2-0.5 seconds that it takes to deploy.

[ZERO]

Oh looks like it is time to clean up the code used for ability triggers rofl. Well the good news is at this point I think I will be getting pretty close to standardizing and fully optimizing all the standard code methodology used for every single race soon. (means future coding is much much faster b/c all the optimization has already been done correctly to begin with (also easier to read and edit code))

Example:

Before:

public OnAbilityCommand( client, ability, bool:pressed )
{
    //Plant
    if( War3_GetRace( client ) == thisRaceID && ability == 0 && pressed && IsPlayerAlive( client ) )
    {
        new skill_level = War3_GetSkillLevel( client, thisRaceID, SKILL_WARD );
        if( skill_level > 0 )
        {
            if( !Silenced( client ) )
            {
                
            }
        }
    }
    
    //Activate
    if( War3_GetRace( client ) == thisRaceID && ability == 1 && pressed && IsPlayerAlive( client ) )
    {
        
    }
}

After:

public OnAbilityCommand( client, ability, bool:pressed )
{
    if(War3_GetRace(client) == thisRaceID && IsPlayerAlive(client))
    {
        //Plant
        if(ability == 0 && pressed)
        {
            new skill_level = skill_level_item[client];
            if(skill_level > 0 && !Silenced(client))
            {
                
            }
        }
        
        //Activate
        if(ability == 1 && pressed)
        {
            new skill_level = skill_level_item[client];
            if(skill_level > 0 && !Silenced(client))
            {
                
            }
        }
    }
}

Notice that redundant duplicate code was eliminated allowing for better permanence reduced possibility of errors and increased readability. Rather than keep rechecking the same dam thing multiple times it is done once. In this case it is further optimized by moving the skill level check to its own statement as well (but this could be for 2 different abilities and you logically would test those individually within the defined statement. Also I will be testing with an else if b/c it appears this method is called on a case by case basis and so there can be some benefit to not running unnecessary code. In fact a switch statement might be passable as well to improve optimization to the highest possible degree.

[ZERO]

Yep there we go fully optimized:

public OnAbilityCommand( client, ability, bool:pressed )
{
    if(War3_GetRace(client) == thisRaceID && IsPlayerAlive(client))
    {
        if(pressed)
        {
            switch (ability)
            {
                //Plant
                case 0:
                {
                    new skill_level = skill_level_item[client];
                    if(skill_level > 0 && !Silenced(client))
                    {
                        
                    }
                }
                
                //Activate
                case 1:
                {
                    new skill_level = skill_level_item[client];
                    if(skill_level > 0 && !Silenced(client))
                    {
                        
                    }
                }
            }
        }
    }
}

Note that with only 2 cases there is not any major performance gain as it should be almost exactly the same as an if else but as soon as there is more than 2 this method is better and is thus preferred. Also it can make things easier to read.

[ZERO]

Here a switch would help b/c it would reduce the number of times you need to read from an array but without making the code messy by creating a temp var:

                        if(ClientItemWards[client]==0)
                        {
                            
                        }
                        else if(ClientItemWards[client]==1 && skill_level >= SecodWardUnlockLevel)
                        {
                            
                        }

vs

switch (ClientItemWards[client])
                        {
                            case 0:
                            {
                                
                            }
                            
                            case 1:
                            {
                                if(skill_level >= SecodWardUnlockLevel)
                                {
                                    
                                }
                            }
                        }

[ZERO]

Holy crap, nearly 500 lines later I got the basic structure for the ability casting and creating the structure to find players to ban from having items.

It turns out there is supposed to be a buff for disabling items called bPerplexed but it is not implemented. For the sake of simplicity I will do it that way and then just make a special case for abilities that are not activated. Thus while a user has the bPerplexed buff their items will simply not work. If they have an item that is a 1 time grant like health I will just detect that and remove and give back the health if the user still has the item when it is time for them to get the restored amount.

[ZERO]

Item Transmutation is now in a basic testing phase. You can not currently see where it is cast even. This is just to test that there is no crashes ect. You should not be able to buy items right now when your hit by it. You do get a message telling you what is going on.

[ZERO]

Got a lot of testing done today and cleaned up a lot of bugs. Now I can see what needs to be done to get the item ability fully working. It will be annoying to code but it will work. I have also uncovered other bugs that people where having with that crash issue on the effect that is now corrected and I am cleaning up some other errors as well in my natives for some new functions which were invented along with this race.

Also does anyone know how I can view the contents of the materials and models now that valve has removed them?

[ZERO]

Transmutation ability has been completed. It should now actually remove and give back all of an effected users items. Please test and confirm and report any glitches. If there is any item that has bad removal behavior like health (will be fixed) let me know so we can deal with what should happen to a client when they lose such an item.

NOTE THAT THERE IS CURRENTLY NO EFFECT SET. You WILL get CHAT MESSAGES indicating as to what is going on.