Thesis on items:

01-17-2004, 06:41 PM

War3 items as we know them have two states. In your inventory, and on the ground.

I propose that these are not seperate states but seperate entites.
But where is my proof? Droping items. its not an order, its a handled screw up.

When you click to drop an item, it moves the hidden version that you pick up to your feet. As if you do a getItemX getItemY they are where your hero was when you first clicked to drop the item, not where his current position is.
Normally this is hidden at some out of bound location. As you move towards the item anything you order will immedietly move the hidden version. War3 then when you come with in the Set range to drop an item, moves it to the pointed at location, unhides the version at your feet and removes the one sitting in your inventory.

Now the test for that assumption. Make a trigger that fires when you drop an item, Now tell it to remove the item in the slot of the dropped item, (heres a quick function to find that here you would pass it GetManipulatedItem, and GetManipulatingUnit)

Code:

function getSlot takes item used,unit who returns integer 
    local integer i=1
    loop
       exitwhen (UnitItemInSlotBJ(who, i)==used)
       set i=i+1
    endloop
    return i
endfunction

[now tell it to add an item to your hero at that slot. (theres a function in Common.j for that). Now run your map and when you drop an item you will get a blank slot where you should have your item.

Okay, so I just found out that war3 handles items like I do. ANd thats absolutely retarded. They should atleast give me someway to get where your click in a drop item event...

01-17-2004, 07:59 PM	#2
Starcraftfreak	That's a nice discovery indeed. Seems that Blizzard was kinda lazy when they did the item code.

01-18-2004, 11:16 AM

Peppar

I agree on the drop item-event being incomplete. I made a small engine for my map that generated 'transporters' that would transport units from one area to another. Move unit immediately causes the unit to lose his order, so after the unit was transported the transporter re-issued the order that the unit had. This works completely, except when you have ordered your unit to drop an item.

The drop item order is not detected with the "Unit is issued order"-events and therefore you cannot get the coordinates of the drop. In fact, you are unaware that the unit is doing anything at all (as far as I know, all other unit activities are detectable with the "issued order"-events.)

You can use GetUnitCurrentOrder to get the order of a unit whenever you want, and if you use it when a unit is running to drop an item you will get an order string named something similar to "Drop Item". The order id is the same for all item slots (Use Item for instance has different order ids for each slot.) This makes it ÃÂ*mpossible to issue a drop-item order as you cannot specify which item you want the unit to drop.

01-18-2004, 04:06 PM

weaaddar

AiAndy helped me find some interesting. While dropping items if you use a fake wait (a timer running at 0 seconds) you can actually get the coords of the dropped item. By going GetItemX(GetManipulatedItem()) and GetItemY(GetManipulatedItem()). The fake wait is the perfect solution for any item based relation, it even gets past that stupid bug where they remove what ever is currently in your slot.
That is interesting that you can get an order string as my trails have shown no such string appearing.

01-20-2004, 02:06 AM

NagelBagel

Quote:

As if you do a getItemX getItemY they are where your hero was when you first clicked to drop the item, not where his current position is.

The item's position is where you first pick up the item. It has nothing to do with the hero.

TriggerSleepAction(0) seems to get the new coordinates perfectly, though. On sold and removed items it returns 0, 0.

01-20-2004, 02:35 AM	#6
weaaddar	hmm its my practice it seemed that triggersleepaction were something to be avoided as they are slow as hell. But it is odd how drop items work.