Post by Bisqwit

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

Posted: 11/19/2006 4:28 PM

Quote

Bisqwit

Editor, Active player (296)

Joined: 3/8/2004
Posts: 7469
Location: Arzareth

Pretty cool!

Posted: 11/19/2006 4:35 PM

Quote

Master_of_Puppets

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

Posted: 11/19/2006 4:46 PM

Quote

qFox

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

Posted: 11/19/2006 5:35 PM

Quote

qFox

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

Posted: 11/19/2006 5:50 PM

Quote

Bisqwit

Editor, Active player (296)

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.

Posted: 11/19/2006 6:05 PM

Quote

qFox

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

Posted: 11/19/2006 6:23 PM

Quote

Bisqwit

Editor, Active player (296)

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]

Posted: 11/19/2006 6:36 PM

Quote

qFox

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

Posted: 11/19/2006 6:41 PM

Quote

Master_of_Puppets

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.

Posted: 11/19/2006 6:46 PM

Quote

Baxter

Skilled player (1402)

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.

http://tasvideos.org/Baxter.html

Posted: 11/19/2006 7:04 PM

Quote

Bisqwit

Editor, Active player (296)

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.

Posted: 11/19/2006 7:12 PM

Quote

qFox

Joined: 4/25/2004
Posts: 615
Location: The Netherlands

Then it is decided :) Grav 32 for teh win

qfox.nl

Posted: 11/19/2006 8:21 PM

Quote

Master_of_Puppets

Joined: 10/31/2006
Posts: 134

well then could I use your bot to make my own 1-shot run for my personnal enjoyment?

Posted: 11/19/2006 9:07 PM

Quote

Bisqwit

Editor, Active player (296)

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.

Posted: 11/19/2006 9:51 PM

Quote

Bisqwit

Editor, Active player (296)

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.

Posted: 11/19/2006 10:37 PM

Quote

qFox

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

Posted: 11/19/2006 11:26 PM

Quote

qFox

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

Posted: 11/20/2006 12:10 AM

Quote

qFox

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

Posted: 11/22/2006 6:36 PM
(Edited: 1/23/2022 9:42 PM)

Quote

Bisqwit

Editor, Active player (296)

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.

Posted: 11/22/2006 9:50 PM

Quote

qFox

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

Posted: 11/25/2006 12:54 AM

Quote

qFox

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

Posted: 11/25/2006 5:39 AM
(Edited: 1/23/2022 9:43 PM)

Quote

Bisqwit

Editor, Active player (296)

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.

Showing items [26 - 50] of 89

1 2 3 4