System Evolving/Devolving Unit

[PurgeandFire]

Cool, some small things though:

public method restore takes hashtable h, integer instance returns nothing
    local integer i = 12  // ??
    set unit = LoadUnitHandle(h, instance, k_unit)
endmethod

You don't use [ljass]integer i[/ljass].

set mana = GetUnitState(u, UNIT_STATE_MANA)
if (mana != 0) then
    call SetUnitState(u, UNIT_STATE_MANA, GetUnitState(u, UNIT_STATE_MAX_MANA)*manaRatio)
endif

Eh, you only use mana once in this function. In the other function you reset it anyway, so you can directly replace [ljass]mana[/ljass] with [ljass]GetUnitState(u,UNIT_STATE_MANA)[/ljass].

Also, out of curiosity, do you have to do this stuff:

call DisableTrigger(trackPointOrder)
call TriggerClearConditions(trackPointOrder)
call DestroyTrigger(trackPointOrder)

call DisableTrigger(trackTargetOrder)
call TriggerClearConditions(trackTargetOrder)
call DestroyTrigger(trackTargetOrder)

Before destroying a trigger?

Otherwise, cool system. Nice idea, of devolving. ;D

 

[Nestharus]

You don't use integer i.

True that o-o... don't know why that was there, haha.

Eh, you only use mana once in this function. In the other function you reset it anyway, so you can directly replace mana with GetUnitState(u,UNIT_STATE_MANA).

mana was supposed to be used twice, my bad : D. It's also meant to be reset (manaRatio used).

Also, out of curiosity, do you have to do this stuff:

Was doing that stuff out of possible safety as I have no idea how the trigger is being used (in case trigger is on a call stack).

Edit
Nvm on this note... I think I'll get rid of that extra crap ^.^

Otherwise, cool system. Nice idea, of devolving. ;D

If you use an indexing system, this is the only way to safely evolve as well, lol.

 

[Crazy_Dead]

So we add to the snippet above an array or simple struct type or something, another what, 30 lines? And we're done? I don't get it.
I mean hell, I think I could do it with GUI.

Angry? :S

OFFTOPIC TO J4L:

Can you use structs in GUI like this: ?

• Custom Script - struct Data
  • Custom Script - unit u
  • Custom Script - method func takes nothing returns nothing
  • Custom Script - //ETC.

 

[PurgeandFire]

OFFTOPIC TO J4L:

Can you use structs in GUI like this: ?

Not necessarily like that. In general, they look ugly in GUI But they are still doable:

• GUI
  • Events
  • Conditions
  • Actions
    • Custom script: if udg_ToEvaluate == null then
    • Custom script: call ExecuteFunc("Initial")
    • Custom script: else
    • Custom script: call TriggerEvaluate(udg_ToEvaluate)
    • Custom script: endif
    • Custom script: endfunction
    • Custom script: struct Fun
    • Custom script: real x
    • Custom script: static method actions takes nothing returns boolean
    • Custom script: return false
    • Custom script: endmethod
    • Custom script: endstruct
    • Custom script: function Initial takes nothing returns nothing
    • Custom script: set udg_ToEvaluate = CreateTrigger()
    • Custom script: call TriggerAddCondition(udg_ToEvaluate,Condition(function Fun.actions))

Half your code won't really be GUI though. You'll need to use custom scripts for most of your stuff. You'd probably be better off using your own allocation/deallocation along with your own global arrays. ;]

 

[Jesus4Lyf]

Angry? :S

Naw, legitimately confused. I'm wondering why there's so much extra code in there... lol.

>Can you use structs in GUI like this:
Yea, purge nailed it. But it's sillyness. In theory you could call your struct members udg_xx and shadow with globals, since JassHelper renames with struct prefix it won't clash and bug. In theory? I dunno... (Off topic.)

 

[Nestharus]

Naw, legitimately confused. I'm wondering why there's so much extra code in there... lol.

I'll go over all of the code and you can tell me what is extraneous.

Part 1: Stacked Field

• Stack struct that contains a delegate of node
• Node struct that contains unit field
• Module that implements Stack struct like regular vjass extending

I used a field stack to keep the code looking more simple. I didn't want there to be a whole stack object, I didn't want nodes cluttering my stuff, and I most certainly wanted access to my unit var without having to track its instance.

Part 2: Order Tracking System
Sadly, the only way to get a unit's current order is to get it the moment that it is issued. I wanted the system to be able to transfer "everything" from a unit to another unit because I felt that an evolved unit was technically the unit it evolved from in a different shape. This means that I had to track the orders so that the orders would be retained after the unit evolved.

This included 2 triggers and 2 methods as well as an Order struct with a few fields. Furthermore, this meant I would have to add some extra methods to reduce code size (increase readability etc) for registering the unit to the triggers, cleaning up the triggers, disabling/enabling them, and so on.

Part 3: Copying
For this, I wanted to be able to call a method that would just copy a unit and I wanted to be able to copy(unit), push(), copyTo(newUnit). This meant that I would need to make the fields globals. Furthermore, the copying was slightly different for evolving and devolving, so I really needed to maintain flexibility for that. To accomplish that, I created a new struct with 2 methods and made all of the locals into private static globals. The methods are allocate (like allocating the struct, which is copy), and copy (which would be the copyTo).

Part 4: API
Rather than having strange methods like push, pop, and so on, I wanted an API that reflected the system. For example, evolve and devolve. Originally, I also made it so that users passed in units, but I changed this to just unit types as passing in a unit handle didn't make sense = ).


That is all of the code in the system. Now tell me how I can improve the design to get rid of your confusion = ).