DanielHarrod
Overall logic of AppTest Studio?
Your app seems to be interesting. But I have some questions about its logical operations. What is its overall logic operation?
- Run from start to the end
- Each event (check if current image/point is matched) is "ONLY check 1 time" imediately: -- if TRUE (matched), go to next action/events. -- if FALSE(not matched), still go yo next action/events (the same with TRUE's result)
So, Can it suport those logical operations currently:
- Each event will be check in a specific duration (X seconds) instead of "1 time" checking, example: in 3s, 5s or 10s, ...
- Able to decide which action/event will be run at the next base on matching result: [IF TRUE -> do something], [IF FALSE -> do something] (like if-else in programming)
I think a lot of people should want that the app can controll the operation of script by steps (phase) and being able to controll which next action/event instead of running from start to end with one checking/cycle for each event. Because there are some case that user want to do different action/event based on the previouse steps althought the same screen. Example:
- case 1: rating -> homescreen of game -> receive gift
- case 2: login -> homescreen of game -> do battle.
Both above cases are have "homescreen of game", it could be hard to implement those logic if they have the same checking screen (homescreen of game).
User maybe want to complete (TRUE/FALSE) one phase (group of event/action) and only in that phase before go to the next phase...instead of runing events of all other phase and repeat. Sorry for my bad English. #question
Hi Ace-Kyle,
Thanks for your insight. Suggestions are always considered, some of the greatest improvements have come from suggestions.
A very detailed explanation of ATS functionality and how to use ATS to automate is in this playlist.
https://www.youtube.com/playlist?list=PLGVepuRQwnsIoVy6SJaZwBS5-b9AEGExs
If it didn't answer your question feel free to reply and I'll try to give you more info.
_Each event (check if current image/point is matched) is "ONLY check 1 time" immediately:
-- if TRUE (matched), go to next action/events.
-- if FALSE(not matched), still go yo next action/events (the same with TRUE's result)_
Events are by default (After Completion = Continue ) Actions are by default (After Completion = Home) You can change the After Completion.
The script travels the tree looking for True notes from top to bottom.
- Events with no criteria are considered (Groups) and are true.
- Event nodes that are true due to logic.
- Actions are always considered true.(put them under an event to control when they run)
If any nodes is true, then it uses the After completions settings.
- Continue would be go to next node,
- Back to Home - Back to the Top of the list
- Back to Parent - jumps back one level.
If an event is false, then it is automatically considered a Continue.
I would recommend writing the script so that it goes back to Home every time there's an action, for maintainability, especially in a large script. This also works nice because when an action is done, it gives the app time to update after you click a button. ---- (Don't worry, I show how to do it inline at the bottom)
Here's a startup script example. With Popups in a group, and a list of potential popups.
These popups may or may not be presented every time.
Check if While you were away is on the screen, if True -> Continue, with 0 second after wait.
Click Okay, back to Home, after wait 1 second (for the app to redraw)
_So, Can it suport those logical operations currently:
Each event will be check in a specific duration (X seconds) instead of "1 time" checking, example: in 3s, 5s or 10s, ...
Wait first means initially consider the delay before limiting.
Don't forget the Repeats button.
Every 10 seconds
Able to decide which action/event will be run at the next base on matching result: [IF TRUE -> do something], [IF FALSE -> do something] (like if-else in programming)_
There's two ways to do an else.
One is leveraging the tree, with a home
The other way is to take the if logic.
Wrap it in NOT (), or ! ( ) too it will work with: AND NOT OR ! | & ||
One the same lines use groups to check which screen your on , then organize all the nodes on that screen in one place.
In this example, I want to run the children if I have atleast Power of 5.
Lets say you don't want to write the script by using a one pass style, and want to chain.
At each event, uncheck "Use Parent Screenshot"
Now it will take a screenshot before checking.
Now set the after completion to "Continue" and the delay to 1 sec (for a screen redraw)
The downside is taking a screenshot is a slow operation compared to the logic. Logic can run 10000's of times faster than taking a screenshot.
The one pass style (recommended / defaulted) takes a single screenshot and processes it on all nodes. Put the nodes in the priority you want them to run. Such as popups first, then gameplay logic.
User maybe want to complete (TRUE/FALSE) one phase (group of event/action) and only in that phase before go to the next phase...instead of running events of all other phase and repeat.
Yea, I think I see what your saying here. If it's not addressed above... Maybe adding user defined variables that can be set to concretely exclude nodes.
But I think you can still solve this most of the time by making the Event nodes: Mutually exclusive to each other. If not mutually exclusive then prioritize them in the tree. Use limits, including session. But also don't worry about checking for something that's already happened.
In my examples above, I made all my popup nodes check for unique colors before clicking. Yes every iteration those colors are checked, but they don't fire because those colors aren't on the screen. They are still checked every iteration, but ATS runs logic so fast it's not a concern. Most computers could handle 100k nodes (pixel checking) with no problems.
One aspect of ATS is that I wanted to set the barrier to entry as low as possible. You can rapidly, visually, and interactively build extremely powerful scripts that would be very hard to code and maintain by hand.
I've implied a particular style, but didn't explain why. Think about building a script that can pick up and run at any phase not just from the very beginning. What if you started the script at the beginning, in the middle of some location, in a sub menu. Try to design it so it will work at any place at any phase.
Thanks,
Daniel
I will give a try more. I have tried (about over 1 days) to run mutiple instances of target app. AppTest Studio supports 3 type of app:
- Steam
- NoxPlayer, or BlueStack emulator
- other apps
The app I want to run multiple instance is "MEmu player" - it is a Android emulator like Nox Player as well. Its performance seems to be smoother than Nox Player. But when I try, AppTest Studio seem not to be support controll multiple instance of MEmu player and only one window (instance) is controll. So do I config uncorrectly or AppStudio support NoxPlayer and BlueStack for mutilple instance only? Thanks for any feedback.
Hi Ace-Kyle,
Thank you so much for your questions, I appreciate you insight.
This is information that was validated years ago, and may not necessarily be valid today as software can improve over time. It's been a while since I looked into this.
ATS uses window name to distinguish between running applications.
BlueStacks and MEmu have much better user experiences, more visually functional, nicer interfaces, easier to use; but automation wise they are not as good as NoxPlayer.
Bluestacks didn't have a way to distinguish between multiple instances. MEmu either I didn't test it or it didn't have a good way to launch.
At the last at the time I was investigating, MEmu and Bluestacks were single instance apps.
Nox Player had better options for automation:
- When Launching NoxPlayer you can specify the window name to use, ATS uses "ATS#Window" this is important because ATS uses the instance number to launch. So very high integration with ATS was built, and can be multi-threaded.
- NoxPlayer lets you launch at a specific resolution,
- NoxPlayer lets you pass DPI DPI Info
- NoxPlayer can accept mouse calls in the background. This is critical for multithreading.
Another aspect is repeatability and transferability. Since NoxPlayer supports 1-4, then you can send your script to someone else and your script will work on their computer with no modifications.
FYI: ATS will simply launch NoxPlayer with the name ATS#Window that way it can determine the different instances running.
I didn't test background keyboard events, with NoxPlayer, but when I originally tested keyboard, it seemed that Windows OS was not sending keystrokes to windows that were not in the foreground and activated. I will put this on my todo list to verify and validate. So essentially in multithreaded mode Keyboard wasn't tested.
Use passive mode for multihreading or just use the scheduler and run the apps serially.
NoxPlayer using Mouse Mode in Project to Passive.
Passive Mouse Mode means ATS will push the mouse events in the app event queue, and simulate a click. Essentially tell the app there was a click even though there really wasn't a click. Works with android emulators and web browsers, but some apps don't use the windows event queue for processing... Thus Active Mouse Mode is needed.
Active Mouse mode means ATS will move the system mouse to the specified window(optional) then move the mouse to the specified location on that window that you specify in the logic, and then perform a click.
And then this Nox Instances that are installed or found, in this example I have 4 with different google accounts on each one.
Most of the development of ATS was with NoxPlayer.
ATS only multithreads in the designer with NoxPlayer. To multithread with other apps, the scheduler would need to be used.
Keep in mind that some apps simply do not accept input in the background, but NoxPlayer does. Most of your AAA AAAA AAAA games ignore input when they are not the foreground / active window. some of the idle games will process background events, but alot don't.
Something not mentioned, is if you make the scripts robust enough, you can just schedule them to start at certain times and build in logic to quit. Such as add a limit to quit after 20 minutes of playing. And then schedule for morning, noon and evening. But don't play 24/7.
Thanks,
Daniel