SolarStrike Software

Posted: **Thu Apr 11, 2013 8:04 am**

I want to log the runes that an item has. How can I achieve it? I looked the item class and I haven't found any property for the runes.

thanks in advance

Posted: **Thu Apr 11, 2013 8:52 am**

My guess would be something like this

Code: Select all

			for i = 1, 4 do
				local tmpid = memoryReadUShort( getProc(), self.Address + 0x2C + 0x2*(i-1) );
				if tmpid == 0 then -- No More stats
					break
				end
				tmpid = tmpid + 500000
				local tmpname = GetIdName(tmpid)
				self.Runes[i] = {Id = tmpid, Name = tmpname}
			end

Code: Select all

Command> local item = inventory.BagSlot[91] table.print(item)
table: 018D99E0
Id:     225219
LastMovedTime:  0
Worth:  5197.5
Stats:  table: 018D9AA8
        1:      table: 018D9AF8
                Id:     512772
                Name:   Seal of Bravery VII
        2:      table: 018D9B48
                Id:     512887
                Name:   Wing of Imprisonment VIII
        3:      table: 018D9B98
                Id:     512884
                Name:   Breakthrough of Imprisonment VIII
        4:      table: 018D9C10
                Id:     512864
                Name:   Power of Imprisonment VIII
        5:      table: 018D9C60
                Id:     512872
                Name:   Day of Imprisonment VIII
        6:      table: 018D9C88
                Id:     512867
                Name:   Fire of Imprisonment VIII
InUse:  false
MaxStack:       1
RequiredLvl:    55
ObjType:        1
ObjSubType:     0
ItemShopItem:   false
SlotNumber:     91
Bound:  true
Quality:        3
BagId:  95
BoundStatus:    1026
ItemCount:      1
Available:      true
Color:  4289225896
Name:   Knight's Falcon Armor
MaxDurability:  82
Empty:  false
Location:       inventory
CoolDownTime:   0
BaseItemAddress:        575379968
CanBeSold:      true
ObjSubSubType:  1
Durability:     82
Value:  51975
Address:        10412976
LastTimeUsed:   0
Icon:
Runes:  table: 018D9A58
        1:      table: 018D9CD8
                Id:     520502
                Name:   Might II
ItemLink:       |Hitem:36fc3|h|cffa864a8[Knight's Falcon Armor]|r|h

Code: Select all

Runes:  table: 018D9A58
        1:      table: 019E92E0
                Id:     520690
                Name:   Hatred X

Code: Select all

Runes:  table: 018D9A58
        1:      table: 018D6150
                Id:     520770
                Name:   Fatal X
        2:      table: 018D61F0
                Id:     520810
                Name:   Wrath X
        3:      table: 018D62B8
                Id:     520724
                Name:   Loot IV

yep that worked.

Posted: **Thu Apr 11, 2013 9:06 am**

I'd say that looks nice enough to add to the bot.

What do you say Lisa?

Posted: **Thu Apr 11, 2013 9:10 am**

rock5 wrote:I'd say that looks nice enough to add to the bot. What do you say Lisa?

Sounds good, works for me anyway =)

My files are so far from the default now I am very hesitant to do any commits.

I added the self.Runes = {} next to the stats bit in the class definition, around line 57.

Then edited the item update like this

Code: Select all

		-- Get Stats (only named stats)
		-- Get Runes (only named Runes)
		self.Stats = {}
		self.Runes = {}
		if self.ObjType == 0 or self.ObjType == 1 or self.ObjType == 5 then -- Weapons, Armor and Equipment Enhancements
			for i = 1, 6 do
				local tmpid = memoryReadUShort( getProc(), self.Address + addresses.itemStatsOffset + 0x2*(i-1) );
				if tmpid == 0 then -- No More stats
					break
				end
				tmpid = tmpid + 500000
				local tmpname = GetIdName(tmpid)
				self.Stats[i] = {Id = tmpid, Name = tmpname}
			end
		end
		if self.ObjType == 0 or self.ObjType == 1 then		
			for i = 1, 4 do
				local tmpid = memoryReadUShort( getProc(), self.Address + addresses.itemStatsOffset + 0xC + (0x2*(i-1)) );
				if tmpid == 0 then -- No More runes
					break
				end
				tmpid = tmpid + 500000
				local tmpname = GetIdName(tmpid)
				self.Runes[i] = {Id = tmpid, Name = tmpname}
			end
		end

