ItemRecipe

[Elprede]

What about other arbitrary requirements, such as a specific region a unit must enter or stand in for each recipe? Why not let the user define special requirements for each recipe or for the system as a whole?

 

[MyPad]

Another Recipe System already exists in the Spells database.

What differentiates this from the Recipe System by Chaosy?

 

[Bannar]

What about other arbitrary requirements, such as a specific region a unit must enter or stand in for each recipe? Why not let the user define special requirements for each recipe or for the system as a whole?

Have you read the documentation? Did you check the demo code? Because what you are asking about is implemented in the system.
You are provided with UnitRequirementPredicate interface (Wurst) or UnitRequirementPredicateMdoule (vJass). Checkout the demo map, in there I posted example of usage of such:
- Crown of Kings can only be assembled if no trolls alive are present on the map.

In your case, recipe assembly could be allowed only if certain units are present or absent in given region - simply modify method "isMet". Word "arbitrary" is used here not by mistake, my friend.

Another Recipe System already exists in the Spells database.

What differentiates this from the Recipe System by Chaosy?

Had you even look into the code and documentation?

On hive there is no ItemRecipe that could stand against this one, feature wise. This, together with ItemRestriction, StackNSplit and sneaky SmoothItemPickup enable one to take control over entire item handling in the map. Customizations are in plenty - your imagination is the limit here.
Think about Island Troll Tribes. I'll give you a glimpse.
Boots in ITT require item of type 'hide' in order to construct. However, you are not limited to just a single hide.. it can be Elk, Wolf or Bear hide. Thus "batches" have been introduced. You are permitted to set several items for the exact same spot.
You can declare ordered and unordered recipes - one that do account for inventory item order and others that don't.
You can easily disassemble result items if need be.
Inventory events can and will take part in recipe assembly process, not just item pickup event.
Allows for arbitrary conditions for unit to assembly recipe, e.g.: a mammoth has to be alive in order to assembly specific item.
Assemble recipes despite unit inventory being full.
And so on..

MyPad, you are a Spell Reviewer, and hive reviewers are expected to spend a while validating the system before moving forward.

 

[Chaosy]

I'd argue some of the features are a bit overkill, still, plenty of inspiration for me in the future.

 

[Bannar]

This resource has been created in 2014, some for StackNSplit and ItemRestriction - that's why those are not released as 1.0.0.0. I've recently posted them on github, and the changelog is rich.
Real life has its own plans as we all know, thus many devs have not been releasing as much stuff as they would like or had to even quit this hobby. This includes me too : ) For three years I've been out of scope.

Disclaimer: this is not posted for anyone to copy from - in any case, it deprecates previous libs.
This is a community resource, if you have questions or feedback, post it here so we can make better resources together. I'm including everyone who gave their solid input into credits. Library is not posted in Chaosy thread because it's completely different being, much greater and more powerful. Would be a complete overhaul / rewrite of his lib and in fact, would not be his own lib any longer.

Whatmore, it's not an overkill - many libs are declared as optional requirements. When you think of items, there are many things that can come into mind.
ItemRecipe has been enriched in all of these and has been granted a breeze of arbitrariness.
DotA item handling melts at the mere sight of ItemRecipe.

 

[Aniki]

It seems to me that a big chunk of the functionality of this library can be implemented in a dozen or so functions, with 0 dependencies, much much less code and more efficiently.

library inv initializer init uses libassert

globals
    private integer array inv
    private integer array slots
    private integer g_s1
    private integer g_s2
    private integer g_s3
    private integer g_s4
    private integer g_s5
    private integer g_s6
endglobals

