Shaiya - WayPoint System

[Administrator]

local l_xml_map = l_xml:getElements("map")

getElements() accepts no parameters and returns all elements inside this node. You can take the "map" part out, I believe. Since 'map' is your root node, you don't need to reference it at all; it will be understood that it is being used.

attempt to call global 'error' (a nil value)

It is a lua native function, so I couldn't work it out, perhaps u know why? :/

I've fixed it. In Lua modules, they do not have global scope by default, so you need to allow them to access global functions and variables. That's why you see all the "local <function> = <function>" at the top of module files. Thanks for pointing this out.

I've also updated the attribute access in the module. I've added getAttribute() (basically the same as getElement(), only for attributes) to be used instead of directly accessing an attribute via the [] or . operators. There's also getAttributes() to return all attributes, and getAttributeCount() to return the number of attributes.

These changes should result in a very small speed increase (depending on how many attributes were being used before), and being able to use _NAME, _VALUE, and _ATTRIBUTES as attributes inside your XML document without screwing it up. And, finally, it should support better forward compatibility. Since you have not used attributes in your code, I don't think you'll need to make any changes.

Here's the new example:

Code: Select all

<root name="Root" type="Example">
	<elem1>
		<subelement value="1" />
		<subelement value="2" />
		<subelement value="3" />
	</elem1>

	<elem2 number="1234" string="This is a string" />

	<elem3>Element 3 has a text value</elem3>
</root>

Code: Select all

function main()
  local root = xml.open(getExecutionPath() .. "/test.xml");
  printf("root._NAME: %s\n", root:getName()); -- "_NAME" should be 'root'
  printf("root.name: %s\n", root:getAttribute("name"));    -- "name" will be set in XML
  printf("root.attribute count: %d\n", root:getAttributeCount());

  local elem1 = root:getElement("elem1");
  elements = elem1:getElements();
  printf("\n---ELEM1---\n");
  for i,v in pairs(elements) do
    local name = v:getName();
    local value = v:getAttribute("value");
    printf(" ==> [%s]: %s\n", name, value);
  end


  local elem2 = root:getElement("elem2");
  printf("\n---ELEM2---\n");
  printf("elem2.number: %d\n", elem2:getAttribute("number"));
  printf("elem2.string: %s\n", elem2:getAttribute("string"));

  local elem3 = root:getElement("elem3");
  printf("\n---ELEM3---\n");
  printf("elem3._VALUE: %s\n", elem3:getValue());
end
startMacro(main);

Output:

root._NAME: root
root.name: Root
root.attribute count: 2

---ELEM1---
==> [subelement]: 1
==> [subelement]: 2
==> [subelement]: 3

---ELEM2---
elem2.number: 1234
elem2.string: This is a string

---ELEM3---
elem3._VALUE: Element 3 has a text value

[zer0]

Works very well.

Just one query, is there a way to have xml.lua change the datatype to a number (using tonumber()), if the xml data is a number, and not a string?

I don't know where the code should be placed in xml.lua, but here is the function to check if the data is a number type.

Code: Select all

function is_number(data)
    print("data: " .. data)
    local l_res = string.find(data, "[^%.?0-9+]")
    if (l_res ~= nil) then
        print("not number")
        return false
    else
        print("number")
        return true
    end
end

Then the call would be like:

Code: Select all

if (is_number(data) then
  data = tonumber(data)
end

[Sgraffite]

This looks very promising! In one of my previous botting areas I contemplated making waypoints, but I was trying to create fake mouse clicks on the ground and move the character that way. Unfortunately I wasn't able to find how the clicks worked and soon leveled out of that area

Are you using a memory location that tells what direction your character is facing? If so would you mind sharing it?

[Administrator]

According to classes/hook.lua:

Code: Select all

AVATAR_PTR            = 0x0081CBEC
AVATAR_NAME_ADDRESS   = 0x00820A3C
AVATAR_SIT_CHECK_ADDR = 0x006DCC80
MEM_ADDRESS_AVATAR_LEVEL  = 0x0081F670

avi_offset = {
    pos_x=16,
    pos_y=20,
    pos_z=24,
    pos_rot_x=28,
    pos_rot_y=36,
    hp=300,
    hp_max=304,
    mp=308,
    mp_max=312,
    sp=316,
    sp_max=320,
    damage_dealt=440,
    movement=609,
}

About the mouse clicks though... It's very difficult to accurately get a bot to move where you want it to through a series of clicks. There's just too many obstacles (monsters, players) that could get in the way, camera angle differences, and other things that cause these systems to get thrown way off.

[Sgraffite]

About the mouse clicks though... It's very difficult to accurately get a bot to move where you want it to through a series of clicks. There's just too many obstacles (monsters, players) that could get in the way, camera angle differences, and other things that cause these systems to get thrown way off.

I meant according to the way Shaiya does it when you click on the ground to move. Like somehow fake a click using the memory at exact coordinates x,y,z which tells the character to move to that exact spot, and let the game figure out which direction to go. So instead of having the script click, you'd be telling the game via memory the coordinates of where you clicked, but having the same outcome as if you had actually clicked. (hope that makes sense)

[Administrator]

Ah, I see. That could work. I know exactly what you mean. It just depends how the game works. The problem is that it is a hard to find a pointer for it. I'm guessing if you can determine the rough range for either the X or Y value of where you clicked, you can stand back, click there, and run a search, you might be able to find the address. Using ranges should allow you to get around minor variances.

[zer0]

It's al in the ZS Shaiya version 0.2b

With my waypoint system it read the offsets part that elverion has posted:

Code: Select all

avi_offset = {
    pos_x=16,
    pos_y=20,
    pos_z=24,
    pos_rot_x=28,
    pos_rot_y=36,
}

The pos_x, pos_z, are the main ones used to determine the map location, and pos_rot_x and pos_rot_y are used in combination to determine direction. Some complex tigonometry functions are applied to figure out how to do it all (well not complex I guess, most of the stuff I used was covered in high school math, just been quite a few years since using it).

The key difference what I use from the way your proposing, is that mine uses the keyboard to move, not using mouse clicks. So far it works pretty good, the only issues I really have is a waypoint can't be that far away, and the direction needs to be extremely precise, like with a 1 degree or so, or he misses his target waypoint. Casting sprint on the avatar, though makes him miss the rotation more often. >.<
The functions that do all that are in classes/avatar.lua, move_to() and rotate_to().
It works surprisingly well so far, download it and try getting it working for yourself, you need to be at the Reikeuseu start (as that's the only waypoints I only have created so far), and set in the avatar options, waypoint_enabled = true.
It could be done with a mouse as well I guess, but as elverion said, it won't be as accurate, since the mouse might click on objects, such as other players, and monsters and such. You would also have to take into account the camera position, and tilt. For a game such as Shaiya it is not needed since there is a simpler way to do it.

[Administrator]

Yes, getting the angle right can be a problem. If you're very far away, you turn so fast that you'll often jump over the gap of having a "good" angle. Same thing if you're too close to the waypoint. One thing I tried to do in the Holic bot was to correct this. When you are far away, you will accept, say, a 65° angle before you start walking towards that waypoint. While walking, you will slowly try and adjust it to finer and finer angles, up until some maximum point that should bring you within x yards of the target.

You might even be able to directly change your angle by writing to memory. This would be much more accurate. This didn't work too well in Holic, as it would cause your character to spaz out, but it might work for Shaiya.

[zer0]

elverion that gives me a good idea, I should have it so the path is corrected and given wider arcs based on distance from the next point and time (which is basically what you said just re-phrased). I'll look at implementing something like this in a few weeks.