Blue Eye Logo

Blue Eye Macro

Automation is freedom
It is currently Sat Nov 27, 2021 2:13 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Color problem?
Thanked: 0 time(s)  Unread post Posted: Sun Oct 24, 2021 7:12 am 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
Getting an error in the log of this:
[code
Checking if: Color.At coordinate is (RGB)(R: 156, G: 181, B: 231, X coordinate: 1047, Y coordinate: 703)
Error: Color sample could not be retrieved. Please make sure you are not trying to retrieve the color of an area outside the PRIMARY monitor
[/code]
monitor is running at 1920x1080 so definately in the coordinates and unsure why its giving the error?
Can anyone assist please?


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Sun Oct 24, 2021 12:59 pm 
Partner / License admin
Partner / License admin
User avatar



Joined: Sun Oct 10, 2010 5:16 pm
Posts: 2218
Location: USA
Been thanked: 520 time(s)
Has thanked: 38 time(s)
Contribution Points: 17606
For one monitor:
Did you limit the area of interest somewhere previous in the macro? By coordinates or window?

For multiple monitors:
The game has to be on the primary monitor and focused. If you have focus on a window displayed on an alternative monitor then it will result in errors like this.

_________________
----------------------------------------Syrifina---------------------------------------------------
PM me for licenses and/or licensing information: Click Here
[Be sure to include and update your profile with your BE ID]

Forum Rules
Reminder of rules regarding Contribution points
Getting started in 1, 2, 3
Virtual Drivers; Manual Installers


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Sun Oct 24, 2021 1:14 pm 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
Single monitor in use. I do use a lot of limits, so from understanding your reply, its possible that I haven't unlimited somewhere?
If there any way to check if a limitation exists?
and would that also cause this?
Code:
System.OutOfMemoryException: Out of memory.
   at System.Drawing.Image.FromHbitmap(IntPtr hbitmap, IntPtr hpalette)
   at System.Drawing.Image.FromHbitmap(IntPtr hbitmap)
   at BlueEye.Wizard.Helpers.ScreenHelper.†††
†††Ž”()
   at BlueEye.Wizard.Helpers.ScreenHelper.GetScreenDump()
   at BlueEye.Macros.Helpers.ColorHelper.†††
†††Ž˜(Byte  , Byte  , Byte  , Byte  , Nullable`1 closestTo, Nullable`1 lastOccurrence)
   at BlueEye.Macros.Helpers.ColorHelper.FindFirstColorOccurenceOnScreen(Byte r, Byte g, Byte b, Byte accuracyRange, Nullable`1 closestTo)
   at BlueEye.Macros.Criterias.Color.Constraints.ColorCanNotBeFoundOnScreen.IsSatisfied(IDictionary`2 variables)
   at BlueEye.Macros.BaseClasses.BaseCriteria.<>c__DisplayClass1.<HasBeenMet>b__0(IConstraint c)
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at BlueEye.Macros.BaseClasses.BaseCriteria.HasBeenMet(IDictionary`2 variables)
   at BlueEye.Macros.MacroStep.evaluateCriterias(Macro owner, IDictionary`2 variables)Out of memory.
Checking if: Color.Pixel pattern can be located on screen(Pattern: 255,255,0,-2,2,255,255,0,2,6,255,255,0,5,-1,255,255,0,1,1,255,255,0,2,0,255,255,0,1,-1,255,255,0,0,-3,255,255,0,-1,-1,255,255,0,1,-3,255,255,0,-4,2,255,255,0,7,-1,255,255,0,0,6,255,255,0,1,1,255,255,0,2,0,255,255,0,1,-1,255,255,0,0,-6,255,255,0,-3,-1,255,255,0,2,0,255,255,0,5,0,255,255,0,-1,2,255,255,0,0,2,255,255,0,0,2,255,255,0,-1,1,255,255,0,0,1,255,255,0, Range: 0)
Error: Unknown
Error: Unknown


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Sun Oct 24, 2021 10:16 pm 
Partner / License admin
Partner / License admin
User avatar



Joined: Sun Oct 10, 2010 5:16 pm
Posts: 2218
Location: USA
Been thanked: 520 time(s)
Has thanked: 38 time(s)
Contribution Points: 17606
Quote:
from understanding your reply, its possible that I haven't unlimited somewhere
That's the first thing I would check. I would see if you have it limited to one section and then searching outside of that area. That's what I think would cause the first problem you posted.

The (other) error message would more than likely be caused by something like this:
- too many searches too fast
-- this could solved by adding "macro.pause" in between searches and/or by using "color.freeze screen dump cache"
- multiple macros searching at the same time
-- I thought that I saw some script that you posted in which you executed different macros; if that's the case then you
would need to ensure that if you have 2 (or more) running at the same time that they are not both trying to perform pixel-pattern searches. You would definitely get "out of memory" errors by doing this.

Use macro.pause (even 100ms helps significantly) and if applicable, check if you have 2 macros performing searches at the same time.

_________________
----------------------------------------Syrifina---------------------------------------------------
PM me for licenses and/or licensing information: Click Here
[Be sure to include and update your profile with your BE ID]

Forum Rules
Reminder of rules regarding Contribution points
Getting started in 1, 2, 3
Virtual Drivers; Manual Installers


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Mon Oct 25, 2021 1:08 am 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
thank you. Yes I have multiples running at the same time, which Im assuming is the only way to have coroutines running consecutively unless theres another method I'd missed?

All files in my screenshot for the macro are running consecutively for different ongoing watches. Is there a more ideal method using BEM than using what would effectively be class files?


Attachments:
Screenshot_8.png
Screenshot_8.png [ 4.06 KiB | Viewed 242 times ]
Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Mon Oct 25, 2021 4:15 am 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
Ok I'm struggling to find a way around this - No matter what I try the error still happens.
Log
Code:
Executing: Color.Unlimit area of interest
Checking if: Color.At coordinate is (RGB)(R: 156, G: 181, B: 231, X coordinate: 1047, Y coordinate: 703)
Error: Color sample could not be retrieved. Please make sure you are not trying to retrieve the color of an area outside the PRIMARY monitor


As you'll see, I've put a unlimit right before where the error is coming up as a check, but still receiving the issue. Single monitor in use at 1920x1080 so 1047x703 should have no issues on being within the primary monitor?

the function causing the error is this:
Code:
function("CheckForDeath")
     begin
          // If dead click and respawn
          Color.Unlimit area of interest()
          if  Color.At coordinate is (RGB)("156", "181", "231", "1047", "703")
               begin
                    // dead return to last save
                    Mouse.Click at coordinate("978", "728", "Left")
                    Humanly.Pause("500", "700")
                    Mouse.Click at coordinate("1038", "606", "Left")
                    Variable.Set("InTown", "true")
                    Macro.Break from loop("no")
               end
     end
function


****Edit****
Have attempted using Pause all other macros just priot as well, but the issue still happening? Im at a loss now as to any other work arounds... any advice?
Code:
Executing: Macro.Pause all other macros
Executing: Color.Unlimit area of interest
Checking if: Color.At coordinate is (RGB)(R: 156, G: 181, B: 231, X coordinate: 1047, Y coordinate: 703)
Error: Color sample could not be retrieved. Please make sure you are not trying to retrieve the color of an area outside the PRIMARY monitor
Executing: Macro.Resume all paused macros


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 1 time(s)  Unread post Posted: Mon Oct 25, 2021 5:01 pm 
Partner / License admin
Partner / License admin
User avatar



Joined: Sun Oct 10, 2010 5:16 pm
Posts: 2218
Location: USA
Been thanked: 520 time(s)
Has thanked: 38 time(s)
Contribution Points: 17606
Are you using "wait for color to be (or not to be)" in any of your macros? If so, that throws the pixel searching off for all of your macros (while it's waiting)...and gives that same error.

It may not be enough to pause all other macros, you need to un-limit all of them also (not just in the one).

You sound very frustrated, hey, I've been there. If I was in the same situation I would take a step back and focus on one macro at a time and try to find which macro is causing the problem. For example, try running only that one macro...do you still get the same error? If not, then you know the issue isn't in that macro. If you can run all of them independently without error, but together it produces an error...then you know that they are conflicting somewhere and you can focus your search in that direction...where is the conflict.

*From experience: Since we tried the basics and you are still getting that error, my bet is that the "Color sample could not be retrieved" error is not caused from that macro, it's in another macro that's running at the same.

_________________
----------------------------------------Syrifina---------------------------------------------------
PM me for licenses and/or licensing information: Click Here
[Be sure to include and update your profile with your BE ID]

Forum Rules
Reminder of rules regarding Contribution points
Getting started in 1, 2, 3
Virtual Drivers; Manual Installers


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Tue Oct 26, 2021 12:25 am 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
Sent you a pm, hope it was ok to do so


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 1 time(s)  Unread post Posted: Thu Oct 28, 2021 3:22 pm 
Partner / License admin
Partner / License admin
User avatar



Joined: Sun Oct 10, 2010 5:16 pm
Posts: 2218
Location: USA
Been thanked: 520 time(s)
Has thanked: 38 time(s)
Contribution Points: 17606
So I read through your code and have some suggestions. Here's my first impressions of the scripting that you sent me:
- it's very well organized
- I can tell you're a programmer, even though you recently joined the forum
-- you seem to have a good grasp on the Instructions/Criteria
-- you are utilizing advanced logic techniques
-- very impressive for someone new to BEM
- the macros are focused
- you used my favorite, "speech.say"; I love it

The TLDR (too long, didn't read): You have too many pixel-pattern searches and they are not used efficiently. I think that's where all of your problems are stemming from. Suggestions:
1. use memory addresses instead
2. cut it down to 1 (or a few) macros
3. write/use plugins

While reading through your code I got a sense of your style. Everyone has their own style. Before I explain that further, let's start from the beginning of BEM. The developer, Gigus, used to create bots for games. (just going to paraphrase his story as I remember it) It was a lot of work when changing games to set up each bot starting from scratch, so he set out to create BEM to have all the structure you needed to make any bot/macro and be able to make a bot/macro quickly. He designed BEM to be intuitive so that anyone could use it, even people with no programming experience. So it's an automation program that even non-programmers can use.

The way I explain how to get started to new users when developing their first macros, since it's intuitive and an automation program, is think about how you would do it and then script BEM to do that for you. For example, if you want to fill in a box with text you may need to click in the box first (with the mouse), then you type with the keyboard.

Yes, yes...I know, you are well past that point, so here's what I saw you doing in your script and how I think you can do it better:

First, the style I observed while reading your script. You wrote it like a programmer would and wrote it with what I consider what a reasonable programmer would expect a program to be able to do because it's a machine. What I mean is that it wasn't written in a manner in which BEM is acting like a real user and automating the actions a person could perform. It's not to say you can't do that, but there's a better way to do it.
For example, your pixel searches in general. Let's say a person is playing the game, they are in combat with a mob. They want to glance at the mini-map. A person would need to take their eyes off of the player and mob, glance at the upper-right corner, make an observation, then turn their attention (eyes) back to the combat.
Your approach is more like a program in which you want it to monitor all those things at once. Nothing unreasonable about that request. But since BEM is non-evasive, it has to perform those actions one at a time. By scripting it in several different macros to perform these actions simultaneously it's going to cause problems; out of memory issues, poor/slow performance, and crashes due to high resource usage. So, how do you fix it? Suggestions:
- run them one at a time; set up a priority system
- use memory addresses instead of pixel-pattern searches
- use RGB instead pixel-patterns (they are quicker and more efficient)
- write plugins to maximize performance

More than likely you've tried to run these in one macro. Even if you hadn't, imagine all your searches in one macro and the speed it could run through one evolution. How slow would it be? It would be very slow. Therefore, the solution is not to separate them into separate macros and run them simultaneously; that's going to then cause performance issues and crashes. So the solution is more creative logic and flow.

I have a bot that does much the same as your bot; It needs to do all the same things as yours' does. In my bot, all the combat functions are in one macro. Selecting a mob, attacking, checking HP, MP, etc., buffs, healing, recognizing when the mob is dead. I have it prioritized and segmented into functions. I segmented mine so that it performs a number of attacks, then checks health, mana, buffs, the mobs health then resumes attacking. It continues this cycle until the mob is dead. Then moves on...regen, rebuff, move, search for another mob. It's all basically linear. The reason it works is because it's segmented...and because I either use RGB searches or memory - they are much quicker and utilize much less resources.

More specifically to your scripts (going in alphabetical order; how they are displayed in BEM):

Constant variables - not necessarily needed as a separate macro, but this is more of a style thing and it's organized. The main thing about this one is that if you follow my suggestions and reduce the number of macros you won't need global variables.

EnemyScanning - This is the first look into conflicting logic.
"while Macro.is running (ROBotMain)" -->unlimit area of interest
-- ROBotMain is always running
-- ROBotMain has functions with "limit area of interest"
-- this macro has functions with "limit area of interest"
...so, do you really want it to always unlimit the area of interest while ROBotMain is running? This is a part in which I would segment functions and consider the implications of using "while"

Healing - going to basically skip this one for now, but mention you have a whole other macro that watches health (HealthWatch), it's executed in this macro, but you also have a redundant function in this one that checks HP. There may be instances where this needed, but I think you may agree that there are more efficient ways of performing this if you were to look at the larger logic and flow of what you are trying to accomplish.

HealthWatch - Alright, this may sound a little harsh, but you could do this all in one function with very few lines of code if you make some minor changes. You could skip the function, "Setup Areas" if you used RGB for the health bar. From what I've seen your character is almost always in the same position in the middle of the screen (yes if you move left/right it briefly scrolls, but it returns to the middle once you stand still) so use this to your advantage. You spend a lot of effort finding the health bar which I don't see a need to; you know where it is. It's in the middle of your screen under your character. I generally only use 2 points for the player and mob. For the player I'm only interested if the HP is below half (or pick a percentage) and needs to heal or closer to death in which I need to do something immediate (like larger heal or potion). The mob, I only care about if it's at full HP or dead. So those are the RGB points I set up. However, considering the amount of things you are monitoring and trying to accomplish with your bot, I would use memory addresses. It will help you out so much. So much less resources and so much quicker.

Okay, I'm not going to go through them all but the main points are:
- simultaneous tasks work much better in programming. Just like a person cannot click at 2 spots on the screen at the same time neither can BEM. If you go into it with the mindset of trying to automate what a person can do...then you will have much less problems with the functionality. At that point your bot will play as a human but faster. Then you can go back and refine it to do more. Better, faster, more efficient. if you're trying to do things a person can't do, I would say write a plugin.
- you have way too many pixel-pattern searches. Yes, it's a machine, but it has limits also. Memory addresses and RGB colors are much more efficient (and quicker). Think about if you really need a pixel pattern or can you accomplish the same thing with one color.
- I would imagine if you opened Windows Task Manager and ran your macro, your performance would be maxed. I can't see how any gaming PC could run this without crashing (or lagging, locking up, etc.). Remember BEM is going to try to run everything as fast as it can; if you have resources available it's going to push it...unless you script in limits. That's where the macro.pauses and other limits come into play. If you tell it to run all these searches at once, it will try...if it crashes your computer, well it's only doing what you told it to do.
- As a programmer you have to take all this into consideration for the user, not just what you are trying to accomplish. If pixel-patterns searches are too slow, the answer isn't always to force it. Maybe the answer lies in looking at whether they are all necessary or perhaps there's a different way to get that information. Do I need all this; can I do it with less? If I gather this information once, can I reuse the information in another function so I don't have to search for it again?

Just trying to help; I hope this information helps and you can put it to use.

_________________
----------------------------------------Syrifina---------------------------------------------------
PM me for licenses and/or licensing information: Click Here
[Be sure to include and update your profile with your BE ID]

Forum Rules
Reminder of rules regarding Contribution points
Getting started in 1, 2, 3
Virtual Drivers; Manual Installers


Top
 Profile  
Reply with quote  
 Post subject: Re: Color problem?
Thanked: 0 time(s)  Unread post Posted: Fri Oct 29, 2021 12:03 am 
Active User
Active User



Joined: Sun Oct 17, 2021 9:07 pm
Posts: 32
Been thanked: 0 time(s)
Has thanked: 6 time(s)
Contribution Points: 67
Thank you for that.
I'll take it all into consideration, to date I've never attempted memory addressing so I'm going to have to look into how it works, especially in bem. I've noticed the regex commands and Im assuming these are what you're referring to?
I realize there may be many redunant functions in it, unfortunately it has come from me attempting different methods to find whats reliable. The health was using the main status window to get hp/sp hence the searches since that had the potential to be moved on the screen. I certainly get what you're saying regarding using the bar below the player though and will look at adjusting it :)
With the pixel patterns I kept finding when I used rgb it would keep returning with the color was not found on screen - or too many results. Hence switching to a pattern rather than a single color. is there a way around this complication? would memory addressing resolve that?

in general, yes I've been a game developer for a few decades now, starting in dos with BBS door games so began with ansi :) I guess I still fall back into that style a lot when developing anything lol
it wasnt too difficult to pick up bem, since the knowledge i've learnt in c#/pascal/delphi/qbasic etc often crosses over to other languages, and just need to look at what the equivalents are in which to apply them.

One primary reason I split the macro's is the lack of a search function within the code. when it was in a single macro, to find one function I was having to scroll the entire macro to look for it. As the macro grows, this becomes extremely difficult and time consuming whereas having individual macro's allows for seperation of the various elements into classes, allowing rapid location of areas causing issues.

If gigas could put a seach into the code view it would simplify things like this considerably :)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ]  Go to page 1, 2  Next

All times are UTC


You cannot post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group