private function inv_load takes unit u returns nothing
    local integer aa
    local integer a = 0
    local item it
    local integer tmp

    set aa = UnitInventorySize(u)
    loop
        exitwhen a == aa
        set it = UnitItemInSlot(u, a)
        if it == null then
            set inv[a] = 0x7FFFFFFF
        else
            set inv[a] = GetItemTypeId(it)
        endif
        set a = a + 1
    endloop

    loop
        exitwhen a == 6
        set inv[a] = 0x7FFFFFFF
        set a = a + 1
    endloop

    set slots[0] = 0
    set slots[1] = 1
    set slots[2] = 2
    set slots[3] = 3
    set slots[4] = 4
    set slots[5] = 5

    // sort the inv array using a sorting network for N = 6;
    // remember the items' original slots
    //
    //! textmacro SWAP takes a, b
        if inv[$a$] > inv[$b$] then
            set tmp = inv[$a$]
            set inv[$a$] = inv[$b$]
            set inv[$b$] = tmp

            set tmp = slots[$a$]
            set slots[$a$] = slots[$b$]
            set slots[$b$] = tmp
        endif
     //! endtextmacro

    //! runtextmacro SWAP("1", "2")
    //! runtextmacro SWAP("0", "2")
    //! runtextmacro SWAP("0", "1")
    //! runtextmacro SWAP("4", "5")
    //! runtextmacro SWAP("3", "5")
    //! runtextmacro SWAP("3", "4")
    //! runtextmacro SWAP("0", "3")
    //! runtextmacro SWAP("1", "4")
    //! runtextmacro SWAP("2", "5")
    //! runtextmacro SWAP("2", "4")
    //! runtextmacro SWAP("1", "3")
    //! runtextmacro SWAP("2", "3")
endfunction

 //! textmacro MATCH takes n
    set m = false
    loop
        exitwhen a == 6
        if x$n$ == inv[a] then
            set m = true
            set g_s$n$ = slots[a]
            exitwhen true
        endif
        set a = a + 1
    endloop
    if not m then
        return false
    endif
    set a = a + 1
//! endtextmacro

private function inv_test2 takes unit u, integer x1, integer x2, boolean flag returns boolean
    local integer a
    local boolean m

static if DEBUG_MODE then
    call assert("[inv_test2] x1 <= x2", /*
        */ x1 <= x2)
endif

    set a = 0
    //! runtextmacro MATCH("1")
    //! runtextmacro MATCH("2")

    if flag then
        call RemoveItem(UnitItemInSlot(u, g_s1))
        call RemoveItem(UnitItemInSlot(u, g_s2))
    endif
    return true
endfunction
private function inv_match2 takes unit u, integer x1, integer x2 returns boolean
    return inv_test2(u, x1, x2, true)
endfunction
private function inv_accept2 takes unit u, integer x1, integer x2 returns boolean
    return inv_test2(u, x1, x2, false)
endfunction
private function inv_remove_items2 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
    call RemoveItem(UnitItemInSlot(u, g_s2))
endfunction

private function inv_test3 takes unit u, integer x1, integer x2, integer x3, boolean flag returns boolean
    local integer a
    local boolean m

static if DEBUG_MODE then
    call assert("[inv_test3] x1 <= x2 and x2 <= x3", /*
        */ x1 <= x2 and x2 <= x3)
endif

    set a = 0
    //! runtextmacro MATCH("1")
    //! runtextmacro MATCH("2")
    //! runtextmacro MATCH("3")

    if flag then
        call RemoveItem(UnitItemInSlot(u, g_s1))
        call RemoveItem(UnitItemInSlot(u, g_s2))
        call RemoveItem(UnitItemInSlot(u, g_s3))
    endif
    return true
endfunction
private function inv_match3 takes unit u, integer x1, integer x2, integer x3 returns boolean
    return inv_test3(u, x1, x2, x3, true)
endfunction
private function inv_accept3 takes unit u, integer x1, integer x2, integer x3 returns boolean
    return inv_test3(u, x1, x2, x3, false)
endfunction
private function inv_remove_items3 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
    call RemoveItem(UnitItemInSlot(u, g_s2))
    call RemoveItem(UnitItemInSlot(u, g_s3))
endfunction

private function inv_test4 takes unit u, integer x1, integer x2, integer x3, integer x4, boolean flag returns boolean
    local integer a
    local boolean m

static if DEBUG_MODE then
    call assert("[inv_test4] x1 <= x2 and x2 <= x3 and x3 <= x4", /*
        */ x1 <= x2 and x2 <= x3 and x3 <= x4)
