Hydra v4.2

[BPower]

Yes it must a mistake inside my code. I will check it again.
Thanks for the report.

Also gonna update the link to List

Edit: I tried 15 minutes to reproduce the bug, but I couldn't. I was spamming
all abilities everywhere. Maybe the code is weak at those part where I have this:

if node.next == 0 then
set node = list.firstelse
set node = node.nextendif

A circular linked list would probably solve the problem.
As node.next will always point to the root, if it's the last node.
Is there a proper debuged written module on the Jass market?

Edit2:
i tried it again. I don't know what you did to produce that bug. Really not

 

[Blightsower]

Ehh i just had fun trying to destroy enemies then the game froze so i post it here. I like how it attack other units and not focus on one unit.

 

[Nestharus]

There's only this circular one right now : \. It has 0 allocators built into it.

https://github.com/nestharus/JASS/b...tructures/SharedUniqueNxCircularList/script.j


You should be able to just watch the replay, no?


Also keep in mind that eventually they are going to move to like 1a1a and 1t1t form. Beyond that, they are going to go to like List<T>, but that'll be when the compiler is ready : ).

 

[BPower]

I found the mistake and I'm suprised I couldn't reproduce the error in game.
It should appear more often.

There was an invalid integer comparison within the function where I kill
a hydras heads. A comparison of two different types which made no sense.

            local HydraHead head = list.first
            
            if (headCount == head) then
                call PauseTimer(stamp)
                call PauseTimer(shoot)
            endif

You can see that I compared head to headCount, which is not only simply wrong.
It also produces the node read to fail, because later in the function I remove ( head ).
The timers are not stopped and that node is eventually read in the next "attemptShoot" function callback.
Intentionally I wanted to call PauseTimer only once and only on running timers,
but I guess PauseTimer on not running timers does not hurt.

I fixed it and also added a timeout calculation, how much timed life a deallocation hydra head has,
so it doesn't die within it's last shooting animation. It wait between 0.0001 - end of aninamation time.

Thanks for the links Nestharus. I'm gonna look into it, when I come back from traveling.

Edit:

• Uploaded fixed version. Everything should work fine now.
• Fixed links to Nes github resources. They now point to the folder where the code is located.

Things I still could improve:

Intelligent target evaluation:
In a previous version I was able to track, if a missile hits its target or collides with i.e. the ground,
because the missile system was hardcoded within the Hydra library.
Therefore I could add an error member, which forces a missile to change its target, if it is hidden.

Solution:
In the current version, which outsources projectile handling to my Missile library this is also possible,
when the user passes in error parameters into Hydra. It's no longer an automatically running process.

Trigger eval spam:
This method onTargetFilter(u, owner), which is actually public stub method onTargetFilter takes unit target, player owner returns boolean,
runs uncontrollable times per shoot attempt, depending how many units are withing attackRange.
Not a big deal for small crowds, but the count of triggerevaluations is equal to the number of units enumerated + 1

Solution:
I could make a second Hydra version using delegates. This will create much more code per different hydra type,
but will run faster ( function call vs trigger eval ). I could track the number of trigger eval in debug mode and
give a recommendation to change the library version if the counter exceeds a specific number.
API would be the same.

method addhead & method removeHead :
So you dynamically add/remove heads like in the greek legend.
The first meets the following problem: Where to located it, which x/y is good.

The second requires a table + GetHandleId to track which list the head should be added to.
Tabke, because I don't want Hydra to fire an onIndex event of indexers. That's overhead we don't need.

different attack animation:
Currently Hydra supports "attack " + suffix, while suffixes are:

            set thistype.animationSuffix[0] = "first"
            set thistype.animationSuffix[1] = "second"
            set thistype.animationSuffix[2] = "third"
            set thistype.animationSuffix[3] = "fourth"
            set thistype.animationSuffix[4] = "fifth"

Individual animations would require a hashtable + GetUnitTypeId as parent key.

 

[BPower]

I'm going to update the spell this week. I have a few cool ideas, which I want to add
to the API.

Edit:
Updated to 4.2; Changelog:

• Ripped out required methods from the List module and added them directly into the code to reduce overall code. ( removed List as requirement )
• replaced real scale with method operator scale= , can be called now at any time, runs for every head in the list.
• replaced real offset with method operator offset= , can be called at any time, is automatically affected by scale.
• replaced real duration with method operator duration= , can be called at any time, may resets the life time of the Hydra.
• the shooting process starts now after the first head is summoned and not when all heads are summoned.
• shooting process now ends, when the last head is removed.
• added real birthAnimationTime as set-able member to add a delay until a head starts to fire missiles.
• You may add heads manually via method addHead.
• Small code & documentation improvement.

I still have to work on the z impact calculation

Edit: I have quite a lot grammar mistakes in the documentation. I will correct them in the next update.

 

[Genesys]

Fearsome spell, yet cool and so realistic.

 

[BPower]

Thanks

 

[Nestharus]

Ripped out required methods from the List module and added them directly into the code to reduce overall code. ( removed List as requirement )

I don't know if this is a good idea : ). For example, the new linked list stuff supports even better debugging capabilities and still shares the same API. You won't be able to update it by just changing the module name.

If anything, what I recommend is doing an implement List within your HydraStructure module. This'll let you go to any new updates with a single line change.

 

[BPower]

I'll consider using List ( new ) again, when making an update on Hydra.
Currently I'm waiting for user reviews and ingame experiences. I'm also testing the spell
myself ( making a map ).

 

[Bribe]

So, BPower, I have been looking over this spell over time as I wanted to give it my best assessment.

Honestly, syntax and coding is well-optimized. You may want to fix the typo in ToogleUnitIndexer.

The biggest issue I have with it - and it's fundamental: the complexity. You mentioned dissatisfaction with stub methods, but it goes deeper than that.

- An event for many different parts of this spell.
- The high learning curve to inplement it.

At some point, you as the spellmaker must say "I will use my creative, stylistic process here and dissolve a lot of the ambiguity with this spell by making things more automatic. Now, you've made a template, which is great. However, a single implementation of this spell will mean all that complexity went to waste. One might say it's not to fault the system but the user's lack of input, but I say it is a fault if such complexity in a simple situation is a deterrent to users.

For a missile system, yes let's make sure we cover those events. But for a system like this I think what would be better served is a universal template which branches out and makes accessible the fundamental parts of the spell. Instead of making Hydra such a complex resource, make a standalone complex resource which will allow spells similar to Hydra to have those powerful pieces. Make Hydra use a generic version of the system it currently integrates, so you have a simpler Hydra spell and a more dedicated system full of a bunch of features.

You'll probably appreciate doing it when it comes time to make your next spells, knowing that you won't have to code so many parts from scratch. The challenge here will be finding which parts should stay Hydra, and which parts should be split into the other system.

Alternatively, you could say I am trying to split Hydra in two. Hur hur.

 

[BPower]

Thanks for the detailed review. I very appreciate your criticism.

What you mention is exactly, what I was thinking about when writing Hydra and
the first released result v.1.0 was similar to a normal spell with a normal global user setup.
It also had a hardcoded missile system.

Then with burning ambition I wanted to re-write the library, so users can use
Hydra in any way the want to. I didn't want to use modules, because it would
duplicate the source code of hydra for each struct. That's why I used OOP code.

My idea was that a user can have in a map in example

• A frosty hydra
• A fire hydra
• A hydra which only attack dead corpses and let it explode

The learning curve is a bit long, then however everything goes very fast and
the customization level is gigantic.

I will think about changes.