I didn't bother to make another offset in addresses.lua, just added the 0xC to the stats offset.

Posted: **Thu Apr 11, 2013 9:29 am**

Ah, no wonder that code looked so nice and tidy.

How much of the "so far from the default" code is useful stuff like this and how much of it is only applicable to yourself?

Posted: **Thu Apr 11, 2013 9:33 am**

rock5 wrote:How much of the "so far from the default" code is useful stuff like this and how much of it is only applicable to yourself?

The majority of it is purely for myself, not so sure it would benefit others or not, only if they were as crazy as me I guess

Might cause more issues if I committed it and to be honest I don't really have the spare time to fix the issues that might pop up.

Ah, no wonder that code looked so nice and tidy.

yep pure copy paste of code I suspect you did, if I wrote it myself it would probably start very sloppy and then start to look a bit better after about 20 rewrites.

Posted: **Thu Apr 11, 2013 9:51 am**

Thank you very much this is what I wanted.

Posted: **Fri Apr 12, 2013 11:06 am**

something I have been working on is how fast (slow) the objectlist is to populate, did some tweaking

Code: Select all

Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
246.01458406367
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:updatebatch() end print(deltaTime(getTime(),tt))
112.78807939882

Those times are without updating the info for every object though but they are encouraging.

So I did some playing around with the object update, using the batch mem read it was a little better again compared to the normal memory reads.

But then I came across this bombshell

Code: Select all

Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
4600.2922561363
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
1908.0722540935

Notice the huuuuuuge difference there, all I did was comment out the code for object name and the time halved instantly.
The issue is the memoryReadString(proc, namePtr), if I comment out this the time print is halved, not sure if there is a better way or a way around this, still working on it.

Ok now I just don't know anymore, did an isolation test using the address for my chars name.

Code: Select all

Command> local tt = getTime() for i = 1,5000 do local nn = memoryReadString(getProc(),0x318130b4) end print(deltaTime(getTime(),tt))
389.62506114333

that is 5000 reads and barely 390 ms, the previous tests it was adding 2000 ms in just 100 reads.

using proc instead of getProc() also dropped that even more, it uses proc in the object update.

Code: Select all

Command> local tt = getTime() local proc = getProc() for i = 1,5000 do local nn = memoryReadString(proc,0x318130b4) end print(deltaTime(getTime(),tt))
200.05687035458

Posted: **Fri Apr 12, 2013 11:30 am**

ok less confused now, the real issue is with

Code: Select all

self.Name = utf8ToAscii_umlauts(tmp)

when I commented out the other code it made it not do the umlauts code, leaving in the other string read and commenting out the umlauts code got the shorter times.

bah I don't get it.

Code: Select all

Command> local tt = getTime() for i = 1,1000 do local nn = utf8ToAscii_umlauts("Somecharname") end print(deltaTime(getTime(),tt))
484.95989562134

Posted: **Fri Apr 12, 2013 12:15 pm**

well I managed to accomplish 1 of my goals anyway.

I added HP, MaxHP, Class, Lvl to the object list without adding much time to the process.

Code: Select all

Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
4791.5162570684
Command> local objectList = CObjectList(); objectList:update(); table.print(obje
ctList:getObject(2))
table: 03DCA8A0
Type:   4
X:      230
Level:  75
MaxHP:  4946421
Class1: 1
HP:     4946421
Address:        813142272
Name:   Tornado
Attackable:     false
Z:      -381
Y:      10.773773193359
Id:     113693

added roughly 180 ms to 100 reads of 33 objects, this means you wouldn't need to do an entire pawn update to do any findenemy code. Only thing missing is targetPtr which is inside the covered batch read anyway, so would be easy enough to add in.
Mind you I think you covered that in your update update

Posted: **Fri Apr 12, 2013 12:25 pm**