endif

    set a = 0
    //! runtextmacro MATCH("1")
    //! runtextmacro MATCH("2")
    //! runtextmacro MATCH("3")
    //! runtextmacro MATCH("4")

    if flag then
        call RemoveItem(UnitItemInSlot(u, g_s1))
        call RemoveItem(UnitItemInSlot(u, g_s2))
        call RemoveItem(UnitItemInSlot(u, g_s3))
        call RemoveItem(UnitItemInSlot(u, g_s4))
    endif
    return true
endfunction
private function inv_match4 takes unit u, integer x1, integer x2, integer x3, integer x4 returns boolean
    return inv_test4(u, x1, x2, x3, x4, true)
endfunction
private function inv_accept4 takes unit u, integer x1, integer x2, integer x3, integer x4 returns boolean
    return inv_test4(u, x1, x2, x3, x4, false)
endfunction
private function inv_remove_items4 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
    call RemoveItem(UnitItemInSlot(u, g_s2))
    call RemoveItem(UnitItemInSlot(u, g_s3))
    call RemoveItem(UnitItemInSlot(u, g_s4))
endfunction

private function inv_test5 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5, boolean flag returns boolean
    local integer a
    local boolean m

static if DEBUG_MODE then
    call assert("[inv_test5] x1 <= x2 and x2 <= x3 and x3 <= x4 and x4 <= x5", /*
        */ x1 <= x2 and x2 <= x3 and x3 <= x4 and x4 <= x5)
endif

    set a = 0
    //! runtextmacro MATCH("1")
    //! runtextmacro MATCH("2")
    //! runtextmacro MATCH("3")
    //! runtextmacro MATCH("4")
    //! runtextmacro MATCH("5")

    if flag then
        call RemoveItem(UnitItemInSlot(u, g_s1))
        call RemoveItem(UnitItemInSlot(u, g_s2))
        call RemoveItem(UnitItemInSlot(u, g_s3))
        call RemoveItem(UnitItemInSlot(u, g_s4))
        call RemoveItem(UnitItemInSlot(u, g_s5))
    endif
    return true
endfunction
private function inv_match5 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5 returns boolean
    return inv_test5(u, x1, x2, x3, x4, x5, true)
endfunction
private function inv_accept5 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5 returns boolean
    return inv_test5(u, x1, x2, x3, x4, x5, false)
endfunction
private function inv_remove_items5 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
    call RemoveItem(UnitItemInSlot(u, g_s2))
    call RemoveItem(UnitItemInSlot(u, g_s3))
    call RemoveItem(UnitItemInSlot(u, g_s4))
    call RemoveItem(UnitItemInSlot(u, g_s5))
endfunction

private function inv_test6 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5, integer x6, boolean flag returns boolean
    local integer a
    local boolean m

static if DEBUG then
    call assert("[inv_test6] x1 <= x2 and x2 <= x3 and x3 <= x4 and x4 <= x5 and x5 <= x6", /*
        */ x1 <= x2 and x2 <= x3 and x3 <= x4 and x4 <= x5 and x5 <= x6)
endif

    set a = 0
    //! runtextmacro MATCH("1")
    //! runtextmacro MATCH("2")
    //! runtextmacro MATCH("3")
    //! runtextmacro MATCH("4")
    //! runtextmacro MATCH("5")
    //! runtextmacro MATCH("6")

    if flag then
        call RemoveItem(UnitItemInSlot(u, g_s1))
        call RemoveItem(UnitItemInSlot(u, g_s2))
        call RemoveItem(UnitItemInSlot(u, g_s3))
        call RemoveItem(UnitItemInSlot(u, g_s4))
        call RemoveItem(UnitItemInSlot(u, g_s5))
        call RemoveItem(UnitItemInSlot(u, g_s6))
    endif
    return true
endfunction
private function inv_match6 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5, integer x6 returns boolean
    return inv_test6(u, x1, x2, x3, x4, x5, x6, true)
endfunction
private function inv_accept6 takes unit u, integer x1, integer x2, integer x3, integer x4, integer x5, integer x6 returns boolean
    return inv_test6(u, x1, x2, x3, x4, x5, x6, false)
endfunction
private function inv_remove_items6 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
    call RemoveItem(UnitItemInSlot(u, g_s2))
    call RemoveItem(UnitItemInSlot(u, g_s3))
    call RemoveItem(UnitItemInSlot(u, g_s4))
    call RemoveItem(UnitItemInSlot(u, g_s5))
    call RemoveItem(UnitItemInSlot(u, g_s6))
