Joined: 10/31/2006
Posts: 134
tried setting the angle adress to 163 and frame advancing to power 255 on grav 5, but didnt get same outcome as you.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Thats odd... The bot is coded to press A when speed is FF Perhaps this results in speed being FE...
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
grav 1, speed FF (or perhaps FE), angle 181 and 245 and 247 it looks as if you get a clearance score of 910 (from balls) every time. For the first table anyways. There's a bonus-system that increases as you go along making consequtive scores. oh and maybe there is some kind of random factor. my bot chooses to change angle by left or right depending on whats closest (uses the attempt counter as angle), but when trying the 181 right now it used the other way to get to that angle. suddenly it didnt clear (where-as it did when i fixed this). It may not make sense but bottom line is, it appears that how you do things does effect the outcome. So I'm guessing there is a random factor after all.
qfox.nl
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Pretty cool!
Joined: 10/31/2006
Posts: 134
Yeah speed becomes FE after the shot, since this memory adress hold the speed of the cue ball after its being shot, so Its gradualy decreasing. FE cant be achived through frame advancing as you probably know.. it goes from FC to FF
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Oh, no I didn't. But if you press A when it's FF, you have the same effect as my bot and it should do the same. I'm checking out how to detect a "next level" screen because I'm having a hard time determining when I cleared the table (but with the score computed). I'm doubting whether you can actually make a perfect clearing on each table...
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Man, it sux that there's a desync bug in my botcode when doing it by part. I implemented some code that could do a game by doing small parts in sequence. However, for some reason it desyncs when linking the computed parts. Even though I can't think of why since it uses the same saving and loading mechanics as a player would. If it wasnt desyncing, i could've let it comute the entire game overnight :D Some day I will though, but since I can't determine the cause of it and don't know whether it's FCEU's legacy code's fault, or mine, I'm not very eager to look for something that may not be there and to fix it right now.
qfox.nl
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Apparently the positioning of the aimer matters after all. I coded a bot, and it reported that at friction 1, angle=48 speed=255 results in five balls pocketed. I tried that input, but it didn't work. The cue ball was pocketed instead. The bot sets those angles and velocities by poking the RAM directly, to save time. Then I did various tests, using a RAM watch to do various shots at angle=48, speed=255. It turned out that the distance of the aimer from the ball, affected whether the cue ball will be pocketed or not even when the angle and velocity match. I was however able to duplicate the result by setting up cheat code to poke those values without adjusting the aimer manually, then press B, and remove the cheat codes, allowing the RAM addresses to change.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Hm On a sidenote, I never really thought of poking stuff to speed things up in a bot. Not sure whether it's applicable anyways, but I'll think about it when I continue the project. Do you know how the distance of the aimer affects the shot? Further means harder/softer? Or what... Because that may be very interesting. There's a very quick clearance for level 2 on grav 1 btw.
qfox.nl
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Okay, got mine working now as I gave up the RAM poking. Doing a test run without aimer distance adjustments. The scr{Begin,FinishV,ReturnV} stuff in this code is due to cothreading/coroutines. The run() method is called every frame, but it is written as if it calls the emulator, not the other way around. It is a shame C++ doesn't support coroutines by default. Example output:
ang[ 30]velo[204][ 45; 91]Record: Pocketed 1 (time 299, angle 30, velo 204)
ang[ 30]velo[192][ 45; 87]Record: Pocketed 1 (time 295, angle 30, velo 192)
ang[ 30]velo[180][ 45; 83]Record: Pocketed 1 (time 291, angle 30, velo 180)
ang[ 31]velo[255][ 46;108]Record: Pocketed 2 (time 351, angle 31, velo 255)
ang[ 43]velo[ 15][ 58;189]
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
We need to agree on a grav though. Grav 1 will make for a lot of perfects but slower (as mentioned before). I do think that the perfects are more fun to watch, as well as the score that'll skyrocket. I've put logging on my todo list for the project. My bot saves and shows (like .16) only the best, and I've added the last as well, to evaluate visually. Oh Bisqiwt you may wanna up the frame-limit. Depending on when you stop counting, it can last quite a while. Here's my first two levels: http://phil.uu.nl/~zee/qfoxlunar2.avi http://phil.uu.nl/~zee/qfoxlunar2.fcm
qfox.nl
Joined: 10/31/2006
Posts: 134
If you dont modify Length it, its fine, but do keep track of it, cause if I remember well, if you change you angle and the cursor become in contact with the sides of the table, the L is automatically reduced to keep the cursor inside the table. So turning the angle clockwise instead of counter-clockwise could give different Length value. (Hope you understand what I'm trying to say, English isnt my native language) Edit: Forget that.. just tested it, and it doesnt reduce the length to keep it inside the table.. I must've been thinking about another game.
Skilled player (1410)
Joined: 5/31/2004
Posts: 1821
qfox wrote:
Here's my first two levels:
I don't like the 1 friction. It seems like it's easy to finish the levels with one try (even though it's probably not)... and it's not (I think) how everyone remembers the game (at least I never changed the friction settings). I'd be much more interested in a movie which plays the default settings. Edit: Also, like you mentioned will this make the movie a lot shorter probably, which is a good thing, since the score counter will go beserk eventually anyway.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I also think that the default friction should be used. Friction 1 is fun for playing, but the minute-long travel paths make the results rather random, and not quite impressive.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Then it is decided :) Grav 32 for teh win
qfox.nl
Joined: 10/31/2006
Posts: 134
well then could I use your bot to make my own 1-shot run for my personnal enjoyment?
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Master of Puppets wrote:
well then could I use your bot to make my own 1-shot run for my personnal enjoyment?
There's the source, go ahead. You will need to adjust it, because it depends on a framework that only exists in my personal version of fceu, tailored to my needs and preferences. Shouldn't be too difficult though.
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Now that I analyze it again, it doesn't seem like the aimer distance affects anything after all. Weird.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
In case you were asking for my bot, I've compiled my last version. I included the docs for the bot and two examples (including the lunar pool file I was working with). The pool file needs work though, seems to screw up when you change X. Bla. Get it here: http://netload.in/datei2bcf7f3b7e31c57786b59cad6b95b217.htm
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Bisqwit wrote:
Now that I analyze it again, it doesn't seem like the aimer distance affects anything after all. Weird.
It seemed like a visual indicator anyways, but I didn't investigate. Oh and the botfile for pool was indeed borked. Trying to fix it, but I'm still having trouble finding a way to determine the end of one shot :( Especially now that perfect shots are out...
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I've found it. Byte 0x00 helps to the rescue! It's 0x10 on startup, then 0x20 on the selectscreen going to 0x00, stays 00 till you can start playing, when it's waiting for a shot its 0x08 and while a shot is playing its 0x07. The key here is that when it's done, it'll be 0x18 for one frame. This is what I check for. This doesn't apply for level-completion. I simply check the level-number for that, whether it has increased.
qfox.nl
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Here's BisqBot's first nine levels. It seems to be quite proficient in playing Lunar Ball now. My part in the making of this movie only consists of the startup menu and adjusting cursor distances for fun (besides creating the bot). However, the score tallying is beginning to reach ludicrous lengths... if this run would be published when finished, it would certainly need a tag "ignores delays caused by bonus effects". https://files.tasvideos.org/bisqwit/bisqwit2-lunarball-incomplete.fcm https://files.tasvideos.org/bisqwit/bisqwit2-lunarball-incomplete.avi It uses no look-ahead; just optimizes each shot at a time without caring where the balls end up for the next shot.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
rofl, or perhaps "misses shots to save time, a lot of it" :p This game may make an interesting speedrun after all... And I cant' say that waiting for all those points makes a very interesting run either... Have you tried pressing a button to see whether the score will just jump to the end? That works on a lot of games... I still have to check whether distance of the cursor makes any difference.
qfox.nl
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Bis are you still running it? I think trying to aim for fastest completion time will remain and the run will include "misses shots to save time". You can miss shots to line up for a better shot as well...
qfox.nl
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
qFox wrote:
Bis are you still running it?
Yes, for fun. Here's another WIP. The URLs are the same as in the previous posting, but the files are updated. https://files.tasvideos.org/bisqwit/bisqwit2-lunarball-incomplete.fcm https://files.tasvideos.org/bisqwit/bisqwit2-lunarball-incomplete.avi (17 MB) It completes now 27 stages of the 60. The length is a whopping 29 minutes. By average, each stage is completed in 62 seconds. Of this, 35 seconds are spent aiming and moving the balls, and 27 seconds accumulating the score. Its best shot so far is 5 balls pocketed at once in stage 11. The same is also accomplished in stage 20. No one-hit KOs. I like the tidiness of the stage 17 solution.
qfox wrote:
I think trying to aim for fastest completion time will remain and the run will include "misses shots to save time". You can miss shots to line up for a better shot as well...
Yes, I'm adjusting the algorithm to do some of this. It seems to be the better choice. However, it'll mean that instead of completing 3―8 stages per day, it would take... umm, 3.5 years to complete one stage. Still needs refinement.