Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
You landed the first attack on the hyeana in first level after 1548 frames counted from level start, I did in 1521 frames. WIP from 2018: User movie #45830007688951778
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
r57shell wrote:
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Here's my specialised script: User movie #51620369168057608
It outputs values to tastudio listview, sets colors, logs positions and draws them to the client screen, numpad#-key displays logged values from branch.
All functions should also be included in the team lua script.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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"
A further problem, in my opinion, with altering the factor based on time since publication is that it can still penalize active members, not just inactive ones. If any penalty to a single publication's rank took place simply due to the passing of an arbitrary amount of time, the author(s) would be penalized regardless of how active they have or haven't been on the site. That member may have gotten 300 more published TASes of other games in that time frame, but would still be penalized because they didn't update that one game. So their personal player score would still suffer even though they've been plenty active.
With the player point degrading I want do archieve exactly that, encouraging people to improve their old TASes. How long do people need to take a break in order to call the inactive? I used 6 - 7 years for time without penatly, because in that time span I would see people as active.
DrD2k9 wrote:
For current publications: every game would start with a base value regardless of game length and then the game length (while potentially exploitable) would still factor into the score Z=(length of publication in frames)/3600*(# of players)+100
I don't like using like using
movie length as a factor into the score. I have movies that are shorter and worked much longer on than movies that are longer.
DrD2k9 wrote:
Regarding obsoleted videos. As much as I don't like the idea of losing drastic amounts of experience points for an obsoleted run, I also don't think a longer run should be worth more points than a shorter run of the same game. So in the case of a run being obsoleted, I'd recommend a couple caveats.
1) If a run is obsoleted by the same author, the author only gets the points of the published run for the given branch.
2) If the run is obsoleted by a different author, the author of the obsoleted run gets the point value of the shorter run which in theory should always be equal to or lower than the published run (some obsoleted runs may actually be shorter due to publication prior to site clarification of game endpoints--in these cases, the author of the longer published run deserves the higher point value than the author of the shorter obsoleted run).
Aren't obsoleted runs usually longer or do you mean how long since the movie has been published?
To 1): It should only count if the author is current author for the branch and only the movies he/she made him-/herself are chained in a list example:
Author A 20 pts
Author A 40 pts
Author B 30 pts
Author C 30 pts
Author A 40 pts
Author A 50 pts
Author A would get 90 points, he doesn't get the additional 60 points, because his obsoletion chain was interrupted by different authors. Author B and C get 0 points.
To 2): I don't agree with that if an author gets obsoleted by a different author the author of the obsoleted movie should get player points aswell.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
ViGadeomes wrote:
But the idea of using rerecord count could be a problem too because we can't if the author increased his rerecord count value. Sometimes, I just copy-paste a big part of my TAS from an older release of BizHawk with ~4000 to a newer version of TAStudio's BizHawk and just resync it. Other time, I can take an other *.tasproj and delete a lot of his content to do a complete other movie and the rerecord count keeps rerecords of the other movie.
And I'm not sure judges will be happy to spend more time for judging a movie with the big work they have to do without it just to choose how many player points the author have to gain from a movie.
Updating to emulator version, resyncing the project and typing the rerecord number from the old file into the new file isn't an issue. And deleting lots of content from a project and not lowering the rerecord counter isn't and issue as well, the number should represent how much work you put into a project, even if you decide to restart.
It's only a little bit of work for judges. Most work would be current published movies, evaluating the tools used (pre 2012 is all non-TAS Editor/TAStudio, lua/botting started ~2009)
Stovent wrote:
I don't agree with the fact that a user without tools will do less rerecords, and I'd say it's the opposite : you cannot simply edit inputs without tools like you would do with TAStudio, because it shows your inputs and a simple click change the input, when you have to load a savestate and change all the inputs you have to manually.
It depends on user. I know many users who use TAStudio and have an rerecord count lower than non-TAStudio users, but I also know people who do the opposite. You can always edit a single frame with one rerecord, no matter which tools are used. You are stating that you can't remember your inputs after the frame you loaded; just recording input alone doesn't increase the rerecord counter.
Stovent wrote:
Also, could you give the details on what are the values for tool_usage and rerecording_behaviour, like could you give us the whole detail on how you would calculate your Kirby TAS ?
For tool_usage the idea is to not give botted TASes with >10M rerecords automatically an higher player point bonus compared to non-botted, the tool_usage value should be higher for botted runs in order to divide by a bigger number. rerecording_behaviour is more complicated to evaluate, people make different amount of rerecords in the same time span, using averages doens't work. For Kirby I'd like at least 2000 points, so I adjusted tool_usage*rerecording_behaviour to a value (100000, my average rerecord count for all my Moon movies is ~200000, but I didn't start with this value) to give me those 2000 points.
DrD2k9: See the reply to ViGadeomes.
DrD2k9 wrote:
As far as using the rank calculation system to try to encourage authors to update older runs, I don't agree. I don't think anyone should be penalized for a long lasting published TAS.
I don't want to penalize people for long lasting runs, I want them to make new movies. Inactivity should be penalized. Maybe the factor could be set back to 1 after 20 years, to account for "perfect" (not all old runs are perfect, of course) runs.
feos: I agree, and have nothing against getting rid of the concept of player points althogether.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
Currently I see two problems with the current player points calculation, these are:
•Calculations do not account for active worktime spend on a project;
•Not encouraging authors to improve their own published movies
First issue:
From all of my movies, [3226] NES Kirby's Adventure by TASeditor in 34:22.22 is the one I spent most time on, ~3 years in fact and all I get is 155 player points for it. In the same time as making the TAS for Kirby's Adventure, I also made some TASes only with a fraction of time spent on and got almost as much as from Kirby, not a small fraction. I selected some of those (4 from Moons, 4 from Vault) which have an equal amount of voters and compiled a list of how much player points I would get if I didn't do Kirby's Adventure but made TASes with equal worktime from the movies from the list, I call this Kirby Equivalent.
From that list it is noticable that if I didn't work 3 years on Kirby's Adventure, but made lots of quick projects I would have gotten at least 2000 points, even for movies that would ended up in vault. Another thing to point out is that the longer a project took to make the lower the Kirby Equivalent.
So, why would anyone be stupid enough to spend 3 years on a project to just get ~150 points, if the same person could do a project that takes a week and gives just as much points?
My idea is to account worktime of a project into player point calculations.
It wouldn't work if just the date from first WIP to submission date was taken, because projects might have breaks in it and it would mean more work for judges/publishers finding evidence for the date of first WIP and breaks. Movie lenght also wouldn't work, because not always takes a longer movie more time to make than a shorter one.
I suggest using rerecords. It gives a good estimate for active time spent on a project, the numbers wont go higher if the author decides to take a break from the project. Of course it is needed to adjust the value according to tools used (a bot makes much more rerecords than a user with TAS Editor/TAStudio and users without these tools often make less, but not always) and probably account for rerecording behaviour of author as well. And if an author decides to submit a movie with a very high faked rerecord count, the judges is encouraged to clear that out and the author would not get a bonus factor to player points. Same should also apply if someone makes a small readjustment (I wont call names out) to a movie which had a long wortime and doesn't update the rerecord count to represent his/her work. The bonus factor should only only apply to movies which are in Moons or Stars. And there should be no penalty, meaning the bonus factor should at least be 1.
The new formula could look like this: Z_movie=O*max(max(round(M-0.75+0.5)*rerecords/(tool_usage*rerecording_behaviour),1)*M*r^max(2.6-0.2*average_ratings/ratings,1)/sqrt(p), 5)
I used a tool_usage*rerecording_behaviour of 100000 for my movies which gives me 1912 player points for Kirby's Adventure.
Second issue:
The higher the amount of voters on a movie the higher the amount of earned player points. Usually older movies tend to have more a higher amount of voters.
The player points earned from an older movie should be reduced, by accounting how old the movie is. I suggest using 6 to 7 years without lowering, then start lowering but stopping at ten years at a factor of 0.5 or 0.3. By doing this the author will be more encouraged to try to update their old movies and stay engaged with the site by making new movies.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
I don't have interrest in picking up this game, I just looked for improvements on the submission, so feel free to use whatever emulator you want.
Final WIP, saves 7 more frames after first flower:User movie #47703142718125924
A rough lua for BizHawk:User movie #47703003744204809Memory wrote:
There is the possibility for a hover off the first crocodile to save time but I haven't managed it yet, so far I lose all my savings at the 2nd flower boost.
The game has a few hidden lag frames here and there, you should try to find the lag address.
Subpixels only increment, a high value also means a low value. Positions update if the subpixel overflow according to speed and direction.
E.g: From standstill the position of 32:48 gives a traveled distance to next frame of 0:16 when right is pressed, but 1:48 when left is pressed.
Landing reduces speed to 3 for 5 frames. Constantly jumping can get rid of 3 frames with reduced speed, hovering off enemies doesn't reduce speed at all.
List with addresses:
...
33C - 341 ?
342 - 347 X Direction
348 - 34D ?
34E - 353 X On Screen
354 - 359 X Off Screen
35A - 35F Y On Screen
360 - 365 Y Off Screen
366 - 36B X Speed
36C - 371 X Speed State
372 - 377 X Subpixel
378 - 37D ?
37E - 383 Y Speed
384 - 389 Y Speed State
38A - 38F Y Subpixel
390 - 395 ?
396 - 39B ?
39C - 3A1 ?
3A2 - 3A7 XY Direction
3A8 - 3AD Timer
3AE - 3B3 ?
3B4 - 3B9 State
3BA - 3BF Gravity Modifier
3C0 - 3C5 Jump Height ?
3C6 - 3CB ?
3CC - 3D1 ?
3D2 - 3D7 ?
3D8 - 3DD ?
...
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
User movie #47614647209221382
About 20f faster after first boost, most from better acceleration at the start of the stage. I need to delay some frames hitting the flower to hit the enemy, loosing 9px.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
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.
Editor, Experienced Forum User, Published Author, Skilled player
(1507)
Joined: 7/9/2010
Posts: 1317
MESHUGGAH wrote:
I would like to use the previous method to select multiple frames which was:
-select a frame with mouse left click
-shift+up to increase selection upwards
-shift+down to increase selection downwards
I rewrote that, because it only allowed extending the selection, not shrinking it.
