Jump to content
AC Tool Forums

The WABBIT

Moderators
  • Content Count

    612
  • Joined

  • Last visited

2 Followers

About The WABBIT

  • Rank
    Forum Master
  • Birthday 02/03/1966

Profile Information

  • Gender
    Not Telling
  • Location
    Denver, Colorado

Contact Methods

  • Yahoo
    The_WABBIT1@yahoo.com

Recent Profile Visitors

16,057 profile views
  1. First of all, are you actually talking about making the program Full Screen? Or are you talking about Maximizing the program's window? There is a difference between the two. Making the program full screen means that the program takes up the whole screen. There is no window Title bar, and no window borders (if any), and windows taskbar is not present. Maximizing the program's window will have the window Title bar, and window borders (if any), and the Windows taskbar will be present (provided you did not set the taskbar to auto-hide). And, depending on what you actually want to do with the program. There is a couple of problems: The WinKey + Up Arrow will Maximize the currently active window. It does not make the program Full Screen. The Ctrl+Esc is a good alternative to just pressing the WinKey. But, it will not work with any of the WinKey+key shortcuts. All it does is bring up the Start Menu. So, if you actually want to make the program Full Screen. Then what you actually need to do is use the Alt+Return (or Enter) shortcut. This will cause the program to become Full Screen provided that the program was created to be Full Screen. Or if you actually want to maximize the program's window. Then there is actually two ways of doing this. Use the Alt+Space shortcut to bring up the window's sub-menu and then press x to maximize the window. (Alt+Space+x) Some programs/games may interfere with the Alt+Space shortcut. Use the program's taskbar icon to maximize the window. You do this by first hovering over the program's taskbar icon. Wait for the preview of the program's window to popup. Move the mouse to hover over the program's window preview. Right click on the preview. And then select Maximize There you go an answer to your problem.
  2. Yes, that very much sucks. And too bad for them that it took them 3 months to do exactly what you asked, and told, them to do.
  3. DaMOB, I'm sorry to here of your major trouble with LOTOR, most specifically the Devs, or the publishing company, for not helping you to retrieve your account. At least they are doing it properly.
  4. That is good. But, I did forget to mention something in Part 3. That in the procedure that is looking for the colored box. You use the MatchColor constant to know which color box you are looking for. Below you will find a example script, example_code2.mac, that shows one way of creating the procedure. This script was create of the top of my head. I have not used or tested this code to make sure it does as it is intended. If the code does not work as intended. Then it should not take more then a few minor changes to get it to work. example_code2.mac This code was create off the top of my head. I have not used or tested this code to make sure it does as it is intended. If the code does not work as intended. Then it should not take more then a few minor changes to get it to work. If you decide to use this code in your own script(s). Then you must add comments to the beginning of your script. Giving me credit for the creation of the code. Now to answer your questions. The reason I said to use the IsColor command for those three checks. Is for 3 reasons: It takes less code to use them. They are already programmed into AC Tool. So why not use them? Since they are already programmed into AC Tool. They are quicker when it is checking the pixel for the color. The only reason why you would not want to use them. Is if you are checking for a specific shade of Red/Green/Blue. Then you would want to use the LoadRGB and check the RGB values. Otherwise, If you are just checking to see if the pixel is Red or Green or Blue, no matter what shade it is, then using the IsColor command would be the best way to go. What you are seeing is normal. This is what I call Normal Variance, or just Variance. This variance is caused by the hardware (CPU, GPU, RAM, etc.) in your system, or the hardware in system of the user of your script. Back in the day people would write a value that can have a variance in the following way: n +/- n So, is a pixel had a value of 54 and it varied by 3. It would be written as 54 +/-3. What is happening here is the game is telling your system to display a pixel with a RGB values of one specific color, or shade of color. And the hardware in the system is causing the pixel to display a slight different shade of the color. It could be the CPU that is causing it or it can be the GPU that is causing the problem. Or any combination of CPU, GPU, RAM in the system. Some times you may pick a pixel and test the that pixel all day long and never see it vary. And yet if you just reboot your system and then check that same pixel. You will see it vary all the time. And other times you can check a pixel for 6hrs and not have it vary for the first 3hrs and then it will vary for the last 3hrs. How much of a variance will you see? Well, pixel color variance is greatly determined by the hardware in the system the script is currently running on. But, at the same time you may not see it vary at all on one day. And it might vary a little bit on another day. And yet on other day it may vary alot. Or it you will see it vary intermittently. In AC Tool certain commands, such as the IsColor, when they test pixel for a specific color. Allow for variance by allowing the creator/user of the script to use the ObjVar command to set how much of a variance you are willing to except. But, when using the LoadRGB command and testing the RGB values directly. There is no automatic way to do this. You have to create the code yourself. So, with my example number above, 54 +/-3, would cause you to have to look for a value that is any one of the following: 51,52,53,54,55,56,57. And the value that you would get could be any one of those 7. A couple of days ago, I created a script that would check for a color by it's RGB values. And it would except a RGB value that is within the value of a constant that you would set with the maximum amount of variance. I just knew that it would be needed. You will find the script file, example_code.mac, below. If you wanted to use this with code in example_code2.mac. Then all you would need to do. Is change two lines of code. Replace line: LoadRGB $tmpBox with: Call TestRGB $tmpBox, $tmpR, $tmpG, $tmpB Replace line: if {RGBRed} = tmpR and {RGBGreen} = tmpG and {RGBBlue} = tmpB with: if $FoundColor = True That's all you need to do. example_code.mac This code was create off the top of my head. I have not used or tested this code to make sure it does as it is intended. If the code does not work as intended. Then it should not take more then a few minor changes to get it to work. If you decide to use this code in your own script(s). Then you must add comments to the beginning of your script. Giving me credit for the creation of the code.
  5. Part 3 of 3 Now you did not mention anything about how the row of boxes move. Do they spin all the way around? Or do they only spin so far in each direction. And you didn't mention if the color boxes on randomly placed on this row. I can pretty much guess that they boxes are randomly placed. But, I have to assume that the row of boxes spins all the way around. But, no matter how far the row of boxes spins. I would now create a second procedure to find the box with the correct color and place it under the top box. Again, I would pick a pixel that is as dead center of the 3 complete boxes on the row. I would also say that the box to the left (the Red box in the image) is Box1. The center box (the Yellow box in the image) is Box2. And the right box (the Purple box in the image) is Box3. Or I could use BoxL, BoxC, BoxR for the name of the boxes. I would then define a constant for each of the box names. And I would define each constant's value to be the X and Y coord for each box. Such as: Constants Box1 = 25,15 end Then I would use the same color checking code from the previously mention procedure. But, I would use the box constants with the LoadRGB command to load the proper pixel for the box being checked. And I would also use the constant set that I had defined for the solid colors. The procedure would also contain the code necessary to move the boxes left or right so that the correct box is under the Top box. Provided the box with the correct color is present. If not then it will have the necessary code to move the boxes Left/Right until the correct box is present and then place it under the Top box. Hopefully within the maximum of 3 tries. The code that would be necessary to move the boxes will have to be up to you. As only you know how far the row of boxes spins in either direction. But, I would highly suggest that if it is possible. When not finding the correct color box in the 3 currently displayed boxes. That you spin the boxes until you have 3 different colored boxes being displayed. Before you check to see of if the correct colored box is present. This will make the checking for the correct colored box to be faster. And it will hopefully help is getting the correct box withing the maximum 3 tries.
  6. Part 2 of 3 At this bout I would need to create a procedure that would check the top box and figure out what color I need to match. And place the name of that color in the MatchColor constant. But, first I need to decide on the pixel to check in the top box. For me, I would use a pixel that is as dead center of the box as possible. And then I would used that specific pixel coordinate for each of the check to see what color I need to match. Once I have the pixel coordinate I would create the procedure to figure out which color I need to match. That uses the IsRed, IsGreen, and IsBlue statements to first check to see if I have to match a Red box, a Green box or a Blue box. That's the easy part. Then I would use the LoadRGB to load the RGB color values for the pixel. And then I would use a single IF statement to compare all three RGB color values to the RGB constant set for a single color. Then I would use addition IF statements for each additional color needed to be check for. Look in the AC Tool help file to understand what IsRed, IsGreen and IsBlue are and how to use them. For my this procedure would look something like the follow: // check if box is the Red box IsRed Set MatchColor = Red else // check if box is the Green box IsGreen Set MatchColor = Green else // check if box is the Blue box IsBlue Set MatchColor = Blue else // We only need to load the RGB once and only at this time. LoadRGB // check if box is the Purple box. if {RGBRed} = $MatchPurpleR and {RGBGreen} = $MatchPurpleG and {RGBBlue} = $MatchPurpleB Set MatchColor = Purple else // create addition nested IF statements // for each color that needs to be checked end end end end
  7. Okay, I am going to do this in three post just to make it easier for me to get it posted. Part 1 of 3 This is how I would create the script. I would load up the game as many times as needed to get all semi-transparent colors. And then I would use AC Tool to show the RGB color values for each of the color boxes that are not Red, Green or Blue. Write these RGB colors down on a piece of paper. Keeping track of which values belong to which color. I would load up the game as many times as needed to get all of the solid colors. And then I would use AC Tool to show the RGB color values for each of the colors that are not Red, Green or Blue. Write these RGB colors down on a separate piece of paper. Keeping track of which values belong to which color. I would define RGB constant sets for all the colors that I have written down. I would define each constant set with names that is easily understood at first glance. Such as: MatchRedR = Match Red RGBRed, MatchRedG = Match Red RGBGreen, MatchRedB = Match Red RGBBlue. I would then do the same for the solid colors: RedR = Red RGBRed, RedG = Red RGBGreen, RedB = Red RGBBlue. As I define each of the constants in the clause group. I would set each constant with the proper RGB color value for the color. So, my constant clause group would look something like this: constants // Yellow Color Box to match MatchYellowR = 128 MatchYellowG = 153 MatchYellowB = 63 // Purple Color Box to match MatchPurpleR = 168 MatchPurpleG = 35 MatchPurpleB = 200 // Orange Color Box to match MatchOrangeR = 143 MatchOrangeG = 125 MatchOrangeB = 63 // and so on for the remaining // semi-transparent colors. // Yellow Color Box YellowR = 62 YellowG = 529 YellowB = 25 // Purple Color Box PurpleR = 148 PurpleG = 53 PurpleB = 200 // Orange Color Box OrangeR = 65 OrangeG = 58 OrangeB = 75 // and so on for the remaining // solid colors. end I would then define one more constant. This constant will be used to hold the name of the color we need to match. I would define this constant with the name of MatchColor Then I would create the rest of the script that has a main section/procedure that uses two different procedures to figure out what color box I would need to match and then to find and move the color box to the proper place.
  8. This would work if you are dealing with the normal variance in pixel color caused by system's hardware. But, it just causes more problems when dealing what should be a static color at a specific pixel. Yes, you can. Remember, Johnny 5 (aka Number 5) helped the bank robbers break into and rob the bank. With very little Input. Of course most of that input was all lies. But, it still helped. Yes, we all do things differently. And it good that we all do. Because it allows all of us to be able to learn from each other. For, me I like looking for at least two different ways to do something in a script. For which I decide on which way might be better to do it. Most of the time it is the simplest way. Other times it is the most efficient. or the best, way. And when someone asks for help. I try to give at least two options to do something. And then I let the user decide on which option they wish to go with. Now, once in a while I will recommend a specific option. Only because it is the better way. But, it is still up to the user which option they go with. And sometimes after I have given the options that I can think of. The user had come up with their own option. And as for you, normally you are not too far off track. You just to see possible other options to do the same thing.
  9. I am glad that I was able to help you in this.
  10. Yes, constants in AC Tool can be confusing. But, just remember that in AC Tool a constant are nothing more than a variable in other programming languages. And I am glad my tip was able to help you with your initial part of your script. I can try. What @Ego asked not withstanding. Because Number 5 needs input, and because it can help us to understand what you are trying to do. In the game that you are creating the script for. There is a specific reason for certain boxes to be semi-transparent. In most game it is because such semi-transparent items are not yet available for your toon to use. But, there are other reason for them to be that way. Until I know differently, I am going to assume that the reason for the semi-transparent boxes is because they are not yet available for you to access/use them yet. To answer your question, technically the boxes are not the same. At least not until the semi-transparent one become accessible/usable to you. There is no reason to say that the semi-transparent box is the same as the solid one. Unless if you are just trying to keep track of semi-transparent boxes until they become available. If that is case then you have two options. Option 1: use two sets of constants per box color. One for the solid and the other for the semi-transparent. Then when you go to check for the box. You have to use both sets to see if you have a purple or orange box. Option 2: Because the amount of semi-transparency should be the same between all boxes, no matter the color. You can use basic math, addition and/or subtraction, to figure out the difference between the solid boxes and the semi-transparent boxes. Then you can use that difference with some basic math. To figure out if you have a purple or orange box, whether it is solid or semi-transparent. But, there is one thing about this you need to know and do. You have to be able to test the exact same place in the box. No matter where in the game screen the box is. You have to test the exact same place in the box. What do I mean by that? If the boxes in the game are displayed in a grid of 10x10 pixels. And you are testing pixel 3,4 x,y (from top left corner of the box). Then you have to test pixel 3,4 x,y (from the top left corner of the box) in every box. The reason for this is because the game, not the hardware, might be displaying a slightly different shade of purple in the pixel that is next to the one you are testing. So, unless you can guarantee that all purple pixels in the box. Are the exact same shade of purple. Then you have no choice but to test the exact same pixel placement in the box. This will save you a whole lot of trouble, by not having way to many unnecessary constants, or math computations, in your script. I hope that helps you.
  11. Okay, finished downloading the game and I was able to login to it. But, looking at the keyboard key bindings for the game. There is no Fn keys bound to any form of action/menu in the game. So, you will have to tell me what Fn keys you have set up and what they are set to do.
  12. I am looking into what is happening. You did not mention where did you get Metin2 from, Steam or GameForge? But, I am currently d/l'ing it from Steam. So, what I will find may, or may not, work with the version from GameForge.
  13. If I understand what you are wanting to do. Is that you want to create a script that then sets up, what would be in essence, a macro key for use in the game. Yes, it is possible to do that. But, the macro key would only be available for use. As long as the script is running. With that said, what you need to do is use the Special Variables {GlobalKeyCount} & {GlobalKeys} and the ClearGlobalKey command. You can find the information for these in the AC Tool help file. If you search the forums, you might be able to find some very old topic talking about how to use the {GlobalKeyCount} & {GlobalKeys} and ClearGlobalKeys with in a script. Otherwise you will have to create a test script to experiment on how to use these to create a macro key.
  14. If you want to compare the RGB of a pixel with the RGB of another pixel. Then what you need to do: load the RGB of the first pixel save the RGB values into a set of constants. load the RGB of the second pixel. compare the RGB values with those in the set of constants.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and to our Privacy Policy.