endfunction

private function inv_remove_slot1 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s1))
endfunction
private function inv_remove_slot2 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s2))
endfunction
private function inv_remove_slot3 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s3))
endfunction
private function inv_remove_slot4 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s4))
endfunction
private function inv_remove_slot5 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s5))
endfunction
private function inv_remove_slot6 takes unit u returns nothing
    call RemoveItem(UnitItemInSlot(u, g_s6))
endfunction


private function unit_add_item_by_id takes unit u, integer item_id returns nothing
    call UnitAddItemById(u, item_id)
endfunction

private function unit_add_item_by_id_charges takes unit u, integer item_id, integer charges returns nothing
    local item it = UnitAddItemById(u, item_id)
    call SetItemCharges(it, charges)
    set it = null
endfunction

native UnitAlive takes unit u returns boolean
globals
    private group g_group = CreateGroup()
endglobals

private function no_trolls_alive takes nothing returns boolean
    local unit u
    local boolean res = true

    call GroupEnumUnitsInRect(g_group, bj_mapInitialPlayableArea, null)
    loop
        set u = FirstOfGroup(g_group)
        exitwhen u == null
        call GroupRemoveUnit(g_group, u)
        if GetUnitTypeId(u) == 'ndtb' and UnitAlive(u) then
            set res = false
            exitwhen true
        endif
    endloop

    call GroupClear(g_group)
    set u = null
    return res
endfunction

private function unit_try_match_recipes takes unit u returns nothing
    call inv_load(u)

    if inv_match2(u, 'kybl', 'kygh') then
        call unit_add_item_by_id(u, 'mgtk')

    elseif inv_accept2(u, 'ches', 'kybl') or inv_accept2(u, 'ches', 'kygh') /*
    */ or inv_accept2(u, 'ches', 'kymn') or inv_accept2(u, 'ches', 'kysn') then
        call inv_remove_slot2(u)
        call unit_add_item_by_id_charges(u, 'mcri', 2)

    elseif inv_accept3(u, 'hcun', 'hval', 'mcou') then
        if no_trolls_alive() then
            call inv_remove_items3(u)
            call unit_add_item_by_id(u, 'ckng')

        else
            call writeln("There are still some trolls alive on the map. Kill them first.")
        endif

    elseif inv_accept6(u, 'bzbe', 'gopr', 'wcyc', 'wlsd', 'woms', 'wshs') then
        call inv_remove_slot1(u)
        call inv_remove_slot3(u)
        call inv_remove_slot4(u)
        call inv_remove_slot5(u)
        call inv_remove_slot6(u)
        call unit_add_item_by_id(u, 'bzbf')
    endif
endfunction

private function on_item_pickup takes unit u returns nothing
    call unit_try_match_recipes(u)
endfunction
private function on_item_pickup_action takes nothing returns nothing
    call on_item_pickup(GetTriggerUnit())
endfunction

private function on_unit_death takes unit d, unit k returns nothing
    if k != null then
        call unit_try_match_recipes(k)
    endif
endfunction
private function on_unit_death_action takes nothing returns nothing
    call on_unit_death(GetTriggerUnit(), GetKillingUnit())
endfunction

private function on_spell_effect takes unit u returns nothing
    local integer sid = GetSpellAbilityId()

    if sid != 'AHtc' then
        return
    endif
    call inv_load(u)

    if sid == 'AHtc' and inv_match4(u, 'ocor', 'ofir', 'oli2', 'oven') then
        call unit_add_item_by_id(u, 'sora')
    endif
endfunction
private function on_spell_effect_action takes nothing returns nothing
    call on_spell_effect(GetTriggerUnit())
endfunction

private function init takes nothing returns nothing
    local trigger t

    set t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_PICKUP_ITEM)
    call TriggerAddAction(t, function on_item_pickup_action)

    set t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_DEATH)
    call TriggerAddAction(t, function on_unit_death_action)

    set t = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(t, EVENT_PLAYER_UNIT_SPELL_EFFECT)
    call TriggerAddAction(t, function on_spell_effect_action)