yep added targetPtr aswell with no significant increase in time.

Code: Select all

Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
4771.481262296
Command> local objectList = CObjectList(); objectList:update(); table.print(obje
ctList:getObject(1))
table: 03FF2800
Address:        813134592
Z:      -416.95184326172
Y:      5.2641448974609
X:      11.353487014771
Type:   1
Class1: 3
MaxHP:  770
Name:   Charname
Level:  20
Id:     1003
Attackable:     false
HP:     770
TargetPtr:      813134592
Command>

Notice TargetPtr is the same as Address, I had myself targeted =)

Back to name issue, I tried with GetIdName but the time was almost double *shrug*

Code: Select all

	if self.Type ~= PT_PLAYER then
		self.Name = GetIdName(self.Id)
	else
		showWarnings(false);
		local namePtr = memoryReadRepeat("uint", proc, self.Address + addresses.pawnName_offset); --0x294
		if( namePtr == nil or namePtr == 0 ) then
			tmp = nil;
		else
			tmp = memoryReadString(proc, namePtr);
		end
		showWarnings(true); -- Re-enable warnings after reading


		-- UTF8 -> ASCII translation not for player names
		-- because that would need the whole table and there we normaly
		-- don't need it, we don't print player names in the MM window or so
		
		if( tmp == nil ) then
			self.Name = "<UNKNOWN>";
		else
			if( bot.ClientLanguage == "RU" ) then
				self.Name = utf82oem_russian(tmp);
			else
				self.Name = utf8ToAscii_umlauts(tmp);	-- only convert umlauts
			end
		end
	end

Posted: **Fri Apr 12, 2013 1:10 pm**

lisa wrote:something I have been working on is how fast (slow) the objectlist is to populate, did some tweaking
Code: Select all
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
246.01458406367
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:updatebatch() end print(deltaTime(getTime(),tt))
112.78807939882
Those times are without updating the info for every object though but they are encouraging.

Took me about 10s.

You can't really compare them until they update everything the same. If you want to do a more accurate comparison now, you could comment out from the original 'update' function, the parts you haven't added the the updatebatch function. Then they would be equivalent.

lisa wrote:But then I came across this bombshell
Code: Select all
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
4600.2922561363
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
1908.0722540935
Notice the huuuuuuge difference there, all I did was comment out the code for object name and the time halved instantly.

That is significant. Good job on picking up that it was utf8ToAscii_umlauts. It's a fairly compact and neat function. I doubt it could be sped up significantly. Maybe we could avoid using it for languages that don't use UmLauts. But then you might get other players with umlauts in their name.

lisa wrote:using proc instead of getProc() also dropped that even more, it uses proc in the object update.

It's surprising how noticable that is cinsidering how little getProc() does. I guess we should use make a habit of using proc where possible.

lisa wrote:bah I don't get it.

Code: Select all

Command> local tt = getTime() for i = 1,1000 do local nn = utf8ToAscii_umlauts("Somecharname") end print(deltaTime(getTime(),tt))
484.95989562134

It's understandable. You have to realize that when you did the object list update 100 times, each update does many name reads. I put a counter in utf8ToAscii_umlauts and got about 5000. When I used 5000 in this loop I got about 3000ms.

