createpath + getid + getpos together

[Bill D Cat]

And I think a GUI would end up being a bit cumbersome to constantly switch over to it in order to click a button or access a pull-down menu option. For those running with multiple monitors this is not a problem, but anyone with a single monitor would either have to run the game in windowed mode or risk the frequent game crashes associated with window swapping while in full screen mode.

One solution would be to have the GUI be small enough in size and be able to live on the RoM screen while in full screen mode while still allowing the mouse and keyboard control of the game. I'm not even sure if that is possible.

I do like the idea of automatically bringing the MM window to the front when additional input is required, and then pushing it to the back afterwards. But again, I have a feeling this will only work if the game is being run in windowed mode.

[rock5]

Good points. I've never played in fullscreen mode. I can't see the point if you are a botter. I even thought the bot might not be 100% compatible with fullscreen, like maybe some addresses didn't work. I should try it sometime.

[BlubBlab]

Hm I have a laptop I wouldn't see much If the game would be "fullscreen" that doesn't mean I can't run it in a windows but the idear running rom in windows mode was pointless for me until you mention it.

About incompatibly can't see their are no errors their are always some glitches after you run the bot a long time, infinity targeting a open chest in AT or don't see the boss in dod If this because of incompatible then their must be an issues with the targetpointer/objectlist. I'm fully aware that reading the memory of a foreign process isn't something you can't say it is a perfect science.

[lisa]

I don't recall ever having RoM in full screen, always been in windowed mode for me.

[Bill D Cat]

If I am actually sitting at the computer and playing the game, then I prefer to have it in full screen mode. For some reason I get a higher frame rate and less latency lag. If I am doing anything with the bot, then I switch to windowed mode so that I can bring the MM window on top of the game to interact with it, then bring the game back to the front to continue whatever I'm doing. Doing the constant screen swapping while in full screen mode will crash my game client after about a dozen swaps. If it were possible to have a child window on a full screen game then I'd use it that way. I don't have any issues running in windowed mode unless I'm participating in a guild instance run or doing siege war where I want a bit more responsiveness from the game.

[rock5]

So can we assume that if you (or anybody else) are using createpath then you would have changed to window mode so we can safely use 'showWindow' to automatically activate the MM console when it needs input then switch back to the game?

[Bill D Cat]

I think that would be a safe assumption for 98%+ of the users. I'm not sure if anyone is using a dual monitor setup with RoM running on one in full screen and MM on the second monitor, but they would certainly be in the minority in my opinion. And even so, using showWindow should only switch focus to the MM window on the second monitor without actually trying to move it to the main monitor.

[rock5]

Even with a dual monitor display I'm pretty sure if the client is in fullscreen mode, it will minimize when focus is given to MM. It would be the same.

And if a user actually does want to use createpath with a client in fullscreen mode they will still have to manually give focus to MM anyway when entering input. So I don't see any harm doing automatically either way..

[Bill D Cat]

Here's a test candidate for the auto-minimizing of the MM window when running createpath. It will restore when user input is needed, and minimize again afterwards. I've also done a bit of work on the formatting of the output file so that it looks a little neater. If there are no actions at the waypoint then the closing tag is on the same line, otherwise everything is done on it's own line as shown below.

Old Style:

Code: Select all

	<!-- # 15 --><waypoint x="4552" z="2076" y="1418">	</waypoint>
	<!-- # 16 --><waypoint x="4536" z="2134" y="1418">	player:target_NPC(120252); -- Dormen Blackjaw
		CompleteQuestByName(425076); -- Assist Pioneer
		AcceptQuestByName(425077); -- Watch Out For Those Gazes!
	</waypoint>

New Style:

Code: Select all

	<!-- # 15 --><waypoint x="4552" z="2076" y="1418">	</waypoint>
	<!-- # 16 --><waypoint x="4536" z="2134" y="1418">
			player:target_NPC(120252); -- Dormen Blackjaw
			CompleteQuestByName(425076); -- Assist Pioneer
			AcceptQuestByName(425077); -- Watch Out For Those Gazes!
	</waypoint>

[rock5]

I actually did it myself as well. : But I've been trying resolve an issue with showWindow with Administrator. Your solution bypasses the issue I was having because you minimize MM but minimizing is not ideal. I, for one, would leave MM open but move it to the other display so it's still visible. I wouldn't want it minimized.

