Hi, I'm writing a huge lua script for analog stick automation. Some significant progress have been made so far, but there're still many things to do. Currently it's only "usable" for N64 and TAStudio. The main point of the script is that the user draws the path in a canvas and sets conditions wheter a button should be pressed, the user then clicks the start button and waits until the script is finished.
If someone want's to help, please don't hesitate. The GitHub repository is here.
Here's a video showing the script in action in it's current state (updated to latest built from 21.12.2018):
Link to videoAs noticable it only follows the path very roughly and in one case even attempts to go back to a point it already bypassed.
Read the readme on GitHub if you're interressted on how to use it.
Functionality for calculating the stick coordinates:
It uses a line drawing algorithm, which is more accurate than calculating the values with trigonometry with integers. Incrementing and decrementing the stick angle also uses this algorithm. There probably isn't a better way to do it.
Point when player starts moving to next waypoint:
It makes the vector line equation L: X = A + l*(B-A) , where A is the start point, B the goal, X the current player position. Solve the equation for l and check if l >= 1 then set next waypoint in list as the goal. As seen in the video this mehod is flawed.
TODOs:
• Unspagghetize the code, sorry I'm a bad coder.
• Remove the logic of toggling read+write mode and set playback, use TAStudio lua input functions when they come, if ever.• Iterate through TAStudio selection when incrementing/decrementing input angle. Increment/decrement the angle for each selected frame individually. Don't use the current method of setting playback courser and then playback to the last frame, wait until there's proper support for TAStudio lua input.• Fix input angle increment/decrement locks for x/y=+-2, x/y=+-1/2. Are there more locks?• A way to set if the stick coordinate calculation for a frame should be ignored. It uses the ones that already were there.
• Implement Pause() function properly. Pressing the Pause button should save current frame number, current waypoint goal, current waypoint list and current input (as saving a branch). The script then should stop calculating any input. If the user then clicks the Pause button again, it should set the saved variables and continue from the point when it was paused.
• Fix dragging a waypoint. Right now the focus jumps to another point if two point the mouse courser moves over another point.• Implement zooming for the canvas. I did some tests, but it didn't draw the lines properly. Use mousewheel (doesn't work outside client window yet)
• Fix zooming: Zoom into point where mouse courser is pointed at.
• Implement undo for deleting waypoint and moving waypoint.
• Canvas right click context menu for the waypoint operations.
• Insert new point for splitting path at the yellow highlighted line segment.
• Saving and loading waypoint lists, also save them on disk and connect them to branch saving/loading.
• Make a table/list in the main form of the waypoints list for viewing and editing points of the waypoints list. Content of that table/list should be: Index; X position; Y position; Global angle between current point and the next point; Angle between the lines of previous point to current point and current point to next point; Lenght of current point to next point.
• Make canvas accessible for other scripts. For level images and collision maps.
• Multiplayer support.
• Improve the path following algorithm. The player coordinates should be always as close as posible to a line. If the angles are very tight, curve the path instead.
• Setting control stick radius for each waypoint individually.
• Add Circle segments and bezier curves as trajectory to follow.
• Make the game object (position, hitbox) variables from other scripts accessible for this script, so the user can do "Go to object".
• Improve the above and recalculate waypoint depending on the hitbox radius of player and objects, see here what I mean.
• Setting conditions if buttons should be pressed or not (i.e. auto-jumping), asign multiple button combinations to test; Set if a waypoint should be ignored under specific conditions, stop ignoring the waypoint if the condition becomes false. These are also drawn into the canvas, more specifically on the lines between waypoint. For example the player goes from A to B and there's a wall in between which the player can jump over, the user will set a "point" or a region (point is a region, the player doesn't need to be exactly on the point) with the condition "if on ground then press A for n frames". If the script then comes at this point it automatically presses A. The user can also specify if n is a constant or not. If the user has set a region it will test different frames to start pressing A.
The TODO list is in no particular order, but the harder stuff should be at the bottom, maybe some is to hard. That should be it for now, maybe I missed something. There might be more TODOs coming in the future.
Edit:Added some TODOs
Edit: Some things done and I updated the readme file on github.
Edit: Some things done and new video.
That's an amazing demonstration !
I had no idea you can do all that stuff with just LUA, that could become quite a powerful framework for longer 3D games. The tracking algortihm could always be improved, I think that's a small part of the puzzle compared to getting the rest of the infrastructure working.
I'll be watching progress on this with great interest, good luck!
I made some little progress with the script as I added lua input functions for TAStudio to Bizhawk. Now the script no longer requires toggling between read+write and read-only modes. Also the bug with not catching the next waypoint was fixed and some massive time inprovements in the line drawing algorithm. And some clean-ups.
Zooming now works and I added function for branch operations (still have to do the one for deleting branches) and added files that get save/loaded with branch operations. Bottom of the canvas now has items to click on to do reset view, zooming, etc. Reassigning input by ungreenzoning now works as well.
I added some tests for a canvas API for other scripts. Values get into shared tables, player and camera stuff works just fine, but for objects the AutoAnalogInput script doesn't use the variable I set from the game script.
Can someone please help with this issue, I added files for the game I use for testing into the Github rep.
Fixed angle locks; added follow player toggle function; when editing path it jumps back to the previous of the edited point if current point is greater than edited point; saving current waypoint into files; clicking on points in view mode jumps to that point.
I added right-click functionality, only adding a waypoint and deleting all waypoints yet.
And a reminder that YOU are always allowed to help out. <3
Some simple (hard enough that I'm to stupid to do them on my own) things to implement/fix would be:
Zooming: If the player is not being followed zoom into where the mouse courser is or into the center of the window if the status strip buttons are used.
Renaming files after deleting a branch: E.g.: There are 5 branches and the user deletes the 3rd, the 3rd would be renamed to -1, the 4th to 3, and the 5th to 4.
Images for status strip buttons: 15x15px. Make images for "toggle follow player on/off", "reset view to player", "view next/previous/current waypoing", "zoom in", "zoom out", "reset zoom", "display objects on/off/auto", "display map on/off/auto"
Now it's possible to display objects and level collision on the canvas.
And frames to ignore input calculations can be set.
Renaming files after branch deletion now works as well.
I updated the readme file on GitHub repo for better usage.
I added some basic functionality for automatic button presses. Right now it only works with relative position between two waypoints (value between 0 and 1), and it gets removed from the list after setting the button.
Right now the buttons can be applied from the "Insert Button" on the Window, but in the future this will be moved to the canvas. The buttons will be applied to the red cross on the line between two waypoints, it'll appear if the mouse courser is near the line.
Disclaimer: I didn't try your script, and I don't planning to.
TASeditor wrote:
Functionality for calculating the stick coordinates:
It uses a line drawing algorithm, which is more accurate than calculating the values with trigonometry with integers. Incrementing and decrementing the stick angle also uses this algorithm. There probably isn't a better way to do it.
Line drawing algorithm is actually also calculating values with integers.
I don't know why do you use it here, probably because you didn't define the problem.
Also, your line drawing implementation is running unused code.
TASeditor wrote:
Point when player starts moving to next waypoint:
It makes the vector line equation L: X = A + l*(B-A) , where A is the start point, B the goal, X the current player position. Solve the equation for l and check if l >= 1 then set next waypoint in list as the goal.
IDK what approach do you use, but there is simple one, it is called dot product.
Just calc l = (X-A, B-A)/(|B-A|*|B-A|) where (v1,v2) is dot product. You can verify it for example in desmos.com/calculator (just piece of awesomeness). But it would allow point to be not on the line, so you also need to check is it on the line. To do that, calculate d = [X-A, B-A]/|B-A|, where [v1,v2] - is cross product, and d = distance to the line.
TASeditor wrote:
• Fix zooming: Zoom into point where mouse courser is pointed at.
Lifehack:
1) Remember point where cursor is aiming at.
2) Just zoom somehow
3) Parallel translate everything in a way that remembered position will match current aiming poisiton.
TASeditor wrote:
• Add Circle segments and bezier curves as trajectory to follow.
To me, it looks kinda strange. You're telling how to move to character, instead of making him move optimally from point to point. For example, imagine you tell character to move along circle with slightly smaller/bigger radius than character would move naturally. So, it would zig-zag along this circle because he is either too close to center, or too far from circle itself. On the other hand, in racing games you tend to select any path that has most speed and fitting inside borders. Same can be used in games like Doom etc. I know they don't use analog stick though.
Regarding to just code: you use atan2 a lot. I guess you can get rid of that. Most of trigonometry stuff can be done without it.
Also I would recomend to make local shortcuts to abs, atan2, floor, etc. You may compare performance with it.
But don't optimize things too early. No reason to take effort to optimize code that will soon be deleted.
Main problem: idk how much this code is reusable for different movement game mechanics. What is really good is: drawing stuff is reusable for sure :)
TASeditor wrote:
i want to cry, why does nobody help with this :(
Perhaps required skill level is too high.
I can help with some geometry, with some optimization problems, but not beyond that.
Line drawing algorithm is actually also calculating values with integers.
I don't know why do you use it here, probably because you didn't define the problem.
Also, your line drawing implementation is running unused code.
I know that it is with integers, but it doesn't use trigonometry.
The line drawing algorithm is used to set the analog stick position. Think of drawing a line on a 256x256 grid from origin to the edge with the optimal input angle an then finding the integer position on the grid which is closest to the line. Doing it with trigonometry didn't gave good enough results.
I'm not seeing any unused code.
r57shell wrote:
Lifehack:
1) Remember point where cursor is aiming at.
2) Just zoom somehow
3) Parallel translate everything in a way that remembered position will match current aiming poisiton.
Well, I know that it zooms into where the (xFollow;yFollow) point is.
r57shell wrote:
TASeditor wrote:
• Add Circle segments and bezier curves as trajectory to follow.
To me, it looks kinda strange. You're telling how to move to character, instead of making him move optimally from point to point. For example, imagine you tell character to move along circle with slightly smaller/bigger radius than character would move naturally. So, it would zig-zag along this circle because he is either too close to center, or too far from circle itself. On the other hand, in racing games you tend to select any path that has most speed and fitting inside borders. Same can be used in games like Doom etc. I know they don't use analog stick though.
I mean, why not? With the current method of going from point to point the character loses speed when doing very sharp turns. Or maybe just letting the character move a circle while needing to wait.
The character also zig-zags along a straight line, I don't see how zig-zagging along a circle would be a problem, this is expected. Of course the amount of zig-zagging needs to be minimized.
r57shell wrote:
Main problem: idk how much this code is reusable for different movement game mechanics. What is really good is: drawing stuff is reusable for sure :)
I plan to eventually do custom behavior scripts, so users can code game specific movement functions. Use physic variables like acceleration, drag and max speed from the game for the movement calculation. And auto-detect obstacles on the way and jump over them or move around and other things like that. But that's for the future.
r57shell wrote:
TASeditor wrote:
i want to cry, why does nobody help with this :(
Perhaps required skill level is too high.
I can help with some geometry, with some optimization problems, but not beyond that.
The line drawing algorithm is used to set the analog stick position. Think of drawing a line on a 256x256 grid from origin to the edge with the optimal input angle an then finding the integer position on the grid which is closest to the line.
Sort all candidates by angle, and then just binary search in it.
TASeditor wrote:
I'm not seeing any unused code.
Sorry, my bad. I thought best is not used, but now I see it used for restricting candidates.
TASeditor wrote:
r57shell wrote:
Lifehack:
1) Remember point where cursor is aiming at.
2) Just zoom somehow
3) Parallel translate everything in a way that remembered position will match current aiming poisiton.
Well, I know that it zooms into where the (xFollow;yFollow) point is.
Probably you don't get what I say. What I say is actually formula in very simplified way. Third step is just: calc difference between where you was pointing, and where you're pointing now, and then multiply/divide by scale.
TASeditor wrote:
The character also zig-zags along a straight line, I don't see how zig-zagging along a circle would be a problem, this is expected. Of course the amount of zig-zagging needs to be minimized.
Depending on how character moving, you can or can not optimize zigzaging straight ahead. For example, if he is constantly adding some vector with fixed precision value, you should better apply one stick position during whole segment. In a bit worse mechanics - you need to pick exactly two stick positions and then: first poistion for n frames, and second position of stick for all other frames. But if camera position affecting stick effect, then it's not simple anymore. In that case I don't think walking along is best way, but at least it's good first approximation.
TASeditor wrote:
r57shell wrote:
Perhaps required skill level is too high.
I can help with some geometry, with some optimization problems, but not beyond that.
My programming skills aren't very high either.
Having any programming skills is already high level.
Thanks to r57shell, I fixed zooming.
Button insertion points can now be moved around, and I added some basic macro file system. Macros are added from a text file (name;text;button;amount\n) when the script loads and are accessible from right click menu on a line.
Right now the macros are very simple, but I plan to make it possible to make more complicated macros, including variable dependend macros. And instead of only points, which are bound to a line, where to insert the button, I want to make button insertion "fields" (polygon). Only if the player is inside the field buttons will be inserted. Also making it possible to set conditions if a button should be inserted, i.e. not inserting A buttons if the player is in mid-air.