Original update x100, about 10s (That doesn't seem right)
Same with utf8ToAscii_umlauts commented out, about 5800ms.
utf8ToAscii_umlauts x5000, about 3000ms.

Sure, I was expecting 4000ms but close enough.

lisa wrote:this means you wouldn't need to do an entire pawn update to do any findenemy code.

Well the bot at the moment only updates parts of pawn that it needs. So it only updates the hp when checking the hp for instance.

I think that's enough for one post. I can't seem to keep up.

Posted: **Fri Apr 12, 2013 1:17 pm**

lisa wrote:Back to name issue, I tried with GetIdName but the time was almost double *shrug*

I thought we had established that the delay was utf8ToAscii_umlauts?

GetIdName shouldn't be faster. It searches for an id then reads the name, if the name of that id hasn't been substantiated yet it has to do a RoMScript command. As apposed to a single quick memory read. Also GetIdName wont work with players.

Posted: **Fri Apr 12, 2013 7:41 pm**

rock5 wrote:You can't really compare them until they update everything the same.

My comparisons were accurate, of course, not going to post the code but yeah I was thorough.

I also did my tests in guild castle where the objects number was always 33, if the object list changed then it would have affected the times. I had CE open with it showing the object list size. So the 100 times would have made it 3300 objects which I figure is more than you would get in varanas.

rock5 wrote:Also GetIdName wont work with players.

yeah the code I did was for type not player, so it never did the function for players, i didn't realise it did RoMScripts I thought it was all purely from memory.

I am thinking to put in a check for self.Name ~= "<UNKNOWN>" and not to do the name check again, if there is an obj:update() like in andor training there is no need to do the name stuff again as it wastes time. Mind you andor training is the only place I know that does the obj:update().

Still looking into this, there must be a way to "fix" the name issue so it doesn't take so long.

Posted: **Fri Apr 12, 2013 8:21 pm**

Ok I added in some prints into GetIdName and also GetItemAddress and the prints tell me the romscripts weren't done. Time was still longer than doing the umlauts code.
The GetIdAddressLine() is pretty indepth though so not really surprising to me now that it takes longer.

Code: Select all

			if address == 0 then
				print("Address not gotten from memory but used a RoMScript: "..id)

			if name == nil then
				print("Id not gotten from memory but used a RoMScript: "..itemId)

I changed all of the getProc() in that file memorytable.lua to be proc and the time to do it with GetIdName is pretty much the same as with the umlauts code. So that is a huge performance increase on GetIdName() atleast.

Posted: **Fri Apr 12, 2013 9:17 pm**

Testing a theory atm, when bot starts up it does a lot of GetIdName(), which is fine but I was wondering if the address for the item changes or if it stays the same. Does it change when zoning?

Anyway theory I am testing atm is to add addresses to a table as it does it's normal usage and if the id already exists in the table then not to go looking for it.

Code: Select all

local itemtable = {}

local function GetIdAddressLine(id)
	if itemtable[id] then return itemtable[id] end

then

Code: Select all

			local currentId = memoryReadInt( proc, dataPointer + addresses.idOffset )
			--printf("currentAddress %X , current ID %X:%d IdToFind %X:%d\n",dataPointer,currentId,currentId,IdToFind,IdToFind)
			itemtable[currentId] = dataPointer

So far this has really reduced the time taken to do my object things using GetIdName
from 4800 ms to 3500 ms.

If the addresses all move when zoning though this would ruin the idea of course, I have been testing this by using the GetIdName in a print and then zoning and doing it again, it seems to be working fine but without more thorough testing it is hard to say if it will hold true or not.

Looks promising so far.

Code: Select all

Command> print(GetIdName(100053))
currentAddress C46DBC0 , current ID 7D02F:512047 IdToFind 186D5:100053
currentAddress D8DF040 , current ID 36B60:224096 IdToFind 186D5:100053
currentAddress FC83780 , current ID 1ADF5:110069 IdToFind 186D5:100053
currentAddress FB82E20 , current ID 194E5:103653 IdToFind 186D5:100053
currentAddress FB22E20 , current ID 18CE5:101605 IdToFind 186D5:100053
currentAddress FB2AE20 , current ID 188E5:100581 IdToFind 186D5:100053
currentAddress FB2EE20 , current ID 186E5:100069 IdToFind 186D5:100053
currentAddress D9DF880 , current ID 8CF:2255 IdToFind 186D5:100053
currentAddress D9DE880 , current ID 94F:2383 IdToFind 186D5:100053
currentAddress FB2F620 , current ID 186A5:100005 IdToFind 186D5:100053
currentAddress FB2F220 , current ID 186C5:100037 IdToFind 186D5:100053
currentAddress FB2F020 , current ID 186D5:100053 IdToFind 186D5:100053
Kobold Supply Officer
Command> print(GetIdName(100053))
Kobold Supply Officer
Command> print(GetIdName(100053)) 
Kobold Supply Officer
-- here I completed logged out of account (didn't kill client), logged back in and print was fine.
Command> print(GetIdName(100053))
Kobold Supply Officer

I originally started to look at making the id search more efficient but to get there in around 15 tries is pretty damn good. Always starts at mid point, 512047 and takes approx 15 steps to get to the right Id.

Code: Select all

This one got me thinking though, more than 15 and the Id was so close to the start point.

Code: Select all

each step is 3 mem reads and a few calculations.

Posted: **Fri Apr 12, 2013 11:16 pm**

doing more on the batch reads, it is really efficient.

Code: Select all

Command> local objectList = CObjectList() objectList:update() table.print(object
List:getObject(1))
table: 00AAA488
Name:   Charname
TargetPtr:      0
Level:  20
Mounted:        false
HP:     770
Type:   1
TargetIcon:     false
attackableFlag: 16781616
MaxHP:  770
Y:      5.2641468048096
Z:      -520.74182128906
Aggressive:     false
Address:        881610752
InParty:        false
X:      -51.051765441895
Id:     1003
Class1: 3
Attackable:     false
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
3629.5832069399
Command> local tt = getTime() for i = 1,100 do local objectList = CObjectList()
objectList:update() end print(deltaTime(getTime(),tt))
3697.3224088312

adding these only added 200ms to the print, was 3500ms.

Code: Select all

		self.attackableFlag = 0
		self.InParty = false
		self.Mounted = false
		self.TargetIcon = false
		self.Attackable = false
		self.Aggressive = false

These seem pretty stable if you want to test them against the default and see the difference it makes on your system. Obviously faster systems will have a reduced increase in efficiency as they are already going super fast.

Posted: **Fri Apr 12, 2013 11:27 pm**

my comparison in a populated area with mobs looks like this.

Default files

Code: Select all

Command> local tt = getTime() for i = 1,40 do player:findEnemy() end print(deltaTime(getTime(),tt))
10000.237132118
Command> local tt = getTime() for i = 1,40 do local objectList = CObjectList() objectList:update() end print(deltaTime(getTime(),tt))
4467.7667133232

My current version

Code: Select all

Command> local tt = getTime() for i = 1,40 do player:findEnemy() end print(deltaTime(getTime(),tt))
5823.1143248843
Command> local tt = getTime() for i = 1,40 do local objectList = CObjectList() objectList:update() end print(deltaTime(getTime(),tt))
3572.3332517229

That is with findenemy still as default, I am almost at the stage I can do entire findenemy without creating a pawn, last bit to do is the isfriend function.
I am very interested to see if it makes a sizable difference.

changed findenemy to not create a pawn and there was a slight decrease in time but only around 300 ms.

Code: Select all

Command> local tt = getTime() for i = 1,40 do player:findEnemy() end print(delta
Time(getTime(),tt))
5528.6958092801

So debatible whether to change findenemy or not, having said that the last few tests were getting results of 1000ms faster for my edited version of findenemy. Hard to get solid results when the environment it changing like this, might need to go into an instance and also add in a check for size of object list to get accurate tests.

Posted: **Sat Apr 13, 2013 2:25 am**

lisa wrote:Ok I added in some prints into GetIdName and also GetItemAddress and the prints tell me the romscripts weren't done. Time was still longer than doing the umlauts code.

That's probably because all the ids you looked up were already substantiated. It probably doesn't come across unsubstantiated ids very often. Actually, all object in memory are already in memory so would already be substantiated.

lisa wrote:The GetIdAddressLine() is pretty indepth though so not really surprising to me now that it takes longer.

It's amazing what we have managed to do with that file. I would never have been able to figure out that stuff myself and I still can't quite wrap my head around how the searching works.

lisa wrote:I changed all of the getProc() in that file memorytable.lua to be proc and the time to do it with GetIdName is pretty much the same as with the umlauts code. So that is a huge performance increase on GetIdName() atleast.

That's a good idea.

lisa wrote:If the addresses all move when zoning though this would ruin the idea of course, I have been testing this by using the GetIdName in a print and then zoning and doing it again, it seems to be working fine but without more thorough testing it is hard to say if it will hold true or not.

Remember, we used to do an initial scan at bot startup and use a table of addresses that didn't change. So my guess is they don't change. I wonder though what happens if your table gets huge. Probably not much, seeing as the table is listed by id, so accessing it would always be quick. BTW, this makes a nice difference to the speed.

lisa wrote:I originally started to look at making the id search more efficient but to get there in around 15 tries is pretty damn good. Always starts at mid point, 512047 and takes approx 15 steps to get to the right Id.

Concidering how many ids there are, that's impressive. This is the bit I don't understand. I'm not sure how the pointers are structured to be able to find the id so quickly.

I don't think you can improve the way it searches. It pretty much searches the way the game does and finds the id in the fewest number of hops. But maybe you can make each step more efficient. Maybe use batch read to read the few addresses it does read. I just tested it, it didn't make any measurable difference. 200ms to do object list update either way.

lisa wrote:doing more on the batch reads, it is really efficient

Yeah I like the batch reads for object but I'm not sure I like the idea of adding pawn info to the object class. I don't think it's good programming practice and I think in the end it will cause more problems than it's worth. It may not even make that much difference in the end. After all, one of the big advantages with reading one value at a time is you can avoid reading anymore memory values if a particular value check fails. Plus pawn is now just values, it's also functions such as 'exists' and 'isFriend'.

I noticed in object.lua you assigned the attackableflag to self.attackableFlag but then proceeded to use the attackableFlag variable (minus the "self."). Fixing that adds a little time.

lisa wrote:changed findenemy to not create a pawn and there was a slight decrease in time but only around 300 ms.

I'm not surprised. Remember, if it doesn't pass the object check it doesn't even create the pawn. And if it does create the pawn it only updates values until the first failed check. So the only objects, that would update all the values that your object class adds, are fully valid mobs. Even though memoryReadBatch is fast, you are reading all those values for every object regardless of what type they are.

Posted: **Sat Apr 13, 2013 3:08 am**

rock5 wrote:This is the bit I don't understand. I'm not sure how the pointers are structured to be able to find the id so quickly.

mostly it is just 0x20 byts apart from the next Id but not all the time, it's kind of weird and yeah I failed at making it any better =(

rock5 wrote:I noticed in object.lua you assigned the attackableflag to self.attackableFlag but then proceeded to use the attackableFlag variable (minus the "self."). Fixing that adds a little time.

Yep I missed that in my copy paste =(
After fixing that it ended up around 4000ms, so yeah that sux.

rock5 wrote:I'm not surprised. Remember, if it doesn't pass the object check it doesn't even create the pawn. And if it does create the pawn it only updates values until the first failed check. So the only objects, that would update all the values that your object class adds, are fully valid mobs. Even though memoryReadBatch is fast, you are reading all those values for every object regardless of what type they are.

well the thing with the batch read is it doesn't take much time to retrieve more info from the block of memory, so if we used it then we may aswell use it for everything we needed which would make the pawn system redundant. Would mean rewriting a lot of code and I don't have the time for that.
I think at the moment though the increase in performance is insignificant, if I did it before your major update to updates it would have been an entirely different matter.

So I might just try to work on the name issue and see what I can come up with. With the table thing and replacing those getProc's I think the increased performance is good enough for me to be happy with for now.
I might leave the object info as

Code: Select all

		self.Address = ptr;
		self.Name = "<UNKNOWN>";
		self.Id = 0;
		self.Type = PT_NONE;
		self.X = 0.0;
		self.Y = 0.0;
		self.Z = 0.0;
		self.TargetPtr = 0;
		self.HP = 1000;
		self.MaxHP = 1000;
		self.Class1 = CLASS_NONE;
		self.Level = 1;

and not worry about the extra stuff I added.

the comment for names has me thinking though.

Code: Select all

			-- UTF8 -> ASCII translation not for player names
			-- because that would need the whole table and there we normaly
			-- don't need it, we don't print player names in the MM window or so

it says not for player names but it has always been used on player names as far as I know anyway.

SolarStrike Software

How to get the runes that I have in an item

How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item

Re: How to get the runes that I have in an item