What I did was make a separate function to receive input to avoid repetition. I also included accepting single numbers from the game so you don't need to switch to mm for ChoiceOption.

Moving code to the next line is a good idea. That always annoyed me. And I didn't do any of the wptype code yet.

So your version is more complete. So I'll probably just move some of my changes to your version. But I really want Administrator to fix showWindow so restore work as expected. At the moment my version of MM is broken so I can't even test properly.

[Bill D Cat]

I was working on adding commands to accept/complete quests by scanning the user's quest book at startup, and adding all accepted quests to a table. Then any time the Quest button was pressed, it would scan the quest book again and then depending on if there was either one less [ use CompleteQuestByName() ] or one more quest [ use AcceptQuestByName() ] enter the appropriate command into the waypoint file.

Would this be a better way than polling the current NPC for quest info? With the few quest items that give border quests, it might cause a few sync issues but I think I can code my way around them.

Any other ideas on avenues to explore here?

[rock5]

I would prefer to get the name when you select it but I suspect you want to use Ids and I don't think you can get a quest id without first having the quest.

If we did go with names it might be possible to merge ChoiceOptionByName, AcceptQuestByName and CompleteQuestByName in to one button. I think it should be possible, after you have made a choice with a number, to have the bot see what the choice is, whether it be an option or accept/complete quest, and add the correct command. You can have a look at the list of options if you print out the following table ('pr' assumes you have my fastlogin addon).

Code: Select all

/script pr(g_SpeakFrameData.option)

I'm trying to rake my to brain think of a better way. Maybe after selecting the choice by number, the bot can select it for us and check the questlog for the quest with the same name and then get the id from that. Completing quests wouldn't be a problem because it can look it up the name of the choice in the questlog. Or maybe, because you usually accept and complete quests in the same waypoint file, we could have it get the Id from the quest in the log when you add the "CompleteQuestByName" and save it in a variable. Then when it writes the file it uses the same id for both commands. Or maybe we can use a variable in the command and then add a "questname" argument in the onload, eg.

Code: Select all

questname = 567890 -- quest name

Administrator has really left me hanging half way through trying to get the window restore working properly. He hasn't been on for about 3 days. Must be busy with real life.

That's all the ideas I can come up with so far.

By the way, here is my current version of createpaths with my changes merged to your last version. If you are already well along in your new edits, don't worry about it, I'll do a new merge when you post your next version.

[Bill D Cat]

If you know the quest name, you can look up the ID with an in-game function. I'm sure this could easily be adapted for better use with the bot. I use something similar to find the ID's of all the quest reward items so that I can pick the best option based on the current primary class of the character that is in use.

Code: Select all

function findId(item)
	for start = 200000, 299999 do -- Or whatever the range is for active quests
		if string.find(string.lower(TEXT("Sys"..start.."_name")), string.lower(item)) then
	        	DEFAULT_CHAT_FRAME:AddMessage(tostring(start.." = "..TEXT("Sys"..start.."_name")))
		end
	end
end

[rock5]

I thought of that. I use a similar id scan method in TooltipsIds. There are a few problems with that.

• 1. I'm not sure all the quests are grouped together like some other id types are, so it might not be possible to limit the search range.
  2. There can be multiple quests with the same id. So you can't be sure to get the right id.

What I'm thinking is whenever it does an AcceptQuestByName it initially remembers the quest name. Then when it does a CompleteQuestByName it also remembers the quest name but also looks up the quest in the questlog and adds the id to a table, eg.

• questids{
  • ["The quest name"] = 567890,
  }

Then when it goes to write the file it substitutes the quest name that it remembered with the id in the table, eg.

Code: Select all

hf_line = hf_line .. "\t\t\t" .. "AcceptQuestByName("..questids[v.quest_name]..") -- "..v.quest_name

Actually, getting the quest id might not be that easy. Normally we can get the quest id in the questlog by using the questlog userfunction but we can't really use a userfunction with createpath. We may have to add some of the functionality of questlog userfunction to createpath to make it work.

[Bill D Cat]

I think each quest has a unique ID but may have a duplicate name. Most recently I've noticed the quests in Logar for "Meet the XXX Instructor" where you have to see the appropriate class instructor in Varanas share the same NAME with the quests in Heffner Camp, but the IDs are different. So looking it up by name using the method I just posted could result in multiple IDs being returned.

Whereas the following would return the exact names and IDs of the quests currently in your questbook:

Code: Select all