endfunction

endlibrary // inv


library libassert

function assert takes string s, boolean b returns nothing
    if not b then
        call BJDebugMsg("|cffFF0000assert failed: |r" + s)
        call I2S(1/0)
    endif
endfunction

function writeln takes string s returns nothing
    call BJDebugMsg(s)
endfunction

endlibrary

PS: in jass strings can span multiple lines

globals
    string description = "1) Blood Key + Ghost Key = Magic Chain Key (ordered, onpickup)\n" + /*
    */ "2) Any key +  Cheese (catalyst) = Mechanical Critter (unordered, onpickup)\n" + /*
    */ "3) Helm of Valor + Hood of Cunning + Medallion of Courage = Crown of Kings\n" + /*
    */ "                (ordered, onpickup, special condition: no trolls alive)\n" + /*
    */ "4) All four Orbs = Shadow Orb (unordered, assembled only via Thunder Clap)\n" + /*
    */ "5) All Wands + Glyph (catalyst) + Empty Vial = Full Vial (unordered, onpickup)\n" + /*
    */ "\nYou can order hero to assemble unordered recipes despite their inventory being full." + /*
    */ " Inventory manipulation e.g. item double click can trigger ordered recipe assembly."
endglobals

// =>

globals
    string description = "1) Blood Key + Ghost Key = Magic Chain Key (ordered, onpickup)
2) Any key +  Cheese (catalyst) = Mechanical Critter (unordered, onpickup)
3) Helm of Valor + Hood of Cunning + Medallion of Courage = Crown of Kings
                (ordered, onpickup, special condition: no trolls alive)
4) All four Orbs = Shadow Orb (unordered, assembled only via Thunder Clap)
5) All Wands + Glyph (catalyst) + Empty Vial = Full Vial (unordered, onpickup)
You can order hero to assemble unordered recipes despite their inventory being full.
Inventory manipulation e.g. item double click can trigger ordered recipe assembly."
endglobals

 

[MyPad]

EDIT:

Removed Quote.

Remarks:

• I must agree with @Chaosy here. This is complete overkill, but a good kind of overkill. (Little to no need for an update in features, that is, due to anticipatory approach in coding)
• I cannot help but try to approve this once I get back on mapping.

Nitpicks:

Just in case, these are relatively minor, and may also contain suggestions.​

• In spell importing, I would suggest to make it a bit more descriptive than just plug-and-play.
• Why not rename UnitAssemblyItem to UnitAssembleItem?
• This should be called an Item Recipe System, not just Item Recipe.

Quirks:

• The documentation is crisp and concise, along with the details of the capability of the resource.

As of now, I would like to get a further look on this.

Status:

• Pending, from Awaiting Update

 

[Bannar]

Thank you for feedback guys!

