719 Changelog - The item class revamp.

[rock5]

Ok. Finally got around to committing these changes. I did more testing than usual because the changes are so extensive. Mainly, all the changes in this commit are about the item class and item containers.

I'll start by mentioning the only non backward compatible part of this commit. 'inventory.EquipSlots[]' has been moved to 'equipment.BagSlot[]'. So if you have any code that directly accesses that table, eg. code to use a Rune Bow, then it wont work and will have to be changed.

Basically, we now can use other item containers besides the inventory. The other containers are 'equipment' (which replaces inventory.EquipSlots), 'bank' and 'guildbank'. They have similar functions 'update()' and 'findItem()'. 'inventory' still has all the original functions and 'equipment' also has the equipment functions that used to be part of inventory. Eg. equipment:getDurability(), equipment:getAmmunitionCount().

They each use their own item classes bassed on what is now a general purpose 'item' class similar to how the pawn class is the base of the player class. The items are in a sub table called 'BagSlot', eg bank.BagSlot[1], guildbank.BagSlot[5]. They use the same name for compatibility reasons. Because they share the same item classs they also share all the item functions. So as an example, if you want to get something from your bank you can use

Code: Select all

item = bank:findItem("itemname")
if item then
    item:moveTo("bags")
end

Or move an item to your bank

Code: Select all

item = inventory:findItem("itemname")
if item then
    item:moveTo("bank")
end

Or this is a good example. I use this to equipe my rune bows and make Runic Thorn arrows

Code: Select all

				local runebow = inventory:findItem("Rune Catapult") or inventory:findItem("Rune War Bow")
				if runebow then
					runebow:moveTo("ranged weapon") yrest(1000)
					equipment:findItem("ranged weapon"):use() yrest(3000)
					inventory:useItem("Runic Thorn")
					yrest(2000)
					runebow:moveTo("ranged weapon")
				end

Not the use of "ranged weapon" to indicate a 'range' of 'equipment' which is actually just one slot. Also note that 'equipment:findItem(range)' is slightly different thatn other container findItem functions in that it only has the one argument. It doesn't have a 'nameorid' argument.

There are a lot more 'ranges' now that can be used with 'findItem' and 'moveTo' and such functions. Look at the 'getInventoryRange()' function in inventory.lua for the full list of valid ranges now.

A new function to the 'item' class is 'pickup()'. It's used extensivly now when moving items.

I was inspired by the way some addons can move items so fast, so I made changes to the bot to make lightning fast moves a reality. There are limitations, eg. when merging items, but you will be surprised at how fast items can now move between containers and how reliable it still is.

Added a 'cursor' class. It basically has information about the item on the cursor and a couple of functions. The main use is to check 'cursor:hasItem()' instead of using a RoMScript command. I also use the information to clear the cursor when necessary using 'cursor:clear()'.

I did a lot of general tidying up that should improve speed a bit, eg. the findItem function no longer does a whole container update() which updates every item in the container. Instead it updates only the items it is checking. And I removed a lot of needless 'self:updates()'.

Last minute addition is 'ItemQueueCount()' which I nearly didn't add. The bot doesn't use it and I doubt many users will use it. It returns the number if items in the item queue. That's the queue of items entering your bags. Basically the only time you would need it is if you've just bought a lot of items or collected some mail and you want to wait until they all enter your bag because you intend to immediately use the items received. Then you would do,

Code: Select all

while ItemQueueCount() > 0 then yrest(500) end

As always, feel free to comment/ask questions.

[grande]

Revision 715 still works. This one gives a "CEquipItem" error.

[rock5]

Revision 715 still works. This one gives a "CEquipItem" error.

Edit: With the new item classes and containers, the equipitem class has been moved to it's own container 'equipment'. So any reference in your code to 'inventory.EquipSlots' will no longer work. Still, I'm not sure how you are getting a "CEquipItem" error when there is no reference to "CEquipItem" in the bot anymore, it's now called 'CEquipmentItem'. Unless you created code that uses that class. If so, you'll have to change it.

[grande]

Maybe it was CEquipmentItem. Not so good with minutia. It failed w/o even running a wp but it may not have been a default profile. If it's something on my end... just another problem to fix eventually I guess. Suppose I can just word search for "inventory.EquipSlots" and edit those to... something.

[BillDoorNZ]

loving

Code: Select all

ItemQueueCount()

great for running about with magic perfume and ks scripts

thx rock! all looking as classy as ever!

[rock5]

loving

Code: Select all

ItemQueueCount()

great for running about with magic perfume and ks scripts

Yeah, I've been using it with my revamped KS script too.

6 bags + 20 itemqueue = 200 items at a time.

[grande]

Used to just SVN update and go. Not with this "revamp"

Code: Select all

MicroMacro v1.02 beta 1
SolarStrike Software
http://www.solarstrike.net
Opening bot.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
-------------------------------------------------------------------------------
6:47pm - ...\micromacro\scripts\rom/bot.lua:31: ...:micromacro/scripts/rom/addresses.lua:74: unexpected symbol near
'<'
Please enter the script name to run.
Type in 'exit' (without quotes) to exit.
Script>

What's with the new address files? addresses.lua.r719 , addresses.lua.r715 ?? Are these just made when I update to revision 715?

still 715 for this dude.

[rock5]

Besides when patches happen, new address files usually happen when a feature has been added that uses a new address or offset.

There 2 most common reasons for getting the '<' error. The first is the user tries to use the 'less than' symbol in their code in an xml file such as the waypoint file or profile. In most cases you can't use '<' in an xml file because it gets interpretted as the beginning of a tag. The other reason, as has happened in your case, is there is a conflict when doing svn update. When getting a conflict svn adds comments into the files starting with '<'. Needless to say the bot is not supposed to be functional until you resolve the conflicts.

The easiest way to deal with conflicts is, after doing an svn update, right click the rom folder and select 'TortoiseSVN/Revert' and revert all the changed files.

In the future please watch what's happening when doing SVN Updates. Don't ignore warnings about confliicts. They don't go away by themselves.

[grande]

Yes sir! Thanks rock5

[Hetrix]

Hey, I did the svnupdate and also revert the rom folder. But still getting the player.addresses have been changed error. I guess the addresses are still in progress or does the bot already work?

/H

[rock5]

Hey, I did the svnupdate and also revert the rom folder. But still getting the player.addresses have been changed error. I guess the addresses are still in progress or does the bot already work?

/H

This changelog is regarding 719 and the changes implemented in it. It was awhile ago. The new game patch will require a new revision. In fact it's already done. Update to 720.