local numquests = RoMScript("GetNumQuestBookButton_QuestBook()")
if numquests > 1 then
	for count = 1, numquests do
		index, _, questName, _, _, _, _, _, questID, _, _ = RoMScript("GetQuestInfo(count)")
		print(index .. " " .. questID .. " = " .. questName)
	end
else
	Msg("No quests in log book")
end

Your method also has the minor drawback of requiring the AcceptQuestByName() and CompleteQuestByName() to be recorded in the same session of createpath. With some of the long detailed waypoints that I'm creating to cover entire zones, that may not always be possible.

[rock5]

I've noticed the quests in Logar for "Meet the XXX Instructor" where you have to see the appropriate class instructor in Varanas share the same NAME with the quests in Heffner Camp, but the IDs are different.

And don't forget all those quests in the new zones where you have a normal, daily and public event quests all with the same name from the same npc.

Whereas the following would return the exact names and IDs of the quests currently in your questbook

Yep, that keeps it simple and saves us the trouble of doing it via memory functions.

Your method also has the minor drawback of requiring the AcceptQuestByName() and CompleteQuestByName() to be recorded in the same session of createpath. With some of the long detailed waypoints that I'm creating to cover entire zones, that may not always be possible.

Well, if you accept the quest then don't complete it, then when you go to write the file and it sees that you still don't have the id for the quest, it can look it up then.

[Bill D Cat]

I've noticed the quests in Logar for "Meet the XXX Instructor" where you have to see the appropriate class instructor in Varanas share the same NAME with the quests in Heffner Camp, but the IDs are different.

And don't forget all those quests in the new zones where you have a normal, daily and public event quests all with the same name from the same npc.

Each of which have a different ID or are flagged as Daily in one of the options I "skipped" by using the _ character to disregard that data returned from the function. Either way, I think both options are viable. I'll investigate mine, you investigate yours and we can see which one integrates well without too many problems.

[rock5]

I'm not 100% sure what you are saying but, yes, every quest has a different Id. That's why if you use the Id then you don't have to specify "daily", "public" or "normal" when using Accept/CompleteQuestByName.

I don't want to really duplicate our efforts. Anyway I'm concentrating on resolving the windowshow issues. I finally got a solutions for the problem of MM not being able to restore itself. As you know your method of minimizing MM then restoring it works but I don't want it minimized but restoring it when it isn't minimized doesn't work. But minimizing it is the solution. When I want to restore MM when it's not minimized, all I have to do is minimize it just before restoring it. Works like a charm. The other problem is if you restore the game client that is maximized in the background then it becomes a window. This is what initially started the conversation between me and Administrator. I think, though, I might just use sw.show with the client. It shouldn't have been minimized anyway.

I think it's time I do some testing with the game in fullscreen mode and see what the effect is.

[Bill D Cat]

I wasn't planning on actually adding code into the createpath file for testing my method. I was going to create an in-game function that could pull the data and see how reliable it is. The other thing that crossed my mind with using my proposed method was; is it possible for createpath to monitor in-game events for when the quest log changes? If so, then maybe we could have quests automatically accepted or completed based on this. If not, then my method will rely on the user accepting or completing the quest, then pressing the corresponding key to check what changed in the quest book and enter the appropriate command.

With your idea of polling the NPC for available quests, how would you know which one(s) the user wanted to accept at a given time? The reason I ask is because I use the official US servers to create my waypoint files so that I know the character should be at an appropriate level to accept it. If I run on the Nexon private server, some NPCs might have quests available a lot earlier than normal due to the enhanced XP rate, and I am not sure I'd want to code for two different servers like that.

[rock5]

The other problem is if you restore the game client that is maximized in the background then it becomes a window. This is what initially started the conversation between me and Administrator. I think, though, I might just use sw.show with the client. It shouldn't have been minimized anyway.

Actually I was wrong. The beta version I'm using works correctly and leaves the window maximized. Still a few bugs to work out though.

With your idea of polling the NPC for available quests, how would you know which one(s) the user wanted to accept at a given time?

We could have the user type a number like with ChoiceOption then have the bot get the name of that option. Maybe using that table I mentioned or maybe systematically going through the different quest groups using GetQuestNameByIndex.

Here, I've written a userfunction with 2 functions using these 2 methods. The second function is faster because it does only one romscript as apposed to 2 in the first. Note, I've made it so it does a CompleteQuestByName if you choose an already accepted but uncompleted quest.