@Aniki what you posted doesn't follow the submission rules (Jass convention).
Now to the things that really matter.. The reason it's coupled the way it is, is to make it intuitive in usage, class instance-methods API that is a very familiar concept for most vJassers. Interface that could be taken out of struct into standalone functions without generating additional code during jasshelper compile, have been moved. On top of that, delegates has been used for module interface to unsure compiled code is clean and again, with no unnecessary methods generated during compile time.
Your code does not account for fact that item recipe could be ordered or unordered type.
Your code does not account for arbitrary recipes (not talking about arbitrary requirements here). I permit user to assembly recipes from vector rather than unit inventory which always limited by the size of 6.
Your code does not account properly for in and out status of units inventory when assembling recipe (what happens to each item in given unit's inventory).
And so on.. I guess you see the point now.

Security is implemented where is it needed and nowhere else, but without any security your code is like a fresh meal for bugs. We don't want bugs.

Thanks for the multiline point tho, I'm used to not being able to use newlines after "." operator (i.e. cascading the invocations) thus I mirrored the string concatenation in the same fashion.

Nitpicks:

Just in case, these are relatively minor, and may also contain suggestions.​

• In spell importing, I would suggest to make it a bit more descriptive than just plug-and-play.
• Why not rename UnitAssemblyItem to UnitAssembleItem?
• This should be called an Item Recipe System, not just Item Recipe.

Could you elaborate on "descriptive"?
The rename of said function seems reasonable.
The "Item Recipe System", you are talking about thread or library itself? I bet it's the former. I agree!

About "overkill" again, I urge you guys to think about Island Troll Tribes recipes, how advanced, how flexible, how dynamic they are. If you ever played that game, you will know what I speak of. If you did not, and perhaps DotA is the only recipe related map you have in mind, know this: troll's recipes are miles away in complexity.

ItemRecipe is an ultimate solution, accounts for basic and advanced needs. Since it and its friends (my other item libs which I've already mentioned) have been accepted by NotD: Aftermath and Island Troll Tribes communities I don't think I followed the wrong path by giving people - read: mappers - tools to do whatever they want with items in their map.
People wanted control. I gave them control.
People wanted power. I gave them power.

 

[MyPad]

I tested this resource and it seemed to work flawlessly.

There are no special effects being played, though that is just my suggestion on item assembly.

Status:

• Approved

 

[Bannar]

The reason for no special effects is because I wanted this to be as generic as possible. Arbitrary content and size of item recipe ingredient list. Arbitrary unit requirements. Arbitrary response on item recipe assembly: EVENT_ITEM_RECIPE_ASSEMBLE. User can register to that event and play whatever effects he or she wants : )

Edit:
As requested, function names have been updated:

ItemRecipe::assembly method has been renamed to assemble.
ItemRecipe::disassembly method has been renamed to disassemble.

ItemRecipe (vJass):
- UnitAssemblyItem function has been renamed to UnitAssembleItem
- UnitDisassemblyItem function has been renamed to UnitDisassembleItem

ItemRecipe (Wurst):
- unit.assemblyItem extension method has been renamed to unit.assembleItem
- unit.diassemblyItem extension method has been renamed to unit.disassembleItem

 

[Bannar]

Wurst package overhaul. For vJass library history, please check war3libs.
Updated test map, fixed code tags.

 

[Cokemonkey11]

This review is for the wurst code only.

- I seem to be missing a high-level API documentation. From reading the code it seems there are lots of public methods that aren't needed in the demo - and thus I think you need a structured set of documentation (A page or so for high-level stuff, and a page or so for lower level (but public stuff)
- "Returns collection of ingredients chosen to assemble the reward item, where each index corresponds to triggering unit inventory slot." - I think this is a good use case for something like a smallvec ( smallvec::smallvec - Rust ) rather than a linked list. In other words, if your LinkedList is always of size 6, may as well use a tupletype - no?
- I noticed that some public methods accept or return data with dynamic lifetime (classes - in particular linkedlist) but your documentation doesn't specify ownership. You should make that abundantly clear in your hotdocs
- Using both halves of a hashmap (negative and positive type ids) is a cool trick!
- "if not batch // removing item when batch is ongoing is forbidden" - you need some error handling here, this kind of code is too fragile
- presentation of code is a bit muddled and weakly documented. I would prefer to see the public API distinct and clear from the private functions; and in general the code needs more comments
- Installation instructions not clear. Are you not using the wurst dependency manager? Maybe you should?

This has a lot of potential, but my view is that the larger and more feature-full the system, so too do things like modularity, documentation quality, and maintainability matter.

3 stars from me, but very improveable

 

[Bannar]

@Cokemonkey11
First things first: thanks for your feedback, appreciated.
In general you want a better documentation. I haven't noticed any code changes per se that you would like to see.

- Ingredient list does not have static size of 6, the size is arbitrary. See the 'test' methods again. This system is highly modular and basically compatible with anything hive has ever produced granted it works with 1.28+ patch. The arbitrary ingredient allows for support of such features as backpack.
- There is no smallvec for wurst or at least I'm not aware of it.
HashMap is basically a Table wrapper and HashList has a very week implementation in wurst. My vJass VectorT is much more suitable for the job, but does not have wurst equivalent.
Wurst documentation does not specify ownership for many container-related public methods either - i.e. it does not destroy the object being manipulated.
The only method that is an exception from that is private, and I handle the release process internally.

- Installation is exactly the same as with wurstStdLib2:
wurstExtLib is just another dependency you link to your project via WurstSetup -> Advanced. Maintainability becomes trivial, you update wurstExtLib the as you do wurstStdLib2.

3/5 seems harsh ;X
Documentation is probably not clear enough for wurst user to quickly get a firm grasp over this powerful library. On the other hand, I expect wurst users to know about installation and such because, frankly, most of wurst users are software engineers or programmers.
Will work on it.

 

[Cokemonkey11]

> In general you want a better documentation. I haven't noticed any code changes per se that you would like to see.

That's right, yes. It's possible that after I see more meaningful documentation I might arrive at some code comments, but right now I think docs is your #1 priority

More complex = more docs needed

> Ingredient list does not have static size of 6, the size is arbitrary. See the 'test' methods again. This system is highly modular and basically compatible with anything hive has ever produced granted it works with 1.28+ patch. The arbitrary ingredient allows for support of such features as backpack.

It's a good point - I did think about pseudo 7th item but didn't keep in mind backpack. I feel somewhat more positive aboud the LinkedList<> centric API now.

I wonder if it makes sense to talk about these structures as Iter<T>. Can wurst describe interfaces over both classes and tuple-types? I'm not sure, but I am sure this is probably overengineering to talk about.

> There is no smallvec for wurst or at least I'm not aware of it.

Given the last point, I don't think it matters - but you could just define a tuple-type, like so:

tuple smallInventory(item i0, item i1, item i2, item i3, item i4, item i5, item pseudo)

These have lower overhead than LinkedList<T>

> Wurst documentation does not specify ownership for many container-related public methods either - i.e. it does not destroy the object being manipulated.

Do you agree though that ownership is important? I think so.

And what about functions that return a new, owned class instance? It's useful to say "returns a new list of item recipes. The list is not otherwise referenced and must be cleaned up." something like that

> wurstExtLib is just another dependency you link to your project via WurstSetup

Cool! But in that case, maybe I could suggest splitting out ItemRecipe from the rest of your dependencies?

Actually I'm not so dead-set on that. The current dependency manager is a bit cumbersome - maybe in the future it would be good to split them, but not so important now.

> 3/5 seems harsh ;X

I'm a harsh guy but based on your responses so far I'm pretty sure I will raise my rating once I see the "executive summary" level documentation and a little bit of cleanup.

 

[Lt_Hawkeye]

Am I correct to assume that the Batch method allows different combinations for the same item?

 

[SinisterLuffy]

@Bannar Can we get static methods for assemble and assembleEx, in which the system will attempt to create any recipe based on given ingredients - whether these are items in normal inventory or custom one?

In other words, can we get like a generic assemble function that does not pertain to a recipe? I want to assemble items with ease on any event, not just on pickup or spell casts.

Without such methods, I thought of creating a stack of my item recipes and then calling assembleEx for each itemRecipe in a loop. However, such a solution is not very elegant, especially if you have a lot of recipes.

 

[Bannar]

@SinisterLuffy just bumping so that you know your comment has been noted. Since the launch of Reforged I haven't been working with WE, really. Compatibility with existing WE version would have to checked first, then status of custom functions that I'd added - see if some aren't deprecated: implemented by Blizzard internally and exposed via public API.

 

[Cokemonkey11]

It would be good to get a clone of the wurst version of this into github for use with wurst.build

 

[Jaccouille]

Hello, I've been having fun using this system in Wurst so far, I just got a few nitpick :

ItemRecipe class contains a "permanent" attribute, this attribute is used to determine whether or not, an item crafted through itemRecipe, can be "disassembled" and refund the ingredients used to assemble the item. I find the term "permanent" confusing as it is a term used in Item Object definition for the Classification field, I actually don't know what's the purpose of classification field other than sorting items in the Editor. Maybe name it "disassemblable" instead?

Same feedback with the "perishable" attribute in the RecipeIngredient class, already used in the Item Object definition, but in the ingredient context, it defines whether or not, the item is consumed upon assemble, maybe rename it to "refundable"?

Last remark is about the ability casted to trigger assemble, I encountered the need to have multiple abilities be used to craft the very same item, if I read correctly, ItemRecipe can hold only 1 ability Id, wouldn't it be possible to use a LinkedList<int> abilityIds to store multiple abilities?