Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
So you have just worked 2 month on this cup, the last one will also take about that long to make then, so why don't you finish all 3 cups first before submitting?
There's no reason, you aren't lazy either then you would needed more time to do the run. It's probably just the philosophy of streamers to produce as much content in little time as possible to get attention.
submission text wrote:
I have to say, that I believe the reason why no TAS has ever been produced of this game in a full league, is the extreme dedication that it takes in order to produce high quality times.
2 month work for a 11 minute long hard to make run sounds like a joke to me, but it's only me so others see it different.
Do I find it entertaining? Yes.
Do I want it published? No. Submit a file that completes all 3 cups. And don't come with "long runs are hard to watch", it's illogical, some people would be entertained by watching paint dry others would find 40 minutes of F-Zero entertaining, and you shouldn't focus on pleasing your audience, your first goal is to make a TAS of good quality. And there isn't anything that would stop the viewer from pausing the video an continue watching later, if they're mentally unable to do so, hands down, you then made a very entertaining run.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Point me to the files where I can find player and camera structs memory addresses. I don't care about stroop or sm64, I only use this game for testing my script because it has angles other than float and the ram map should be well known by now so I don't have to search for my own.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Can someone provide me memory addresses of the player and camera struct (positions, speed, acceleration, etc.)?
The ones I found have only basic stuff.
I tested my input script and the angles seem very unprecise. In the script are many more things wrong, don't use it.
See here: https://youtu.be/mMqwVekr0Ak The lines are twitching to much and I don't know if there're special conditions for the control stick for this game that would make an optimal solution of my script unoptimal.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Timestoppa wrote:
I'd hate to TAS the N64 with a TAStudio like thing
That's why you wait for TAStudio lua input, faster and more precise to set analog stick coordinates than any other method. If you're noob and don't bother ultra-optimizing your movement then you might not find any difference, my N64 WIP has 40k (sic) rr's for 10 frames and it still is suboptimal, due tastudio being a total disaster when it comes to setting analog stick, with lua it can be reduced to 20 rr's for a frame to test. TAStudio is nowhere close to support a good method for TASing platformers which use analog sticks, neither is mupen, the traditional method in BizHawk is if you know lua.
KnucklesMaster368 wrote:
1. When I want to copy a level, input for input over from a previous TAS. When I did this, it took 2 hours.
Was it your first time doing this? Routine speeds up your workflow.
KnucklesMaster368 wrote:
I just find TASeditor too slow to work on, and I can't work at the speed I can with just my trusty USB controller with 5 savestate slots.
That is because you don't know how to use it, every one has trouble using unfamiliar software for the first time, and so did I. The only game you worked on was VS SMB? You might not see benefits by TASing a simple game, but try out one where complicated input patterns are needed. And please read if you haven't already: http://www.fceux.com/web/help/taseditor/ If you already did you can read again, maybe you already forgot things.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Don't bother with the rules from speedrun.com, they're useless. And the branch "100%" is idiotic, this is a game where subgames loop forever. There's no percentage counter or anything that would mesure progress.
Randomness is seeded on title screen, by pressing different combinations of A,B,S,T when selecting the subgame, while the subgame is loading only A,B affect RNG. This run doesn't do this.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Managed to clip to the corner in the second room to the right while testing stuff, but then guy fell down and I wasn't recording. Both walls are exactly 90°. So skipping first world is somewhat more reachable, if the guy doesn't fall down after clipping. Other methods that would skip world 1: Save+quit, has the stone door open in the beginning but closes, unsucessful with walking under it; glitch out spitting out enemies, so speed modifier is set to 0.5 or higher, glitched mode needs to stop in order to use Z, or just walk trought the wall.
Here're some notes about various things: https://pastebin.com/zmRTibA9
I did some shitty test of first room and was about 90f faster, didn't use any speed locking of course.
Edit: A gif showing speed locking: http://imgur.com/PfMN6tg
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Dagging Marker+right click:
System.InvalidOperationException: Das Objekt mit Nullwert muss einen Wert haben.
bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
bei BizHawk.Client.EmuHawk.InputRoll.DrawCellDrag(PaintEventArgs e)
bei BizHawk.Client.EmuHawk.InputRoll.OnPaint(PaintEventArgs e)
bei System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
bei System.Windows.Forms.Control.WmPaint(Message& m)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
